Ubiquitous language

- A common language to help communication between software developers and domain experts.

Invariant

- describes something that must be true with your design all the time.

Bounded Context

- A specific responsibility enforced by explicit boundaries. These boundaries are set by the different way we represent models. Different contexts may have completely different models of common concepts with mechanisms to map between them.
- A Bounded Context can be considered as a miniature application, containing it’s own Domain, own code and persistence mechanisms.
- Communication to and from a Bounded Context is done via a Context Map.

describe things in the domain model

Entity

- A unique thing that has a life cycle and can change state. For example, a conference in a conference management system will be an entity; many of its attributes could change over time (such as its status, size, and even name), but within the system each particular conference will have its own unique identity.

Value object

- Not all objects are defined by their identity. For some objects what is important are the values of their attributes.
- Sometimes in one context something is an entity while in another it is just a value object.

Services

- You cannot always model everything as an object.
- it may make sense to model a third-party payment processing system as a service. The system can pass the parameters required by the payment processing service and then receive a result back from the service.
- A service in a DDD domain model is not a web service. It communicates aggregate roots, performs complex use cases, cross aggregates transaction. An operation offered as an interface that stands alone in the model, with no encapsulated state.

Aggregate

- Whereas entities, value objects, and services are terms for the elements that DDD uses to describe things in the domain model, the terms aggregate and aggregate root relate specifically to the lifecycle and grouping of those elements.
- Aggregate is a cluster of domain objects that can be treated as a single unit to provide a specific functionality and for the purpose of data changes.
- Every aggregate has a unique ID; therefore, you can use that ID to record which aggregate in the system was the source of a particular event.
- In summary, aggregates are the mechanism that DDD uses to manage the complex set of relationships that typically exist between the many entities and value objects in a typical domain model.

Aggregate root

- An aggregate root (also known as a root entity) is the gatekeeper object for the aggregate. All access to the objects within the aggregate must occur through the aggregate root; external entities are only permitted to hold a reference to the aggregate root, and all invariants should be checked by the aggregate root.
- An aggregate root is an entity that composes other entities (as well as its own values) by composition. It is the domain’s only entry point for data access. A heart of your domain.
- Another area where there can be confusion is in distinguishing entities from aggregates. Every aggregate has an entity acting as its aggregate root, and for lots and lots of entities the aggregate will consist of just this entity. The point is that "Customer have Orders" does not mean imply aggregation; Customer, Order and Product are all aggregate roots.

Domain Event

- A Domain Event is something that happened in the past, and that is of interest to the business.
- Domain Events is an immutable array of Domain Event objects. Once they have been initialized, there's no way to change them, there are no setters. Because events happen in the past, they cannot be changed or undone. That makes perfect sense: History can't be altered!
- Events happen in the past. For example, "the speaker was booked," "the seat was reserved," "the cash was dispensed."
- Events can be processed multiple times, by multiple consumers.
- Here are sets of events we may come up with from the cafe tab scenario. TabOpened, DrinksOrdered, FoodOrdered, FoodCancelled, DrinksServed, FoodPrepared, FoodServed, TabClosed.

CQRS — Command-Query Responsibility Segregation

- A common sense rather than a pattern. CQRS just separates a model into two separate parts — READ model and WRITE model.
- They also can be referenced as Query model and Command model. Segregation must be clean so commands can’t return any data.
- A command is any method that mutates state and a query is any method that returns a value.
- CQRS is not a top-level architecture. CQRS is something that happens at a much lower level.

Commands

- Commands are imperatives; they are requests for the system to perform a task or action. For example, "book two places for conference X" or "allocate speaker Y to room Z." Commands are usually processed just once, by a single recipient.
- Commands are things that indicate requests to our domain.
- A command may be accepted or rejected.
- An accepted command leads to zero or more events being emitted to incorporate new facts into the system.
- A rejected command leads to some kind of exception.
- Commands are also identified by looking for verbs. For example OpenTab, PlaceOrder, MarkFoodServed, CloseTab etc. However, they are focused around what the user considers as an operation.

Exceptions

- An important part of the modeling process is thinking about the things that can cause a command to be refused. We are expected to model these "sad paths" into exception types, just as commands and events are expressed as DTOs.
- Looking to the cafe domain scenario, we can identify three notable exceptions we need in our model: CannotCancelServedItem, TabHasUnservedItems and MustPayEnough. The names here try to explain why the command failed.

Command Bus

- The idea of a command bus is that you create command objects that represent what you want your application to do. Then, you toss it into the bus and the bus makes sure that the command object gets to where it needs to go.
- So, the command goes in -> the bus hands it off to a handler -> and then the handler actually does the job. The command essentially represents a method call to your service layer.
- The Command Bus pattern relies on 3 types of classes:
Command (encapsulate our input, does simple validation on it)
CommandHandler (dedicated to a single Command, does the actual logic)
CommandBus (interface allowing us to build Middlewares that calls the appropriate CommandHandle for the given Command)

Query

— an interpreter, which is a structure of objects which can form itself into an SQL query. You can create this query by referring to classes and fields rather than tables and columns. In this way, those who write the queries can do so independently of the database schema and changes to the schema can be localized in a single place.

Event Sourcing

- Event sourcing is a way of persisting your application's state by storing the history that determines the current state of your application. For example, a conference management system needs to track the number of completed bookings for a conference so it can check whether there are still seats available when someone tries to make a new booking.
- ensuring every change to the state of an application is captured in an event object, and that these event objects are themselves stored in the sequence they were applied for the same lifetime as the application state itself.

Repository

- mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.
- A mechanism for encapsulating storage, retrieval, and search behavior which emulates a collection of objects.
- pretends to be a collection of Aggregate Roots.



https://developer-paradize.blogspot.com/2016/05/ddd-building-blocks-dictionary.html
https://blog.lelonek.me/ddd-building-blocks-for-ruby-developers-cdc6c25a80d2

It's often useful to represent things as a compound. A 2D coordinate consists of an x value and y value. An amount of money consists of a number and a currency. A date range consists of start and end dates, which themselves can be compounds of year, month, and day.

I run into the question of whether two compound objects are the same. Objects that are equal due to the value of their properties, in this case their x and y coordinates, are called value objects.

In some noon functional languages you will need to override the default equals method with the tests for the values.

One of the nice consequences of value objects is that I don't need to care about whether I have a reference to the same object in memory or a different reference with an equal value.

Aliasing Bug

To avoid aliasing bugs I follow a simple but important rule: value objects should be immutable. If I want to change my object, I create a new object instead. With objects I can usually do this by simply not providing any setting methods.

my thanks to:
https://martinfowler.com/bliki/ValueObject.html

Tip 1: Use object exporter

During debugging, it’s often necessary to inspect the current object instances. if you’re working with arrays, this becomes tedious very quickly.

Oftentimes, it’s necessary to find a specific set of elements in the array. Object Exporter is for. It’s a Visual Studio extension, and you can install it manually from the Visual Studio Marketplace. Or you can install it from within Visual Studio via Tools -> Extensions and Updates. Please make sure that you select Online in the tree view to the left before you search for the extension.

It can export an object in different formats, namely JSON, XML, and C#. It’s also possible to export custom expressions. This is very helpful if you just want to export a subtree of an object graph.

