Fix typos and change some grammatical constructions

radar/2017-03-01/ant.md

@@ -4,6 +4,10 @@ ring:       hold
 quadrant:   tools
 ---
 
-Apache Ant was build in 1997 to have something like Make in the C/C++ world for Java. Ant uses xml files to describe steps required to produce executable artifacts from source code. The main concepts of tasks and targets are programmable in an imperative style.
+Apache Ant was build in 1997 to have something like Make in the C/C++ world for Java.
+Ant uses xml files to describe steps required to produce executable artifacts from source code.
+The main concepts of tasks and targets are programmable in an imperative style.
 
-Apache Ant was and is widely used by large software projects. Our recommendation is to stop using Apache Ant for new projects. If you are free to choose, we recommend Gradle as an Apache Ant replacement.
+Apache Ant was and is widely used by large software projects.
+Our recommendation is to stop using Apache Ant for new projects.
+If you are free to choose, we recommend Gradle as an Apache Ant replacement.

radar/2017-03-01/anypoint-platform.md

@@ -8,6 +8,11 @@ Anypoint platform (formerly known as Mule or Mule ESB) is an Enterprise Integrat
 
 Anypoint provides tools to use Enterprise Integration Patterns (EAI) and has a high number of ready-to-use connectors to communicate with software tools such as SAP, Salesforce, etc.
 
-Anypoint Community Version is Open Source and contribution is possible. The platform is pluggable with own connectors. Mulesoft is also driving the [RAML](/tools/raml.html) specification and related Open Source tools.
+Anypoint Community Version is Open Source and contribution is possible.
+The platform is pluggable with own connectors.
+Mulesoft is also driving the [RAML](/tools/raml.html) specification and related Open Source tools.
 
-AOE is a Mulesoft Partner and we use both the Community and Enterprise Versions of Anypoint. We use Anypoint as an API Gateway to combine and transform data from multiple backends. We use it as ESB or Integration platform for loose coupling of software components. We also use it as legacy modernization to provide modern APIs for legacy or external software.
+AOE is a Mulesoft Partner and we use both the Community and Enterprise Versions of Anypoint.
+We use Anypoint as an API Gateway to combine and transform data from multiple backends.
+We use it as ESB or Integration platform for loose coupling of software components.
+We also use it as legacy modernization to provide modern APIs for legacy or external software.

radar/2017-03-01/api-first-design-approach.md

@@ -4,13 +4,21 @@ ring:       trial
 quadrant:   methods-and-patterns
 ---
 
-The API-First Design Approach puts the API design at the beginning of the implementation without any constraints, for example, from the current IT infrastructure or the implementation itself. The idea is to design the API in a way that it serves its purpose best and the consumers are enabled to work efficiently.
+The API-First Design Approach puts the API design at the beginning of the implementation without any constraints, for example, from the current IT infrastructure or the implementation itself.
+The idea is to design the API in a way that it serves its purpose best and the consumers are enabled to work efficiently.
 
-There are several advantages to this approach. For example, it can help to avoid reflecting the internal structure of the application or any internal constraints. Furthermore, as one of the most important design aspects is consistency, one can define features such as the behavior of security, URL schemes, and API keys upfront. It also helps speed up parallel implementation. A team that consumes the API can start working directly after the API design because it can easily be mocked.
+There are several advantages to this approach. For example, it can help to avoid reflecting the internal structure of the application or any internal constraints.
+Furthermore, as one of the most important design aspects is consistency, one can define features such as the behavior of security, URL schemes, and API keys upfront.
+It also helps speed up parallel implementation.
+A team that consumes the API can start working directly after the API design because it can easily be mocked.
 
-There are several tools for modelling an API, but here at AOE we mainly use [RAML](/tools/raml.html) as it provides a rich set of tools for generating documentation, mocking and more. For mocking we use [WireMock](/tools/wiremock.html), for example.
+There are several tools for modelling an API, but here at AOE we mainly use [RAML](/tools/raml.html) as it provides a rich set of tools for generating documentation, mocking and more.
+For mocking we use [WireMock](/tools/wiremock.html), for example.
 
