Merge branch 'hassanhabib:master' into master

0. Introduction/0.2 Principles.md

@@ -1,25 +1,25 @@
 # 0.2 Principles
-In this chapter, we will explore the principles of The Standard. These principles apply to all components in Standard-compliant system. Whether these components are brokers, services or exposers.
+In this chapter, we will explore the principles of The Standard. These principles apply to all components in a Standard-compliant system, whether these components are brokers, services, or exposers.
 
 ## 0.2.0 People-First
-The main idea of this principle is to build and design Standard-compliant systems with people in mind. Not just the people who are going to utilize the system but also the people who are going to be maintaining and evolving it.
+The main idea of this principle is to build and design Standard-compliant systems with people in mind, not just the people who will utilize the system but also the people who will be maintaining and evolving it.
 
-In order for a system to follow the people-first principle it must honor simplicity over complexity. Simplicity leads to rewritability. It also leads to designing monolithic systems that are built with modulus mindset to allow a true fractability in the overall pattern of the system.
+A system must honor simplicity over complexity to follow the people-first principle. Simplicity leads to rewritability. It also leads to designing monolithic systems built with a modular mindset to allow a true fractality in the overall pattern of the system.
 
-The Standard also enforces the principles of measuring advanced engineering concepts against the understanding of mainstream engineers. New engineers in the industry are the leaders of tomorrow. If they are not buying in on any system they'll eventually give-up and rewrite it over and over again.
+The Standard also enforces the principles of measuring advanced engineering concepts against the understanding of mainstream engineers. New engineers in the industry are the leaders of tomorrow. If they are not buying in on any system, they'll eventually give up and rewrite it repeatedly.
 
 ### 0.2.0.0 Simplicity
-Code written according to The Standard has to be simple. There are measures to ensure this simplicity takes place, these measures are as follows:
+Code written according to The Standard has to be simple. There are measures to ensure this simplicity takes place; these measures are as follows:
 
 #### 0.2.0.0.0 Excessive Inheritance
-Any software written according to The Standard shall not have more than one level of inheritance. Over one level of inheritance will be considered excessive and prohibited. Except in cases of versioning for the vertical scaling of flows. Excessive inheritance has proven itself over the years to be a source of confusion and difficulty in terms of readability and maintainability.
+Any software written according to The Standard shall not have more than one level of inheritance. Over one level of inheritance will be considered excessive and prohibited except in cases of versioning for the vertical scaling of flows. Excessive inheritance has proven to be a source of confusion and difficulty in terms of readability and maintainability over the years.
 
 #### 0.2.0.0.1 Entanglement
 
 ##### 0.2.0.0.1.0 Horizontal Entanglement
-Building "common" components in every system with the promise to simplify the development process is another prohibited practice in Standard-compliant systems. This practices manifests itself in components with names like `Utils`, `Commons` or `Helpers`. These terminologies and what they imply in terms of false promised simplifications are not allowed. Any system built according to The Standard should be comprised of Brokers, Services or Exposers, nothing more or less.
+Building "common" components in every system with the promise to simplify the development process is another prohibited practice in Standard-compliant systems. This practice manifests itself in components with names like `Utils`, `Commons` or `Helpers`. These terminologies and what they imply in terms of false promised simplifications are not allowed. Any system built according to The Standard should be comprised of Brokers, Services, or Exposers, nothing more or less.
 
-Another example of horizontal entanglements are shared models across multiple independent flows - sharing exceptions, validation rules or any other form of entanglement across multiple flows.
+Another example of horizontal entanglements is shared models across multiple independent flows - sharing exceptions, validation rules, or any other form of entanglement across multiple flows.
 
 <br />
     <div align=center>
@@ -28,9 +28,9 @@ Another example of horizontal entanglements are shared models across multiple in
 <br />
 
 ##### 0.2.0.0.1.1 Vertical Entanglement
-This principle also applies to scenarios where base components are used. Unless these base components are native or external they will not be allowed in a Standard-compliant system. Local base components create a vertical level of entanglement that harms the maintainability and readability of code. Vertical entanglements are just as harmful as `Commons` components that create single points of failure across any system.
+This principle also applies to scenarios where base components are used. Unless these base components are native or external, they will not be allowed in a Standard-compliant system. Local base components create a vertical level of entanglement that harms the maintainability and readability of code. Vertical entanglements are just as harmful as `Commons` components, creating single points of failure across any system.
 
