• Client-Side Caching
• Server-Side Caching
• Content Delivery Network (CDN) Cache
• Page Cache
• Opcode Cache
• Object Cache
• Database Cache

Client-Side Caching

Browser caching

• Local Storage
• Session Storage
• IndexedDB
• Web SQL

Server-Side Caching

• Redis, memcache.
• File cache.

Content Delivery Network (CDN) Cache

Cloudflare, Cloudfront AWS, Cloud CDN.

Page Cache

Users specify:

• a map function that processes a key/value pair to generate a set of intermediate key/value pairs, and
• a reduce function that merges all intermediate values associated with the same intermediate key.

Threading programming: task manager, delivery task to worker on thread pool, after worker done, get more to execute. Until done.

MapReduce vs Spark

The primary difference between MapReduce and Spark is that MapReduce uses persistent storage and Spark uses Resilient Distributed Datasets

Spark: Support real-time streaming. Lesser line code. Features API In-memory rather disk write.

Ref: white paper by Google in 2004

• Layered pattern
• Client-server pattern
• Master-slave pattern
• Pipe-filter pattern
• Broker pattern
• Peer-to-peer pattern
• Event-bus pattern
• Model-view-controller pattern
• Blackboard pattern
• Interpreter pattern

Layered pattern: for desktop app, e-commerce web app

• Presetation layer
• Application layer
• Business logic layer
• Data access layer

Client-server pattern: email, docs sharing and banking

Master-slave pattern: database replication, Peripherals connected to a bus in a computer system

Pipe-filter pattern: Compilers, Workflow

Broker pattern: Message broker queue,

Peer-to-peer pattern: File-sharing networks, Multimedia protocols

Event-bus pattern: Android development, Notification services

o	event source, event listener, channel and event bus
o	Listeners subscribe to particular channels.

Model-view-controller pattern: For web app

Blackboard pattern: Speech recognition, Vehicle identification and tracking, Protein structure identification

o	Blackboard
o	knowledge source
o	control component

Interpreter pattern

o	Database query languages
o	Languages used to describe communication protocols.

Ref: https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The agile industrial complex. Everyone know agile, but really?

Many argue that “faux agile,” as it’s also called, and its evil twin “dark agile,” are exacerbated by the monetization of agile education and consulting.

“There’s cargo cult agile where you’re doing and saying the right things, but you don’t understand the fundamental principles. You’re not getting the results,” Buchanan said.

Call it “faux,” “dark,” or “cargo cult,” these agile subversions often lead to situations that fly in the face of the Manifesto’s intentions—micromanagement, burnout-rate pacing, lack of delivery, and adherence to process over principles register as the most egregious—even if their practitioners come with a certificate. Unfortunately, these dark agile experiences cause some people to swear off agile altogether, (or rewrite it to reflect their real-world experience with it.)

What does it all mean?

So, the agile principles existed before the Agile Manifesto. People applied them to software development. Those values were captured in the Agile Manifesto. Then, people took the Manifesto’s principles and started applying them to their own work.

“In a lot of ways, the Manifesto is a basis of a conversation,” Wortham said. “Here’s how I interpret it. How do you interpret it? All right, let’s figure out how to work together.”

Ref:

• The Twelve Principles of Agile Software
• https://www.atlassian.com/agile/manifesto

This process often involves a set of activities including:

• Requirements elicitation: getting business requirements from relevant stakeholders to understand user needs;
• Requirements documentation: codifying that information in the form of user stories and feature specifications so they are accessible to the project team;
• Requirements understanding: making sure everyone’s on the same page about what the heck you’re all trying to build.

1. Establish project goals and objectives early

Simple: does it help accomplish a goal, or does it satisfy an objective?

2. Document every requirements elicitation activity

When you’re in the midst of stakeholder interviews and documentation review, you can often feel like you have a great grasp on things.

But then a week goes by,you realize you don’t quite have a full grasp of your business requirements.

You’ll see in #3…

3. Be transparent with requirements documentation

Sure, you understand the requirements. And your stakeholders understand the requirements. But do your stakeholders understand your understanding of the requirements?

This transparency not only helps make sure everyone’s on the same page, it fosters a sense of project buy-in all the way through your project, beginning with the business requirements. And it circumvents the issue of someone saying “hey, you agreed to X but it’s not here!” 6 weeks into the project. If it’s not in the notes, it didn’t happen.

4. Talk to the right stakeholders and users

A project can often have “hidden” stakeholders. Ask probing questions in your kickoff and initial meetings to try and get to who the real users are. Often those people are not going to be the main decision-makers, but their buy-in is essential to a successful project.

Disgruntled users who are forced to use a system every day that was designed without their input are a key ingredient for a failed project.

5. Don’t make assumptions about requirements

The devil truly is in the details, but you can catch him by the tail if you ask a lot of questions and don’t rely on assumptions.

6. Confirm, confirm, confirm

