Maintain first results from Tech Radar Q1 2017

This commit is contained in:
Daniel Pötzinger
2017-03-31 08:56:31 +02:00
parent 2656df8cc7
commit 24628cc38f
20 changed files with 254 additions and 101 deletions

35
radar/2017-03-01/babel.md Normal file
View File

@@ -0,0 +1,35 @@
---
title: "Babel"
ring: trial
quadrant: languages-and-frameworks
---
[Babel](https://babeljs.io/) gives you the possibility to use the latest features from JavaScript ([ECMAScript](https://en.wikipedia.org/wiki/ECMAScript)) in the browser of your choice.
Without Babel in the backbone; you had to use the feature set of your oldest browser or use feature detections such as [modernizr](https://modernizr.com/) or write polyfills on your own.
In general, Babel is split in 2 ways to bring you the new goodies you want.
1. New syntax will be compiled to old EcmaScript 5 code e.g.:
* [arrow-functions](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions)
* [generators](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Generator)
* [destructing](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment)
* [template literals](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals)
* [...](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)
* [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)
The configuration is really simple due to the [plugin system](http://babeljs.io/docs/plugins/). You can choose which ECMAScript version and [stage presets](http://babeljs.io/docs/plugins/) you want to use.
* for the latest ECMAScript version use [babel-preset-latest](https://babeljs.io/docs/plugins/preset-latest/)
* for version 2015 only use [babel-preset-2015](https://babeljs.io/docs/plugins/preset-es2015/)
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.

View File

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

View File

@@ -0,0 +1,16 @@
---
title: "ELK Stack"
ring: adopt
quadrant: platforms-and-aoe-services
---
The company behind Elasticsearch offers a very nice solution for logging and analysis of distributed data such as logfiles.
In today's increasingly distributed IT systems, it's very helpful to have a central view of what is going on in your systems - and of course nobody can and wants to look in different logfiles on different servers. A central logging solution provides the option to detect potential relationships between different events more easily. Also, also it can be used to extract useful KPIs or to visualize information on dashboards.
The abbreviation "[ELK](https://www.elastic.co/products) Stack" stands for the Tools <u>E</u>lasticsearch, <u>L</u>ogstash and <u>K</u>ibana: Together, they provide a solution for collecting data the ability to search, visualize and analyze data in real time.
Logstash is used to process and forward different data (or logfile) formats. <u>E</u>lasticsearch is used as a search index and together with the Kibana plugin you can configure highly individual dashboards. Recently, there are also the Beats Tools joining this toolstack to ship data to Elasticsearch.
We have been using the ELK Stack for several years now in several projects and different infrastructure setups - we use it to visualize traffic, certain KPIs or just to analyze and search in application logs. We encourage all teams to use such a solution and take care to write useful logs in your applications.

16
radar/2017-03-01/flow.md Normal file
View File

@@ -0,0 +1,16 @@
---
title: "Flow"
ring: hold
quadrant: languages-and-frameworks
---
[Flow](https://flow.neos.io/) is a PHP web application framework developed for the [Neos](https://www.neos.io/) project.
We used Flow in a couple of projects and decided to put it on hold for the following reasons:
* slow during development and hard to debug because of its need to "compile" the application to integrate e.g. AOP
* 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))

View File

@@ -1,7 +0,0 @@
---
title: "Foo"
ring: trial
quadrant: methods-and-patterns
---
Foo

View File

@@ -1,7 +1,25 @@
---
title: "Grunt 2"
title: "Grunt"
ring: hold
quadrant: tools
---
Hier steht was neueres über *Grunt*
Grunt is a JavaScript task runner that automates repetitive tasks. While Grunt served us well for a good amount of projects,
other alternatives such as [Gulp](http://gulpjs.com/) emerged in the meantime and proved to be a better pick for the
majority of our teams.
We have two main reasons for discarding Grunt in favor of other tools:
### Speed
If a decent amount of tasks is reached, Grunt is known to run slower than other tools, because it heavily relies on I/O operations and
always stores the result of one task as files on the disk.
### Configuration
On large projects where a lot of automation is required, it can get very tedious to maintain complex and parallel running tasks.
The grunt configuration files sometimes simply don´t gave us the flexibility that we needed.
Currently our preferred way to go is either simply use [NPM scripts](https://docs.npmjs.com/misc/scripts) or rely on [Webpack loaders](https://webpack.js.org/concepts/loaders/) for file preprocessing. For non-webpack projects we also utilize Gulp.

53
radar/2017-03-01/gulp.md Normal file
View File

@@ -0,0 +1,53 @@
---
title: "Gulp"
ring: adopt
quadrant: tools
---
Gulp is a javascript task runner much like Grunt. The tasks are written in javascript code.
It is a tool that helps you automate numerous tasks surrounding web development. A typical use is to configure preprocessors for Sass, to compile CSS or to optimize CSS, Javascript and Images.
With Gulp and its many plugins you can also do stuff such as start a web server and reload the browser if changes happen.
To get started you need to install Gulp on your machine via npm.
```javascript
npm install gulp -g
```
You also need it locally in your project, so you have to install it as a dependency in your project .
```javascript
npm install gulp --save-dev
```
You can split your tasks into various smaller sub-tasks and even split it up into smaller files.
A basic Gulp task can look like this:
```javascript
const gulp = require('gulp');
// Requires the gulp-sass plugin
const sass = require('gulp-sass');
const autoprefixer = require('gulp-autoprefixer');
const cssnano = require('gulp-cssnano');
gulp.task('sass', function(){
return gulp.src('app/scss/**/*.scss') // tell gulp where your source files are
.pipe(sass()) // Converts sass into css with the help of a gulp plugin called gulp-sass
.pipe(autoprefixer({browsers: ['last 2 versions']})) // auto prefixes the css for the last 2 versions of browser, like ie9 specific css
.pipe(cssnano()) // minify the css
.pipe(gulp.dest('app/css')) // tell gulp where to put the converted file. this is the first time where a file is written
});
```
you can now run this task simply by executing the following command in your terminal:
```javascript
gulp sass
```

View File

@@ -0,0 +1,22 @@
---
title: "Microservices"
ring: trial
quadrant: methods-and-patterns
---
Microservices as an architecture style is getting very popular recently. At AOE, more and more teams are adding microservices to their existing application architecture or designing applications with microservices.
We also like the term "self-contained systems" instead of microservices.
The benefits we see are:
* better handling of complexity compared to adding features in a monolithic approach
* beeing able to use the languages and framework that best fit the purpose of the service
* 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.
Also [Resilience thinking](/confluence/display/knowledge/Resilience+thinking) is especially important when designing an application as a suite of microservices.

View File

@@ -0,0 +1,22 @@
---
title: "Pin external dependencies"
ring: adopt
quadrant: methods-and-patterns
---
A lot of applications have dependencies on other modules or components. We have used different approaches regarding how and when these dependencies are resolved and have agreed on using a method we call "Pin (External) dependencies".
This is especially relevant for script languages, where the dependency management references the code and not immutable prebuild binaries - and therefore resolves the complete transient dependencies on the fly.
Most of these package- or dependency management solutions support two artefacts:
* a semantic dependency definition. This defines the compatible versions of the required dependencies. (Composer: composer.json / NPM: package.json)
* a lock file defining the exact revisions of the dependencies and the transient dependencies (dependencies of dependencies). This is created after running the tool. (Composer: composer.lock / NPM: npm-shrinkwrap.json).
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))
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,12 @@
---
title: "Pipeline as Code"
ring: assess
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.](/confluence/display/knowledge/Artifactory)

View File

@@ -1,28 +0,0 @@
---
title: "This is a long title"
ring: assess
info: React is a view library
quadrant: languages-and-frameworks
---
React blablab *React* - super **"cool"**
> Das ist aber askdfjas jkdfhas kdf af als
# test h1
## Test h2
### Test h3
Hier steht der Rest!
- 123123
- 12312 3
- 123123123
1. test
2. adsfsdf

30
radar/2017-03-01/sass.md Normal file
View File

@@ -0,0 +1,30 @@
---
title: "SASS"
ring: adopt
quadrant: languages-and-frameworks
---
SASS (Syntactically Awesome Style-Sheets) is an extension to native CSS, which, as a preprocessor, simplifies the generation of CSS by offering features that enable developers to more efficiently write robust, better readable and maintainable CSS.
Core features of SASS are:
* Nesting of rules: CSS rules can be indented, reducing redundancy of selectors and increasing readability due to shorter selectors.
* Use of variables: Commonly-used values such as colors can be stored in variables
* Mixins: Often-used CSS blocks can be referenced by using mixins, which work like functions
* Extends: CSS properties can be inherited
* SASS files can be split into modules, which leads to smaller files and better file structures
* Operators: Simple math calculations can be applied to CSS properties
* Easily to integrate in nodejs-environments and build tools such s [NPM](/confluence/display/knowledge/NPM), [Gulp](/confluence/display/knowledge/Gulp) and [Grunt](/confluence/display/knowledge/Grunt).
SASS has been widely adopted for many years and has evolved to an industry-standard backed by an active community since 2006.
The learning curve is very smooth as SASS is fully compatible to CSS, meaning that all features are optional: Starting with SASS is as easy as renaming .css-files to .scss in a first step and then refactoring it step-by-step with the use of SASS features.
At AOE, SASS has been recommended by the frontend COI and is used in nearly every current project.
More information:
* [SASS Language](http://sass-lang.com/)
* [SASSDoc](http://sassdoc.com/)
* [Improving Sass code quality on](https://www.theguardian.com/info/developer-blog/2014/may/13/improving-sass-code-quality-on-theguardiancom) [theguardian.com](http://theguardian.com)

View File

@@ -0,0 +1,18 @@
---
title: "Spock + Geb"
ring: adopt
quadrant: languages-and-frameworks
---
[spockframework.org](http://www.spockframework.org) - Spock is a testing and specification framework for Java and Groovy applications. What makes it stand out from the crowd is its beautiful and highly expressive specification language. Thanks to its JUnit runner, Spock is compatible with most IDEs, build tools and continuous integration servers. Spock is inspired from JUnit, jMock, RSpec, Groovy, Scala, Vulcans, and other fascinating life forms.
[gebish.org](http://www.gebish.org) - Geb is a browser automation solution. It brings together the power of WebDriver, the elegance of jQuery content selection, the robustness of Page Object modelling and the expressiveness of the Groovy language. It can be used for scripting, scraping and general automation or equally as a functional/web/acceptance testing solution via integration with testing frameworks such as Spock, JUnit & TestNG.
At AOE, we use Spock in combination with Geb in various projects for black-box testing. Mainly, we implement our functional integration and acceptance testing automation with these frameworks, which work together seamlessly. And, we also like the convenience of extending the tests with Groovy built-ins or custom extensions.
Because of the successful use in two of our large projects and the wide range of opportunities within the testing domain with Spock and Geb, we classify this combo with adopt.
<!--except-->

View File

@@ -1,17 +1,12 @@
---
title: "Vue"
ring: adopt
title: "Vue.js"
ring: assess
quadrant: languages-and-frameworks
---
Hier steht eine Einleitung über *React* - super "cool"
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/).
Hier noch ein [link](http://www.google.de) zu google
Vue uses an HTML-based template syntax that allows you to declaratively bind the rendered DOM to the underlying Vue instances 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.
<!--except-->
Hier steht der Rest!
History
-------
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.

View File

@@ -1,17 +0,0 @@
---
title: "Vue 123"
ring: assess
quadrant: languages-and-frameworks
---
Hier steht eine Einleitung über *React* - super "cool"
Hier noch ein [link](http://www.google.de) zu google
<!--except-->
Hier steht der Rest!
History
-------

View File

@@ -1,17 +0,0 @@
---
title: "Something else"
ring: hold
quadrant: languages-and-frameworks
---
Hier steht eine Einleitung über *React* - super "cool"
Hier noch ein [link](http://www.google.de) zu google
<!--except-->
Hier steht der Rest!
History
-------

View File

@@ -1,8 +0,0 @@
---
title: "Flow"
ring: assess
quadrant: languages-and-frameworks
---
Irgendwas über flow...