-Entanglements (vertical or horizontal) also prevent engineers in any system (especially newcomers) from fully understanding the depth of the system and fully own it's functionality. They also prevent engineers from having the opportunity to build end-to-end flows when half of the functionality is presumably componentized for the sake of development expedition and simplicity. 
+Entanglements (vertical or horizontal) also prevent engineers in any system (especially newcomers) from fully understanding the depth of the system and fully own its functionality. They also prevent engineers from having the opportunity to build end-to-end flows when half of the functionality is presumably componentized for the sake of development expedition and simplicity. 
 
 <br />
     <div align=center>
@@ -39,54 +39,54 @@ Entanglements (vertical or horizontal) also prevent engineers in any system (esp
 <br />
 
 #### 0.2.0.0.2 Autonomous Components
-This principle favors duplication over presumed simplification via code entanglement. Every component in every system should be self-sufficient. Every component implements it's own validations, tooling and utilities in one of it's dimensions with no hard-dependency on any other external components except through dependency injection.
+Every component in every system should be self-sufficient. Every component implements its own validations, tooling, and utilities in one of its dimensions with no hard dependency on any other external components except through dependency injection. This principle favors duplication over presumed simplification via code entanglement.
 
-Autonomous components will open up the opportunity for every single engineer on every team to fully own every dependency and tool their component may need to fulfil it's purpose. This may cause a bit of duplication in some of the code for the sake of opening an equal opportunity for every developer to fully learn how to build and evolve a component.
+Autonomous components will open up the opportunity for every engineer on every team to fully own every dependency and tool their component may need to fulfill its purpose. This may cause a bit of duplication in some of the code to open an equal opportunity for every developer to learn how to build and evolve a component fully.
 
 ##### 0.2.0.0.2.0 No Magic
-Autonomous components put all their routines up in front of the engineer. No hidden routines, shared libraries or magical extensions that require chasing references once an inevitable split of the big monolith begins to occur.
+Autonomous components put all their routines up front, in plain sight of the engineer. No hidden routines, shared libraries, or magical extensions that require chasing references once an inevitable split of the big monolith begins to occur.
 
-We will treat Objects the way they are in nature. multi-dimensional components that are self-containerized like atoms in nature. These components perform their own validations, exception handling, tracing, security, localization and everything else in between.
+We will treat Objects the way they are in nature: multi-dimensional components self-containerized like atoms in nature. These components perform their own validations, exception handling, tracing, security, localization, and everything else.
 
 <br />
 	<div align=center>
 		<img src="https://user-images.githubusercontent.com/1453985/169712032-3184e22a-d91f-4baa-a0f2-657de294220b.png" />
 	</div>
 <br />
 
-Components built according to The Standard strictly adheres to the idea of _What You See Is What You Get_ (WYSIWYG) - everything concerning the components will be on the component itself.
+Components built according to The Standard strictly adhere to the idea of _What You See Is What You Get_ (WYSIWYG) - everything concerning the components will be on the component itself.
 
 ## 0.2.1 Rewritability
-Every system should be developed with the rewritability principle in mind. The principle dictates that our assumptions in the systems we develop has the high potentiality of being reexamined and probably reconsidered. Every system out there should be easily rewritable as a measure of adherence to a forever growing and changing business requirements.
+Every system should be developed with the rewritability principle in mind. The principle dictates that our assumptions in the systems we develop have the high potential of being reexamined and probably reconsidered. Every system should be easily rewritable as a measure of adherence to forever growing and changing business requirements.
 
-Rewritable code is code that is easy to understand, modify and fully rewrite. Rewritable code is extremely modular and autonomous it encourages engineers to evolve it with the least amount of effort and risk possible.
+Rewritable code is code that is easy to understand, modify and fully rewrite. Rewritable code is extremely modular and autonomous; it encourages engineers to evolve it with the least effort and risk possible.
 
-Rewritable code doesn't play tricks on the reader. There are no hidden dependencies, injected routines at runtime nor unknown prerequisites. It should be plug-n-play - fork, clone, build and run all it's tests successfully with no issues. 
+Rewritable code doesn't play tricks on the reader. It should be plug-n-play - fork, clone, build and run all its tests successfully with no issues. There are no hidden dependencies, injected routines at runtime, nor unknown prerequisites. 
 
 ## 0.2.2 Mono-Micro
-Building monolithic systems with modular mindset. Every flow should be built fully independent from other flows. For instance, we may build a monolithic system with microservice mindset. Which means that any flow can be extracted out of the system and turned into it's own microservice or lambda with the least amount of effort possible.
+Build monolithic systems with a modular mindset, with every flow fully independent from other flows. For instance, we may build a monolithic system with a microservice mindset, meaning that any flow can be extracted out of the system and turned into its own microservice or lambda with the least effort possible.
 
-This principle goes hand in hand with the concept of autonomous components at a higher-level where flows are also autonomous from their neighboring flow and their hosting system.
+This principle goes hand in hand with the concept of autonomous components at a higher level where flows are also autonomous from their neighboring flow and their hosting system.
 
 ## 0.2.3 Level 0
-Code must be understandable by an entry-level individual in the engineering craft. Our code base continues to live only based on how easy it is to understand by the mass majority of engineers in the industry. The mass-majority of engineers in our industry will always be those who are new in the craft.
+Code must be understandable by an entry-level individual in the engineering craft. The majority of engineers in our industry will always be those who are new to the craft. Our code base continues to live on based on how easy it is to understand by most engineers in the industry.
 
 Level 0 engineers are our measure of success. Their ability to understand our code is our reassurance that this very code will continue to live and evolve with the next generation of engineers.
 
-This principle also mandates every engineer in the industry to cross-examine their code and pair with juniors in the field to see if they meet this principle.
+This principle also mandates that every engineer in the industry closely examine their code and pair with juniors in the field to see if they meet this principle.
 
 ## 0.2.4 Open Code
-Open code as a principle dictates that everything written according to The Standard should be commonly available to the public. Developing internal tools that is not accessible shall inevitably harm the engineering experience for those who are trying to evolve these very tools. This applies to internal artifactory practices, on-trial libraries and any other form of module development that doesn't allow every engineer everywhere to learn and evolve any given system.
+Open code as a principle dictates that everything written according to The Standard should be commonly available to the public. This applies to internal architectural practices, trial libraries, and any other form of module development that doesn't allow every engineer to learn and evolve any given system. Developing internal tools that are not accessible shall inevitably harm the engineering experience for those who are trying to evolve these very tools.
 
-The principle also recognizes that under extreme circustances, such as when saftey or security are threatened or under some contractural obligation, one cannot make code, tooling, platforms and patterns available to the public. However, making the source proprietary solely for personal or organizational gain is not permitted by The Standard.
+The principle also recognizes that under extreme circumstances, such as when safety or security are threatened, or under some contractual obligation, one cannot make code, tooling, platforms, and patterns available to the public. However, making the source proprietary solely for personal or organizational gain is not permitted by The Standard.
 
 ## 0.2.5 Airplane Mode (Cloud-Foreign)
-The Standard enforces the idea of airplane mode. Where engineers can stand-up their entire infrastructure on their local machine without needing or having any form of network connection. This principle goes heavily against principles such as Cloud-Native applications where a given system cannot stand and run without cloud infrastructure.
+The Standard enforces the idea of airplane mode. Where engineers can stand up their entire infrastructure on their local machine without needing or having any network connection, this principle goes heavily against principles such as Cloud-Native applications, where a given system cannot stand and run without cloud infrastructure.
 
-The Standard also encourages it's adapters to develop the proper tooling to bridge the gap between cloud infrastructural components and local components such as queues, event hubs and any other tools to make it easily testable and modifiable.
+The Standard also encourages its adopters to develop the proper tooling to bridge the gap between cloud infrastructural components and local components such as queues, event hubs, and other tools to make it easily testable and modifiable.
 
 ## 0.2.6 No Toasters
-The Standard shall be taught man to man not machine to man. There should be no stylecops or analyzers implemented to force people into following The Standard. It should be driven by passion in the heart and conviction in the mind. The Standard should be taught by people to people. It's meant to foster an engineering culture of open discussions, conviction and understanding.
+The Standard shall be taught man to man, not machine to man. No stylecops or analyzers should be implemented to force people into following The Standard. It should be driven by passion in the heart and conviction in the mind. The Standard should be taught by people to people. It's meant to foster an engineering culture of open discussions, conviction and understanding.
 
 ## 0.2.7 Pass Forward
-The Standard shall be taught at no cost. As it arrived to you at no cost. It should be passed forward to the next engineer also at no cost. Regardless of their financial, social or educational status. The Standard is pure knowledge given by the selfless to the selfless. There shall be no profiteering off of it, neither shall it be a reason for someone to belittle others or make them feel less. Teaching The Standard for profit violates The Standard, and denies it's beneficiary any further guidance from The Author.
+The Standard shall be taught at no cost as it arrived to you at no cost. It should be passed forward to the next engineer also at no cost, regardless of their financial, social, or educational status. The Standard is pure knowledge given by the selfless to the selfless. There shall be no profiteering off of it; neither shall it be a reason for someone to belittle others or make them feel less. Teaching The Standard for profit violates it and denies the beneficiary (the violator) any further guidance from The Author.