Merge pull request #6 from sha1sum/language-fixes

Grammar & Spelling Fixes

README.md

@@ -56,12 +56,11 @@ To support the laid-out activities specific skills are required. From my experie
 ## (1) Design
 What makes a good design? This is probably the most important and challenging question. I will make a distinction between theory and practice. To my experience, having a mix of both is most valuable. Let’s start with theory:
 
-* **Know the basic design patterns**: Patterns are one of the most important tool an architect needs to have to develop maintainable systems. With patterns you can reuse design to solve common problems with proven solutions. The book “Design Patterns: Elements of Reusable Object-Oriented Software” written by John Vlissides, Ralph Johnson, Richard Helm, Erich Gamma is a must read to everyone who is in software development. Although the pattern where published more than 20 years ago they are still the basis of modern software architecture. For example the Model-View-Controller (MVC) pattern was described in this book which is applied in many areas or is the basis for newer pattern, e.g. MVVM.
-* **Dig deeper into patterns and anti-pattern**: If you already know all basic GoF patterns, then extend your knowledge with more software design patterns. Or dig deeper into your area of interest. One of my favorite for application integration is the book “Enterprise Integration Patterns” written by Gregor Hohpe. This book is applicable in various areas whenever two applications need to exchange data, whether it is an old school file exchange from some legacy systems or modern Microservice architectures.
-* **Know quality measures**: Defining architecture is not an end. It has reasons why guidelines and coding standards are defined, applied and controlled. You do this because of quality and non-functional requirements. You want to have a system which is maintainable, reliable, adaptable, secure, testable, scaleable, usable, etc. And one piece to achieve all these quality attributes is to apply good architecture work. You could start to learn more about quality measures on wikipedia.
-Theory is important. Practice is equally or even more important if you do not want to become an Ivory Tower Architect.
-
-* **Try out and understand different technology stacks**: I think this is the most important activity if you want to become a better architect. Try out (new) technology stacks and learn their ups and downs. Different or new technology comes with different design aspects and patterns. You most likely do not learn anything from just flipping through abstract slides but by trying it out by yourself and feel the pain or the relieve. An architect should not only have broad but also in some areas deep knowledge. It is not important to master all technology stacks but to have a solid understanding of the most important in your area. Also try out technology which is not in your area, e.g., if you are deep into SAP R/3 you should also try JavaScript and vice versa. Still, both parties will be surprised about the latest advances in SAP S/4 Hana. For example, you can try it by yourself and take a course at openSAP for free. Be curious and try out new things. Also try out stuff which you did not liked some years ago.
+* **Know the basic design patterns**: Patterns are one of the most important tools an architect needs to have to develop maintainable systems. With patterns you can reuse designs to solve common problems with proven solutions. The book “Design Patterns: Elements of Reusable Object-Oriented Software” written by John Vlissides, Ralph Johnson, Richard Helm, Erich Gamma is a must-read to everyone who is in software development. Although the patterns were published more than 20 years ago they are still the basis of modern software architecture. For example, the Model-View-Controller (MVC) pattern was described in this book, which is applied in many areas or is the basis for newer pattern, e.g. Model-View-ViewModel (MVVM).
+* **Dig deeper into patterns and anti-patterns**: If you already know all basic Gang-of-Four patterns, then extend your knowledge with more software design patterns or dig deeper into your area of interest. One of my favorite books about application integration is “Enterprise Integration Patterns” written by Gregor Hohpe. This book is applicable in various areas whenever two applications need to exchange data, whether it is an old-school file exchange from some legacy systems or a modern microservice architecture.
+* **Know quality measures**: Defining architecture is not the end. There are reasons why guidelines and coding standards are defined, applied and controlled. You do this because of quality and non-functional requirements. You want to have a system which is maintainable, reliable, adaptable, secure, testable, scaleable, usable, etc. And one piece to achieving all of these quality attributes is applying good architecture work. You can start to learn more about quality measures on Wikipedia.
+Theory is important. Practice is equally—or even more—important if you do not want to become an Ivory Tower Architect.
+* **Try out and understand different technology stacks**: I think this is the most important activity if you want to become a better architect. Try out (new) technology stacks and learn their ups and downs. Different or new technology comes with different design aspects and patterns. You most likely do not learn anything from just flipping through abstract slides but by trying it out by yourself and feeling the pain or the relief. An architect should not only have broad, but—also in some areas—deep knowledge. It is not important to master all technology stacks but to have a solid understanding of the most important in your area. Also, try out technology which is not in your area, e.g., if you are deep into SAP R/3 you should also try JavaScript and vice versa. Still, both parties will be surprised about the latest advances in SAP S/4 Hana. For example, you can try it by yourself and take a course at openSAP for free. Be curious and try out new things. Also try out stuff which you did not like some years ago.
 * **Analyze and understand applied patterns**: Have a look at any current framework, e.g., Angular. You can study a lot of patterns in practice, e.g., Observables. Try to understand how it is applied in the framework, why it was done. And if you are really dedicated, have a deeper look into the code and understand how it was implemented.
 * **Be curious and attend User Groups**. [Meetup](https://www.meetup.com/)