Tip 2: Use ,nse to evaluate an expression without side effects

During debugging, you need to evaluate expressions all the time. As long as these expressions don’t change the state of the system, all is fine.

However, oftentimes, evaluating an expression causes a side effect.

For example, if you’re evaluating a property with lazy initialization, it’ll actually initialize that property in the context of the debugged code. This can lead to strange problems during debugging.

So if you want to watch o.MyProperty, add the following to the Watch window:

o.MyProperty, nse

This will execute the expression in a special sandbox, preventing any changes to the state of the debugged application.

Tip 3: Freeze multithreaded applications

Debugging multi-threaded applications can be a real pain, especially if multiple threads are executing the same code. Breakpoints will be hit by each thread, and single-stepping will switch between threads. It’s very easy to lose orientation and concentration like this. Wouldn’t it be great if it were possible to tell Visual Studio that you want to debug just this one thread and not switch to other threads that are currently executing the same code?

Well, turns out, there is a way to do this.

Open the Threads window via Debug -> Windows -> Threads. This window shows all threads of the current application. Double-clicking a thread switches to it. Right-clicking a thread shows different options, one of which is Freeze:

Threads window to freeze all threads for the current location except one. You can now debug this one thread and single-step through the code without thread switches interrupting your concentration. You can also set breakpoints and be sure they’ll be hit for the correct thread.

If you want to continue running the program after you’ve debugged the code in the thread, you should unfreeze—or Thaw—the other threads so they can perform their work as well.

Tip 4: Use Object ID

Object IDs are a feature of the Visual Studio Debugger that has several helpful use cases.

One such use case is that object IDs basically allow you to make a certain object instance globally available during debugging. This lets you compare it to other instances at a code location where the instance wouldn’t be available otherwise.

Another use case is to compare object identities. Imagine a scenario where you’re debugging an app that uses a dependency injection container. This app contains two classes that are receiving an instance of a service class via their constructors. The service instance resembles the way by which the two classes can communicate with each other. However, this coordination doesn’t work for some reason. One reason for this issue could be that the two classes aren’t receiving the same instance of the service class.

Object ID can easily identify this issue.

To use it, add a breakpoint at the constructors of the two classes. When the breakpoint gets hit in the first class, right-click the service instance in the Locals window and choose Make Object ID. When the breakpoint in the second class gets hit, check if the instance shows the object ID. If so, they’re the exact same instance.

Tip 5: Make sure you’re getting stack traces

When you catch an exception and rethrow it, never ever use throw ex;. Instead, use throw; . The first variant loses the original stack trace and therefore masks the original error location.

my thanks to this great article:
https://raygun.com/blog/dot-net-debugging/

Delegate Types

A delegate is simply a reference to a method. Delegates can be stored and passed around in a variable, and hence they must have a type definition:

private delegate int FuncTwoInts(int one, int two);

The line above defines the type FuncTwoInts. The FuncTwoInts type is a reference to a method that takes two int parameters and returns a single int result.

Delegate expressions

The FuncTwoInts type can be used to declare variables like this:

private static int Add(int one, int two)
{
    return one + two;
}

private FuncTwoInts theFunc = Add;

Or like this:

FuncTwoInts theFunc = delegate (int one, int two)
{
    return one + two;
};

Or this:

FuncTwoInts theFunc = (one, two) =>
{
    return one + two;
};

Or even like this:

FuncTwoInts theFunc = (one, two) => one + two;

Lambda expressions

The last two delegate examples above (the ones utilizing the => operator) are called lambda expressions. Lambda expressions are just a more efficient way of defining a delegate. If the function defined by the lambda expression is more than a single line, then the { } are required, as is the return keyword.

Built-in delegate types

There is a family of built-in delegate types that can be used to declare delegate variables without the need to define a custom type.

Action

The types that represent a delegate without a return value (void return) are the Action types in the System namespace.

private Action supFunction = () => Console.WriteLine("Sup?!");

Here's an example of a delegate that takes three parameters of different types:

private Action<string, int, bool> printThreeValues =
    (s, i, b) => Console.WriteLine($"string: {s}, int: {i}, bool: {b}");

Func

The Func family of delegate types can return a value of any type you wish. For example: Func<TResult> for no params and TResult return type.

private Func twoPlusThree = () => 2 + 3;

Func<T1, T2, TResult> for two parameters and TResult return type. Here is an example of a delegate declaration that takes two string parameters and returns an int:

private Func<string, string, int> sumCharacters = 
    (s1, s2) => s1.Length + s2.Length;

my thanks to this course:
https://www.codingame.com/playgrounds/345/c-linq-background-topics/review

If you woke up one day resolved to be a great writer, you’d hear two simple pieces of feedback: write a lot, and read a lot.

In software, nearly everyone falls short on the latter. Early in your career, embrace reading code. Read widely and read often.

Why read code?

Great writers are a function of the writers they’ve read. Similarly, seeing diverse coding practices lets you expand your own palette when it comes time to write your own code. It exposes you to new language functionality, different coding styles, and important dependencies.

Reading your dependencies will make you a more productive programmer. You’ll know what the full functionality your dependencies offer. You’ll know exactly how they work and what tradeoffs they’re making. You’ll know where to debug when things go wrong.

Being comfortable reading code reduces the likelihood that you’ll have a “not invented here” mindset. The more you read, the more comfortable you’ll feel depending or augmenting someone else’s code, rather than building your own.

Cultivating regular reading will teach you tools and products widely different from your day to day work.

As a web engineer, reading a small part of a raytracer’s codebase will expose you to a wholly different set of constraints and user needs.

The more you read, the less scary it’ll be. Developing a strategy to read code then becomes a virtuous cycle.

How to “read” code?

Approaching a codebase like you would a book— reading from start to end—is a recipe for failure. Any medium-sized codebase is impossible to read linearly. Instead, “reading” code requires a substantial amount of active work.

I use this four-party strategy for approaching any complex code base (RSDW for short):

•  1) Run: compile, run, and understand what the code is supposed to do

•  2) Structure: Learn high level structure and review key integration tests

•  3) Deep Dives: Follow key flows and read important data structures

•  4) Write: Write tests and prioritize simple features and bug fixes

When you’re starting to read, be humble. A common mistake for early engineers is to weigh their code as “good” and that of others as “bad.” Instead, have some empathy for the styles of others and the uneven process that leads to the birth of most new software systems.

As a new developer, when you notice missing things, especially documentation and poor test coverage, help out. This is an exceptional way to learn, and will endear you to the others who develop the codebase, whose support will speed up your journey to learn a new codebase.

Second, reading new code is exhausting. You are intricately retracing code flows and trying to hold tens of new data structures and functions in your head concurrently. Be aggressive about taking breaks when you’re approaching a new code base. When I’m starting on a new complex codebase, a few good hours of reading is all I need to feel productive for the rest of the day.

With the right frame of mind, it’s much easier to go through the active process of digesting new code.

1) Run

The first step in reading code, isn’t to read code. It is to use the software.

Do not read code without understanding exactly what the software does and what functionality it offers. During this stage of reading, you should be able to make a summary of the code and have an understanding what the inputs and outputs could be.

