Fix typos

radar/2019-11-01/container-based-builds.md

@@ -5,4 +5,4 @@ quadrant:   methods-and-patterns
 
 ---
 
-Updated to "adopt". Container based builds has getting to the defacto standard for our pipelines in [Gitlab](/tools/gitlab.html) or other CI Tools.
+Updated to "adopt". Container based builds has getting to the de facto standard for our pipelines in [Gitlab](/tools/gitlab.html) or other CI Tools.

radar/2019-11-01/event-storming.md

@@ -19,7 +19,7 @@ It's like brainstorming - with the goal to visualize a business line or process.
 Event Storming is done in a workshop format.
 
 To get a business process modeled quickly and complete, it's important to get domain experts, developers, UX and
-everybody else who is involved to some extend in the related business line into one room.
+everybody else who is involved to some extent in the related business line into one room.
 With virtually unlimited space for modeling using big paper rolls put onto the walls, equipped with colored stickies
 and markers, the modeling workshop can start.
 

radar/2019-11-01/flamingo.md

@@ -18,22 +18,22 @@ Flamingo is:
 Go as simple, powerful and typesafe language is great to implement and scale serverside logic.
 Flamingo has a clean architecture with clear dependencies in mind and offers a typical features and support for nowadays web applications:
 
-* Powerful Templating Engines. E.g. support for Pug templates with reusable mixins and lightweight scripting.
+* Powerful Templating Engines, e.g. support for Pug templates with reusable mixins and lightweight scripting.
 * Configuration concepts using yml and support for multiple areas and contexts
 * Powerful Dependency Injection
 * A Module concept for building modular and pluggable applications
 * Authentication concepts and security middleware
 * Flexible routing with support for prefix routes and reverse routing
 * Web Controller Support with: Request / Response / Form Handling etc
-* Operational Readyness: Logging, (distributed) Tracing, Metrics and Healthchecks with seperate endpoint
+* Operational Readyness: Logging, (distributed) Tracing, Metrics and Healthchecks with separate endpoint
 * Localisation
 * Commands
-* Sessionhandling and Management
+* Session Handling and Management
 * GraphQL support and therefore support to build nice SPA and PWAs on top of it
 * Resilience and Caching for external APIs calls.
 
-Flamingo itself does not contain ORM Mapper or libraries - instead it emphasizes ["ports and adapters"](/methods-and-patterns/ports-and-adapters.html)  architecture - so that you have a technology free (domain) model and any possible (and replaceable) persitence behind it.
+Flamingo itself does not contain ORM Mapper or libraries - instead it emphasizes ["ports and adapters"](/methods-and-patterns/ports-and-adapters.html)  architecture - so that you have a technology free (domain) model and any possible (and replaceable) persistence behind it.
 That makes Flamingo useful to build microservices and applications - especially to build "frontends" or portals that require interaction with other (micro) services in a distributed architecture. 
-When sticking to the architectural recommendation you can build modular applications with replaceable adapters that gives you independed testability.
+When sticking to the architectural recommendation you can build modular applications with replaceable adapters that gives you independent testability.
 
 With **"Flamingo Commerce"** there is an additional active projects that offer rich and flexible features to build modern e-commerce applications.

radar/2019-11-01/flowtype.md

@@ -4,5 +4,5 @@ ring:       assess
 quadrant:   tools
 
 ---