This ties into “be transparent” but is not entirely the same thing. Just sharing your notes with a stakeholder is great, but far more valuable is actually having a quick review with them and getting their official sign-off.

This is true for meeting notes, user stories, diagrams, wireframes, really any kind of requirements artifact that you are creating. Get actual confirmation from your stakeholders that you are representing the requirements correctly in whatever format you’re using, then move on.

7. Practice active listening

Don’t assume that you’re always getting the whole story – listen for little cues that reveal pain points, desires, unstated goals, and assumptions.

8. Focus on business requirements, not tools

Focusing on and listening to what your stakeholder needs, not what your tool-of-choice happens to do best.Remember: requirements are about the WHAT, not the HOW.

9. Prioritize your product features

In an agile methodology, we work towards a Minimum Viable Product (MVP), that would count as a successful product at launch.

10. Remember that you didn’t get everything

Even the best requirements gatherer is going to miss things. Why? Because you and your stakeholders are human beings, and human beings make mistakes. You will think of things later that you forgot to ask. Your stakeholder will think of things that they forgot to mention. Things will change. Priorities will shift.

Ref:

• https://www.phase2technology.com/blog/successful-requirements-gathering

Architectural Constraints

REST defines 6 architectural constraints which make any web service – a true RESTful API.

• Uniform interface
• Client–server
• Stateless
• Cacheable
• Layered system
• Code on demand (optional)

Uniform interface

Define resources: e.g. api/users for (website, mobile app, other services)

There are 4 guidelines principle:

• Resource-Based: EX: API/users.
• Manipulation of Resources Through Representations: Client get user id and then delete and modify resource based on that user id.
• Self-descriptive Messages: URI + HTTP methods + data as json
• Hypermedia as the Engine of Application State (HATEOAS): Include other links for each response, so client can discover more other resources easily.

Client–server

Client application (Mobile, Front end Angular) and server application(Back end) MUST be able to evolve separately without any dependency on each other. A client should know only resource URIs, and that’s all.

Stateless

The server will not store anything about HTTP request.

Advantages:

• Scaling by deploying multiple servers. Because no session related dependency.
• Less complex – by removing all server-side state synchronization logic.
• Easy to cache.
• Never loses track, because the client sends all necessary information with each request.

Cacheable

A well-managed caching partially or completely eliminates some client–server interactions

Layered system

An application architecture needs to be composed of multiple layers. Intermediary servers may improve system availability by enabling load-balancing and by providing shared caches.

Code on demand (optional)

return executable code to support a part of your application, e.g., clients may call your API to get a UI widget rendering code.

“Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we settled on the name Dependency Injection”.

Patterns are all about removing dependencies from your code. Callbacks

Related: Event-driven programming, the event loop and dispatch of events/messages is handled by the framework

Is programming principle which one of SOLID principle?

The term is related to, but different from, the dependency inversion principle, which concerns itself with decoupling dependencies between high-level and low-level layers through shared abstractions

Creational design patterns

These design patterns are all about class instantiation. This pattern can be further divided into class-creation patterns and object-creational patterns. While class-creation patterns use inheritance effectively in the instantiation process, object-creation patterns use delegation effectively to get the job done.

• Abstract Factory: Creates an instance of several families of classes
• Builder: Separates object construction from its representation
• Factory Method: Creates an instance of several derived classes
• Object Pool: Avoid expensive acquisition and release of resources by recycling objects that are no longer in use
• Prototype: A fully initialized instance to be copied or cloned
• Singleton: A class of which only a single instance can exist

Structural design patterns

These design patterns are all about Class and Object composition. Structural class-creation patterns use inheritance to compose interfaces. Structural object-patterns define ways to compose objects to obtain new functionality.

• Adapter: Match interfaces of different classes
• Bridge: Separates an object’s interface from its implementation
• Composite: A tree structure of simple and composite objects
• Decorator: Add responsibilities to objects dynamically
• Facade: A single class that represents an entire subsystem
• Flyweight: A fine-grained instance used for efficient sharing
• Private Class Data: Restricts accessor/mutator access
• Proxy: An object representing another object

Behavioral design patterns

These design patterns are all about Class’s objects communication. Behavioral patterns are those patterns that are most specifically concerned with communication between objects.

• Chain of responsibility: A way of passing a request between a chain of objects
• Command: Encapsulate a command request as an object
• Interpreter: A way to include language elements in a program
• Iterator: Sequentially access the elements of a collection
• Mediator: Defines simplified communication between classes
• Memento: Capture and restore an object’s internal state
• Null Object: Designed to act as a default value of an object
• Observer: A way of notifying change to a number of classes
• State: Alter an object’s behavior when its state changes
• Strategy: Encapsulates an algorithm inside a class
• Template method: Defer the exact steps of an algorithm to a subclass
• Visitor: Defines a new operation to a class without change

Ref:

• Refactoring.guru
• sourcemaking.com