Using the software forces you to get it to run. This means compiling the code (in some languages) and pulling down the dependencies. This is also the time to run the tests and review the output messages. If you have trouble getting the system running, this is the perfect time to document what it actually takes to compile and run the software.

2) Structure

Next, identify the most critical parts of the code. This is the part that is most different from reading a book. Instead of beginning at the beginning, you identify the key nexuses in the code.

Start with understand the structure of the code. At minimal, use tree | less and cloc to figure out the languages and files of the codebase.

To identify the most important files, look at the most modified files (git log --pretty=format: -name-only | sort | uniq -c | sort -rg | head -10^[2]) and use other advanced tools. Review the most important integration tests, listing out the functions that are called. Flag these tests for later.

There’s a cheat code for this process too: find someone who’s worked on the code before. understanding the structure is a good first task for a whiteboarding session.

3) Deep Dives

Once you have a lay of the land, dig in.

Programming languages revolve around two fundamental paradigms: functional (when actions are primary) and objects (when objects are primary). Similarly, when reading code, you should look at code flows (seeing the actions that are being created) and look at data structures (where the results of actions are stored).

Pick 3-5 few critical flows you’ve found from key integration tests or your review of the source files. Then dive deeper. Start at the top of a specific action and trace the code through. Some developers swear by debuggers that let you step through. Others prefer building UML diagrams or flamegraphs. If you decide to manually follow the code, make sure your editors is setup to let you use “go to definition” and “find all references” for quick navigation.

For data structures, review the data types and when key variables are being set. Use the debugger to interrogate these data structures at critical moments.

I also keep two markdown docs open for these deep dives. The first is a “level up my coding” doc where I list out new syntax I’m seeing and code patterns I find interesting for my own learning (others call this a glossary). This allows me to return for further investigation. The second is a doc that lists out key questions I have for the developers of the codebase. At this stage, I also add to the documentation when I notice gaps.

Deep dives are especially powerful in pairs with someone who knows the code. If I have limited time with a developer on the project, I always have them trace me through a few key flows.

4) Write Code

Unlike passive reading in literature, a critical part of “reading” code is writing code. The two easy ways to “read” is to write tests and address simple features/ bugs.

Writing tests is an active form of reading, forcing you to pay attention to the actual inputs and outputs of a particular interaction.

Writing tests is when you realize that you’re still missing important details. Writing tests imprints the code in your memory in a way that reading alone cannot. Unit tests are an easy way to start, and once I have some base mastery, I move over to integration tests that force me to understand increasingly larger parts of the codebase.

The other easy way to write early code is to write simple features or address easy bugs. Both these tasks don’t demand complete knowledge of the codebase, but force you to confront the code. They also provide quick wins that increases your confidence and motivation.

What code to read?

Early in your career, 60% of your time should be spent reading code. Maybe half of that should be code outside of the direct codebases you actually build on top of. That’s an awfully large amount of time to fill, so what should you read?

The easiest way to get started reading and the highest ROI is to learn your dependencies. Internalizing how your dependencies work lets you more easily debug and reason across your entire system.

The other high ROI path is to pick an important system at your company that you interface with, and read through it. Not only will this be valuable in your work, but professional codebases are different from open source codebases. They are written closest to how your team’s engineers feel is the “right” way.

Beyond the direct systems you interact with, cultivate an openness to reading widely. Early on in my career, I recommend putting aside an hour in the morning or evening to read through code outside your day to day work.

To start, pick a few easily understood codebases. Redis is known as a popular starting point in C. Famed codebases — say reading Vim — are more complicated with lots of nuance, but an easy way to start is to read a specific subsystem.

Try to actively read tools widely different from your day job. If you’re used to high level abstractions, learn an abstraction level (or three) down. If you work in one language, pick another language to read in your free time.

Find coders you respect or want to mimic and follow them on Github. Read a few of their other codebases. Stay up to date of their most recent work.

Create a reading group, a code club. In Stockholm, I heard great things about “The Classical Code Reading Group of Stockholm,” where they read classic codebases (I used to join at an affiliate run by Thoughtbot in NYC).

When you first start reading code, uour focus is not simply to learn a codebase, but to develop a mindset that will pay long term dividends.

Links

Articles on reading code

•  Ask HN: How do you familiarize yourself with a new codebase

•  Ask HN: How to understand the large codebase of an open source project?

•  Strategies to quickly become productive in an unfamiliar codebase

•  What's the best way to become familiar with a large codebase?

•  Tips for Reading Code

•  Software Engineering Radio: Software Archaeology with Dave Thomas (Podcast)

Books

•  Code Reading: The Open Source Perspective

(book)

•  Working Effectively with Legacy Code (book)

Codebases to read

•  Good Python codebases to read

•  Good Go codebases to read

Source

this article is taken from a post on a forum which can be found here
https://news.ycombinator.com/item?id=19431874 https://hackernoon.com/one-secret-to-becoming-a-great-software-engineer-read-code-467e31f243b0

ClaimsPrincipal represents a user (is what the HttpContext.SignInAsync method accepts and passes to the specified AuthenticationHandler.) and contains one or more instances of

ClaimsIdentity which in turn represent a single form of identification and contain one or more instances of

Claim, which represents a single piece of information about a user.

Authentication handlers are components that actually implement the behavior of the 5 verbs above. The default auth handler provided by ASP.NET Core is the Cookies authentication handler

Authentication Middleware is a module that can be inserted into the startup sequence and is run on every request. When the request is run, the authentication middleware asks the default scheme auth handler to run its authentication code.

my thanks to this article:
https://digitalmccullough.com/posts/aspnetcore-auth-system-demystified.html

my thanks to this great repo:
https://github.com/MoienTajik/AspNetCore-Developer-Roadmap

Great article on the "most common" workflow used by front end developers and a brief overview of the tools used.
https://medium.com/the-node-js-collection/modern-javascript-explained-for-dinosaurs-f695e9747b70

JavaScript package managers(npm)

Bower was arguably the most popular in 2013, but eventually was overtaken by npm around 2015. (It’s worth noting that starting around late 2016, yarn has picked up a lot of traction as an alternative to npm’s interface, but it still uses npm packages under the hood.)

JavaScript module bundler (webpack)

In 2009, a project named CommonJS was started with the goal of specifying an ecosystem for JavaScript outside the browser. A big part of CommonJS was its specification for modules, which would finally allow JavaScript to import and export code across files like most programming languages, without resorting to global variables. The most well-known of implementation of CommonJS modules is node.js. As mentioned earlier, node.js is a JavaScript runtime designed to run on the server.

The most popular module bundler was Browserify, which was released in 2011 and pioneered the usage of node.js style require statements on the frontend (which is essentially what enabled npm to become the frontend package manager of choice). Around 2015, webpack eventually became the more widely used module bundler (fueled by the popularity of the React frontend framework, which took full advantage of webpack’s various features).

Transpiling code for new language features (babel)

Transpiling code means converting the code in one language to code in another similar language. This is an important part of frontend development — since browsers are slow to add new features, new languages were created with experimental features that transpile to browser compatible languages.

