Merge pull request #15 from AOEpeople/finalize

Finalize

.travis.yml

@@ -28,4 +28,4 @@ deploy:
     local_dir: dist
     detect_encoding: true
     on:
-      branch: next
+      branch: next

radar/2017-03-01/elasticsearch.md

@@ -6,4 +6,4 @@ 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.
 
-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 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.

radar/2017-03-01/jest.md

@@ -4,9 +4,9 @@ ring:       assess
 quadrant:   tools
 
 ---
-[Jest](https://facebook.github.io/jest/) is a javascript testing framework by facebook to test javascript code **and** react applications / components.
+[Jest](https://facebook.github.io/jest/) is a javascript testing framework by facebook to test javascript code **and** react applications / components.
 
-We started using Jest (and [watchmen](https://github.com/facebook/watchman)) instead of Karma because it:
+We started using Jest (and [watchmen](https://github.com/facebook/watchman)) instead of Karma because it:
 
 -   gives us integrated mocking library
 -   gives us integrated support for testing "promises"
@@ -15,4 +15,4 @@ We started using Jest (and [watchmen](https://github.com/facebook/watchman)) in
 -   gives us parallel test execution
 -   gives us snapshot testing for react components
 
-It is easy to set up. And even if you have a running setup with karma/chai you can easily replace karma with jest. With a small [workaround](https://medium.com/@RubenOostinga/combining-chai-and-jest-matchers-d12d1ffd0303#.3callo273), chai and jest test matchers work fine together.
+It is easy to set up. And even if you have a running setup with karma/chai you can easily replace karma with jest. With a small [workaround](https://medium.com/@RubenOostinga/combining-chai-and-jest-matchers-d12d1ffd0303#.3callo273), chai and jest test matchers work fine together.

radar/2017-03-01/puppet-environments.md

@@ -10,13 +10,12 @@ Puppet
 
 Puppet is an Open Source configuration management tool. It is used by a wide range of different companies world-wide, e.g. the Wikimedia Foundation, Mozilla, Reddit, CERN, Dell, Rackspace, Twitter, the New York Stock Exchange, PayPal, Disney, Citrix Systems, Spotify, Oracle, the University of California Los Angeles, the University of North Texas, QVC, Intel, Google and others.
 
-Puppet has been the basic tool to address Continuous Configuration Automation (CCA) in AOE's [Infrastructure as Code](/methods-and-patterns/infrastructure-as-code.html) strategy (IaC) for more than 4 years.
+Puppet has been the basic tool to address Continuous Configuration Automation (CCA) in AOE's [Infrastructure as Code](/methods-and-patterns/infrastructure-as-code.html) strategy (IaC) for more than 4 years.
 
 Puppet Environments
 -------------------
 
 Intended to give projects the means to develop and maintain their own infrastructure, separated and not influenced by other projects, Puppet environments, together with Puppet module versioning and ENC, have been introduced.\
-Puppet Environments are rated "Trial". It supports our strategy of Infrastructure as Code (IaC) and links it to our DevOps approach, enabling project teams to set up and customize their own infrastructure. 
+Puppet Environments are rated "Trial". It supports our strategy of Infrastructure as Code (IaC) and links it to our DevOps approach, enabling project teams to set up and customize their own infrastructure.
 
 Teams that want to use the Puppet Environments service from the AOE IT Team will find detailed information about the implemented CI/CD process for this.
-

radar/2017-03-01/scala-lang.md

@@ -11,4 +11,4 @@ It is fully interoperable with Java but has a big ecosystem of tools and framewo
 
 Scala provides one of the best high-level concurrency- and async features on the language level as well as on the framework level, making it the default choice of twitter and the like.
 
-At AOE, we already use Scala in various projects to create scalable backend systems (Play, Akka) or for batch processing (Spark).
+At AOE, we already use Scala in various projects to create scalable backend systems (Play, Akka) or for batch processing (Spark).

radar/2017-03-01/wiremock.md

@@ -4,12 +4,12 @@ ring:       trial
 quadrant:   tools
 
 ---
-**[WireMock](http://wiremock.org/docs/)** is an HTTP mock server - it can be used to mock APIs for testing.
+**[WireMock](http://wiremock.org/docs/)** is an HTTP mock server - it can be used to mock APIs for testing.
 
-At its core, it is a web server that can be prepared to serve canned responses to particular requests (stubbing), and that captures incoming requests so that they can be checked later (verification). It also has an assortment of other useful features including record/playback of interactions with other APIs, injection of faults and delays, simulation of stateful behavior. 
+At its core, it is a web server that can be prepared to serve canned responses to particular requests (stubbing), and that captures incoming requests so that they can be checked later (verification). It also has an assortment of other useful features including record/playback of interactions with other APIs, injection of faults and delays, simulation of stateful behavior.
 
 It can be used as a library by any JVM application, or run as a standalone process either on the same host as the system under test or a remote server. All of WireMock's features are accessible via its REST (JSON) interface and its Java API. Additionally, the mock server can be configured via JSON files.
 
-At AOE, we use WireMock as a standalone server to mock APIs that are outside our system context to get a stable environment for testing and rapid feedback. Besides the decoupled test and development advantages, the mocked APIs can also be used in contract-based tests. We also use embedded WireMock in functional tests to stub external services. The explicit test of faults are especially helpful in building and testing the [resilience of your application](/methods-and-patterns/resilience-thinking.html).
+At AOE, we use WireMock as a standalone server to mock APIs that are outside our system context to get a stable environment for testing and rapid feedback. Besides the decoupled test and development advantages, the mocked APIs can also be used in contract-based tests. We also use embedded WireMock in functional tests to stub external services. The explicit test of faults are especially helpful in building and testing the [resilience of your application](/methods-and-patterns/resilience-thinking.html).
 
-Because of the features such as flexible deployment, powerful request matching and record/payback interactions, as well as the fact that the server runs stable in our project environments, we classify WireMock as *trial*.
+Because of the features such as flexible deployment, powerful request matching and record/payback interactions, as well as the fact that the server runs stable in our project environments, we classify WireMock as *trial*.

radar/2017-10-01/adr.md

@@ -0,0 +1,26 @@
+---
+title:      "ADR"
+ring:       assess
+quadrant:   methods-and-patterns
+
+---
+Architecture Decision Records
+
+Is a lightweight documentation of important architecture decisions taken by the team.
+Without documentation of the architecture and the architecture decisions, new team members can only do two things:
+* either (blindy) accept what they find and see  or
+* (blindy) change things
+
+Both is of course not right.
+
+Therefore we suggest to document the important architecture decisions. We are using a simple tool like https://github.com/npryce/adr-tools and store them in version control.
+In bigger projects with many teams we also establish a regular "architecture board / coi" with regular meetings.
+Often the architecture decision are taken in such meetings.
+
+The main purpose of this documentation is:
+* inform new team members about the previous architecture decisions and its purpose and backgrounds
+* inform the whole team (also all the people who where absent)
+* documentation that can be used to remeber things (e.g. conventions, patterns, etc)
+
+
+

radar/2017-10-01/alpakka.md

@@ -5,4 +5,15 @@ quadrant:   languages-and-frameworks
 
 ---
 
-Test test test test
+When using [Akka Streams](/languages-and-frameworks/akka-streams.html) to build
+reactive data transformation services you usually need to connect to several
+different services like FTP, S3 buckets, AMQP brokers or different databases.
+
+[Alpakka](https://developer.lightbend.com/docs/alpakka/current/) provides
+integration building blocks for Akka Streams to access these services in a
+reactive fashion and also contains transformations for working with XML, CSV or
+JSON structured data.
+
+Akka Streams and Alpakka combined enables us to build small reactive
+integration services with minimal resource consumption and good performance and
+are good alternative to bigger ESB solutions or integration tools.

radar/2017-10-01/angular.md

@@ -5,7 +5,7 @@ quadrant:   languages-and-frameworks
 
 ---
 Beside that many major upgrades from version 2 to 5 which often needed manual hands on a lot has happened in the Angular 
-ecosystem in 2017. Like in particular the improvements on the HTTP-Client which requires less coding effort from now or 
+ecosystem in 2017. Like in particular the improvements on the HTTP-Client which require less coding effort from now or 
 the great improvements on angular.cli like aot (ahead of time compile) for faster rendering, fewer requests and 
 much smaller builds to name just the most important ones.
 
@@ -13,5 +13,5 @@ Beside that many facts about, we made many good experiences using Angular in lar
 it's the choice in our telecommunication sector teams as single page application framework (SPA) for micro service front 
 ends.
 
-The convenient scaffolding of unit- and end-2-end-tests provides a very quality driven workflow.
-Also the component architecture helps to keep the codebase understandable end maintainable.
+The convenient scaffolding of unit- and end-2-end-tests provide a very quality driven workflow.
+Also the module and component architecture helps to keep the codebase understandable end maintainable.

radar/2017-10-01/blameless-post-mortems.md

@@ -0,0 +1,17 @@
+---
+title:      "Blameless Post Mortems"
+ring:       trial
+quadrant:   methods-and-patterns
+---
+
+> Failure and invention are inseparable twins.
+>
+> — <cite>Jeff Bezos</cite>
+
+Blameless Post Mortems provide a concept of dealing with failures inevitably occuring when developing and operating complex software solutions. After any major incident or outage the team gets together, performing an in-depth analysis of what has happened and what can be done to mitigate the risk of similar issues to happen in the future.
+
+Based on trust and under the assumption that every person involved had good intentions doing the best given the information at hand, Blameless Post Mortems provide an opportunity to continuously improve the quality of software and infrastructure and the processes to deal with critical situations.
+
+The post mortem documentation usually consist of both a timeline of the events leading to an incident and the steps taken to its remediation, and future actions and learnings for increasing reslience and stability of our services.
+
+At AOE, we strive to conduct a Blameless Post Mortem meeting after every user-visible incident.

radar/2017-10-01/crc.md

@@ -0,0 +1,38 @@
+---
+title:      "CRC Games"
+ring:       assess
+quadrant:   methods-and-patterns
+
+---
+
+Class Responsibility Collaboration Card Games are a method to discuss and align the software design - especially useful for object-oriented software.
+
+A proper software design is one of the most important things to ensure the sucess and the maintainability of your software.
+Especially for iterative development methods where you work on a software task by task, it is important to have designs sessions that also look forward to the next iterations and the conceptional whole.
+
+And for software design to be sucessfull, it is very important that everybody (in the team) has the same understanding of the design and stands behind it.
+
+CRC sessions help to design and align the high level object design and collaboration of your system with the whole team. During such sessions new team members can learn from the experience and explainations of tropers.
+
+This is how we often do this CRC Sessions:
+* Preparation:
+    * Make sure everybody has a high level overview of the software (bounded context / use case overview). Because design should also focus on the long term.
+    * Choose some szenarios (like "customer adds a promoted product to cart and see the discounts..") that you want to discuss in this session
+* Collect candidates for classes:
+    * For the first session it makes sense to search for potential candidates for classes.
+    * Just put them on a whiteboard. Often nouns in szenarios are good candidates.
+    * Put the most promising ones on post its. (You can add more at any time)
+* CRC session:
+    * 1 or 2 people stand up and try to explain the szenario with the help of the classes.
+    * This is much like explaining a sequence diagramm and the cards are put on the table from left to right. During or after this you can discuss design decissions and alternatives with the team.
+    * After this someone else can stand up and present a potential alternative sequence.
+    * Once the team aligned on a version they want to implement, it makes sense that it is repeated by different persons. Beeing exact is very important and avoids the situation where some people have "his" understanding of the model. The model and the collaboration lives in the heads of the people in the team - therefore it is important that everyone understands it the same way.
+* Closing:
+    * We are often not too enthusiatic about adding a list of "collaborators" to the cards, since the sequence explains this very well.
+    * So just take a picture and document the result somewhere, so that you can review the status for the next CRC session.
+    * Maybe some decisions are worth beeing documented in your [Architecture decision records](/methods-and-patterns/adr.html)
+
+
+
+
+

radar/2017-10-01/elasticsearch.md

@@ -0,0 +1,9 @@
+---
+title:      "Elasticsearch"
+ring:       adopt
+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.
+
+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.

radar/2017-10-01/grafana.md

@@ -0,0 +1,9 @@
+---
+title:      "Grafana"
+ring:       assess
+quadrant:   platforms-and-aoe-services
+---
+
+[Grafana](https://grafana.com//) is an open source data visualization platform written in Go and NodeJS. It provides a vast choice of differen graph types that can be easily combined into dashboards for displaying any kind of numerical or time-based data.
+
+At AOE, we usually use Grafana in conjunction with [Prometheus](https://prometheus.io/) or [AWS CloudWatch](https://prometheus.io/) for visualizing both application and infrastructure metrics.

radar/2017-10-01/grpc.md

@@ -0,0 +1,17 @@
+---
+title:      "GRPC"
+ring:       assess
+quadrant:   languages-and-frameworks
+
+---
+
+gRPC, "A high performance, open-source universal RPC framework", is a framework to easily connect clients and servers in a RPC setup.
+gRPC is initially build at google, and uses protobuf service definitions for method and payload specification.
+Essentially this allows to define methods a server exposes, with either a single payload or an incoming stream, and either a single response or a stream of responses.
+The definition itself is done with the help of protobuf to define message types and method signatures, and then client and server interfaces are compiled for the language(s) you want. Currently there is support for languages such as C++, Java, Python, Go and many more.
+The shared language-neutral protobuf definition allows to automatically create all code for all languages and helps with the interoperability of different systems.
+
+From a technical point of view gRPC uses HTTP/2 as a transport, direcly benefitting from the default TLS encryption.
+Beside gRPC there exist other frameworks as well which use protobuf RPC definitions, such as twirp from twitch, which makes it easy to change the transport/control layer with only very small changes to the application code.
+
+We at AOE plan to assess gRPC for microservice architectures which are more RPC style and less REST style.

radar/2017-10-01/helm-terraform.md

@@ -0,0 +1,14 @@
+---
+title:      "Helm/Terraform"
+ring:       assess
+quadrant:   tools
+
+---
+
+For our OM3 projects infrastructure we run multiple Kubernetes clusters, and to orchestrate the infrastructure provisioning decided quite fast to go with Terraform.
+Terraform allows us to easily manage our infrastructure, from AWS EC2 instances to RabbitMQ message queues.
+Also the Kops installer for Kubernetes on AWS uses terraform as it's main building brick, and we can trigger Kops via Terraform.
+
+For managing deployments within Kubernetes we use Helm, which makes templating Kubernetes configuration files super easy (also known as Helm charts).
+
+We bring both tools together to manage similar parts of the infrastructure, for example a shared file with domainname to application mappings allows us to provision Route 53 DNS entries via Terraform and then roll out Kubernetes Ingress definitions with the appropriate hostname to service mapping via Helm.

radar/2017-10-01/invision.md

@@ -0,0 +1,13 @@
+---
+title:      "Invision"
+ring:       trial
+quadrant:   tools
+
+---
+
+Invision is an online tool used to work and collaborate on design and prototypes and to share them between clients and the team.
+
+We use it in many projects now to present prototypes and designs and it helps in understanding the planned user experience.
+Also we use this directly as a reference from the User stories, to help the development teams in understanding and implementing the right frontend and backend functionalities.
+
+

radar/2017-10-01/jest.md

@@ -2,6 +2,17 @@
 title:      "Jest"
 ring:       adopt
 quadrant:   tools
----
 
-TODO
+---
+[Jest](https://facebook.github.io/jest/) is a javascript testing framework by facebook to test javascript code **and** react applications / components.
+
+We started using Jest (and [watchmen](https://github.com/facebook/watchman)) instead of Karma because it:
+
+-   gives us integrated mocking library
+-   gives us integrated support for testing "promises"
+-   gives us integrated code coverage report
+-   automatically runs tests related to changed files (instead of all tests)
+-   gives us parallel test execution
+-   gives us snapshot testing for react components
+
+It is easy to set up. And even if you have a running setup with karma/chai you can easily replace karma with jest. With a small [workaround](https://medium.com/@RubenOostinga/combining-chai-and-jest-matchers-d12d1ffd0303#.3callo273), chai and jest test matchers work fine together.

radar/2017-10-01/kubernetes.md

@@ -0,0 +1,10 @@
+---
+title:      "Kubernetes"
+ring:       adopt
+quadrant:   platforms-and-aoe-services
+
+---
+
+Kubernetes is a container orchestration platform, which supports many different infrastructure providers. It allows you to deploy containers and takes care of running, scaling or self-healing your applications based on configurations you provide. It's based on years of knowledge and experience Google gained by using containers.
+
+At AOE, we started Kubernetes in a test environment on bare metal to experiment with it. It's currently used for running AOE internal apps such as dashboards as well as running builds in containers. We also started to use it for upcoming projects to run and manage several services. There are Tools to automate the setup of kubernetes in AWS like [Cops](https://kubernetes.io/docs/getting-started-guides/kops/). Another helpful tool is [Minikube](https://github.com/kubernetes/minikube), which allows to test and run kubernetes locally.

radar/2017-10-01/pact.md

@@ -0,0 +1,17 @@
+---
+title:      "PACT"
+ring:       trial
+quadrant:   tools
+
+---
+
+PACT (http://pact.io/) is a family of frameworks that provide support for *Consumer Driven Contract testing* accross different langauages and frameworks.
+
+Consumer Driven Contract testing is a pattern for testing interfaces/boundaries between services.
+
+It allows "consumers" to run tests against a defined Mock and record the defined interactions (=PACT).
+It puts "providers" in the position, that they can run the PACT tests inside theire Continuous Integration Pipelines, so that the provider knows if he might break any consumers.
+
+This approach makes sense in organisations where teams collaborate more closely (See [Strategic Domain Driven Design](/methods-and-patterns/strategic-domain-driven-design.html) ), e.g. to build [Microservice oriented architectures](/methods-and-patterns/microservices.html)
+
+Consumer Driven Contract Testing and how they can be done with Pact is documented very nicely on the official Pact website: https://docs.pact.io/.

radar/2017-10-01/pipeline-as-code.md

@@ -0,0 +1,12 @@
+---
+title:      "Pipeline as Code"
+ring:       adopt
+quadrant:   methods-and-patterns
+
+---
+
+Continuous Integration and Delivery is a critical part of our development and deployment process at AOE. Using Jenkins for many years the "instructions" how to build, test and deploy applications were scattered between many custom scripts and the pipeline was often maintained by manual maintenance of Jenkins jobs. Soon, we realized that we need a more native way to express the full CI/CD pipeline process in code and manage it in version control.
+
+Being an important part of each project, the pipeline configuration should be managed as code and rolled out automatically - this also allows us to manage the pipeline itself applying the same standards that apply to application code.
+
+While some teams started using Jenkins' [JobDSL plugin,](https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin) others explored the new [Jenkins Pipeline](https://jenkins.io/doc/book/pipeline/) - in both ways, the build artifacts should be published to an artifact repository such as [Artifactory.](/platforms-and-aoe-services/artifactory.html)

radar/2017-10-01/ports-and-adapters.md

@@ -0,0 +1,34 @@
+---
+title:      "Ports and Adapters"
+ring:       trial
+quadrant:   methods-and-patterns
+
+---
+
+Ports and Adapters is an architecture or layering approach for software design. As with other layering approaches it seperates different concerns in different layers, where dependencies are only allowed to be from the outside to the inside.
+
+We use "ports and adapters" with success for (bigger) applications which contains certain business logic and/or provides several ways to access the services.
+We often use it hand in hands with domain driven design. In comparison with other layering patterns (e.g. layered architecture) it allows to have a true technologie free core (domain) model, because with the concept of "secondary ports" (=interfaces) it inverts the control and allows outer layers to provide adapters (=implementations of the defined interface).
+It also defines clear boundaries for where to put what logic of your application.
+
+You can find more about the details and its origins in famous blog posts like [The Clean Architecture](https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html) or [Hexagonal architecture](http://alistair.cockburn.us/Hexagonal+architecture)
+
+In short here is how we often layer such applications:
+* Domain:
+    * Is the inner layer and contains the technology free domain model
+    * Often using building blocks from domain driven design
+    * It defines primary and secondary ports. (E.g. a secondary port is in "interface" that need to be implemented in the infrastructure layer.)
+* Application:
+    * Contains the Applications API and Services, that are developed around the use cases in the application requirements.
+    * This use cases orchestrate the flow of data to and from the domain
+* Interfaces:
+    * set of adapters that convert data from the 
format most convenient for the 
use cases to the format most convenient for 
some external agency/access
+    * e.g. (Web) Controllers / DTOs for handling forms etc
+* Infrastructure:
+    * 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.
+    * This is where you can use frameworks and tools such as the RDB Mappers etc.
+    * communication details with other external systems (and its DataTransferObjects and Mappers)
+
+This layers belong to every bounded context (modules) inside the application.
+
+So if you are searching for a potential timeless architecture for your critical application? Try to implement a potent technology free domain model in the core layer and use ports and adapters to layer your application.

radar/2017-10-01/puppet-environments.md

@@ -0,0 +1,22 @@
+---
+title:      "Puppet Environments"
+ring:       trial
+quadrant:   platforms-and-aoe-services
+
+---
+
+Puppet
+------
+
+Puppet is an Open Source configuration management tool. It is used by a wide range of different companies world-wide, e.g. the Wikimedia Foundation, Mozilla, Reddit, CERN, Dell, Rackspace, Twitter, the New York Stock Exchange, PayPal, Disney, Citrix Systems, Spotify, Oracle, the University of California Los Angeles, the University of North Texas, QVC, Intel, Google and others.
+
+Puppet has been the basic tool to address Continuous Configuration Automation (CCA) in AOE's [Infrastructure as Code](/methods-and-patterns/infrastructure-as-code.html) strategy (IaC) for more than 4 years.
+
+Puppet Environments
+-------------------
+
+Intended to give projects the means to develop and maintain their own infrastructure, separated and not influenced by other projects, Puppet environments, together with Puppet module versioning and ENC, have been introduced.\
+Puppet Environments are rated "Trial". It supports our strategy of Infrastructure as Code (IaC) and links it to our DevOps approach, enabling project teams to set up and customize their own infrastructure. 
+
+Teams that want to use the Puppet Environments service from the AOE IT Team will find detailed information about the implemented CI/CD process for this.
+

radar/2017-10-01/redux.md

@@ -1,7 +1,14 @@
 ---
 title:      "Redux"
-ring:       adopt
+ring:       trial
 quadrant:   languages-and-frameworks
+
 ---
 
-TODO
+[Redux](http://redux.js.org/) helps us to maintain state in our frontend applications in a more predictable and clearer way. It is extendable though middleware, it has a great documentation and some awesome [devtools](https://github.com/gaearon/redux-devtools) that are especially helpful when you are new to Redux.
+
+The functional concepts for updating the state, combined with immutable data, lead to extremely easy and enjoyable [unit tests](http://redux.js.org/docs/recipes/WritingTests.html) - this is maybe the biggest plus for us developers.
+
+The official [react-redux bindings](https://github.com/reactjs/react-redux) also made it straightforward to weave Redux into our React applications. For asynchronous actions we use [redux-sagas](https://redux-saga.github.io/redux-saga/) which has proven itself as a better alternative for [redux-thunk](https://github.com/gaearon/redux-thunk).
+
+Currently, we use Redux only in our React projects, but we are evaluating it together with other frameworks such as Angular or Vue.js, as well.

radar/2017-10-01/scala-lang.md

@@ -2,5 +2,15 @@
 title:      "Scala Lang"
 ring:       adopt
 quadrant:   languages-and-frameworks
+
 ---
-Scala is used in many projects here at AOE and therefore we moved it into the adopt level.
+
+Scala is used in many projects here at AOE and therefore we moved it into the adopt level.
+
+Besides Java, Scala is the most mature language on the Java Virtual Machine. Its unique blend of object-oriented and functional language features and rich type system with advanced type inference enables one to write concise code.
+
+It is fully interoperable with Java but has a big ecosystem of tools and frameworks on its own.
+
+Scala provides one of the best high-level concurrency- and async features on the language level as well as on the framework level, making it the default choice of twitter and the like.
+
+At AOE, we already use Scala in various projects to create scalable backend systems (Play, Akka) or for batch processing (Spark).

radar/2017-10-01/self-service-infrastructure.md

@@ -0,0 +1,12 @@
+---
+title:      "Self service infrastructure"
+ring:       assess
+quadrant:   methods-and-patterns
+
+---
+
+With growing teams, growing projects and growing infrastructure we decided to follow the "You build it, you run it"-approach, and when we started to run Kubernetes, where we have a great abstraction layer between infrastructure and applications, we decided to make the developer teams write their own Helm charts.
+By agreeing on just a couple of patters, this allows us to easily manage a microservice architecture with more than 60 Applications, without too much hassle managing infrastructure/runtimes for (amongst others) JVM, Go and PHP applications.
+Most of the hosting/provisioning decisions are better kept at the team, as they are the ones who know how their application works. By providing a clear interface this became the cornerstone for running our microservice architecture, and keeping the amount of actual servers much lower than in projects with a centralized operations/IT team.
+
+Eventually self service infrastructure, and "You build it, you run it", allowed us to give both our application developers as well as our infrastructure engineers more flexibility than one team explaining another team what to do, resulting in a better collaboration than before.

radar/2017-10-01/vue.md

@@ -0,0 +1,12 @@
+---
+title:      "Vue.js"
+ring:       trial
+quadrant:   languages-and-frameworks
+
+---
+
+Vue is a progressive, incrementally adoptable framework for building user interfaces maintained by Evan You. Unlike [other monolithic frameworks](http://vuejs.org/v2/guide/comparison.html), the core library is focused on the view layer only and is very easy to pick up and integrate with other libraries or existing projects. Vue is also perfectly capable of powering sophisticated single-page applications when used in combination with modern tooling and supporting libraries such as [vuex](https://vuex.vuejs.org/en/) and [vue-router](http://router.vuejs.org/en/).
+
+Vue uses an HTML-based template syntax that allows you to declaratively bind the rendered DOM to the underlying Vue instance’s data. Under the hood, Vue compiles the templates into Virtual DOM render functions. Combined with the [reactivity system](http://vuejs.org/v2/guide/reactivity.html) Vue is able to intelligently figure out the minimal amount of components to re-render and apply the minimal amount of DOM manipulations when the app state changes, which provides for very high performance.
+
+Applications can be split into [Single File Components](http://vuejs.org/v2/guide/single-file-components.html) - a single file containing the template (HTML), style (CSS) and functionality (JS) - which simplifies maintainability and testability of the code and promotes reusability across other projects.

radar/2017-10-01/yarn.md

@@ -4,6 +4,8 @@ ring:       trial
 quadrant:   tools
 
 ---
-Yarn is dependency management tool for frontend (node) projects similar to npm. It also uses the npm registry and infrastructure. According to yarn the benefits are that yarn is much faster, automatically writes a .lock file and builds up an local cache to be even faster when installing packages again.
+Yarn is dependency management tool for frontend (node) projects similar to npm. It also uses the npm registry and 
+infrastructure. According to yarn the benefits are that yarn is much faster, automatically writes a .lock file and 
+builds up an local cache to be even faster when installing packages again.
 
 At AOE, we started using yarn in different projects to evaluate if we can switch to yarn for all projects.

yarn.lock

@@ -2513,9 +2513,9 @@ minimist@^1.2.0:
   dependencies:
     minimist "0.0.8"
 
-moment@2.19.2:
-  version "2.19.2"
-  resolved "https://registry.yarnpkg.com/moment/-/moment-2.19.2.tgz#8a7f774c95a64550b4c7ebd496683908f9419dbe"
+moment@2.19.3:
+  version "2.19.3"
+  resolved "https://registry.yarnpkg.com/moment/-/moment-2.19.3.tgz#bdb99d270d6d7fda78cc0fbace855e27fe7da69f"
 
 morgan@^1.6.1:
   version "1.8.1"