-[Flow](https://flow.org/) is a static type checker for JavaScript code. It's goal is to make code faster, smarter, 
+[Flow](https://flow.org/) is a static type checker for JavaScript code. Its goal is to make code faster, smarter, 
 more confidently, and to a bigger scale.

radar/2019-11-01/gitflow.md

@@ -6,9 +6,9 @@ quadrant:   methods-and-patterns
 ---
 Ever since there are recurring discussions about the version control strategy that a team should use.
 
-We have also made the experience when new teams start off with using blocking or long lived feature branches (merge late once all review comments are done) it has a negative impact on team performance.
+We have also made the experience when new teams start off with using blocking or long-lived feature branches (merge late once all review comments are done) it has a negative impact on team performance.
 
-We recommend to use trunk based development with short lived (<1day) feature branches, because this has shown to support continuous integration and team collaboration the best. However we do accept teams choices to use GitFlow, we just do not try to encourage them in the first place.
+We recommend to use trunk based development with short-lived (<1day) feature branches, because this has shown to support continuous integration and team collaboration the best. However, we do accept teams choices to use GitFlow, we just do not try to encourage them in the first place.
 
 See also:
 * trunk based development https://trunkbaseddevelopment.com/

radar/2019-11-01/graphql.md

@@ -12,8 +12,8 @@ The main challenge it solves is to improve communication between browser and ser
 
 The advantages are:
 * schema and schema validation together with a useful type system
-* the client (browser) controls what data should be send (data reduction)
-* whith one request you can fetch "all" required data
+* the client (browser) controls what data should be sent (data reduction)
+* with one request you can fetch "all" required data
 
 We are using it together with [Apollo Client](/tools/apollo-client.html) in our [React.js](/languages-and-frameworks/react.html) based frontend.
 This way the React components have their relevant GraphQL snippet, defining what data they request or mutate from the "backend for frontend", directly coupled. 

radar/2019-11-01/grpc.md

@@ -5,4 +5,4 @@ quadrant:   languages-and-frameworks
 
 ---
 
-We adopted GRPC, because its used on multiple places within our microservice oriented architectures for internal communication.
+We adopted GRPC, because it is used on multiple places within our microservice oriented architectures for internal communication.

radar/2019-11-01/hal-hateoas.md

@@ -5,4 +5,4 @@ quadrant:   methods-and-patterns
 featured:   false
 ---
 
-We use HAL in cases where we need to link ressources in payloads. HATEOAS has not proven to be very useful in our projects.
+We use HAL in cases where we need to link resources in payloads. HATEOAS has not proven to be very useful in our projects.

radar/2019-11-01/hystrix.md

@@ -5,4 +5,4 @@ quadrant:   tools
 featured:   false
 ---
 
-Hystrix is not actively mainatined anymore and some of its goals can now be handled with service meshs.
+Hystrix is not actively maintained anymore and some of its goals can now be handled with service meshs.

radar/2019-11-01/jaeger.md

@@ -7,5 +7,5 @@ quadrant:   platforms-and-aoe-services
 
 [Jaeger](https://www.jaegertracing.io/) is a tool for [Distributed Tracing](/platforms-and-aoe-services/distributed-tracing.html). Developed at Uber and inspired by Dapper and OpenZipkin it grew into an [Cloud Native Computing Foundation](https://www.cncf.io/) project.
 
-Jaeger is a great tool for troubleshooting distributed systems, such as microservice architectures. Developers and Operation can quickly see communicaiton between services, and what data is communicated where.
+Jaeger is a great tool for troubleshooting distributed systems, such as microservice architectures. Developers and Operation can quickly see communication between services, and what data is communicated where.
 Errors in services can be traced to the originating system. Global trace identifiers are communicated using B3 headers. Jaeger supports Zipkin, which allows easy migration von OpenZipkin & co.

radar/2019-11-01/kotlin.md

@@ -12,5 +12,5 @@ From the beginning it was designed with practical thought in mind. So the IDE Su
 
 The Spring Framework Developer put a lot of effort that Springs play well together with Kotlin. 
 
-With it's concise syntax, null safety, 
+With its concise syntax, null safety, 
 Due to its explicit type system, this language is also great replacement for Groovy usage with Gradle.

radar/2019-11-01/open-api.md

@@ -8,7 +8,7 @@ quadrant:   tools
 The OpenAPI Specification is becoming a broadly adopted industry standard for describing modern REST APIs. Other initiatives like RAML have [joined](https://blogs.mulesoft.com/dev/api-dev/open-api-raml-better-together/) the OpenAPI Initiative.
 
 OpenAPI v2 version is basically the former Swagger - and Swagger provides useful tools for OpenAPI like the online editor and viewer http://editor.swagger.io/
-We have also found that this version currently have a good tool support accross languages, so you will find API client and server generation tools for a lot of languages, which makes it quite easy to connect to an API that is described in OpenAPI standard.
+We have also found that this version currently have a good tool support across languages, so you will find API client and server generation tools for a lot of languages, which makes it quite easy to connect to an API that is described in OpenAPI standard.
 
 
 **OpenAPI v3**

radar/2019-11-01/rabbitmq.md

@@ -4,4 +4,4 @@ ring:       adopt
 quadrant:   tools
 
 ---
-RabbitMQ has proven to work very well for messaging in our projects, thats why we updated it to "adopt". 
+RabbitMQ has proven to work very well for messaging in our projects, that is why we updated it to "adopt". 

radar/2019-11-01/raml.md

@@ -5,6 +5,6 @@ quadrant:   languages-and-frameworks
 
 ---
 
-Since the RAML project has decided to [join](https://blogs.mulesoft.com/dev/api-dev/open-api-raml-better-together/) the OpenAPI initiative and the RAML ecosystem lacks further development and additional tools, we decided to  use and recommend using ["OpenAPI specififcation (OAS)"](/tools/open-api.html) as description standard instead.
+Since the RAML project has decided to [join](https://blogs.mulesoft.com/dev/api-dev/open-api-raml-better-together/) the OpenAPI initiative and the RAML ecosystem lacks further development and additional tools, we decided to  use and recommend using ["OpenAPI specification (OAS)"](/tools/open-api.html) as description standard instead.
 
 RAML still provides advantages in modeling an API through it's more expressive modeling language and can produce OAS

radar/2019-11-01/temporal-modeling.md

@@ -15,7 +15,7 @@ model and too far away from reality.
 
 By focusing on the domain processes first, one can visualize all aspects of a process over time.
 Having the process visualized, allows to see potential pitfalls or forgotten aspects.
-With a temporal model at hand, it is easy to create a object-oriented or structural model that perfectly
+With a temporal model at hand, it is easy to create an object-oriented or structural model that perfectly
 represents all required information.
 
 We tried this method when tackling big or complex domains. 

radar/2019-11-01/terraform.md

@@ -7,7 +7,7 @@ quadrant:   platforms-and-aoe-services
 [Terraform](https://www.terraform.io/) is a tool for building, changing and versioning infrastructure using the infrastructure as code pattern.
 Terraform supports popular service providers like AWS, Google Cloud Platform, Azure and many more.
 
-Infrastructure is described in configuration files trough the HCL (HashiCorp Configuration Language), which brings a set of string interpolations and built-in functions, 
+Infrastructure is described in configuration files through the HCL (HashiCorp Configuration Language), which brings a set of string interpolations and built-in functions, 
 including conditionals and loops. Terraform validates configuration files before trying to run updates. It checks not only that all files use the correct syntax, 
 but also that all parameters are accessible and the configuration as a whole is valid. In Terraform, you can (and should) run a ‘plan’ step before applying any changes. 
 This step tells you precisely what is going to change and why.