For CSS, there’s Sass, Less, and Stylus, to name a few. For JavaScript, the most popular transpiler for a while was CoffeeScript (released around 2010), whereas nowadays most people use babel or TypeScript. CoffeeScript is a language focused on improving JavaScript by significantly changing the language — optional parentheses, significant whitespace, etc. Babel is not a new language but a transpiler that transpiles next generation JavaScript with features not yet available to all browsers (ES2015 and beyond) to older more compatible JavaScript (ES5). Typescript is a language that is essentially identical to next generation JavaScript, but also adds optional static typing. Many people choose to use babel because it’s closest to vanilla JavaScript.

Using a task runner (npm scripts)

Now that we’re invested in using a build step to work with JavaScript modules, it makes sense to use a task runner, which is a tool that automates different parts of the build process. For frontend development, tasks include minifying code, optimizing images, running tests, etc.

In 2013, Grunt was the most popular frontend task runner, with Gulp following shortly after. Both rely on plugins that wrap other command line tools. Nowadays the most popular choice seems to be using the scripting capabilities built into the npm package manager itself, which doesn’t use plugins but instead works with other command line tools directly.

Interesting series of articles from Postman, how they implemented Micro-Services architecture, issues encountered and solutions.

Part 1

https://medium.com/postman-engineering/conquering-the-microservices-dependency-hell-at-postman-with-postman-part-1-introduction-a1ae019bb934

Part 2

https://medium.com/postman-engineering/conquering-the-microservices-dependency-hell-at-postman-with-postman-part-2-7c825d576947

Decision Tree

High level overview:

On environment to be deployed to:

• - create website on IIS
• - Export publish settings file from website

Visual Studio

• - create Build Conifguration
• - create new Publish Profile by importing the publish settings file, remembering to rename the profile.
• - create web config transform file

TeamCity

• - create Project
• - create build configuration
• - add Version Control Settings
• - add build steps

Possibly helpful article:

https://medium.com/monkii/how-to-deploy-asp-net-core-sites-using-teamcity-or-just-command-line-cf05fdee58f5
https://docs.microsoft.com/en-us/visualstudio/deployment/tutorial-import-publish-settings-iis?view=vs-2017

Developing Question Application with React

With your backend API up and running, you are finally ready to start developing your React application.

With the "create-react-app" tool, you can scaffold a new React application with just one command. As such, to create your React app, open a new terminal and go to the same directory where you created the qa-api Node.js app. From there, issue the following command:

# this command was introduced on npm@5.2.0
npx create-react-app qa-react

This will make NPM download and run create-react-app in a single command, passing to it qa-react as the desired directory for your new application.

# move into the new directory
cd qa-react

# start your React app
npm start

The last command issued above will start a development server that listens on port 3000 and will open the new app in your default web browser.

After seeing your app, you can stop the server by hitting

Ctrl + c 

Configuring the React Router in Your App

React Router is a very complete solution and, in your first React app, you will touch only the tip of the iceberg. If you do want to learn more about React Router, please, head to the official documentation.

Configuring Bootstrap in Your React App

To make your React app more appealing from the User Interface (UI) point of view, you are going to configure Bootstrap on it.

Creating a Navigation Bar in Your React App

create a component called NavBar (which stands for Navigation Bar), and you will add it to your React app.

Creating a Class Component with React

create a stateful component (a class component) to fetch questions from your backend and to show it to your users. To fetch these questions, you will need the help of another library, Axios. In a few words, Axios is a promise-based HTTP client for the browser and for Node.js. Note: This component is touching a topic that was not addressed in this article, the Lifecycle of React Components. In this case, you are just using one of the extension points provided by React, the componentDidMount method.

Routing Users with React Router

import React, { Component } from 'react';
import {Route} from 'react-router-dom';
import NavBar from './NavBar/NavBar';
import Question from './Question/Question';
import Questions from './Questions/Questions';

class App extends Component {
  render() {
    return (
      

        
        
        
      
    );
  }
}

export default App;

In the new version of your App component, you are using two Route elements (provide by react-router-dom) to tell React when you want the Questions component rendered and when you want the Question component rendered.
More specifically, you are telling React that if your users navigate to / (exact path='/') you want them to see Questions and, if they navigate to /question/:questionId, you want them to see the details of a specific question.

Configuring an Auth0 Account

If you do not have one, now is a good time to sign up for a free Auth0 account. With your free account, you will have access to the following features:

• Passwordless authentication
• Lock for Web, iOS & Android
• Up to 2 social identity providers (like Twitter and Facebook)
• Unlimited Serverless Rules
• Community Support

Create Application
Set Allowed Callback URLs field

Securing your Backend API with Auth0

To secure your Node.js API with Auth0, you will have to install and configure only two libraries:

• express-jwt: A middleware that validates a JSON Web Token (JWT) and set the req.user with its attributes.
• jwks-rsa: A library to retrieve RSA public keys from a JWKS (JSON Web Key Set) endpoint.

both of them declare that they want to use checkJwt, which makes them unavailable to unauthenticated users. Second, both add a new property called author on questions and answers. These new properties receive the name (req.user.name) of the users issuing requests.

Securing your React App with Auth0

install only one library: auth0-js. This is the official library provided by Auth0 to secure SPAs like yours.

refactor your NavBar component to allow users to authenticate. So, open the NavBar.js file and replace its code

After refactoring the NavBar component, you will have to create a component to handle the callback. This componet will be responsible for 2 things:
First, it calls the handleAuthentication method to fetch the user information sent by Auth0.
Second, it redirects your users to the home page (history.replace('/')) after it finishes the handleAuthentication process. In the meantime, this component shows the following message: "Loading profile".

Adding Features to Authenticated Users

First, you will enable authenticated users to create new questions. Then, you will refactor the Question (singular) component to show a form so authenticated users can answer these questions.

Keeping Users Signed In after a Refresh

if you refresh your browser, you will notice that you will be signed out. Because you are saving you tokens in memory (as you should do) and because the memory is wiped out when you hit refresh.

Luckily, solving this problem is easy. You will have to take advantage of the Silent Authentication provided by Auth0. That is, whenever your application is loaded, it will send a silent request to Auth0 to check if the current user (actually the browser) has a valid session.

You will have to change a few configurations in your Auth0 account.
Add your url http://localhost:3000 to Allowed Web Origins, as your app is going to issue an AJAX request to Auth0.
Add your url http://localhost:3000 to Allowed Logout URLs, To enable users to end their session at Auth0, you will have to call the logout endpoint. Similarly to the authorization endpoint, the log out endpoint only redirects users to whitelisted URLs after the process.

Now update the src/Auth.js file to implement silent login when component has loaded

There are a lot of links on the original article that should be used to investigate further and delve deeper into the technologies used.

my thanks to this great blog post:
https://auth0.com/blog/react-tutorial-building-and-securing-your-first-app/

In the following sections, you will build a simple Q&A (Question & Answer) app that will allow users to interact with each other asking and answering questions. To make the whole process more realistic, you will use Node.js and Express to create a rough backend API.

Developing a Backend API with Node.js and Express

build a backend API to support your Q&A app. In this section, you will use Express alongside with Node.js to create this API. With this library, as you will see here, you can quickly build apps to run on servers

# use NPM to start the project
npm init -y

this will create a file called package.json inside your directory. This file will hold the details (like the dependencies) of your backend API.