-Related to the "API-First" approach is the "Headless" approach where an existing application (with or without existing API) is used as a backend for a separate frontend. We used this with sucess for Magento-based E-Commerce platforms. This allows encapsulating the core features of that application, while integrating it into a larger landscape of components using its API as a unified way to interact between components. Decoupling the core logic from its presentation layer allows picking the best technology stack for the various parts independently.
+Related to the "API-First" approach is the "Headless" approach where an existing application (with or without existing API) is used as a backend for a separate frontend.
+We used this with sucess for Magento-based E-Commerce platforms.
+This allows encapsulating the core features of that application, while integrating it into a larger landscape of components using its API as a unified way to interact between components.
+Decoupling the core logic from its presentation layer allows picking the best technology stack for the various parts independently.
 
 For further reading see:
 * [Understanding API First Design](https://www.programmableweb.com/api-university/understanding-api-first-design)

radar/2017-03-01/artifactory.md

@@ -5,16 +5,20 @@ quadrant:   platforms-and-aoe-services
 ---
 
 JFrog [Artifactory](https://www.jfrog.com/open-source/)is a software tool, which, in the end, manages and stores (binary) artifacts.
-In addition to storage, it provides a managing interface, which also allows to store build information, properties as well as dependencies per artifact which are organized within repositories. A fine grained security system enables easy management of which artifacts are available to whom.
-The artifacts are exposed via an HTTP(S)-Url Artifactory, which can generate package-manager compatible manifests for the repositories. AOE utilizes Artifactory to serve Maven, Apt, Npm, Composer and Docker Repositories.
+In addition to storage, it provides a managing interface, which also allows to store build information, properties as well as dependencies per artifact which are organized within repositories.
+A fine grained security system enables easy management of which artifacts are available to whom.
+The artifacts are exposed via an HTTP(S)-Url Artifactory, which can generate package-manager compatible manifests for the repositories.
+AOE utilizes Artifactory to serve Maven, Apt, Npm, Composer and Docker Repositories.
 
 In addition to storing own assets, Artifactory is able to proxy remote Repository for and cache resolved artifacts locally. 
 This results in an increased build performance and decouples builds from external service dependencies and ensures builds still work even if they utilize outdated dependencies that might not be publicly available anymore.
 
-Artifactory provides a powerful REST-API for managing Artifacts including a powerful search AQL. It is utilized to provide complex release processes based on QA-Attributes on an artifact level.
+Artifactory provides a powerful REST-API for managing Artifacts including a powerful search AQL.
+It is utilized to provide complex release processes based on QA-Attributes on an artifact level.
 
 Artifactory at AOE currently comes with some problems, too:
 * Cleanup in Artifactory has to be done manually. Therefore, if every build is pushed to Artifactory it currently pollutes disk space since old or unused versions are never removed.
 * The Composer Integration mirroring GitHub proves to be slower than directly connecting to GitHub.
 
-AOE is using the Professional version for a central instance that can be used by different teams. We encourage teams to use Artifactory instead of Jenkins to store and manage build artifacts - and to take care of cleaning up old artifacts automatically.
+AOE is using the Professional version for a central instance that can be used by different teams.
+We encourage teams to use Artifactory instead of Jenkins to store and manage build artifacts - and to take care of cleaning up old artifacts automatically.

radar/2017-03-01/aws-lambda.md

@@ -4,6 +4,10 @@ ring:       trial
 quadrant:   platforms-and-aoe-services
 ---
 
-AWS Lambda is one of the exciting new "cloud-native" / serverless ways to run code without worrying about infrastructure. While it is possible to directly respond to web requests using the API Gateway, our teams are currently using AWS Lambda mostly for tasks outside the critical path. As a custom resource for CloudFormation, it allows us to manage all aspects of a deployment in an elegant way by simply deploying a new CloudFormation stack. Baking AMIs and doing green/blue switches are only two of the many use cases where AWS Lambda comes in very handy.
+AWS Lambda is one of the exciting new "cloud-native" / serverless ways to run code without worrying about infrastructure.
+While it is possible to directly respond to web requests using the API Gateway, our teams are currently using AWS Lambda mostly for tasks outside the critical path.
+As a custom resource for CloudFormation, it allows us to manage all aspects of a deployment in an elegant way by simply deploying a new CloudFormation stack.
+Baking AMIs and doing green/blue switches are only two of the many use cases where AWS Lambda comes in very handy.
 
-In addition to deployment automation, we're using AWS Lambda to process incoming data. Being able to respond to events from various sources such as S3 Buckets, SNS topics, Kinesis streams and HTTP endpoints it's a perfect match to process, transform and forward incoming data almost in real time at a fraction of the cost of running an ESB.
+In addition to deployment automation, we're using AWS Lambda to process incoming data.
+Being able to respond to events from various sources such as S3 Buckets, SNS topics, Kinesis streams and HTTP endpoints it's a perfect match to process, transform and forward incoming data almost in real time at a fraction of the cost of running an ESB.

radar/2017-03-01/bower.md

@@ -6,6 +6,8 @@ quadrant:   tools
 
 [Bower](https://bower.io/) is a package manager for frontend resources such as JavaScript libraries and CSS frameworks. Compared to [npm](https://www.npmjs.com/), it has a somewhat different approach to loading and resolving the packages, resulting in a smaller and cleaner folder structure.
 
-In small web projects, this approach is good and sufficient, but larger projects will need more dependencies such as task runners or testing frameworks, which are not available through Bower. As most of the frontend libraries are also available through npm, it's not surprising that we ask ourselves why Bower is still needed.
+In small web projects, this approach is good and sufficient, but larger projects will need more dependencies such as task runners or testing frameworks, which are not available through Bower.
+As most of the frontend libraries are also available through npm, it's not surprising that we ask ourselves why Bower is still needed.
 
-At AOE, we decided to use npm as the only package manager to avoid having multiple tools doing similar things. Developers only need to deal with one solution, which makes the project easier to maintain.
+At AOE, we decided to use npm as the only package manager to avoid having multiple tools doing similar things.
+Developers only need to deal with one solution, which makes the project easier to maintain.

radar/2017-03-01/client-side-error-logging.md

@@ -4,8 +4,12 @@ ring:       trial
 quadrant:   methods-and-patterns
 ---
 
-More and more business logic is done client-side with various web and app technologies. How do we know if everything works in production? We can easily track backend exceptions in the server logs, but what about client-side errors in the user's browser or mobile app?
+More and more business logic is done client-side with various web and app technologies.
+How do we know if everything works in production?
+We can easily track backend exceptions in the server logs, but what about client-side errors in the user's browser or mobile app?
 
-With client-side error logging, we send errors to a central server to see instantly what is going wrong. With this method errors can be found and resolved quickly before they affect even more users.
+With client-side error logging, we send errors to a central server to see instantly what is going wrong.
+With this method errors can be found and resolved quickly before they affect even more users.
 
-At AOE, we use the Open Source solution [Sentry](https://sentry.io/welcome/).io. It can handle multiple projects and teams and integrates well with other services such as Mattermost/Slack and Issue Tracking Systems.
+At AOE, we use the Open Source solution [Sentry](https://sentry.io/welcome/).io.
+It can handle multiple projects and teams and integrates well with other services such as Mattermost/Slack and Issue Tracking Systems.

radar/2017-03-01/consul.md

@@ -5,8 +5,10 @@ quadrant:   tools
 ---
 
 Consul is a lightweight service to provide a service discovery registry with failure detection (health checks) for circuit breakers. It also provides configuration management with key/value storage.\
-The typical way to use it is that a consul master cluster takes care of the update and write processes and consul clients run locally on the apps host - data is shared across the complete Consul cluster. The data can be accessed by using DNS and HTTP APIs.
+The typical way to use it is that a consul master cluster takes care of the update and write processes and consul clients run locally on the apps host - data is shared across the complete Consul cluster.
+The data can be accessed by using DNS and HTTP APIs.
 
-At AOE, we use Consul for settings distribution with consul-template as a way to do [Settings Injection](/methods-and-patterns/settings-injection.html) during deployment. Consul is also used as service discovery between apps inside [microservice](/methods-and-patterns/microservices.html) environments.
+At AOE, we use Consul for settings distribution with consul-template as a way to do [Settings Injection](/methods-and-patterns/settings-injection.html) during deployment.
+Consul is also used as service discovery between apps inside [microservice](/methods-and-patterns/microservices.html) environments.
 
 With Vault there is another tool that can be used to manage and share secrets.

radar/2017-03-01/container-based-builds.md

@@ -4,8 +4,14 @@ ring:       assess
 quadrant:   methods-and-patterns
 ---
 
-Running your builds in isolated containers keeps your build servers clean. It allows you to even run them with multiple versions of a framework or programming language. You don't need additional machines like you would for running builds with PHP5 or PHP7 at the same time or running some legacy builds.
+Running your builds in isolated containers keeps your build servers clean.
+It allows you to even run them with multiple versions of a framework or programming language.
+You don't need additional machines like you would for running builds with PHP5 or PHP7 at the same time or running some legacy builds.
 
 Note that you need to think about some kind of caching mechanism for your dependencies to avoid downloading them in every build, which would cause long build times.
 
-At AOE, we are currently starting to use this approach for building services and it is especially useful if your build has special dependencies. Also, it's possible to use GitLab as a build tool or use Docker with the new Jenkins pipeline. For caching we are evaluating minio as a cache server. We noticed that our builds run quite rapidly and reliably with that. Also, the complexity of the builds decreased since we don't need any workarounds, which were caused by having everything installed on one build server.
+At AOE, we are currently starting to use this approach for building services and it is especially useful if your build has special dependencies.
+Also, it's possible to use GitLab as a build tool or use Docker with the new Jenkins pipeline.
+For caching we are evaluating minio as a cache server.
+We noticed that our builds run quite rapidly and reliably with that.
+Also, the complexity of the builds decreased since we don't need any workarounds, which were caused by having everything installed on one build server.

radar/2017-03-01/dagger.md

@@ -4,6 +4,7 @@ ring:       adopt
 quadrant:   tools
 ---
 
-[Dagger](https://google.github.io/dagger/) is a fully static, compile-time [dependency injection](http://en.wikipedia.org/wiki/Dependency_injection) framework for both Java and Android. [Dagger](https://google.github.io/dagger/) doesn't use reflections at runtime, it saves resources. For us, it is a perfect match for Android development.
+[Dagger](https://google.github.io/dagger/) is a fully static, compile-time [dependency injection](http://en.wikipedia.org/wiki/Dependency_injection) framework for both Java and Android. [Dagger](https://google.github.io/dagger/) doesn't use reflections at runtime, it saves resources.
+For us, it is a perfect match for Android development.
 
 We at AOE use it as a base framework for every Android project.

radar/2017-03-01/datadog.md

@@ -4,4 +4,7 @@ ring:       assess
 quadrant:   platforms-and-aoe-services
 ---
 
-After realizing that AWS CloudWatch isn't flexible enough, and running our own metrics aggregation, monitoring and altering isn't something we want to do ourselves, we decided to give Datadog a try. Datadog is very simple to set up and retrieves metrics from the AWS API (and many other integrations) and from an agent running on the EC2 instances. On top of that, it comes with many plugins for services such as Apache, NGINX and ElasticSearch, allowing us to track all important metrics without much effort. Creating dashboards, setting up alarms and integrating into other applications (such as ticket systems) is easy to do and works fine.
+After realizing that AWS CloudWatch isn't flexible enough, and running our own metrics aggregation, monitoring and altering isn't something we want to do ourselves, we decided to give Datadog a try.
+Datadog is very simple to set up and retrieves metrics from the AWS API (and many other integrations) and from an agent running on the EC2 instances.
+On top of that, it comes with many plugins for services such as Apache, NGINX and ElasticSearch, allowing us to track all important metrics without much effort.
+Creating dashboards, setting up alarms and integrating into other applications (such as ticket systems) is easy to do and works fine.

radar/2017-03-01/decoupling-infrastructure-via-messaging.md

@@ -4,6 +4,11 @@ ring:       trial
 quadrant:   methods-and-patterns
 ---
 
-In [Microservices](/methods-and-patterns/microservices.html) we have already covered the trend that modern architectures are moving away more and more from big monolithic applications to distributed software suites. The result of splitting our software and infrastructure in smaller parts, is the need to communicate with each other. This can be done by direct communication or by message-based asynchronouous communication. While synchronuous communication allows for more plannable "real-time" response times of the overall systems, asynchronouos communication increases the resilience and stability of the system significantly and allows one to use other integration and scaling patterns. However, it often comes with additional complexity.
+In [Microservices](/methods-and-patterns/microservices.html) we have already covered the trend that modern architectures are moving away more and more from big monolithic applications to distributed software suites.
+The result of splitting our software and infrastructure in smaller parts, is the need to communicate with each other.
+This can be done by direct communication or by message-based asynchronouous communication.
+While synchronuous communication allows for more plannable "real-time" response times of the overall systems, asynchronouos communication increases the resilience and stability of the system significantly and allows one to use other integration and scaling patterns. However, it often comes with additional complexity.
 
-Most of the IaaS Cloud providers offer messaging services such as AWS SQS which provide the possibility to decouple our infrastructure via Messaging. Also, we use [RabbitMQ](/tools/rabbitmq.html) as a Messaging and Broker solution within our applications. The decision of using messaging and messaging patterns as an integration strategy can be made as part of [strategic design](/methods-and-patterns/strategic-domain-driven-design.html) considerations.
+Most of the IaaS Cloud providers offer messaging services such as AWS SQS which provide the possibility to decouple our infrastructure via Messaging.
+Also, we use [RabbitMQ](/tools/rabbitmq.html) as a Messaging and Broker solution within our applications.
+The decision of using messaging and messaging patterns as an integration strategy can be made as part of [strategic design](/methods-and-patterns/strategic-domain-driven-design.html) considerations.

radar/2017-03-01/devops-practices.md

@@ -4,7 +4,8 @@ ring:       adopt
 quadrant:   methods-and-patterns
 ---
 
-DevOps is a term that has been around for some years now. We understand DevOps as a philosophy and culture with related practices and tools - all with the aim of bringing (IT) Operations closer to Development.  
+DevOps is a term that has been around for some years now.
+We understand DevOps as a philosophy and culture with related practices and tools - all with the aim of bringing (IT) Operations closer to Development.  
 
 Jez Humble described the devops movement like this: "a cross-functional community of practice dedicated to the study of building, evolving and operating rapidly changing, secure, resilient systems at scale".
 
@@ -16,7 +17,8 @@ We have been using the following practices with success:
 
 In the past year, we have moved from a more centralistic or standalone IT and operations service team to cross-functional teams with Infrastructure experts working in and with the development team (admins joining the project team).
 
-And, we changed to cross-functional teams and a "you build it, you run it" approach for the bigger projects. We have seen that this leads to the following positive effects:
+And, we changed to cross-functional teams and a "you build it, you run it" approach for the bigger projects.
+We have seen that this leads to the following positive effects:
 * Software application architecture demands a certain infrastructure and the other way around. Having all the know-how in one team leads to more major decisions and implementations. Also, solving of root causes for problems works better.
 * Rotating operation and incident management inside the whole team brings everyone into closer contact with the day-to-day operation of their software. This results in a shared and improved responsibility and commitment to the complete platform in the team. In addition, this brings developers into contact with the customer - which is an important feedback loop as well.
 * Increased flexibility in the infrastructure: Implementations and adjustments in the infrastructure are faster and can be done together with the ongoing agile development of the platform.
@@ -31,6 +33,7 @@ Another important aspect and also enabler of DevOps practices is the increase of
 
 **DevSetup = Prod Setup, [Infrastructure as a Code](methods-and-patterns/infrastructure-as-code.html)**
 
-Keeping the development infrastructure setup close to production is also a commonly implemented practice and a direct result of the "Infrastructure as Code" method. Handling infrastructure and the required changes and innovations in ways similar to those used for applications is important; you can ready more about this here: Infrastructure as Code
+Keeping the development infrastructure setup close to production is also a commonly implemented practice and a direct result of the "Infrastructure as Code" method.
+Handling infrastructure and the required changes and innovations in ways similar to those used for applications is important; you can ready more about this here: Infrastructure as Code
 
 We encourage all teams to adopt devops practices in the teams and to take care that there is a true collaboration between the different experts in a team and no invisible wall.

radar/2017-03-01/docker.md

@@ -10,7 +10,8 @@ Essentially, Docker is a platform to build container images, distribute them and
 
 In a DevOps environment, this helps a lot as we can run the exact same software and runtime (such as PHP) on both production and locally while developing. This enables us to debug our software much easier.
 
-Also, Docker allows us to keep our development setup much smaller and faster; instead of VirtualBox setups on a per-project base, we can compose our project development setup out of small containers. A CI environment building the containers allows us to package and test the whole environment instead of different software components on different runtimes in a much more stable way.
+Also, Docker allows us to keep our development setup much smaller and faster; instead of VirtualBox setups on a per-project base, we can compose our project development setup out of small containers.
+A CI environment building the containers allows us to package and test the whole environment instead of different software components on different runtimes in a much more stable way.
 
 Backed by services such as [Kubernetes](/platforms-and-aoe-services/kubernetes.html), we can deploy Docker containers on a flexible infrastructure and enable our developers to test their software more easily in different environments.
 

radar/2017-03-01/elasticsearch.md

@@ -4,6 +4,11 @@ ring:       trial
 quadrant:   platforms-and-aoe-services
 ---
 
-Elasticsearch is a REST-based search and analytics engine based on Lucene. Unlike its competitor Apache Solr, it was developed in the beginning with clustering and scaling in mind. It allows you to create complex queries while still delivering results very fast.
+Elasticsearch is a REST-based search and analytics engine based on Lucene.
+Unlike its competitor Apache Solr, it was developed in the beginning with clustering and scaling in mind.
+It allows you to create complex queries while still delivering results very fast.
 
-At AOE, we use Elasticsearch for logging as well as our own search solution [Searchperience®](http://www.searchperience.com/). We recently moved the Searchperience stack from Solr to Elasticsearch and think this was the right decision. Especially in terms of scaling, ease of use and performance, Elasticsearch really shines. Also, the API design took some of the learnings from Apache SOLR into account - for example, the queryDSL is a powerful way of describing different search use cases with highly flexible support of aggregations, etc.
+At AOE, we use Elasticsearch for logging as well as our own search solution [Searchperience®](http://www.searchperience.com/).
+We recently moved the Searchperience stack from Solr to Elasticsearch and think this was the right decision.
+Especially in terms of scaling, ease of use and performance, Elasticsearch really shines.
+Also, the API design took some learnings from Apache SOLR into account - for example, the queryDSL is a powerful way of describing different search use cases with highly flexible support of aggregations, etc.