rename to march because of adjustments done lately

radar/2018-03-01/adr.md

@@ -0,0 +1,26 @@
+---
+title:      "ADR"
+ring:       assess
+quadrant:   methods-and-patterns
+
+---
+Architecture Decision Records
+
+ADR 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
+
+It goes without saying that both options aren't right.
+
+Therefore, we suggest documenting the important architecture decisions. We use a simple tool such as https://github.com/npryce/adr-tools and store them in version control.
+In larger projects with many teams we also establish a regular "architecture board / COI" with regular meetings.
+Often, the architecture decisions are taken in such meetings.
+
+The main purpose of this documentation is to:
+* inform new team members about the previous architecture decisions and their purpose and backgrounds
+* inform the whole team (including all people who were absent)
+* create documentation that can be used to remember things (e.g. conventions, patterns, etc.)
+
+
+

radar/2018-03-01/akka-streams.md

@@ -0,0 +1,33 @@
+---
+title:      "Akka Streams"
+ring:       assess
+quadrant:   languages-and-frameworks
+
+---
+
+In our backend services, we frequently encounter the task to transform data
+coming from and uploading to external sources and services.
+
+Building more complex data transformation processes with Akka Actors has proven
+very difficult for us in the past.
+
+Seeing this data as a stream of elements could allow handling them piece by
+piece and only keeping as much of the data in-process as can currently be
+handled.
+
+[Akka Streams](http://doc.akka.io/docs/akka/current/scala/stream/index.html) is
+a [Reactive Streams](http://www.reactive-streams.org/) implementation that
+provides a very end-user friendly API for setting up streams for data
+processing that are bounded in resource usage and efficient.  It uses the Akka
+Actor Framework to execute these streams in an asynchronous and parallel
+fashion exploiting today's multi-core architectures without having the user to
+interact with Actors directly. It handles things such as message resending in
+failure cases and preventing message overflow. It is also interoperable with
+other Reactive Streams implementations.
+
+Our first trials with Akka Streams were promising but we haven't yet implemented
+complex services with it.
+
+We will continue looking into it together with the
+[Alpakka](/languages-and-frameworks/alpakka.html) Connectors for integration
+work.

radar/2018-03-01/alpakka.md

@@ -0,0 +1,19 @@
+---
+title:      "Alpakka"
+ring:       assess
+quadrant:   languages-and-frameworks
+
+---
+
+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 such as 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 contains transformations for working with XML, CSV or
+JSON structured data.
+
+Combined, Akka Streams and Alpakka enable us to build small reactive
+integration services with minimal resource consumption and good performance, and
+are a good alternative to larger ESB solutions or integration tools.

radar/2018-03-01/angular.md

@@ -0,0 +1,17 @@
+---
+title:      "Angular"
+ring:       trial
+quadrant:   languages-and-frameworks
+
+---
+In addition to numerous major upgrades from version 2 to 5, which often needed a "hands-on" approach, a lot has happened in the Angular 
+ecosystem in 2017. Specifically, the improvements in the HTTP-Client, which now requires less coding effort. Or 
+the vast improvements on angular.cli such as aot (ahead of time compile) for faster rendering, fewer requests and 
+much smaller builds, to just name the most important ones.
+
+We have achieved particularly good results using Angular in large and medium-size projects. Actually, 
+it's our framework-of-choice in our telecommunication sector teams as a single-page application framework (SPA) for microservice front 
+ends.
+
+The convenient scaffolding of unit- and end-to-end-tests provides a quality-driven workflow.
+Also, the module- and component architecture helps to keep the codebase understandable end maintainable.

radar/2018-03-01/artifactory.md

@@ -0,0 +1,11 @@
+---
+title:      "Artifactory"
+ring:       adopt
+quadrant:   platforms-and-aoe-services
+
+---
+
+Artifactory is now used in every newly started project at AOE and plays a
+central role as an artifact repository for libraries, applications and docker
+images.  While cleanup is still an issue, we recommend the adoption of an
+artifact repository in all our projects.

radar/2018-03-01/asciidoc.md

@@ -0,0 +1,12 @@
+---
+title:      "AsciiDoc"
+ring:       assess
+quadrant:   tools
+
+---
+
+AsciiDoc is a [lightweight markup language](https://en.wikipedia.org/wiki/Lightweight_markup_language) such as Markdown. 
+With a concise Syntax, it supports more features than Markdown without extensions such as Tables and Table of Contents.
+It's easy to write complex documentation with AsciiDoc. And with Asciidoctor you can export your text to Pdf, HTML, etc.
+
+At AOE, we use AsciiDoc for Documentation in our Repositories.

radar/2018-03-01/axure.md

@@ -0,0 +1,16 @@
+---
+title:      "Axure"
+ring:       trial
+quadrant:   tools
+
+---
+
+[Axure](https://www.axure.com/) is a tool that enables the creation of flowcharts, wireframes, mockups, user journeys and more.
+Through features such as conditional logic, dynamic content and animations it is possible to create highly functional and rich UI prototypes, which convey a realistic look and feel as to how the application to be developed should behave and look.
+ 
+We at AOE have used Axure successfully in several projects and it helped us a lot, particularly:
+ - as a basis for discussing how features should look, feel and work with customers
+ - as a basis for customers' discussions with other stakeholders
+ - as a basis for discussion and specifications for developers as to how features should look and behave
+ 
+In conclusion, Axure is a great tool that provides all stakeholders with a common understanding and helped us a lot to specify requirements and find their implications.

radar/2018-03-01/babel.md

@@ -0,0 +1,10 @@
+---
+title:      "Babel"
+ring:       adopt
+quadrant:   languages-and-frameworks
+---
+
+We have been using babel for some time now. Since we have started using it, we don't have to
+struggle with unimplemented features of ECMAScript. In this regard, JavaScript is
+JavaScript, no matter what browser you are using. We we strongly recommend 
+using Babel or similar solutions (e.g. TypeScript).

radar/2018-03-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 that inevitably occur when developing and operating complex software solutions. After any major incident or outage, the team gets together to perform an in-depth analysis of what happened and what can be done to mitigate the risk of similar issues happening in the future.
+
+Based on trust, and under the assumption that every person involved had good intentions to do the best-possible job 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 consists of both a timeline of the events leading to an incident and the steps taken to its remediation, as well as 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/2018-03-01/consul.md

@@ -0,0 +1,3 @@
+---
+featured: false
+---

radar/2018-03-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 explanations of tropers.
+
+This is how we often conduct a CRC Session:
+* 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 scenarios (such as "customer adds a promoted product to cart and sees 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 scenarios 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 scenario with the help of the classes.
+    * This is similar to explaining a sequence diagramm and the cards are put on the table from left to right. During or after this, you can discuss design decisions and alternatives with the team.
+    * After this, someone else can stand up and present a potential alternative sequence.
+    * Once the team is aligned on a version they want to implement, it makes sense that it is repeated by different persons. Being exact is very important and avoids the situation where people can have an individual 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 being documented in your [Architecture decision records](/methods-and-patterns/adr.html)
+
+
+
+
+

radar/2018-03-01/docker.md

@@ -0,0 +1,8 @@
+---
+title:      "Docker"
+ring:       adopt
+quadrant:   platforms-and-aoe-services
+
+---
+
+Docker has pulled off very quickly and we updated it to "adopt".

radar/2018-03-01/elasticsearch.md

@@ -0,0 +1,10 @@
+---
+title:      "Elasticsearch"
+ring:       adopt
+quadrant:   platforms-and-aoe-services
+
+---
+We are continuing to use Elasticsearch successfully in [Searchperience®] and have benefited from the aggregation features for related use cases such as rendering category trees.
+We are also using Elasticsearch for some microservices as our persistence solution.
+
+This is why we have updated its status to **adopt**.

radar/2018-03-01/flow.md

@@ -0,0 +1,3 @@
+---
+featured: false
+---

radar/2018-03-01/gatlin.md

@@ -0,0 +1,10 @@
+---
+title:      "Gatling"
+ring:       adopt
+quadrant:   tools
+
+---
+
+Gatling is now the de-facto tool of choice for load testing in all of our
+projects, having superseded JMeter completely. We therefore moved it to the
+**Adopt** level. 

radar/2018-03-01/gitlab-ci.md

@@ -0,0 +1,16 @@
+---
+title:      "Gitlab CI"
+ring:       assess
+quadrant:   tools
+---
+
+Until now, we have been using [Jenkins](https://jenkins.io/) for almost every single task that we have automated. With [Gitlab CI](https://about.gitlab.com/features/gitlab-ci-cd/) on the market, we have a number of new possibilities.
+
+Some of the highlights are:
+
+* Multi-platform – you can execute builds on Unix, Windows, OSX, and any other platform that supports Go.
+* Multi-language – build scripts are command-line driven and work with Java, PHP, Ruby, C and any other language.
+* Pipeline – you can define multiple jobs per stage and you can trigger other builds.
+* Autoscaling – you can automatically spin up and down VM's to make sure your builds get processed immediately and minimize costs.
+* Build artifacts – you can upload binaries and other build artifacts to GitLab and browse and download them.
+* Docker support – you can use custom Docker images, spin up services as part of testing, build new Docker images, even run on Kubernetes. 

radar/2018-03-01/gitlab.md

@@ -0,0 +1,13 @@
+---
+title:      "Gitlab"
+ring:       trial
+quadrant:   tools
+---
+
+[Gitlab](https://about.gitlab.com/) provides nearly the same feature set as [Github](https://github.com/), but at a lower price. It also provides the possibility of hosting iternally, which is essential for us.
+
+We are migrating more and more repositories from [gitolite](http://gitolite.com/gitolite/index.html), even from SVN to gitlab, as it provides a more stable and user friendly interface.
+
+Gitlab also makes user/permission handling easier than our old gitolite. We don't need the IT team every time a new repository needs to be set up.
+
+

radar/2018-03-01/go-lang.md

@@ -0,0 +1,9 @@
+---
+title:      "Go / Golang"
+ring:       trial
+quadrant:   languages-and-frameworks
+
+---
+
+We have moved Go to Trial because multiple teams have used Go with success for different services and tools.
+The learning curve and productivity have proven to be immense and we are convinced that this language will find more adoption in other teams.

radar/2018-03-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 different 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/2018-03-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 an RPC setup.
+gRPC was initially built at Google, and uses protobuf service definitions for method and payload specification.
+Essentially, this makes it possible to define methods that a server exposes, with either a single payload or an incoming stream - either as a single response or a stream of responses.
+The definition itself is carried out 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 you to create all code for all languages automatically and helps with the interoperability of different systems.
+
+From a technical point of view, gRPC uses HTTP/2 as a transport, directly benefitting from the default TLS encryption.
+Besides gRPC, other frameworks also use protobuf RPC definitions. These frameworks include 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/2018-03-01/gulp.md

@@ -0,0 +1,3 @@
+---
+featured: false
+---

radar/2018-03-01/hal-hateoas.md

@@ -0,0 +1,12 @@
+---
+title:      "HAL / HATEOAS"
+ring:       trial
+quadrant:   methods-and-patterns
+
+---
+We still recommend the usage of HAL and HATEOAS.
+ 
+But, depending on the resource structure, there are some pitfalls to be aware of:
+- Increased amount of HTTP calls
+- Parallelization of client-side calls is more difficult or even impossible when following links on heavily nested resource structures
+- Consumer side code might get larger  

radar/2018-03-01/helm-terraform.md

@@ -0,0 +1,14 @@
+---
+title:      "Helm/Terraform"
+ring:       trial
+quadrant:   tools
+
+---
+
+For the infrastructure of our OM3 projects we run multiple Kubernetes clusters, and to orchestrate the infrastructure provisioning we quickly decided 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 its 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/2018-03-01/imgix.md

@@ -0,0 +1,3 @@
+---
+featured: false
+---

radar/2018-03-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/2018-03-01/jest.md

@@ -0,0 +1,8 @@
+---
+title:      "Jest"
+ring:       adopt
+quadrant:   tools
+
+---
+
+Updated to "adopt".

radar/2018-03-01/keycloak.md

@@ -0,0 +1,10 @@
+---
+title:      "Keycloak"
+ring:       adopt
+quadrant:   tools
+---
+Most distributed systems still face a growing demand for user management, authentication, authorization and Single sign-on. In light of a growing security demand and specialization, the Open Source project JBoss Keycloak is a perfect match. 
+
+Keyloak has been a growing project from the outset and has a strong community. Keyloak is based on standards such as OAuth2, OIDC and SAML2. Securing a distributed system is supported by adapters, which are provided by Keycloak developers for different technology stacks. If there is no adapter for your technology stack, an integration on the protocol level with a library is simple. Many configurable features require no coding in the integrated projects. The required configuration is managed via code and promoted as usual. 
+
+We use Keycloak in our OM3 suite for several authentication-related use cases – such as user management for system users and Single sign-on for customers. The OAuth access tokens can be used to secure APIs that access sensitive information. In addition, Keycloak is part of the AOE infrastructure and helps in securing the various services to support employees and customers.

radar/2018-03-01/kubernetes.md

@@ -0,0 +1,13 @@
+---
+title:      "Kubernetes"
+ring:       adopt
+quadrant:   platforms-and-aoe-services
+
+---
+
+Kubernetes has developed into the quasi-standard for container orchestration: Nearly every cloud provider provides managed Kubernetes, and even Docker Enterprise uses Kubernetes.
+We are running several production systems with Kubernetes and we are using it in concepts such as:
+ * "secrets" and "configmaps" to manage configurations for the applications. By updating these resources with an automated configuration pipeline you have a great method for configuration management.
+ * Autoscaling of Kubernetes nodes and the usage of "horizontal pod scaling" inside Kubernetes allows elastic scaling
+ * The support of managing permissions with OAuth allows you to secure Kubernetes with [Keycloak](/tools/keycloak.html) (SSO)
+ * Kubernetes extensibility and API can be used for automation and customization. There is a growing ecosystem around extensions, which adds additional features.

radar/2018-03-01/maintain-third-party-packages.md

@@ -0,0 +1,3 @@
+---
+featured: false
+---

radar/2018-03-01/micro-frontends.md

@@ -0,0 +1,17 @@
+---
+title:      "Micro Frontends"
+ring:       assess
+quadrant:   methods-and-patterns
+---
+
+We see many benefits in Microservices – especially in large teams – but often this architecture 
+does not involve the user interface. Instead, you might end up maintaining a frontend monolith. With Micro Frontends 
+you enable your frontend developers to gain the same benefits that we have grown accustomed to in a Microservice architecture: 
+Decoupled components, which are developed and deployed by independent teams. But what sounds reasonable comes with 
+challenges. Integrating different Frontends on the client- or server-side can be tricky, as well as keeping the overall 
+User Experience consistent.
+
+Despite the challenges, Micro Frontends help us to develop large applications across multiple teams. Developers can
+work more independently without having too much trouble maintaining a large codebase. Being able to update oder 
+replace Frontend libraries in some parts of the application is yet another benefit in the fast-moving world of 
+frontend development.

radar/2018-03-01/microservices.md

@@ -0,0 +1,11 @@
+---
+title:      "Microservices"
+ring:       adopt
+quadrant:   methods-and-patterns
+
+---
+
+We continue to stand by are belief in the microservices concept. However, it's worth mentioning that we we had to learn some lessons when it came to resilient thinking and deployment-related dependencies between microservices. 
+
+We feel that our microservice-based applications are more robust than monolithic ones have been. Thanks to the 
+split of the overall complexity into multiple services, new employees or team members are becoming productive within days or a few weeks.

radar/2018-03-01/neo4j.md

@@ -0,0 +1,3 @@
+---
+featured: false
+---

radar/2018-03-01/oro-platform.md

@@ -0,0 +1,3 @@
+---
+featured: false
+---

radar/2018-03-01/pact.md

@@ -0,0 +1,17 @@
+---
+title:      "PACT"
+ring:       trial
+quadrant:   tools
+
+---
+
+PACT (http://pact.io/) is a family of frameworks that provides 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 to 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 it can be conducted with PACT is documented very nicely on the official PACT website: https://docs.pact.io/.

radar/2018-03-01/pair-working.md

@@ -0,0 +1,3 @@
+---
+featured: false
+---

radar/2018-03-01/phan.md

@@ -0,0 +1,3 @@
+---
+featured: false
+---

radar/2018-03-01/php7-over-php5.md

@@ -0,0 +1,3 @@
+---
+featured: false
+---

radar/2018-03-01/pipeline-as-code.md

@@ -0,0 +1,10 @@
+---
+title:      "Pipeline as Code"
+ring:       adopt
+quadrant:   methods-and-patterns
+
+---
+
+We moved this pattern to **adopt**, because it is used by nearly every team and project now and is an important part of our automation.
+
+For Jenkins, we often use a mix of Job DSL and Jenkins Pipelines and recently also used Gitlab Pipelines.

radar/2018-03-01/ports-and-adapters.md

@@ -0,0 +1,33 @@
+---
+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 from the outside to the inside.
+
+We use "ports and adapters" with success for (larger) applications, which contain certain business logic and/or provide several ways to access the services.
+We often use the approach hand-in-hand with Domain Driven Design. In comparison with other layering patterns (e.g. layered architecture) it allows you to have a true technology-free core (domain) model. Why? 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 regarding where to put what logic of your application.
+
+You can find out more about the details and its origins in well-known blog posts such as [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 uses building blocks from Domain Driven Design
+    * It defines primary and secondary ports. (E.g. a secondary port is in "interface" that needs to be implemented in the infrastructure layer.)
+* Application:
+    * Contains the Application's API and Services, that are developed around the use cases in the application requirements.
+    * These use cases orchestrate the flow of data to and from the domain
+* Interfaces:
+    * Contain everything required to convert data from the format most-convenient for the use cases (e.g. in the application layer) to the format required for external agency/access
+    * e.g. (Web) Controllers / DTOs for handling forms, etc.
+* Infrastructure:
+    * This layer is where all the (technical) details live. (The database and persistence is a detail, the communication format and mappings with external services is a detail, etc.)
+    * In this layer you typically have adapters for the secondary ports that have been defined in the layers below. (e.g. an Implementation of a Repository interface from the Domain layer)
+
+These layers belong to every bounded context (modules) inside the application.
+
+Are you searching for a potential timeless architecture for your critical application? Try implementing a potent technology-free domain model in the core layer and use ports and adapters to layer your application.

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

@@ -0,0 +1,8 @@
+---
+title:      "Puppet Environments"
+ring:       trial
+quadrant:   platforms-and-aoe-services
+
+---
+
+Puppet Environments has proven to work well for our projects using Puppet.

radar/2018-03-01/react.md

@@ -0,0 +1,11 @@
+---
+title:      "React.js"
+ring:       adopt
+quadrant:   languages-and-frameworks
+---
+
+The past months have shown that React is still a great fit for us for frontend-heavy
+applications. With its rewritten core in version 16, Facebook shows how
+important this framework is for them. Therefore, Facebook is investing a lot of effort into React and a
+healthy community. In addition, we **REALLY** enjoy writing React
+components – so much so, that we have to move this library into **adopt**!

radar/2018-03-01/reactive-programming.md

@@ -0,0 +1,34 @@
+---
+title:      "Reactive Programming"
+ring:       trial
+quadrant:   methods-and-patterns
+
+---
+
+Classic (web-) applications typically consist of transactions that submit
+large forms to the server side, which then processes these and, in response, returns HTML
+for the browser to render. Today's applications have more and more
+fine-grained 'real-time'-like aspects: A simple modification of a form field
+could trigger a complete roundtrip to the server including other services and
+persistence. Naturally, all of these transactions should respect the
+expectations of a user who wants a highly interactive application.
+
+"Reactive Programming" tries to provide an answer to the challanges mentioned above
+by raising the level of abstraction. This allows you to focus on the stream of
+events that make up your business logic in a responsive, asynchronous fashion.
+
+There are various descriptions of what Reactive Programming actually is - at
+the most general level it is programming with asynchronous data streams and
+contains tools to create, manipulate, combine and filter these streams. Under the term
+"Reactive Programming", we summarize the principles and implementations that
+underlie [ReactiveX](http://reactivex.io/) and the [Reactive
+Manifesto](https://www.reactivemanifesto.org/). 
+
+"Reactive Programming" is employed in many of our services – frontend and
+backend – but not always as an explicitly choosen pattern. As different
+plattforms have different means to tackle this style of programming, we choose
+to include "Reactive Programming" as a general Method and Patterns Item in
+addition to concrete libraries and APIs such as
+[Rx.JS](languages-and-frameworks/rxjs.html) or [Akka
+Streams](/languages-and-frameworks/akka-streams.html) to highlight the
+importance of the approach in general.

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

@@ -0,0 +1,8 @@
+---
+title:      "Scala Lang"
+ring:       adopt
+quadrant:   languages-and-frameworks
+
+---
+
+Scala is used in many projects at AOE. We have therefore moved it to the **adopt** level.

radar/2018-03-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 infrastructures, 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 (among others) JVM, Go and PHP applications.
+Most of the hosting/provisioning decisions are better kept within the team, as the teams know how their applications work. 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 to another team what to do, resulting in a better collaboration than before.

radar/2018-03-01/sonarqube.md

@@ -0,0 +1,8 @@
+---
+title:      "SonarQube"
+ring:       assess
+quadrant:   tools
+
+---
+
+At AOE, we're evaluating SonarQube to get an historical overview of the code quality of our Projects. With SonarQube, you can get a quick hint about the condition of your code. It analyzes many languages and provides numerous static analysis rules.

radar/2018-03-01/sparkpost.md

@@ -0,0 +1,3 @@
+---
+featured: false
+---

radar/2018-03-01/spring-boot.md

@@ -0,0 +1,10 @@
+---
+title:      "Spring Boot"
+ring:       trial
+quadrant:   languages-and-frameworks
+
+---
+
+We have had good experiences with Spring Boot, and already have several Spring Boot-based services running in 
+production. We like the ease of kickstarting new services and the variety of tools in the Spring ecosystem.
+ 

radar/2018-03-01/styleguide-driven-development.md

@@ -0,0 +1,8 @@
+---
+title:      "Styleguide Driven Development"
+ring:       adopt
+quadrant:   methods-and-patterns
+
+---
+
+Updated to "adopt".

radar/2018-03-01/typo3-as-a-framework.md

@@ -0,0 +1,3 @@
+---
+featured: false
+---

radar/2018-03-01/vue.md

@@ -0,0 +1,8 @@
+---
+title:      "Vue.js"
+ring:       trial
+quadrant:   languages-and-frameworks
+
+---
+
+Updated to "trial".

radar/2018-03-01/webpack.md

@@ -0,0 +1,12 @@
+---
+title:      "Webpack"
+ring:       adopt
+quadrant:   tools
+---
+
+In the last few years, Webpack has grown to become the de-facto standard for Web
+bundling in the JavaScript-Ecosystem. With Version 3, Webpack is a more robust
+and better documented bundler with nice new features such as
+[scope hoisting](https://webpack.js.org/plugins/module-concatenation-plugin/).
+Because of this, and because of the continuously growing community, we have adopted Webpack for nearly
+every single-page application we have.

radar/2018-03-01/xataface.md

@@ -0,0 +1,3 @@
+---
+featured: false
+---

radar/2018-03-01/yarn.md

@@ -0,0 +1,11 @@
+---
+title:      "Yarn"
+ring:       trial
+quadrant:   tools
+
+---
+Yarn is a 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 a 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.