npm i body-parser cors express helmet morgan

This command will install five dependencies in your project:

1. body-parser:
   This is a library that you will use to convert the body of incoming requests into JSON objects.
2. cors:
   This is a library that you will use to configure Express to add headers stating that your API accepts requests coming from other origins. This is also known as Cross-Origin Resource Sharing (CORS).
3. express:
   This is Express itself.
4. helmet:
   This is a library that helps to secure Express apps with various HTTP headers.
5. morgan:
   This is a library that adds some logging capabilities to your Express app.

Also, you will see a new file called package-lock.json. NPM uses this file to make sure that anyone else using your project (or even yourself in other environments) will always get versions compatible with those that you are installing now.

Then, the last thing you will need to do is to develop the backend source code. So, create a directory called src inside your qa-api directory and create a file called index.js

//import dependencies
const express = require('express');
const bodyParser = require('body-parser');
const cors = require('cors');
const helmet = require('helmet');
const morgan = require('morgan');

// define the Express app
const app = express();

// the database
const questions = [];

// enhance your app security with Helmet
app.use(helmet());

// use bodyParser to parse application/json content-type
app.use(bodyParser.json());

// enable all CORS requests
app.use(cors());

// log HTTP requests
app.use(morgan('combined'));

// retrieve all questions
app.get('/', (req, res) => {
  const qs = questions.map(q => ({
    id: q.id,
    title: q.title,
    description: q.description,
    answers: q.answers.length,
  }));
  res.send(qs);
});

// get a specific question
app.get('/:id', (req, res) => {
  const question = questions.filter(q => (q.id === parseInt(req.params.id)));
  if (question.length > 1) return res.status(500).send();
  if (question.length === 0) return res.status(404).send();
  res.send(question[0]);
});

// insert a new question
app.post('/', (req, res) => {
  const {title, description} = req.body;
  const newQuestion = {
    id: questions.length + 1,
    title,
    description,
    answers: [],
  };
  questions.push(newQuestion);
  res.status(200).send();
});

// insert a new answer to a question
app.post('/answer/:id', (req, res) => {
  const {answer} = req.body;

  const question = questions.filter(q => (q.id === parseInt(req.params.id)));
  if (question.length > 1) return res.status(500).send();
  if (question.length === 0) return res.status(404).send();

  question[0].answers.push({
    answer,
  });

  res.status(200).send();
});

// start the server
app.listen(8081, () => {
  console.log('listening on port 8081');
});

With this file in place, you are good to go. To run your app, just issue the following command:

# from the qa-app directory
node src

Test if everything is really working, open a new terminal and issue the following commands:

# issue an HTTP GET request
curl localhost:8081

# issue a POST request
curl -X POST -H 'Content-Type: application/json' -d '{
  "title": "How do I make a sandwich?",
  "description": "I am trying very hard, but I do not know how to make a delicious sandwich. Can someone help me?"
}' localhost:8081

curl -X POST -H 'Content-Type: application/json' -d '{
  "title": "What is React?",
  "description": "I have been hearing a lot about React. What is it?"
}' localhost:8081

# re-issue the GET request
curl localhost:8081

With your backend API up and running, you are finally ready to start developing your React application.

my thanks to this great blog post:
https://auth0.com/blog/react-tutorial-building-and-securing-your-first-app/

React and the JSX Syntax

React uses a funny syntax called JSX. JSX, which stands for JavaScript XML, is a syntax extension to JavaScript that enables developers to use XML (and, as such, HTML) to describe the structure of the user interface.

function showRecipe(recipe) {
  if (!recipe) {
    return 
Recipe not found!
;
  }
  return (
    

      
{recipe.title}
      
{recipe.description}
    
  );
}

In this case, the showRecipe function is using the JSX syntax to show the details of a recipe (i.e., if the recipe is available) or a message saying that the recipe was not found.

React Components

Components in React are the most important pieces of code. Everything you can interact with in a React application is (or is part of) a component. For example, when you load a React application, the whole thing will be handled by a root component that is usually called App.

The biggest advantage of using components to define your application is that this approach lets you encapsulate different parts of your user interface into independent, reusable pieces. Having each part on its own component facilitates reasoning, testing, and reusing each piece easily.

Defining Components in React

there are two types of React components

functional components
are simply "dumb" components that do not hold any internal state (making them great to handle presentation)

function UserProfile(props) {
  return (
    

      
      
{props.userProfile.name}
    
  );
}

class components
Are more complex components that can hold internal state. For example, if you are creating a component that will only show the profile of the user that is authenticated, you can create a functional component as follows:

However, if you are going to create a component to handle things that need to hold some state and perform more complex tasks, like a subscription form, you will need a class component. To create a class component in React, you would proceed as follows:

class SubscriptionForm extends React.Component {
  constructor(props) {
    super(props);

    this.state = {
      acceptedTerms: false,
      email: '',
    };
  }

  updateCheckbox(checked) {
    this.setState({
      acceptedTerms: checked,
    });
  }

  updateEmail(value) {
    this.setState({
      email: value,
    });
  }

  submit() {
    // ... use email and acceptedTerms in an ajax request or similar ...
  }

  render() {
    return (
      

         {this.updateEmail(event.target.value)}}
          value={this.state.email}
        />
         {this.updateCheckbox(event.target.checked)}}
          />
         {this.submit()}}>Submit
      
    )
  }
}

