Add some more articles

This commit is contained in:
Daniel Pötzinger
2017-03-31 09:27:03 +02:00
parent 24628cc38f
commit ff6b9f3988
17 changed files with 147 additions and 9 deletions

1
.gitignore vendored
View File

@@ -1,3 +1,4 @@
.DS_Store
dist
node_modules
npm-debug.log

View File

@@ -29,6 +29,11 @@ Each file has a [front-matter](https://github.com/jxson/front-matter) header whe
---
Text goes here
<!--except-->
Additional Stuff goes here
```
Following front-matter attributes are possible:

Binary file not shown.

After

Width:  |  Height:  |  Size: 164 KiB

View File

@@ -0,0 +1,16 @@
---
title: "Angular 2"
ring: assess
quadrant: languages-and-frameworks
---
The latest version of the Angular Framework, which is used for large single-page applications.
[Angular 2](https://angular.io/) is a complete rewrite of Angular 1 — any many things have changed compared to the first version. The latest best practices and toolings from the JavaScript community have found their way into Angular2.
It supports DI (dependency injection), it has a clean inheritance and a good separation of concerns. Angular2 follows the [web component standards](https://www.w3.org/standards/techs/components#w3c_all) to avoid negative side effects between components.
We think that Angular2+ is well-structured on both a development and an application level.
When talking about Angular2, we must consider the [angular.cli](https://cli.angular.io/) as well, which provides a huge level of intelligent automation along the development process and project setup.

View File

@@ -0,0 +1,7 @@
---
title: "Artifactory"
ring: adopt
quadrant: platforms-and-aoe-services
---

View File

@@ -20,7 +20,7 @@ In general, Babel is split in 2 ways to bring you the new goodies you want.
* [...](https://babeljs.io/learn-es2015/)
2. New globals and functions are provided by [babel-polyfill](http://babeljs.io/docs/usage/polyfill/) e.g.:
* * [Promise](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise)
* [Promise](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise)
* [Array.find](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/find)
* [Array.includes](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/includes)
* [...](https://github.com/zloirock/core-js#index)
@@ -32,4 +32,4 @@ The configuration is really simple due to the [plugin system](http://babeljs.io/
To know what you need you can practice ECMAScript 6 by doing it with [es6katas](http://es6katas.org/) and ask [caniuse](http://caniuse.com/).
If you are using [TypeScript](https://extranet.aoe.com/confluence/display/knowledge/Typescript), Babel is not necessary since you already get the new features with TypeScript.
If you are using [TypeScript](/languages-and-frameworks/typescript.html), Babel is not necessary since you already get the new features with TypeScript.

View File

@@ -0,0 +1,7 @@
---
title: "Decoupling Infrastructure via Messaging"
ring: trial
quadrant: methods-and-patterns
---

View File

@@ -13,4 +13,4 @@ We used Flow in a couple of projects and decided to put it on hold for the follo
* limited documentation and community
* development of the framework is closely coupled to the progress of the Neos project
Although it could be that some of the above-mentioned aspects have improved in the past, we decided to use other PHP frameworks such as [Symfony](http://symfony.com/) or other Languages (See [Go](/confluence/display/knowledge/Go); [Play Framework](/confluence/display/knowledge/Play+Framework); [Spring Boot](/confluence/display/knowledge/Spring+Boot))
Although it could be that some of the above-mentioned aspects have improved in the past, we decided to use other PHP frameworks such as [Symfony](http://symfony.com/) or other Languages (See [Go](/languages-and-frameworks/go-lang.html); [Play Framework](/languages-and-frameworks/play-framework.html); [Spring Boot](/languages-and-frameworks/spring-boot.html))

View File

@@ -0,0 +1,18 @@
---
title: "Go / Golang"
ring: assess
quadrant: languages-and-frameworks
---
2016 was the year of Go, with a lot of Open Source projects gaining a lot of attention and many companies started to use it.
Go went from #54 to #13 on the [TIOBE index](http://www.tiobe.com/tiobe-index/) in January 2017, and it became the TIOBE programming language of the year 2016.
Here at AOE, we use several services written in Go on a daily basis, such as Mattermost, Docker, Consul and Kubernetes. Also, more and more applications, such as Gitlab, incorporate Go-based services to "off load" heavy work.
Go, as a programming language, has some very interesting features such as native support for concurrency (go routines), static compiled binaries with a very small memory footprint, cross compiling and much more. A big advantage of Go is the very flat learning curve, which allows developers from more dynamic languages such as PHP to be proficient in a very short time.
If you want to get a feeling for Go, you should start with the [online tour](https://tour.golang.org/welcome/1), within a day you'll have a good understanding of the core concepts, syntax, etc. - that is also because the language often tries to provide only one simple way of doing things; an example for this is that code formatting and styling is defined (yet not enforced as in Python). Part of this is also that Go itself is very opinionated: So, for example, for object oriented programming in Go, composition is the prefered way of defining data structures, and some might miss advanced concepts such as inheritance.
We currently use Go for projects and microservices where we need flexibility and performance.

View File

@@ -17,6 +17,6 @@ The benefits we see are:
* enabling better parallel work in big teams or multi-team projects
* flexibility in deploying changes to production - by just deploying the changed service
Related patterns are [Strategic Domain Driven Design]() as an approach to wisely cut your architecture according to useful bounded contexts and decide on the relevant communication and "translation" between the services.
Related patterns are [Strategic Domain Driven Design](/methods-and-patterns/strategic-domain-driven-design.html) as an approach to wisely cut your architecture according to useful bounded contexts and decide on the relevant communication and "translation" between the services.
Also [Resilience thinking](/confluence/display/knowledge/Resilience+thinking) is especially important when designing an application as a suite of microservices.
Also [Resilience thinking](/methods-and-patterns/resilience-thinking.html) is especially important when designing an application as a suite of microservices.

View File

@@ -17,6 +17,6 @@ We suggest the following:
* Keep the dependency definition AND the lock file in version control. This ensures that chained dependencies are also locked and you have changes of that file visible in your version control commit history. This helps finding issues or bugs that might relate to unintended updates in external modules or transient dependencies.
* Build Step: The application build step should use the the pinned versions (with the help of the lock file) to ensure that the same revisions of the dependent packages are used.
* It's also suggested to use local or central caches for the retrieval of packages. (E.g. [artefactory as composer and npm cache](https://extranet.aoe.com/confluence/display/knowledge/Artefactory))
* It's also suggested to use local or central caches for the retrieval of packages. (E.g. [artifactory as composer and npm cache](/platforms-and-aoe-services/artifactory.html))
For updating of dependencies define a process in the team. This can either be done on the dev-system or in a seperate automated CI job - both resulting in updated dependency definitions in the applications VCS.

View File

@@ -0,0 +1,6 @@
---
title: "Play Framework"
ring: adopt
quadrant: languages-and-frameworks
---

View File

@@ -1,13 +1,24 @@
---
title: "React"
title: "React.js"
ring: trial
quadrant: languages-and-frameworks
---
React blablab *React* - super "cool"
React claims to be "the V in MVC". But for us it is much more than that. React improved the way we approach frontend applications as we build them. Its functional way of writing components
and its declarative JSX syntax help us to build interactive UIs very efficiently.
React's one-way data flow keeps everything modular and fast and makes even large applications more readable.
Components are the central point of React - once we fully started [thinking in react](https://facebook.github.io/react/docs/thinking-in-react.html), our components became smaller, more reusable and better testable.
After some 1.5 years of experience with React and the steady growth of the community and ecosystem around it,
we can confidently say that we still see great protential to build upcoming projects with React.
<!--except-->
Hier steht der Rest!

View File

@@ -0,0 +1,20 @@
---
title: "Resilience thinking"
ring: trial
quadrant: methods-and-patterns
---
Resilience is the cabability of an application or service to resist different error scenarios. Especially for distributed systems - where a lot of communication between different services happen - it's very important to explicitly think of implementing resilience.
There are a lot of different resilience patterns and it is also a matter of the overall software design. Typical patterns and methods used are:
* Do not hide API calls or any other external communication in your application (for example with unnecessary abstraction) - instead make it explicit that an external communication happens - e.g. by using the Facade Pattern. On the one hand, this makes it obvious that a potential slow and errorprone communication is going to happen, and it makes it easier to implement error handling.
* Detect errors explicitly: Check the response message format and configure proper timeouts for external communication
* Handle errors in a smart way: Show a nice error message to your customer or, even better, graceful degrade features - e.g. by showing some fallback text
* Use Message-based communication where useful ([Decoupling Infrastructure via Messaging](/methods-and-patterns/decoupling-infrastructure-via-messaging.html))
* Use Circuit Breaker to Isolate errors and allow system to recover
* Use short activation paths in your strategic architecture - so that there is only a minimal set of communications between your services required for certain features or business requests
"Embrace Errors" should be the mindset - because its not a question if errors appear - it's just a question of when.

View File

@@ -0,0 +1,6 @@
---
title: "Spring Boot"
ring: assess
quadrant: languages-and-frameworks
---

View File

@@ -0,0 +1,19 @@
---
title: "Strategic Domain Driven Design"
ring: adopt
quadrant: methods-and-patterns
---
Design of distributed applications need to be done wisely. Strategic Domain Driven Design is an approach for modelling large-scale applications and systems and is introduced in the last part of Eric Evans' book _**Domain Driven Design**_.
Domain driven design is a well-known pattern family and has been established at AOE for quite some time now. Unlike Domain Driven Design, which focuses on the tactical design in an application, strategic domain driven design is an approach that is very helpful for the high-level strategic design of an application and distributed software architecture.
It is a pattern familiy focused on using and defining Bounded Context and thinking explicitly of the different relationship patterns and the required "translation" of similar "concepts" between the bounded contexts. It is helpful to argue and find a good strategic architecture in alignment with the requirements, the domain and by considering Conway's Law.
A context map and a common conceptional core help to understand and improve the overall strategic picture. Especially with the Microservice approach, it is important to define and connect services following the low coupling - high cohesion principles by idendifying fitting bounded contexts.
The following chart gives an overview of possible relationships between bounded contexts:
![strategic-domain-driven-design-relationships](/assets/images/strategic-domain-driven-design-relationships.png =400x "strategic-domain-driven-design-relationships")
While we have found that this approach is especially useful in designing distributed systems and applications with microservices, we have also extended this approach to provide guidlines for general enterprise architectures.

View File

@@ -0,0 +1,22 @@
---
title: "Typescript"
ring: assess
quadrant: languages-and-frameworks
---
[TypeScript](https://www.typescriptlang.org/) is a language that gets transpiled to native JavaScript code.
It offers support for the latests EcmaScript features and has strict typing and support for interfaces built in.
JavaScript scoping, which led into recurring workarounds such as **var self = this, myFunc.bind(this)_,_**was eliminated in TypeScript.
In TypeScript **this** stays **this**, which leads to more readable and understandable code from an OOP perspective.
TypeScript continues to be actively developed by Microsoft and is also well-Integrated in today's IDEs.
The excellent strucure and the possibilities for extension make it a good choice to consider for larger JavaScript projects.
Typescript was the choice for [Angular 2+](/confluence/pages/viewpage.action?pageId=88047913) and one can assume that it will get more traction with the success of Angular 2 in the future.
There are also projects that support Typescript „code execution“ on the server such as [ts-node](https://www.npmjs.com/package/ts-node).