this component is defining three input elements (actually, two input tags and one button

this component is defining an internal state (this.state) with two fields: acceptedTerms and email

my thanks to this great blog post:
https://auth0.com/blog/react-tutorial-building-and-securing-your-first-app/

Concurrency Conflicts

A concurrency conflict occurs when one user displays an entity's data in order to edit it, and then another user updates the same entity's data before the first user's change is written to the database.

Pessimistic Concurrency (Locking)

before you read a row from a database, you request a lock for read-only or for update access. If you lock a row for update access, no other users are allowed to lock the row either for read-only or update access. If you lock a row for read-only access, others can also lock it for read-only access but not for update. complex to program. requires significant database management resources can cause performance problems as the number of users of an application increases The Entity Framework provides no built-in support for it

Optimistic Concurrency

Optimistic concurrency means allowing concurrency conflicts to happen, and then reacting appropriately if they do. There are 3 different approaches:

1. You can keep track of which properties conflicting users have modified and update only the corresponding columns in the database. Can't avoid data loss if competing changes are made to the same property of an entity. Often not practical in a web application, because it can require that you maintain large amounts of state in order to keep track of all original property values for an entity as well as new values.
2. Client Wins or Last in Wins allow all changes to happen, if you don't do any coding for concurrency handling, this will happen automatically.
3. Store Wins prevent 2nd user's change from being updated in the database. Typically, you would display an error message, show this user the current state of the data, and allow her to reapply her changes if she still wants to make them.

my thanks to this article on handling data concurrency with Entity Framework:
https://docs.microsoft.com/en-us/aspnet/mvc/overview/getting-started/getting-started-with-ef-using-mvc/handling-concurrency-with-the-entity-framework-in-an-asp-net-mvc-application

Learning & Improving

The best way I know of to excel in software is to keep a growth mindset. The more you can learn and improve, the more career options you'll have.

Improvement can be broken down along two lines: input and output. I've tended to go through phases in my career where I've done more input than output, and (less often) vice versa, but I've found both to be essential for improvement.

Input

There are innumerable ways to gain knowledge: articles, books, papers, MOOCs, conversations, experimentation, project documentation, access to experts who are willing to answer questions, and many more. Quality and efficiency vary across these

Personally, I've gotten a ton of value out of reading books and applying what I've learned. concentrating your reading more on classic books that'll help you throughout your career. Book authors have spent many months, maybe years, distilling their years of experience into a well-crafted format that you can inhale over a few weekends.

I'll mostly stick to broad areas here rather than specific book recommendations, but you can check out my Goodreads profile for more specifics if you're curious.

Learn about software career development. For broad career development issues, I'll make an exception in this post and highly recommend Apprenticeship Patterns, The Pragmatic Programmer, and The Passionate Programmer. Bluntly, if you were to stop reading this post right now and go read those three books instead, I'd think you made a wise decision.

Learn about code. Again, I prefer books to blog posts.
Learn about the specific languages and frameworks that you're concentrating on.
Learn about software design & architecture principles and patterns.
Learn about test-driven development and refactoring.
Learn about the platform you're deploying to.
Learn about foundational computer science concepts.

Learn about communication. There's a lot of material out there, both in the software space and outside. The way you communicate is a crucial part of the way others perceive you, whether it's in conversations, in emails, or in documentation. Learn about logical fallacies, cognitive biases, and nonviolent communication. Look for materials on communicating in effective writing, presentations, and difficult conversations.

Read open-source code. My experience is that reading OSS code is most effective when you've got a specific purpose in mind. But it can also be instructional to clone a repository from GitHub, run the tests, try and reproduce issues in the issue tracker, etc. At worst, you get an idea of how someone else codes and what's easy or hard for you to understand. And at best, you'll find yourself leaning over into the output side of things, which we'll discuss next.

Output

Write code. This isn't necessarily the most important skill you'll need in your software career, but it's certainly the one that's most unique to the role of a software developer. There are lots of ways to practice writing code, but my personal favorite is doing code katas.

Code katas have a couple of main schools of thought, and I like both of them for different reasons:

• Repetition. By solving the same problem many times with the same or similar solutions, you get to understand the problem really well. This gives you a sense of mastery, which I've found to be great for my emotional well-being when I'm mostly frustrated by programming problems. You can treat these as either a meditation, where you're thinking deeply, or as a race, where you're honing your skills with the tools. Some folks even treat repetition katas as a performance, with or without musical or spoken accompaniment.
• New problems/solutions. The idea here is that most of the coding part of the job is about thinking about and solving new problems, ones that might be related to ones you've seen before but aren't identical. With new problem katas, you're intentionally putting yourself in the uncomfortable position of not-knowing, where we each need to learn to be OK as we're moving toward solutions. You can find lots of examples of bite-sized katas—many have ridiculous names, but they can still be great exercises to work through.

Katas are typically fairly constrained problems compared with "the real world"—more on the order of a single sitting, though some can get quite tricky and take much longer.

Breakable toys are much more realistic and larger-scope projects than katas, but they still aren't mission-critical.So it's OK if they get broken as you're learning. Having a breakable toy lets you see how different ideas work in the long term, which is super-helpful in the work world.

Open source software can be pretty intimidating to get into, but there are a few reasons I still think it's a good idea to look at. First, you can get practice learning a new codebase. Second, for many (not all) open-source projects, the level of code quality is pretty high. You'll get a chance to see how experienced folks approach problems and solve them, by browsing issue and pull request history.

Learn to use the project really well if you don't already. This will force you to go through the existing documentation, and you'll probably find some low-hanging fruit: typos, grammar issues, hard-to-understand explanations, etc. I've also heard good things about OSS issue aggregators like OpenHatch and Up for Grabs for finding projects that fit the bill here.

Practice empathy and communication in your daily interactions. When little misunderstandings occur, ask yourself how they happened and what you can do in the future to prevent them. And how can you get past the misunderstanding with everyone feeling better afterward than before. When you're talking, ask yourself what your audience needs from you—do they need all the details, or do they mostly care about the highest-level bits? These skills are among the most crucial for any job that requires collaboration.

Managing your time

decide what your goals are at a high level, and find ways to move in that direction incrementally. One idea is to take a tip from agile project management: take your big hairy audacious goal (product), figure out the first step or two towards it (releases), break the first one down to the first few medium-sized goals toward it (epics), and break those down into goals that you can knock out in a single sitting (stories). In this way, you can fit learning into the space that's available, rather than having to rely on luxuries like wide-open nights and weekends.

Find mentors

We all need feedback. Without feedback on how we're progressing, it's easy to divorce our own self-assessment from reality, and to think that we're doing much worse or better than we really are.
try to find at least one person who can help guide you in your progress. My first real mentor didn't have a formal mentoring role, but he was the developer in the next cube, he was a few years ahead of me in experience, and he understood how to communicate the basics. Between his direct feedback and the books he told me to read
You can find mentors outside the workplace, too.

• CodeNewbie is a Twitter chat, podcast, blog, and community with tons of great ideas about breaking into and excelling in this industry, with participants at all levels.
• Social media: Despite its [my] faults, I've found Twitter to be particularly well-populated with software experts sharing tips, links, and stories. And some people are willing to answer questions directly—others have too many folks jostling for their attention, so don't feel too bad if they can't make time for you directly.
• User groups: If you're in an area that has them and you can make the timing work, user groups can be a great place to meet other folks who are excited about software. Check out Meetup for topics you might be interested in. Introduce yourself and make connections—if you're like me this will be hard, but you might just meet your next employer here.
• Open source software: The people reviewing your pull requests are already giving you direct feedback! Maybe not career-level stuff, but they might be up for that too as you contribute more.

the name of the relationship isn't all that important—what you really want here is to get external feedback and make progress toward your goals.

my thanks to this fantastic blog post:
https://8thlight.com/blog/colin-jones/2017/10/24/advice-for-early-career-developers.html

Alot of modern architectures(a lit of which is on the original post referenced at the bottom) are trying to achieve the same objective, which is the separation of concerns. They all achieve this separation by dividing the software into layers. Each has at least one layer for business rules, and another for interfaces.

Each of these architectures produce systems that are:

1. Independent of Frameworks. The architecture does not depend on the existence of some library of feature laden software. This allows you to use such frameworks as tools, rather than having to cram your system into their limited constraints.
2. Testable. The business rules can be tested without the UI, Database, Web Server, or any other external element.
3. Independent of UI. The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules.
4. Independent of Database. You can swap out Oracle or SQL Server, for Mongo, BigTable, CouchDB, or something else. Your business rules are not bound to the database.
5. Independent of any external agency. In fact your business rules simply don’t know anything at all about the outside world.

The diagram at the top of this article is an attempt at integrating all these architectures into a single actionable idea.

The Dependency Rule

The concentric circles represent different areas of software. In general, the further in you go, the higher level the software becomes. The outer circles are mechanisms. The inner circles are policies.

The overriding rule that makes this architecture work is The Dependency Rule. This rule says that source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about something in an outer circle. In particular, the name of something declared in an outer circle must not be mentioned by the code in an inner circle. That includes, functions, classes. variables, or any other named software entity.

By the same token, data formats used in an outer circle should not be used by an inner circle, especially if those formats are generate by a framework in an outer circle. We don’t want anything in an outer circle to impact the inner circles.

Entities

Entities encapsulate Enterprise wide business rules. An entity can be an object with methods, or it can be a set of data structures and functions. It doesn’t matter so long as the entities could be used by many different applications in the enterprise.

If you don’t have an enterprise, and are just writing a single application, then these entities are the business objects of the application. They encapsulate the most general and high-level rules. They are the least likely to change when something external changes. For example, you would not expect these objects to be affected by a change to page navigation, or security. No operational change to any particular application should affect the entity layer.

Use Cases

The software in this layer contains application specific business rules. It encapsulates and implements all of the use cases of the system. These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their enterprise wide business rules to achieve the goals of the use case.

We do not expect changes in this layer to affect the entities. We also do not expect this layer to be affected by changes to externalities such as the database, the UI, or any of the common frameworks. This layer is isolated from such concerns.

We do, however, expect that changes to the operation of the application will affect the use-cases and therefore the software in this layer. If the details of a use-case change, then some code in this layer will certainly be affected.

Interface Adapters

The software in this layer is a set of adapters that convert data from the format most convenient for the use cases and entities, to the format most convenient for some external agency such as the Database or the Web. It is this layer, for example, that will wholly contain the MVC architecture of a GUI. The Presenters, Views, and Controllers all belong in here. The models are likely just data structures that are passed from the controllers to the use cases, and then back from the use cases to the presenters and views.

Similarly, data is converted, in this layer, from the form most convenient for entities and use cases, into the form most convenient for whatever persistence framework is being used. i.e. The Database. No code inward of this circle should know anything at all about the database. If the database is a SQL database, then all the SQL should be restricted to this layer, and in particular to the parts of this layer that have to do with the database.

Also in this layer is any other adapter necessary to convert data from some external form, such as an external service, to the internal form used by the use cases and entities.

Frameworks and Drivers.

The outermost layer is generally composed of frameworks and tools such as the Database, the Web Framework, etc. Generally you don’t write much code in this layer other than glue code that communicates to the next circle inwards.

This layer is where all the details go. The Web is a detail. The database is a detail. We keep these things on the outside where they can do little harm.

Only Four Circles?

No, the circles are schematic. You may find that you need more than just these four. There’s no rule that says you must always have just these four. However, The Dependency Rule always applies. Source code dependencies always point inwards. As you move inwards the level of abstraction increases. The outermost circle is low level concrete detail. As you move inwards the software grows more abstract, and encapsulates higher level policies. The inner most circle is the most general.

Crossing boundaries.

At the lower right of the diagram is an example of how we cross the circle boundaries. It shows the Controllers and Presenters communicating with the Use Cases in the next layer. Note the flow of control. It begins in the controller, moves through the use case, and then winds up executing in the presenter. Note also the source code dependencies. Each one of them points inwards towards the use cases.

We usually resolve this apparent contradiction by using the Dependency Inversion Principle. In a language like Java, for example, we would arrange interfaces and inheritance relationships such that the source code dependencies oppose the flow of control at just the right points across the boundary.

For example, consider that the use case needs to call the presenter. However, this call must not be direct because that would violate The Dependency Rule: No name in an outer circle can be mentioned by an inner circle. So we have the use case call an interface (Shown here as Use Case Output Port) in the inner circle, and have the presenter in the outer circle implement it.

The same technique is used to cross all the boundaries in the architectures. We take advantage of dynamic polymorphism to create source code dependencies that oppose the flow of control so that we can conform to The Dependency Rule no matter what direction the flow of control is going in.

What data crosses the boundaries.

Typically the data that crosses the boundaries is simple data structures. You can use basic structs or simple Data Transfer objects if you like. Or the data can simply be arguments in function calls. Or you can pack it into a hashmap, or construct it into an object. The important thing is that isolated, simple, data structures are passed across the boundaries. We don’t want to cheat and pass Entities or Database rows. We don’t want the data structures to have any kind of dependency that violates The Dependency Rule.

For example, many database frameworks return a convenient data format in response to a query. We might call this a RowStructure. We don’t want to pass that row structure inwards across a boundary. That would violate The Dependency Rule because it would force an inner circle to know something about an outer circle.

So when we pass data across a boundary, it is always in the form that is most convenient for the inner circle.

Conclusion

Conforming to these simple rules is not hard, and will save you a lot of headaches going forward. By separating the software into layers, and conforming to The Dependency Rule, you will create a system that is intrinsically testable, with all the benefits that implies. When any of the external parts of the system become obsolete, like the database, or the web framework, you can replace those obsolete elements with a minimum of fuss.

my thanks to this great blog post:
https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html

Fleeting Knowledge - Language Specific

That would be a framework’s API and syntax. Knowing those nitty gritty details of Angular and its API is necessary to be productive in an Angular codebase, but it’s useless in any other codebase. I refer to this type of knowledge as the “how” as in, “How do I do X in Angular?”.

Enduring Knowledge

The more enduring kind of knowledge is the “why”. Why does Angular exist? Why does it have the features that it has? What problems is it trying to solve?
Frameworks like Angular may have a short lifespan, but the problems they tackle live on for much longer. Angular was built to tackle the problem of writing, maintaining, and iterating on complex web apps. Any knowledge that helps us approach this problem will be valuable for a long time. In fact, it’s not a huge stretch to swap “web apps” for “software”, and suddenly we’ve got a problem that’s going to last an entire career! That’s the kind of knowledge we want — the enduring kind.

Diving Deep

Asking “why” and getting to those enduring nuggets of knowledge isn’t always easy unfortunately. The context and motivation behind a particular feature is the kind of knowledge that’s harder to come by, but it’s well worth the effort. Let’s go through an example.

Say I google “Why should I use Angular”. I might run into reasons like this:

1. MVC and separation of concerns
2. Two-way data binding
3. Dependency Injection

If I don’t know what MVC and dependency injection are and why they’re good practices, then I’m simply left with more questions. Why would I want dependency injection? And why is separation of concerns useful?
So let’s keep digging (this is super simplified):

1. Angular uses dependency injection…
2. …and dependency injection is useful for writing unit tests
3. …and unit tests are useful for maintaining and iterating on software

Got it! Now I learned about dependency injection, which a generic design pattern that’ll be useful to me past Angular’s lifetime. This knowledge also helps me better understand how and when to use that Angular feature, and when I can ignore it. Practical knowledge for our Angular work today, and enduring design pattern knowledge for the future. Win-win!

In general, asking why is a recursive process, just like installing a software dependency. We have to follow all the recursive dependencies until they all resolve, otherwise we end up with broken software or in this case, incomplete understanding. We have to continually dig deeper until we hit a layer whose value we understand. Kids know this intuitively!

Your brain’s dependency tree

Here’s how I (simplistically) imagine the “Why Angular” knowledge dependency tree:

1. At the top level we have the most specialized and most fleeting solutions: frameworks like Angular.
2. One level deeper, we get into specific patterns that are common across different frameworks: DI, MVC, etc.
3. As we dive deeper, we get into more fundamental software engineering practices, and so on until we arrive at core problems in software engineering.

I love this visualization because it exposes the deeper level concepts for what they are: building blocks. Once we dive deep into a framework that uses MVC and learn what MVC is all about, then we’ll carry that understanding over to any other MVC framework we use in the future. It’s just like when a package manager installs a new package and finds one of the dependencies already installed — it can just reuse it.

Having more building blocks doesn’t just makes us faster learners, it’s also essential for innovating new solutions. Almost every new piece of software is inspired by many other ideas before it. One example is redux, which is inspired by Flux, CQRS, Event Sourcing, and probably more (perhaps Clojure atoms). We stand on the shoulders of giants not just by using the software they built, but by understanding the ideas they introduced.

Personal Reflection

When working on a project the path of least resistance can be copy, paste and ship. But isn’t the best idea for personal growth.

You can get more value from these projects by:

1. understanding the frameworks(Angular’s) decisions within the context of the problems it was solving
2. asking why and not being afraid of following the rabbit holes
3. understanding the motivations and tradeoffs behind the Angular features

We should learn frameworks not just to build stuff, but to learn new ideas because once a framework is out of use, the ideas are all that’s left. But when a framework doesn’t teach us anything new, I am reminded of Alan Perlis’s quote:

• “A language [or framework] that doesn’t affect the way you think about programming, is not worth knowing.”

Even if frameworks come and go, we can still learn the ideas behind them and become better engineers, as long as we dive deep enough.

my thanks to this great blog post:
https://hackernoon.com/how-ages-faster-than-why-712e25c9eb3b

In software, we use version numbers to signal that something has changed.

But when it comes to software version numbers, the current leader in version numbering schemes is SemVer (or Semantic Versioning). Don't be fooled, though! Many people claim to know how SemVer works, but have never read the specification. Since this is a critical piece of what we are about to talk about, here is a summary of the spec:

Version numbers take the form X.Y.Z, sometimes augmented with additional pre-release and build information: X.Y.Z-AAA#BBB. And each of those fields means something well defined and specific.

SemVer Summary

1. X is the major number. Changes in this indicate breaking changes to the API (and/or behavior).
2. Y is the minor number. Changes to this number indicate that new features were added, but that no APIs are broken as a result.
3. Z is the patch version. Changes to this indicate that internal changes were made, but that no changes (even compatible changes) were made to the API.

Countless projects use a format that looks like SemVer, but many of them ignore the semantics behind the version number. Often, it seems that version numbers are incremented by "gut feel" instead of any consistent semantic: "This feels like a minor version update."

Why use versioning

Version numbers help your users understand something about the nature of the changes they can expect. If you don't follow a pattern, they are left guessing. And this frustrates people.

Following SemVer introduces rigor on two fronts:

1. It sends clear signals to users about the depth of changes they can expect in a release.
2. It sends a clear signal to your developers about what is, and what is not, allowed when it comes to changing the code.

I cannot understate the importance of (2). SemVer helps us impose self-discipline, which in turn minimizes both internal and external disruption.

Reorganizing, Refactoring, and Renaming

If you reorganize the package structure of your public API, or if you do a major renaming, or if you choose to change the methods/structs/classes/etc of your public API, you must increment the major version number.
Such changes mean that anyone who's using your code will experience breakage.

It's okay to make internal changes that don't touch any public API items. So minor internal-only refactoring can be done in minor, and even patch, releases (though we don't recommend doing it in patch releases).

So in effect, the following are not be be changed except during major updates:

1. Package structure
2. Public class, struct, enum, trait, interface, etc. names, nor the names of any of the items on these
3. Constants or public variable names or values
4. Function/method names
5. Function/method signatures for existing functions except where the change is additive and the added argument is optional. Return value types and exceptions must also not change.

Introducing New Features

Minor versions may introduce new features, but features must be introduced without breaking existing APIs.

Features are additive in nature: They bring new things, but do not modify or delete existing things.

Deprecating

1. Mark a thing as deprecated as soon as it is considered deprecated, even if that is a patch or minor release. Deprecation, after all, is a warning condition, not an error condition.
2. Do not change the behavior of the deprecated thing during minor or patch releases
3. Remove deprecated things only at major version changes. Until that time, you're still on the hook for supporting them.

Deprecation is a signal that in the future a thing will be removed. But it is not an excuse to change, delete, or ignore the functionality of that bit of code outside of the SemVer constraints.

Errors and Exceptions

Do not make casual changes to what exceptions are thrown and when.

Bugs and Security Fixes: How To Handle Real Life

When the real world comes crashing in, we make exceptions. But professional software developers make them wisely and carefully.

The important concept here is the minimally invasive change. That is, when patching bugs or security releases, we may need to change the API, but we should do it by changing the absolute minimum number of things we can get away with. And we do that even if it means sacrificing our "architectural purity".

Conclusion

The professional software developer has long-term usability and stability as a goal. Yes, well-architected code is important. But there is a time and place for making that your focus. And maintenance releases (minor and patch versions) are not an occasion to refactor, re-organize, or make sweeping modifications.

Be conscientious about how much effort the users of your code put into using your code. I can tell you from experience what we do when the maintenance burden you impose on us gets wearying: We stop using your tools (or we fork them).

SemVer is a communications tool. But to use it well, we must use it accurately. And that means writing code focused on stability.

my thanks to this great article:

http://technosophos.com/2018/07/04/be-nice-and-write-stable-code.html

How to run JMeter:

• 1) Download JMeter Archive,
• 2) Unzip the archive,
• 3) Run jmeter executable in bin/ folder. Executable extensions depends on OS (.bat for Windows, .sh for Linux / MaC)
• 4) JMeter should launch the UI!

Create Request

1)Add http Headers ie Sampler

Right-click on the TestPlan Add->Config Element->Http Header Manager

Add necessary http headers.

2) Create a ThreadGroup by right clicking on the Test Plan

Right-click on the TestPlan Add -> Threads (users) -> Thread Group.

The ThreadGroup is a container for the logic which will be run by a user thread.

3)Add http Request

Right-click on the ThreadGroup, then select Add -> Sampler -> Http Request.

Add server name, http method, path and parameters etc here

4) Add results viewers ie listeners

Add->Listener->View Results Tree
Add->Listener->Graph Results
Click on the Play button to run.

Graph Analysis

At the bottom of the graph, there are the following statistics, represented in colors:

• Black: The total number of current samples sent.
• Blue: The current average of all samples sent.
• Red: The current standard deviation.
• Green: Throughput rate that represents the number of requests per minute the server handled

The Throughput is the most important parameter. It represents the ability of the server to handle heavy load. The higher the Throughput is, the better is the server performance.

The deviation is shown in red - it indicates the deviation from the average. The smaller the better.
https://www.guru99.com/jmeter-performance-testing.html



Analyze the results
https://octoperf.com/blog/2017/10/19/how-to-analyze-jmeter-results/

my thanks to these awesome sites:
https://www.guru99.com/jmeter-element-reference.html
https://octoperf.com/blog/2018/03/29/jmeter-tutorial

Table of contents.



my thanks to a great article here:
https://recurse.henrystanley.com/post/better/