Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Cloud-Native

Data & Machine Learning

Generative KI

IT-Security

Produktentwicklung

Weitere Leistungen...

Leistungen

Arbeitsweise

Projekte

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Softwerker

Fachmedien

Webinare

Events

Wissens-Hub

Unsere Kultur

Kultur & Karriere Podcast

Deine Entwicklung

Jobs

Karriere

Über uns

Aktuelles

Kontakt

Alle Standorte

Du hast Fragen oder möchtest dich mit mir austauschen? Gern – trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

STANDORT-TEAM

codecentric Berlin

Unser codecentric Team am Standort Berlin stellt sich vor.

codecentric Team Berlin

Willkommen im Team Berlin

<p>Nachdem im ersten Teil (<a href="/wissens-hub/blog/tutorial-serverseitiges-rendering-mit-react-teil-1-einfuehrung">Tutorial: Serverseitiges Rendering mit React – Teil 1: Einführung</a> ) die grundlegende Konfiguration für unsere serverseitig gerenderte App umgesetzt wurde und im zweiten Teil (<a href="/wissens-hub/blog/tutorial-serverseitiges-rendering-mit-react-teil-2-react-router-helmet">Tutorial: Serverseitiges Rendering mit React – Teil 2: React Router und React Helmet</a> ) React Router und React Helmet thematisiert wurden, schauen wir uns in diesem Teil an, wie wir unseren Redux Store auf dem Server und dem Client nutzen können.</p><h2>4. Redux Store</h2><p>Die größte Herausforderung beim serverseitigen Rendering ist das Herstellen des richtigen States, damit alle Komponenten so gerendert werden, wie es im Browser passieren würde.</p><p>Wir haben z.B. das Problem, dass Lifecycle-Methoden wie <code>componentDidMount()</code> nicht beim serverseitigem Rendering (SSR) ausgeführt werden. Das führt dazu, dass auch keine Daten geladen werden, die typischerweise innerhalb dieser Lifecycle-Methoden abgerufen werden. Das ist ein Problem, dass wir mit einer ganzen Menge an Boilerplate-Code beheben müssen. Gleichzeitig ist dies auch der schwierigste Teil des serverseitigen Renderings.</p><p>Ich zeige die Anpassungen beispielhaft an folgender ToDoList-Komponente:</p><div>

```javascript
import React, { Component } from 'react';
import { connect } from 'react-redux';
import { fetchToDos } from '../actions';
 
class ToDoList extends Component {
 componentDidMount() {
   this.props.fetchToDos();
 }
 
 renderToDos() {
   return this.props.todos.map(todo => {
     return <li key={todo.id}>{todo.message}</li>;
   });
 }
 
 render() {
   return (
     <div>
       ToDos:
       <ul>{this.renderToDos()}</ul>
     </div>
   );
 }
}
 
function mapStateToProps(state) {
 return { todos: state.todos };
}
 
export default connect(mapStateToProps, { fetchToDos })(ToDoList);
```

</div><p>Diese Komponente lädt die ToDos nachdem sie gemountet wurde. Anschließend werden die ToDos in einer Liste angezeigt. Wir wollen erreichen, dass auch beim SSR diese Liste bereits im statischen HTML gerendert wird.</p><h3>4.1 Redux Store hinzufügen</h3><p>Wir statten zunächst die beiden Stellen, an denen wir die Routes rendern mit dem Redux Store aus.</p><div>

```javascript
import React from 'react';
import ReactDOM from 'react-dom';
import { BrowserRouter } from 'react-router-dom';
import { createStore, applyMiddleware } from 'redux';import thunk from 'redux-thunk';import { Provider } from 'react-redux';import Routes from './Routes';
import reducers from './reducers'; 
const store = createStore(reducers, {}, applyMiddleware(thunk)) 
ReactDOM.render(
 <Provider store={store}>    <BrowserRouter>
       <Routes />
     </BrowserRouter>
 </Provider>, document.querySelector('#app')
);
```

</div><div>

```javascript
import express from 'express';
import React from "react";
import { Provider } from 'react-redux';import {StaticRouter} from "react-router-dom";
import {createStore, applyMiddleware} from 'redux';import ReactDOM  from 'react-dom/server';
import Routes from "./src/Routes";
import thunk from 'redux-thunk';import reducers from './src/reducers'; 
const app = express();
 
const renderer = (req, store) => { const content = ReactDOM.renderToString(
  <Provider store={store}>    <StaticRouter location={req.path} context={{}}>
      <Routes>
    </StaticRouter>
  </Provider> );
 
 return `
   <html>
     <head></head>
     <body>
       <div id="app">${content}</div>
       <script src="bundle.js"></script>
     </body>
   </html>
 `;
};
 
app.use(express.static('public'));
app.get('*', (req, res) => {
 const store = createStore(reducers, {}, applyMiddleware(thunk)); 
 res.send(renderer(req, store));});
 
app.listen(3000, () => {
 console.log('Server gestartet auf http://localhost:3000');
});
```

</div><p>Neu ist hier die Provider-Komponente für den Client und den Server, die den <code>store</code> als Parameter übergeben bekommt und ihn an alle Unterkomponenten weiterreicht.</p><p>Die <code>renderer()</code>-Funktion in der <em>server.js</em> bekommt neben dem Request auch einen Store als Parameter übergeben. Dieser Store wird in der <code>app.get()</code>-Methode erzeugt.</p><h3>4.2 Daten laden</h3><p>Wir wollen nun sicherstellen, dass alle Komponenten vor dem serverseitigen Rendering ihre Daten laden. Um das zu erreichen, erstellen wir eine Funktion innerhalb der Komponenten-Datei die wir z.B. <code>fetchData()</code> nennen und exportieren diese zusammen mit der eigentlichen Komponente:</p><div>

```javascript
...
class ToDoList extends Component {
...
}
 
function fetchData(store) {
 return store.dispatch(fetchToDos()); // returns a promise
}
 
export default {
 fetchData,
 component: connect(mapStateToProps, { fetchToDos })(ToDoList);
}
```

</div><p>Der Funktion <code>fetchData()</code> werden wir später den Redux Store als Parameter übergeben. Diesen nutzen wir, um die gleiche Action zu dispatchen, die auch innerhalb der <code>componentDidMount()</code>-Methode dispatched wird.</p><p>Am Ende exportieren wir ein Objekt mit den Properties <code>fetchData</code> und <code>component</code> anstelle der einzelnen Komponente. Das ist nützlich, wenn wir mit den Routes arbeiten. Aber dazu kommen wir gleich.</p><h3>4.3 Routes anpassen</h3><p>Wir wollen dafür sorgen, dass die Methode <code>fetchData()</code> für jede unserer Komponenten aufgerufen wird. Im Prinzip brauchen wir also eine Liste von Komponenten, die für die angefragte Seite gerendert werden sollen. Da hilft uns unsere <em>Routes.js</em> weiter.</p><p>Damit wir die Einträge in der <em>Routes.js</em> sehr einfach analysieren und über sie iterieren können, bringen wir sie in ein passendes Format:</p><div>

```javascript
import React from 'react';
import App from './App';
import Home from "./components/Home";
import ToDoList from "./components/ToDoList";
 
export default [
  {
    ...App,
    routes: [
      {
        ...Home,
        path: '/',
        exact: true
      },
      {
        ...ToDoList,
        path: '/todos'
      }
    ]
  }
];
```

</div><p>Wir sehen hier, dass anstelle der jsx-Syntax nun eine Liste von Objekten für jede Route erzeugt wird. Das ist zwar nicht sehr hübsch, bringt uns aber im Folgenden viele Vorteile. Und wir verlieren hiermit auch keine Funktionalität, denn auch verschachtelte Routes lassen sich definieren, wenn wir sie brauchen.</p><p>Weiterhin wird hier der Import von <code>Home</code> und <code>ToDoList</code> dem Route-Objekt per Spread-Operator hinzugefügt (<code>...Home</code>). Da wir bei der ToDoList-Komponente nun ein Objekt anstelle der einzelnen Komponente exportieren, landen hier automatisch die Properties <code>component</code> und <code>fetchData</code> in unserer Route-Konfiguration. Das macht die Liste hier etwas übersichtlicher.</p><p>Wir müssen nun auch das Export-Statement in der Home-Komponente und allen anderen Page-Komponenten anpassen, wenn sie in der Routes.js verwendet werden. Jede dieser Komponenten muss ein Objekt exportieren, das mindestens das Property <code>component</code> enthält:</p><div>

```javascript
...
export default {
  component: Home
}
```

</div><h3>4.4 Daten aller Komponenten laden</h3><p>Bevor wir React unser statisches HTML rendern lassen, wollen wir nun die Liste der relevanten Komponenten ermitteln und für jede die <code>fetchData()</code>-Funktion aufrufen. Wir passen also unsere <em>server.js</em> wie folgt an:</p><div>

```javascript
import express from 'express';
import React from "react";
import { Provider } from 'react-redux';
import {StaticRouter} from "react-router-dom";
import {createStore, applyMiddleware} from 'redux';
import ReactDOM  from 'react-dom/server';
import Routes from "./client/Routes";
import { matchRoutes, renderRoutes } from 'react-router-config';import thunk from 'redux-thunk';
import reducers from './src/reducers';
 
const app = express();
 
const renderer = (req, store) => {
const content = ReactDOM.renderToString(
 <Provider store={store}>
   <StaticRouter location={req.path} context={{}}>
     <div>{renderRoutes(Routes)}</div>   </StaticRouter>
 </Provider>
 );
 
 return `
   <html>
     <head></head>
     <body>
       <div id="app">${content}</div>
       <script src="bundle.js"></script>
     </body>
   </html>
 `;
};
 
app.use(express.static('public'));
app.get('*', (req, res) => {
 const store = createStore(reducers, {}, applyMiddleware(thunk));
 
 const promises = matchRoutes(Routes, req.path).map(({ route }) => {  return route.fetchData ? route.fetchData(store) : null; });  Promise.all(promises).then(() => {  res.send(renderer(req, store)); }); 
});
 
app.listen(3000, () => {
 console.log('Server gestartet auf http://localhost:3000');
});
```

</div><p>Hier ist eine Menge passiert innerhalb der <code>renderer()</code> und <code>app.get()</code>-Methode:</p><ul><li>Da wir die Routes angepasst haben, können wir innerhalb des <code><StaticRouter></code> nicht mehr die <code><Routes></code>-Komponente nutzen, da wir jetzt nicht mehr eine React-Komponente importieren, sondern ein Array von Objekten. Deshalb nutzen wir die Methode <code>renderRoutes()</code> vom Modul <a href="https://github.com/ReactTraining/react-router/tree/master/packages/react-router-config" target="_blank">react-router-config</a> .<div>

```javascript
<StaticRouter location={req.path} context={{}}>
     <div>{renderRoutes(Routes)}</div></StaticRouter>
```

</div></li><li>Das gleiche muss übrigens auch innerhalb unserer <em>/src/index.js</em> passieren:<div>

```javascript
<BrowserRouter>
 <div>{renderRoutes(Routes)}</div></BrowserRouter>
```

</div></li><li>Innerhalb von <code>app.get()</code> nutzen wir die Methode <code>matchRoutes()</code> von <code>react-router-config</code>, um die Routes zu erhalten, die zum aktuellen Request passen.<div>

```javascript
matchRoutes(Routes, req.path)
```

</div></li><li>Das Ergebnis ist eine Liste von Objekten, die jeweils als Property die Route enthalten, in welcher wiederum, unsere <code>fetchData()</code>-Methode vorhanden ist:

```

matchRoutes(Routes, req.path);

// ... produces this result:
[
  {
    route: { path: ‘/todos’, component: [Object], fetchData: [Function: fetchData] }
    match: {path: ‘/todos’, url: ‘/users’, isExact: true, params: {} }
  },
...
]

```

</li><li>Wenn eine Route die Methode <code>fetchData()</code> enthält, führen wir diese anschließend innerhalb der <code>map()</code>-Methode aus und speichern das Ergebnis im Array <code>promises</code>. Die <code>fetchData()</code>-Methode gibt jeweils ein Promise zurück.<div>

```javascript
const promises = matchRoutes(Routes, req.path).map(({ route }) => {
  return route.fetchData ? route.fetchData(store) : null;
});
```

</div></li><li>Das Ergebnis ist eine Liste von Promises, welche wir im folgenden alle resolven, bevor wir das statische HTML erzeugen:<div>

```javascript
Promise.all(promises).then(() => {
  res.send(renderer(req, store));
});
```

</div></li></ul><p>Damit haben wir alle <code>fetchData()</code>-Methoden ausgeführt und dabei auch unseren Store mit Inhalt gefüllt. Die Ergebnisse der <code>fetchData()</code>-Aufrufe sind also im Store enthalten und diesen nutzen wir nun beim statischen Rendern. Damit haben unsere Komponenten alle Daten, die sie brauchen, um die korrekten Inhalte zu rendern.</p><h3>4.5 State vom Server zum Client transferieren</h3><p>Wir haben es fast geschafft, unsere Redux-App serverseitig mit dynamischen Daten zu rendern. Das Einzige, was jetzt noch stört, ist die Fehlermeldung im Browser, die uns sagt, dass der DOM unserer statisch gerenderten Seite nicht mit dem berechneten DOM der dynamischen Seite übereinstimmt:</p><p><code>Warning: Did not expect server HTML to contain a <li> in <ul>.</code></p><p>React erwartet, dass sich der DOM beim initialen Rendern im Browser nicht vom serverseitig gerendertem DOM unterscheidet. Erst durch die Nutzerinteraktion dürfen Änderungen passieren.</p><p>Der Grund für die Fehlermeldung ist, dass der State im Browser initial leer ist, wenn die <em>bundle.js</em> geladen wird. Wir haben zwar zuvor auf dem Server unseren State mit Inhalt gefüllt, jedoch wird dieser bisher nur serverseitig für das statische HTML genutzt. Sobald die <em>bundle.js</em> im Browser geladen wird, ist der State wieder leer. Die Folge ist, dass React die Komponenten zunächst mit leeren Inhalt rendert bevor dann die Lifecycle-Methoden greifen und durch die Actions die Daten nachgeladen werden. Um das zu verhindern und den State auch im Client von Anfang an mit den richtigen Daten zu befüllen, müssen wir den State vom Server auf den Client übertragen:</p><div>

```javascript
...
import serialize from 'serialize-javascript'; 
...
 
const renderer = (req, store) => {
...
return `
 <html>
   <head></head>
   <body>
     <div id="app">${content}</div>
     <script>     window.INITIAL_STATE = ${serialize(store.getState())}     </script>     <script src="bundle.js"></script>
   </body>
 </html>
`;
}
```

</div><div>

```javascript
import React from 'react';
import ReactDOM from 'react-dom';
import { BrowserRouter } from 'react-router-dom';
import { createStore, applyMiddleware } from 'redux';
import thunk from 'redux-thunk';
import { Provider } from 'react-redux';
import { renderRoutes } from 'react-router-config';
import Routes from './Routes';
import reducers from './reducers';
 
const store = createStore(reducers, window.INITIAL_STATE, applyMiddleware(thunk)); 
ReactDOM.hydrate(
 <Provider store={store}>
   <BrowserRouter>
     <div>{renderRoutes(Routes)}</div>
   </BrowserRouter>
 </Provider>,
 document.querySelector('#app')
);
```

</div><p>In unserer <code>renderer()</code>-Funktion in der <em>server.js</em> speichern wir den Zustand des Stores in einer globalen Variablen <code>INITIAL_STATE</code> innerhalb unseres Template-Strings. Durch die Methode <code>store.getState()</code> lässt sich dieser Zustand einfach abrufen.</p><p>Um XSS-Attacken zu verhindern, escapen wir alle schädlichen Zeichen unter Verwendung des npm-Moduls <a href="https://www.npmjs.com/package/serialize-javascript" target="_blank">serialize-javascript</a> .</p><p>Innerhalb der <em>index.js</em> müssen wir diese globale Variable <code>window.INITIAL_STATE</code> beim erstellen des Stores nur noch verwenden und voilá, unser State im Client wird mit den Werten vom Server initialisiert und die Fehlermeldung verschwindet.</p><p>Puh, das war ein langer Weg, um den Redux State in unserer Applikation sowohl auf den Server als auch im Browser zu nutzen. Der Code sieht zugegebenermaßen nicht sehr schön aus, jedoch gibt es zurzeit keine guten Alternativen dazu.</p><h2>Zusammenfassung</h2><p>Wir haben gesehen, dass das serverseitige Rendering keine simple Angelegenheit ist. Jedoch ist SSR für eine SEO-kritische Webseite nach wie vor sehr zu empfehlen, da die Crawler nicht zuverlässig alle Inhalte einer Seite indizieren. Es erfordert einiges an zusätzlichem Code, um eine Seite mit allen dynamischen Inhalten auf dem Server zu rendern.</p><p>In diesem Artikel bin ich nicht auf die Themen Authentifizierung innerhalb der React-App eingegangen, genauso wenig wie auf das 404-Handling auf dem Server, wenn bestimmte Routes nicht verfügbar sind. Außerdem kann in der <em>server.js</em> beim Ausführen der <code>fetchData()</code>-Methoden ein Fehler auftreten, der dann zum Abbruch des <code>Promise.all()</code> führen würde. Diese Probleme sind zwar ebenfalls lösbar, erfordern jedoch ebenfalls einiges an Aufwand.</p><p>Man muss in seinem eigenen Projekt überlegen, ob der Aufwand des SSR im Verhältnis zum Nutzen steht oder ob man nicht doch lieber eine andere Möglichkeit nutzt, um SEO-relevante Seiten bereit zu stellen. Man ist dabei auch schnell bei der Diskussion, wann eine Single Page Applikation (SPA) überhaupt eine sinnvolle Alternative zur statischen Webseite ist. Wenn man weder den Aufwand für das SSR betreiben möchte noch auf die SPA verzichten will, bleiben nach wie vor Alternativen wie <a href="http://prerender.io" target="_blank">prerender.io</a> , um gegen Bezahlung ein performantes SSR-System zu bekommen. Weiterhin gibt es mittlerweile Frameworks wie z.B. <a href="https://github.com/zeit/next.js/" target="_blank">Next.js</a> , die das SSR vereinfachen. Jedoch muss man sich hier auch wieder an das Framework anpassen und verliert ggf. an einigen Stellen die Flexibilität gegenüber der „handgemachten“ Lösung, die ich in dieser Serie vorgestellt habe.</p><p>Ich freue mich jederzeit über Kommentare und Hinweise zu anderen Möglichkeiten, SPAs serverseitig zu rendern. Also hinterlasse mir gern deinen Tipp oder deine Kritik im Kommentarfeld weiter unten.</p>

Tutorial: Serverseitiges Rendering mit React – Teil 3: Redux Store

<p>Wie ich in dem Artikel <a href="/wissens-hub/blog/seo-spa-serverseitiges-rendering">SEO + SPA = serverseitiges Rendering?</a>  aufgezeigt habe, ist das serverseitige Rendering (SSR) nach wie vor die sicherste Möglichkeit, um SEO-kritische Inhalte zu präsentieren.</p><p>In diesem Tutorial zeige ich Schritt für Schritt, wie man eine clientseitige React-App auf eine serverseitig gerenderte App umstellt.</p><p>Das Tutorial habe ich in drei Teile aufgeteilt:</p><ol><li><a href="/wissens-hub/blog/tutorial-serverseitiges-rendering-mit-react-teil-1-einfuehrung">Einführung</a> </li><li><a href="/wissens-hub/blog/tutorial-serverseitiges-rendering-mit-react-teil-2-react-router-helmet">React Router und React Helmet</a> </li><li><a href="/wissens-hub/blog/tutorial-serverseitiges-rendering-mit-react-teil-3-redux-store">Redux Store</a> </li></ol><p>In diesem Teil schauen wir uns an, was SSR überhaupt ist und wie es prinzipiell funktioniert. Dabei steigen wir auch schon in die ersten Code-Beispiele ein und erstellen eine simple Version der serverseitig gerenderten App.<br /> Im <a href="/wissens-hub/blog/tutorial-serverseitiges-rendering-mit-react-teil-2-react-router-helmet">zweiten Teil</a>  kümmern wir uns um React Router und um React Helmet, damit wir für jede der angefragten Seiten immer das richtige statische HTML vom Server bekommen.<br /> Im <a href="/wissens-hub/blog/tutorial-serverseitiges-rendering-mit-react-teil-3-redux-store">dritten Teil</a>  geht es dann um den State unserer Applikation. Wir tauchen tiefer in Redux und die Möglichkeiten ein, wie wir sowohl auf dem Server als auch auf dem Client den globalen State nutzen, um unsere Komponenten mit dynamischen Inhalten zu rendern.</p><h2>1. Einführung</h2><p>SSR bringt einiges an zusätzlichen Aufwand mit sich und hat auch ein paar Nachteile, die man bedenken sollte. Sowohl React als auch Angular bringen nativ die Möglichkeit mit, den Inhalt auf dem Server zu rendern. Das ist schonmal eine gute Sache, denn man muss nicht unbedingt kostenpflichtige externe Dienste wie <a href="https://prerender.io/" target="_blank">prerender.io</a>  nutzen. Jedoch gibt es u.a. folgende Probleme:</p><ul><li>SSR passiert immer dann, wenn die Seite angefragt wird. Es müssen also zunächst alle Inhalte auf dem Server zusammengesetzt werden bevor sie zum Browser gesendet werden. Gerade wenn es sich um Inhalte handelt, die man erst per API Request von externen Services holt, kann das eine gewisse Zeit in Anspruch nehmen, was die Wartezeit für den Nutzer erhöht. Hier macht es also Sinn, sich Gedanken über einen Caching Mechanismus zu machen. (Varnish, CDN)</li><li>Auf dem Server gibt es kein window-Objekt in JavaScript. Sollte dieses irgendwo im Code im Einsatz sein und nicht vor der Benutzung abgefragt werden, kommt es beim Rendern zu Fehlern.</li><li>Der Aufwand für das SSR hängt davon ab, wie viele Features wir aus dem React Ökosystem nutzen. Meistens kommen Module wie React Router, Redux, React Helmet usw. zum Einsatz. Für all die genannten müssen wir uns überlegen, wie der Server diese handhaben kann, denn ohne unser Zutun funktionieren diese Module nicht wie auf dem Client.</li></ul><p>Für diejenigen, die noch nicht so viel Erfahrung mit SSR haben, zeigt der Infokasten „<b>Wie funktioniert SSR in React?“ </b>kurz zusammengefasst, was die grundlegende Funktionsweise des SSR ist.</p><div><h3>Info: Wie funktioniert SSR in React?</h3><p>Die Frage, die häufig gestellt wird, wenn es um das serverseitiges Rendering geht, ist, ob dann die ganze Dynamik der Single Page App (SPA) verloren geht, wenn man eine statische HTML Seite zum Browser schickt. Ich kann euch beruhigen, die Funktionalität wird in keinster Weise beeinflusst. Der Ablauf beim SSR ist zweistufig:</p><ol><li>Die statische HTML-Seite wird auf dem Server generiert und zum Client geschickt</li><li>Im HTML ist ein <code>script</code>-Tag mit der <em>bundle.js</em> als <code>src</code> enthalten, die man auch im normalen React-Projekt ohne SSR laden würde. Die <em>bundle.js</em> enthält den minifizierten Code von React und allen anderen Dependencies. Sobald der Browser diese nachlädt, wird React initialisiert und aktualisiert den statischen Code, registriert alle Event-Handler etc.</li></ol><p>Nach dem Laden der <em>bundle.js</em> funktioniert die Webseite genauso, wie ohne das SSR. Das heißt, es werden beim Navigieren solange keine erneuten Requests zum Server gemacht, bist der Nutzer die Seite komplett neu lädt. Die folgende Abbildung zeigt den Mechanismus nochmal grafisch:</p><div> <a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/RSkcCZZZQCyGdURPsESv"><img width="450" height="495" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/RSkcCZZZQCyGdURPsESv" alt="React Serverside Rendering Flow" /></a> </div></div><h3>1.1 Projektstruktur<p>Als Beispiel nutze ich eine einfache ToDo-App. Hierbei reduziere ich jedoch den Umfang der App allein auf das Anzeigen einer Homepage und einer Liste von ToDos.<br /> Ich gehe von einem typischen Projekt-Setup für eine clientseitige React-App aus. Die Ordnerstruktur des Projektes könnte z.B. so aussehen:</p>

```

my-project/
|------build/
|------src/
|      |-----actions/
|            |----- index.js
|      |-----components/
|            |----- Header.js
|            |----- Home.js
|            |----- ToDoList.js
|      |-----reducers/
|            |----- index.js
|            |----- todosReducer.js
|      |-----App.js
|      |-----index.js
|      |-----Routes.js
|------package.json
|------server.js
|------webpack.config.js

```

<p>Weiterhin gehe ich davon aus, dass die React-App über einen express-Node.js-Server ausgeliefert wird. Die aktuelle <em>server.js</em> könnte in etwa so aussehen:</p><div>

```javascript
import express from 'express';
const app = express();
 
app.use(express.static('build/assets'));
 
app.get('*', (req, res) => {
 res.sendFile(path.join(__dirname, "build/index.html"));
});
 
app.listen(3000, () => {
 console.log('Server gestartet auf http://localhost:3000');
});
```

</div><h3>1.2 Webpack für Client und Server konfigurieren</h3><p>Zunächst müssen wir uns klar machen, dass die serverseitig gerenderte React App in zwei verschiedenen Umgebungen gerendert werden wird (Server, Client). Wir benötigen deshalb auch unterschiedliche Konfigurationen.</p><p>In der Regel besitzen wir bei einer normalen React-App eine Webpack-Konfiguration, die dafür sorgt, dass der Code mit Babel zu ES5 transpiliert und in eine einzige <em>bundle.js</em>-Datei zusammengefasst wird. Das Ergebnis landet dann typischerweise in einem „build“-Ordner. Dies passen wir als erstes an.</p><p>Grundidee ist es, eine <em>bundle.js</em> für die statische Version unserer Webseite zu erzeugen, die dann vom Node-Server ausgeführt wird und eine zusätzliche <em>bundle.js</em> für die „dynamische“ React-App, die wir dann innerhalb der statischen HTML-Seite referenzieren und welche anschließend im Browser nachgeladen und ausgeführt wird.</p><p>Also passen wir zunächst unsere Webpack-Konfiguration an. Die bestehende <em>webpack.config.js</em> unterteilen wir in <em>webpack.server.js</em> und <em>webpack.client.js</em>:</p><div>

```javascript
const path = require('path');
const webpackNodeExternals = require('webpack-node-externals');
 
module.exports = {
 target: 'node',
 entry: './server.js',
 output: {
   filename: 'bundle.js',
   path: path.resolve(__dirname, 'build'),
 },
 module: {
  rules: [
    ... // babel-loader, style-loader etc.
  ]
 },
 externals: [webpackNodeExternals()]
};
```

</div><div>

```javascript
const path = require('path');
 
module.exports = {
 entry: './src/index.js',
 output: {
  filename: 'bundle.js',
  path: path.resolve(__dirname, 'public')
 },
 module: {
  rules: [
    ... // babel-loader, style-loader etc.
  ]
 }
};
```

</div><p>Bei diesen Konfigurationen sind drei Properties besonders wichtig:<br /> Das Erste ist das <code>target</code> innerhalb der <em>webpack.server.js</em>. Standardmäßig geht webpack von einer Browser-Umgebung aus (<code>target: 'web'</code>). Durch <code>target: 'node'</code> sagen wir webpack, dass es für eine Node.js-Umgebung transpilieren soll. Damit nutzt es z.B. die „require“-Syntax um Module zu importieren und verändert Module wie <code>fs</code> oder <code>path</code> nicht.</p><p>Das zweite wichtige Property ist der <code>output</code> path. Hier legen wir unsere transpilierten <em>bundle.js</em> Dateien in den public-Ordner (für den Client) und in den build-Ordner (für den Server).</p><p>Als drittes haben wir innerhalb der <em>webpack.server.js</em> durch <code>externals: [webpackNodeExternals()]</code> angegeben, dass keine npm-Module in die <em>bundle.js</em> eingebaut werden sollen, weil diese ganz einfach per <code>require('npm-module-name')</code> in der Node-Umgebung geladen werden können. Damit müssen sie nicht im <em>bundle.js</em> vorhanden sein, was die Datei kleiner macht.</p><p>Als nächstes passen wir die <em>package.json</em> an und rufen dort die beiden webpack-Konfigurationen auf:</p><div>

```json
...
"scripts": {
 "dev": "npm-run-all --parallel dev:*",
 "dev:start-server": "nodemon --watch build --exec \"node build/bundle.js\"",
 "dev:build-server": "webpack --config webpack.server.js --watch",
 "dev:build-client": "webpack --config webpack.client.js --watch"
}
```

</div><p>Ich nutze hier das Modul <a href="https://www.npmjs.com/package/npm-run-all" target="_blank">npm-run-all</a>  um alle „dev:*“-Skripte zu starten. Damit wird sowohl der Server als auch der Client gebaut und der Server gestartet. Mit <a href="https://github.com/remy/nodemon" target="_blank">nodemon</a>  überwache ich den „build“-Ordner und starte den Server automatisch neu, wenn sich dort eine Änderung ergibt. Mit <code>npm run dev</code> steht uns somit eine komfortable Entwicklungsumgebung zur Verfügung.</p><p>Zum Schluss passen wir nun noch die <em>server.js</em> an und integrieren hier bereits das serverseitige Rendering von React.</p><div>

```javascript
import express from 'express';
import ReactDOM from 'react-dom/server';const app = express();
 
const renderer = () => { const content = ReactDOM.renderToString(/* TODO */);  return `   <html>     <head></head>     <body>       <div id="app">${content}</div>       <script src="bundle.js"></script>     </body>   </html> `;}; 
app.use(express.static('public'));app.get('*', (req, res) => {
 res.send(renderer());});
 
app.listen(3000, () => {
 console.log('Server gestartet auf http://localhost:3000');
});
```

</div><p>Neu ist hier die Methode <code>renderer()</code>. Darin nutzen wir für das SSR die Methode <code>renderToString()</code> von <code>react-dom/server</code>. Damit wird unsere App gerendert und als String ausgegeben. Unser HTML-Template lagern wir nicht wie zuvor in eine extra HTML-Datei aus, sondern definieren es hier mit Hilfe eines Template-Strings. Wir werden in den nächsten Abschnitten sehen, dass das sehr praktisch ist.</p><p>Die statischen Ressourcen liegen ab sofort im public-Ordner, weshalb wir <code>app.use(express.static('public'));</code> definiert haben.</p><p>Ein letztes Augenmerk will ich auf das <code><script></code>-Tag kurz vor dem schließenden <code><body></code>-Tag im Template-String legen. Hier referenzieren wir unser clientseitiges <em>bundle.js</em>. Ist dieses geladen, wird der DOM innerhalb von <code><div id="app"></div></code> von React analysiert und ggf. geändert, sofern er sich geändert hat.</p><p>Das Ergebnis bis hier hin ist eine simple serverseitig gerenderte React App. Die App liefert in diesem Zustand jedoch immer die Startseite zurück, egal welche Route aufgerufen wird. Im nächsten Teil (<a href="/wissens-hub/blog/tutorial-serverseitiges-rendering-mit-react-teil-2-react-router-helmet">Tutorial: Serverseitiges Rendering mit React – Teil 2: React Router und React Helmet</a> ) kümmern wir uns um React Router, damit genau die Seite gerendert wird, die der User angesurft hat. Weiterhin schauen wir uns an, wie man mit React Helmet die Meta-Tags im statisch gerenderten HTML richtig setzt.</p></h3>

Tutorial: Serverseitiges Rendering mit React – Teil 1: Einführung

<p>Nachdem wir im ersten Teil (<a href="/wissens-hub/blog/tutorial-serverseitiges-rendering-mit-react-teil-1-einfuehrung">Tutorial: Serverseitiges Rendering mit React – Teil 1: Einführung</a> ) die grundlegende Konfiguration für unsere serverseitig gerenderte App umgesetzt haben, schauen wir uns in diesem Teil an, wie wir React Router auf dem Server nutzen können, um genau die Seiten zu rendern, die der User angefragt hat. Außerdem lernen wir, wie React Helmet für das Setzen von Meta-Tags auf dem Server konfiguriert werden muss.</p>
<h2>2. React Router</h2><p>Wir wollen sicherstellen, dass der User beim Abrufen der Seiten „/“, „/ueber-uns“, „/impressum“ etc. immer auch genau die richtigen statischen Inhalte vom Server geliefert bekommt. Im Client kümmert sich React Router darum, die richtigen Komponenten anzuzeigen, je nachdem, welche Route angesurft wird. Dieses Verhalten müssen wir nun auch auf dem Server ermöglichen.</p><p>Wenn wir React Router v4 in unseren bisherigen Projekt eingesetzt haben, dann kennen wir bereits das Modul <code>BrowserRouter</code>. Wahrscheinlich enthält unsere clientseitige <em>index.js</em> im „src/“-Verzeichnis einen ähnlichen Code wie diesen hier:</p><div>

```javascript
import React from 'react';
import ReactDOM from 'react-dom';
import { BrowserRouter } from 'react-router-dom';
import Routes from './Routes';
 
ReactDOM.render(
 <BrowserRouter>
   <Routes />
 </BrowserRouter>,
 document.querySelector('#app')
);
```

</div><p>Dieser kann fast genau so bestehen bleiben. Wir ändern an dieser Stelle nur die Methode <code>ReactDOM.render()</code> zu <code>ReactDOM.hydrate()</code>, um zu verhindern, dass uns React folgende unschöne Warnmeldung in der Browserkonsole anzeigt:</p><p><code>"Warning: render(): Calling ReactDOM.render() to hydrate server-rendered markup will stop working in React v17. Replace the ReactDOM.render() call with ReactDOM.hydrate() if you want React to attach to the server HTML."</code></p><p><code>ReactDOM.hydrate()</code> ist genau für unseren Anwendungsfall zugeschnitten. Es geht von einem serverseitig gerenderten DOM aus und prüft lediglich, ob sich am bestehenden DOM etwas geändert hat.</p><p>In unserer <em>server.js</em> wollen wir nun auch das Routing integrieren, um immer die richtige statische HTML-Seite auf dem Server zu rendern.</p><div>

```javascript
import express from 'express';
import React from "react";
import {StaticRouter} from "react-router-dom";import ReactDOM  from 'react-dom/server';
import Routes from "./src/Routes"; 
const app = express();
 
const renderer = req => { const content = ReactDOM.renderToString(
   <StaticRouter location={req.path} context={{}}>     <Routes />   </StaticRouter> );
 
 return `
    <html>
      <head></head>
      <body>
        <div id="app">${content}</div>
        <script src="bundle.js"></script>
      </body>
    </html>
  `;
 };
 
 app.use(express.static('public'));
 app.get('*', (req, res) => {
  res.send(renderer(req)); });
 
 app.listen(3000, () => {
  console.log('Server gestartet auf http://localhost:3000');
 });
```

</div><p>Man sieht, dass wir innerhalb unserer <code>renderToString()</code>-Methode anstelle von <code>BrowserRouter</code> den <code>StaticRouter</code> nutzen. Wir gehen hier auch noch einen Schritt weiter und übergeben dem <code>StaticRouter</code> den Anfragepfad, der uns über <code>req.path</code> von <code>express</code> zur Verfügung gestellt wird. Damit weiß React Router, welche Seite gerendert werden soll und wir bekommen nicht immer die Startseite zurück geliefert. Der <code>StaticRouter</code> benötigt immer ein <code>context</code>-Property, den wir hier erstmal mit einem leeren Objekt definieren.</p><p>Mit diesen einfachen Änderungen haben wir erreicht, dass wir immer genau die Seite auf dem Server rendern, die der User anfragt. Als nächstes können wir uns um die Meta-Tags kümmern.</p><h2>3. React Helmet Meta-Tags</h2><p>React Helmet ist ein hilfreiches Tool, um für jede beliebige Page-Komponente Meta-Tags zu setzen. Normalerweise sieht eine Komponente, die React Helmet verwendet, so aus:</p><div>

```javascript
...
import { Helmet } from 'react-helmet';
 
class ToDoList extends Component {
...
 
 render() {
  return (
    <div>
      <Helmet>
        <title>Mein Titel</title>
        <meta name="description" content="Meine Beschreibung"/>
        <meta property="og:title" content="Ein etwas anderer Titel" />
      </Helmet>
      ...
    </div>
  );
 }
}
```

</div><p>React Helmet ist also selbst eine einfache Komponente, die wir innerhalb unserer (Page-)Komponenten integrieren. Man kann innerhalb von <code><Helmet></Helmet></code> beliebige Meta-Tags definieren.</p><p>Beim SSR haben wir jedoch das Problem, dass diese Meta-Tags nicht ohne unser Zutun im <header>-Bereich gerendert werden. Um das zu erreichen müssen wir unsere <em>server.js</em> anpassen:</p><div>

```javascript
import express from 'express';
import React from "react";
import {StaticRouter} from "react-router-dom";
import ReactDOM  from 'react-dom/server';
import Routes from "./src/Routes";
import { Helmet } from 'react-helmet'; 
const app = express();
 
const renderer = (req, store) => {
 const content = ReactDOM.renderToString(
  <StaticRouter location={req.path} context={{}}>
    <Routes />
  </StaticRouter>
 );
 
 const helmet = Helmet.renderStatic(); 
 return `
   <html>
     <head>
        ${helmet.title.toString()}        ${helmet.meta.toString()}     </head>
     <body>
     <div id="app">${content}</div>
     <script src="bundle.js"></script>
   </body>
 </html>
 `;
};
 
app.use(express.static('public'));
app.get('*', (req, res) => {
  res.send(renderer(req));
});
 
app.listen(3000, () => {
 console.log('Server gestartet auf http://localhost:3000');
});
```

</div><p>Nach dem Aufruf von <code>ReactDOM.renderToString()</code> enthält Helmet alle Informationen über die zu rendernden Meta-Tags. Deswegen können wir im Anschluss die Meta-Informationen einfach auslesen:</p>

```
const helmet = Helmet.renderStatic();
```

<p>Wie wir hier sehen, sind die Titel- und Meta-Informationen in zwei verschiedenen Properties am Helmet-Objekt verfügbar:</p>

```
${helmet.title.toString()}
${helmet.meta.toString()}

```

<p>Es gibt auch noch weitere Properties am Helmet-Objekt, die in der <a href="https://github.com/nfl/react-helmet#server-usage" target="_blank">React Helmet Doku</a>  nachzulesen sind.</p><p>Durch diese kleine Anpassung sind nun auch unsere Meta-Tags im statisch gerenderten HTML enthalten.</p><p>Im letzten und umfangreichsten Teil der Serie (<a href="/wissens-hub/blog/tutorial-serverseitiges-rendering-mit-react-teil-3-redux-store">Tutorial: Serverseitiges Rendering mit React – Teil 3: Redux Store</a> ) beleuchten wir, wie wir den Redux Store serverseitig konfigurieren. Wir sehen uns außerdem an, wie wir dynamische Inhalte laden bevor wir das statische HTML erzeugen und wie wir den befüllten Redux State an den Client übergeben.</p>

Tutorial: Serverseitiges Rendering mit React – Teil 2: React Router und React Helmet

<p>Wir haben in den ersten beiden Teilen dieser Serie (<a href="/wissens-hub/blog/webseiten-mit-alexa-und-websockets-navigieren">Webseiten mit Alexa und Websockets navigieren</a>  und <a href="/wissens-hub/blog/eine-pipeline-fuer-lambda-mit-aws-codestar-erstellen">Eine Pipeline für Lambda mit AWS CodeStar erstellen</a> ) gesehen, wie wir mit dem ASK einen Alexa Skill erstellen und mittels CodeStar eine Deployment Pipeline für unsere Lambda-Funktion erzeugen. In diesem Teil werden wir unsere Lambda so anpassen, dass sie auf unsere Intents des Skills reagiert und mit unserem Webservice kommuniziert, auf dem wir per Websockets die Navigation ermöglichen.</p><h2>Alexa SDK: Einführung</h2><p>Wir schauen uns zunächst einmal an, welcher Boilerplate Code in unserer <em>index.js</em> von CodeStar erzeugt wurde.</p><div>

```javascript
'use strict';
 
const Alexa = require('alexa-sdk');
 
const APP_ID = undefined;  // TODO replace with your app ID (OPTIONAL).
 
const languageStrings = {
   ...
};
 
const handlers = {   'LaunchRequest': function () {
       this.emit('GetFact');
   },
   'GetNewFactIntent': function () {
       this.emit('GetFact');
   },
   'GetFact': function () {
       // Get a random space fact from the space facts list
       // Use this.t() to get corresponding language data
       const factArr = this.t('FACTS');
       const factIndex = Math.floor(Math.random() * factArr.length);
       const randomFact = factArr[factIndex];
 
       // Create speech output
       const speechOutput = this.t('GET_FACT_MESSAGE') + randomFact;
       this.emit(':tellWithCard', speechOutput, this.t('SKILL_NAME'), randomFact);
   },
   'AMAZON.HelpIntent': function () {
       const speechOutput = this.t('HELP_MESSAGE');
       const reprompt = this.t('HELP_MESSAGE');
       this.emit(':ask', speechOutput, reprompt);
   },
   'AMAZON.CancelIntent': function () {
       this.emit(':tell', this.t('STOP_MESSAGE'));
   },
   'AMAZON.StopIntent': function () {
       this.emit(':tell', this.t('STOP_MESSAGE'));
   },
   'SessionEndedRequest': function () {
       this.emit(':tell', this.t('STOP_MESSAGE'));
   },
};
 
exports.handler = (event, context) => {   const alexa = Alexa.handler(event, context);
   alexa.APP_ID = APP_ID;
   // To enable string internationalization (i18n) features, set a resources object.
   alexa.resources = languageStrings;
   alexa.registerHandlers(handlers);
   alexa.execute();
};
```

</div><p>Wir sehen hier einen fertigen Alexa Skill. Zwei Bereiche sind hier besonders wichtig. Die Definition des sog. „handlers“-Objektes und die Export-Anweisung am Ende der Datei. Zunächst zur Export-Anweisung: Wir exportieren hier die Funktion <code>handler</code>. Diese wird aufgerufen, wenn unsere Lambda-Funktion getriggert wird. Sie bekommt das Event und einen Kontext als Parameter. Wir initialisieren zunächst das Alexa SDK, reichen das Event und den Kontext weiter und registrieren weiter unten die Handler mit <code>alexa.registerHandlers(handlers)</code>. Die <code>APP_ID</code> und die Ressourcen sind optionale Dinge, die ich in diesem Tutorial nicht weiter betrachte. Durch das Registrieren der Handler sagen wir dem SDK, welche Intents es verarbeiten soll. Mit <code>alexa.execute()</code> wird die Antwort generiert und an die aufrufende Alexa zurückgesendet.</p><p>Nun zum Objekt <code>handlers</code>. In diesem definieren wir die Intents, auf die wir reagieren wollen. Man sieht hier unter anderem die vorgegebenen Intents <code>AMAZON.HelpIntent</code>, <code>AMAZON.Cancellntent</code> und <code>AMAZON.StopIntent</code>. Wofür diese sind, verrät bereits der Name und ich habe es auch im <a href="/wissens-hub/blog/webseiten-mit-alexa-und-websockets-navigieren">ersten Blogeintrag</a>  nochmal beschrieben. Dann finden wir noch den <code>LaunchRequest</code> und den <code>SessionEndedRequest</code>. Der <code>LaunchRequest</code> wird immer dann aufgerufen, wenn unser Skill ohne zusätzliche Anweisung gestartet wird. Also wenn jemand sagen würde: „Alexa, starte Webseiten-Navigator“. Der <code>SessionEndedRequest</code> wird aufgerufen, wenn der Nutzer über 7 Sekunden lang nicht mit dem Skill interagiert.</p><p>Dann sehen wir noch den <code>GetNewFactIntent</code> und die Funktion <code>GetFact</code>, welche vom <code>GetNewFactIntent</code> aufgerufen wird. Das Alexa SDK kümmert sich darum, dass die passenden Funktionen aufgerufen werden, je nachdem, was wir in unserem Intent-Schema im Alexa Skills Kit definiert haben und was der Nutzer zur Alexa sagt. Wenn der Nutzer den Skill startet, wird die <code>LaunchRequest</code>-Funktion ausgeführt. Wenn er „Stop“ sagt, wird der <code>AMAZON.StopIntent</code> ausgeführt. Und wenn der Nutzer eine unserer Utterances des <code>NavigateToPage</code> Intents sagt, dann wird unsere Funktion für <code>NavigateToPage</code> aufgerufen. Bisher gibt es die Funktion nicht, was wir aber gleich nachholen. Der Rückgabewert aller dieser Funktionen ist jeweils die Antwort für den Nutzer.</p><p>Das Alexa SDK stellt uns mehrere Möglichkeiten bereit, eine Antwort zu erzeugen. Mittels <code>this.emit(‘:ask’, ...)</code> und <code>this.emit(‘:tell’, ...)</code> können wir direkt Antworten ausgeben, wobei der Unterschied ist, dass die <em>„:ask“</em>-Anweisung die Session offen hält und somit auf eine Antwort des Nutzers wartet, während <em>„:tell“</em> nur einen Text ausgibt und dann die Konversation und damit den Skill beendet. Die sehr gute Dokumentation des Alexa SDKs findet man hier: <a href="https://github.com/alexa/alexa-skills-kit-sdk-for-nodejs" target="_blank">https://github.com/alexa/alexa-skills-kit-sdk-for-nodejs</a> </p><h2>Den Fact Skill Boilerplate Code aufräumen</h2><p>Wir räumen in der <em>index.js</em> zunächst einmal auf und lassen nur das übrig, was wir für den weiteren Verlauf benötigen. Die bereinigte Funktion sieht dann so aus:</p><div>

```javascript
'use strict';
 
const Alexa = require('alexa-sdk');
 
const handlers = {
   'LaunchRequest': function () {
       this.emit(':ask', "Wohin möchtest du navigieren?", "Wohin möchtest du navigieren, sage Home oder Impressum.");
   },
   'NavigateToPage': function () {
 
   },
   'AMAZON.HelpIntent': function () {
       this.emit(':ask', "Wohin möchtest du navigieren?", "Wohin möchtest du navigieren, sage Home oder Impressum.");
   },
   'AMAZON.CancelIntent': function () {
       this.emit(':tell', "Ok, bye");
   },
   'AMAZON.StopIntent': function () {
       this.emit(':tell', "Ok, bye");
   },
   'SessionEndedRequest': function () {
       this.emit(':tell', "Ok, bye");
   },
};
 
exports.handler = (event, context) => {
   const alexa = Alexa.handler(event, context);
   alexa.registerHandlers(handlers);
   alexa.execute();
};
```

</div><p>Der <code>LaunchRequest</code> fragt den Nutzer nun, wohin er navigieren möchte und auch die anderen Intents haben eine sinnvolle Antwort. Die beiden Funktionen <code>GetNewFactIntent</code> und <code>GetFact</code> habe ich gelöscht. Wir haben in unserem Skill den <strong>NavigateToPage</strong> Intent definiert, deswegen habe ich dafür die Funktion <code>NavigateToPage</code> angelegt. Hier wird nun unsere Magie stattfinden, mit der wir die Webseite fernsteuern.</p><h2>Slot für den PAGE_NAME auslesen</h2><p>Als nächstes wollen wir wissen, zu welcher Page der Nutzer navigieren möchte.<br /> Wir haben den Slot <strong>PAGE_NAME</strong> im Alexa Skills Kit definiert. Dieser lässt sich sehr leicht mit dem Alexa SDK abrufen. Wir ergänzen folgende Zeilen in der NavigateToPage Funktion:</p><div>

```javascript
'use strict';
 
const Alexa = require('alexa-sdk');
 
const pageNameToFile = { "home": "index.html", "impressum": "impressum.html"}; 
const handlers = {
   'LaunchRequest': function () {
       ...
   },
   'NavigateToPage': function () {     const pageName = this.event.request.intent.slots.PAGE_NAME.value;     const file = pageNameToFile[pageName.toLowerCase()];   },   ...
};
 
...
```

</div><p>Mit <code>this.event.request.intent.slots.PAGE_NAME.value</code> kommen wir an den Slot-Wert heran, den der Nutzer genannt hat. Dieser kann entweder „Home“ oder „Impressum“ sein. In dem Objekt <code>pageNameToFile</code> habe ich diese Seiten auf ihre entsprechenden HTML-Seiten gemappt.</p><h2>Axios für die Kommunikation zum Webserver einbinden</h2><p>Um einen Request zu unserem Webserver absetzen zu können, installieren wir uns das npm-Modul axios (<a href="https://www.npmjs.com/package/axios">https://www.npmjs.com/package/axios</a> ) mittels <code>npm i -S axios</code>.  Durch <code>const axios = require('axios');</code> importieren wir das Modul auch gleich in unserer <em>index.js</em>.</p><h2>Den Request zum Webserver absetzen</h2><div>

```javascript
'use strict';
 
const Alexa = require('alexa-sdk');
const axios = require('axios'); 
const pageNameToFile = {
 "home": "index.html",
 "impressum": "impressum.html"
};
 
const handlers = {
   'LaunchRequest': function () {
       ...
   },
   'NavigateToPage': function () {
     const pageName = this.event.request.intent.slots.PAGE_NAME.value;
     const file = pageNameToFile[pageName.toLowerCase()];
 
     axios.get('https://alexa-navigate.now.sh/navigate?file=' + file).then(() => {              this.emit(':ask', "Ok, ich navigiere. Was kann ich noch tun?", "Was kann ich noch tun?");         });   },
   ...
};
 
...
```

</div><p>Ich lese den Wert für die Page aus der Map <code>pageNameToFile</code> aus und übergebe ihn anschließend als Parameter mit dem Namen „file“ an den GET-Request zu meinem Webserver. Wenn der Request erfolgreich abgeschlossen ist, soll Alexa noch fragen, was sie als nächstes tun soll.</p><p>Das ist auch schon die ganze Magie, die innerhalb der Lambda passiert. Wir triggern mit dem GET-Request unseren Webserver, der unter dem Pfad <em>„/navigate“</em> erreichbar ist und darauf wartet, dass ihm eine Seite übergeben wird. Den Code pushe ich nun in mein CodeCommit Repository und die Pipeline sorgt dafür, dass meine Lambda aktualisiert wird.</p><p>Schauen wir uns nun noch an, wie der Webserver aufgebaut ist:</p><h2>Webserver erstellen und Websockets konfigurieren</h2><p>Der Webserver ist eine einfache express app (<a href="https://www.npmjs.com/package/express" target="_blank">https://www.npmjs.com/package/express</a> ). Sie hat folgende Verzeichnisstruktur:</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/UE4MvnNRaK5MiITJpaeh"><img width="498" height="396" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/UE4MvnNRaK5MiITJpaeh" alt="Webserver Ordner" /></a> </p><p>Der Server wird in der <em>server.js</em> definiert. Die einzelnen Seiten der Page sind <em>index.html</em> und <em>impressum.html</em>. Jede dieser beiden HTML-Dateien bindet die <em>client.js</em> ein.</p><p>Die HTML-Dateien sind sehr simpel und sehen wie folgt aus:</p><div>

```html
<!doctype html>
<html>
<head>
 <meta charset="utf-8">
 <title></title>
</head>
<body>
<h1>Home</h1>
<script src="js/client.js" async defer></script>
</body>
</html>
```

</div><p>Die <em>server.js</em> sieht wie folgt aus:</p><div>

```javascript
const express = require('express');
const WebSocket = require('ws');
const http = require('http');
const path = require("path");
 
const app = express();
 
const server = http.createServer(app);
const wss = new WebSocket.Server({ server });
 
let myWebsocket = null;
 
wss.on('connection', function connection(ws, req) {
 myWebsocket = ws;
 console.log("user connected");
});
 
app.use("js", express.static("js"));
 
// e.g. mywebsite.com/navigate?file=impressum.html
app.use('/navigate', function (req, res) { if (myWebsocket && req.query.file) {   myWebsocket.send(JSON.stringify({href: req.query.file})); } res.send('OK');}); 
app.use('/', function (req, res) {
 res.sendFile(path.join(__dirname, req.path));
});
 
server.listen(8080, function listening() {
 console.log('Listening on %d', server.address().port);
});
```

</div><p>Ich benutze das npm-Modul „ws“ (<a href="https://www.npmjs.com/package/ws" target="_blank">https://www.npmjs.com/package/ws</a> ), um eine Websocket-Verbindung zwischen Client und Server aufzubauen. Die eigentliche Funktionalität des Servers liegt in der <code>app.use('/navigate')</code> Funktion. Hier sende ich an meinen Websocket-Endpunkt auf dem Client ein JSON-Objekt, das ein einziges Property <em>„href“</em> besitzt. Diesem Property gebe ich den Wert, den ich aus dem Request auslese (<code>req.query.file</code>). Der restliche Code in der <em>server.js</em> ist typischer express.js Boilerplate Code.</p><p>Die <em>client.js</em> hat auch nur ein paar Zeilen Code:</p><div>

```javascript
const mySocket = new WebSocket("wss://alexa-navigate.now.sh");
 
mySocket.onopen = function (event) {
 console.log("connected to backend");
};
 
mySocket.onmessage = function (event) { let data = JSON.parse(event.data); window.location.href = data.href;}; 
mySocket.onerror = function (event) {
 console.log(event);
};
```

</div><p>Hier wird nur eine neue Websocket-Verbindung zu unserem Webserver unter <em>wss://alexa-navigate.now.sh</em> aufgebaut. Mit <code>mySocket.onmessage()</code> reagieren wir auf eine Nachricht, die vom Server kommt. Unter <code>event.data</code> erhalten wir das JSON-Objekt mit dem <em>„href“</em>-Property, das wir vom Server gesendet haben. Die eigentliche Navigation der Page passiert dann mittels der Zeile <code>window.location.href = data.href</code>. So leicht kann das sein 😉</p><h2>Webserver deployen mit now</h2><p>Um meinen Webserver zu deployen, führe ich einfach den Befehl <code>> now</code> in meinem Terminal aus und die Node.js App wird automatisch in meinem kostenfreien Webspace deployt (<a href="https://zeit.co/now" target="_blank">https://zeit.co/now</a> ). Damit meine Seite auch eine feste Subdomain hat, muss ich anschließend auch noch <code>> now alias https://[generated-id].now.sh alexa-navigate</code> ausführen.</p><h2>Nächste Schritte</h2><p>Um unsere Anwendung produktiv einsetzen zu können, müsste man natürlich noch ein paar Sachen beachten, die aber den Umfang des Artikels sprengen würden. Z. B. würde die Webseite aktuell für alle Nutzer navigiert werden, die sich gleichzeitig auf der Webseite befinden. Denn der Server sendet an alle Websocket-Clients gleichzeitig die Message. Wir wollen ja eigentlich, dass nur der User, der seine Alexa steuert, auch durch unsere Seite navigiert wird. Dazu müssten wir den Nutzer identifizieren. Das geht einmal über den Alexa Skill, indem wir in unserem Skill das sog. Account Linking integrieren (<a href="https://developer.amazon.com/de/docs/custom-skills/link-an-alexa-user-with-a-user-in-your-system.html" target="_blank">https://developer.amazon.com/de/docs/custom-skills/link-an-alexa-user-with-a-user-in-your-system.html</a> ) und außerdem müsste sich der Nutzer auch zuerst auf unserer Webseite einloggen, damit wir den Account der Alexa mit dem Benutzerkonto auf der Webseite zuordnen können. Anschließend könnten wir nur dem Client des Benutzers eine Websocket Message senden.</p><h2>Zusammenfassung</h2><p>In dem Tutorial haben wir gesehen, wie leicht es ist, einen Alexa Skill mit dem Alexa Skills Kit Web-Interface zu definieren und dass mit CodeStar auch sehr leicht die passende Lambda inklusive der Deployment Pipeline erzeugt werden kann.<br /> Innerhalb der Lambda bietet uns das alexa-sdk eine komfortable Möglichkeit, die Antworten für unseren Skill zu definieren. Mit dem npm-Modul <em>ws</em> haben wir im Handumdrehen die Websockets zwischen Client und Server erstellt und mussten nur noch mit ein paar Zeilen JavaScript dafür sorgen, dass unsere Page navigiert, sobald ein bestimmter Endpoint auf unserem Webserver von der Lambda getriggert wird.</p><p>Wenn du noch Fragen oder Anregungen zu dieser Lösung hast, dann freue ich mich über Feedback in den Kommentaren.</p>

Per Lambda für Alexa eine Webseite steuern

<p>Die Idee zu diesem Artikel kam mir bei einem Vortrag auf der Product-People-Konferenz in Köln. Birgit Schumacher hat dort einen Vortrag über „Konfliktmanagement in Projekten“ gehalten, der mich sehr inspiriert hat. Ich möchte den Impuls gerne weitergeben und werde dazu in diesem Artikel die Frage klären, warum Konflikte entstehen können und welche Möglichkeiten es gibt, diese Konflikte wieder aufzulösen.</p><p>Bei der Zusammenarbeit in Projektteams läuft auch bei uns bei codecentric nicht immer alles reibungslos ab. Besonders wenn die Teammitglieder sich noch nicht so gut kennen, durchlaufen sie oft die allseits bekannten Phasen von Tuckman (Forming, Storming, Norming, Performing, mehr dazu: <a href="/wissens-hub/blog/tuckmans-4-phasenmodell">/wissens-hub/blog/tuckmans-4-phasenmodell</a> ). Damit können wir codecentricer i.d.R. gut umgehen, sodass sich für unsere Kunden keine negativen Auswirkungen ergeben. Aber auch wir sind nicht unfehlbar und manchmal kommt es zwischen den Teammitgliedern zu stärkeren Konflikten bzw. Streits, die auch die Zusammenarbeit negativ beeinflussen. Wir wären jedoch nicht codecentric, wenn wir dafür nicht auf Strategien und Lösungsmöglichkeiten zurückgreifen könnten, die uns wieder ins produktive Fahrwasser zurückführen, um unseren Kunden die besten Ergebnisse zu liefern.</p><h2>Von der Meinungsverschiedenheit zum Konflikt</h2><p>Am Anfang der meisten Konflikte steht eine einfache Meinungsverschiedenheit. Man diskutiert sachlich über ein Thema und kommt dabei jedoch nicht auf den gleichen Nenner. Das ist zunächst nichts Ungewöhnliches. Problematisch wird es erst dann, wenn aus der sachlichen Diskussion eine emotionale wird.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/U90nx6QSRnaVqW5t5sVj"><img width="700" height="500" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/U90nx6QSRnaVqW5t5sVj" alt="Diskussion wird emotional" /></a> <br /> <i>Emotionen kommen auf in der Diskussion</i></p><p>Es lohnt sich, diesen Zeitpunkt genauer zu betrachten, denn wer früh erkennt, dass sich ein Konflikt anbahnt, ist viel besser in der Lage, diesen wieder aufzulösen. Warum werden wir jedoch emotional bei einer Diskussion? Was wollen uns unsere Gefühle in diesem Moment sagen?</p><p>Dazu hilft es sich klar zu machen, dass negative Gefühle immer ein Zeichen dafür sind, dass etwas nicht stimmt. Sie sind im Prinzip wie Halsschmerzen. Der Körper sendet uns Signale, die uns klarmachen sollen, dass etwas im Argen liegt. Bei den Halsschmerzen reagieren wir meist mit einer Ruhepause und ziehen uns warm an. Bei negativen Gefühlen schauen wir oft nicht so genau hin und bereiten damit den Weg, dass sich die Situation verschlimmert.</p><h2>Konflikte entstehen aus verletzten Bedürfnissen</h2><p>Um zu verstehen, warum negative Emotionen entstehen, hilft es, wenn wir uns klar machen, dass es in jeden von uns tief verankerte Bedürfnisse gibt.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/BT42tJ8yTJGKgUcyxaYJ"><img loading="lazy" width="700" height="199" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/BT42tJ8yTJGKgUcyxaYJ" alt="Wichtige Bedürfnisse bei Streits" /></a> <br /> <i>Drei wichtige Bedürfnisse bei Konflikten</i></p><p>Im Kontext der Konflikte sind drei wichtige Bedürfnisse: Sicherheit, Autonomie und Beziehungen. <b>Sicherheit</b> bedeutet, dass wir uns wohl fühlen wollen in dem Umfeld, in dem wir uns bewegen. Wir wollen auf unsere Kompetenz vertrauen können und es soll uns möglich sein, unsere Meinung zu äußern, ohne dafür bestraft oder ausgelacht zu werden. Damit einher geht das Bedürfnis nach <b>Beziehungen</b>: Wir wollen anerkannt werden und uns von unseren Teammitgliedern respektiert, wertgeschätzt und wahrgenommen fühlen. Das Gefühl, zum Team zu gehören und an einem Strang zu ziehen, ist dabei besonders wichtig. Fühlen wir uns ausgegrenzt und nicht verstanden, führt das schnell zu negativen Emotionen. Zu guter Letzt wollen wir unsere <b>Autonomie</b> wahren. Wir wollen selbstbestimmt entscheiden können und uns nicht durch Entscheidungen anderer eingeengt fühlen.</p><p>Sobald in einer Diskussion diese Bedürfnisse verletzt werden, löst das spontan negative Emotionen aus. Wir spüren z. B. Angst oder auch Wut. Wie wir darauf reagieren, ist unterschiedlich. Der eine wird laut und drückt seinen Ärger aus indem er ebenfalls verletzend wird (Angriff), der andere zieht sich zurück und meidet in Zukunft den Kontakt (Flucht).</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/hNgebuTVQniN6ldTWp0F"><img loading="lazy" width="700" height="416" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/hNgebuTVQniN6ldTWp0F" alt="Wut als Zeichen verletzter Bedürfnisse" /></a> <br /> <i>Wut ist ein Zeichen verletzter Bedürfnisse</i></p><p>Egal wie sich die Verletzung der Bedürfnisse ausdrückt, es ist an dieser Stelle wichtig, dass frühzeitig reagiert wird. Was in jedem Fall nicht hilft, sind Sätze wie „Bleib doch mal sachlich!“ oder „Warum sagst du denn nichts?“. Wer verstanden hat, dass es hier nicht mehr um die sachliche Diskussion geht, sondern um die ganz andere Ebene der Bedürfnisse, der wird merken, dass diese Sätze eigentlich die Situation noch verschlimmern. Aber wie soll man reagieren, und vor allem wer?</p><h2>Konflikte lösen</h2><p>Zum einen kann die Person, die sich verletzt fühlt, selbst aktiv werden, indem sie innehält und sich nicht von den eigenen negativen Emotionen mitreißen lässt. Statt also mit einem Gegenangriff oder Flucht zu reagieren, sollte man sich fragen, welches Bedürfnis der Kollege mit seinem Verhalten gerade verletzt hat. Meist ist das jedoch nicht so leicht. Es erfordert ein hohes Maß an Achtsamkeit und Selbstbeherrschung.</p><p>Wenn man es schafft, besteht die Möglichkeit, die Negativspirale zu durchbrechen. Allein die Erkenntnis, dass das Verhalten des anderen ein Bedürfnis verletzt, verringert bereits die dazugehörige negative Emotion. Das macht es leichter, konstruktiv auf den anderen zuzugehen. Man kann dem Kollegen erklären, was sein Verhalten in einem auslöst. Ist das Gegenüber einsichtig und empathisch, stehen die Chancen gut, dass der Konflikt beendet werden kann. Falls der andere keine Einsicht zeigt, kann man zumindest besser mit dessen Verhalten umgehen und die Situation selbst sachlicher betrachten und danach handeln.</p><p>Ein anderer Weg, solche Konflikte zu lösen, ist durch einen achtsamen Scrum Master. Dieser beobachtet die Kommunikation im Team und kann bei ausreichender Erfahrung erkennen, wenn etwas nicht in Ordnung ist und somit frühzeitig mit den Beteiligten sprechen. Am besten passiert das zunächst in einer kleinen Runde oder sogar im Einzelgespräch, damit sich die betreffenden Personen sicher fühlen kann, ihre Gefühle zu äußern. Wir reden hier vom sog. Safe-Space, aus dem nichts nach außen gelangt, was besprochen wurde. Ziel des Gespräches der zwei Konfliktparteien ist es, das Vertrauen wiederaufzubauen und ein empathisches Miteinander zu fördern. Wenn dies nicht zum gewünschten Erfolg führt, bleibt immer noch die Mediation von unbeteiligten Kollegen aus anderen Standorten. Bei codecentric haben wir mehrere Coaches und Mentoren, die auch bei scheinbar aussichtslosen Fällen in der Lage sind, zusammen mit den Beteiligten ein produktives Miteinander wiederherzustellen.</p><h2>Fazit</h2><p>Die Grundannahme in diesem Artikel ist es, dass Konflikte ihren Ursprung in verletzten Bedürfnissen haben. Jeder von uns hat diese Bedürfnisse und es lohnt sich, bei negativen Emotionen genauer hinzuschauen, um herauszufinden, welche Bedürfnisse verletzt wurden. So lässt sich ein Konflikt von der emotionalen auf die sachliche Ebene zurückführen, was den Weg zum respektvollen Miteinander bereitet.</p>

Konflikte in Teams lösen

<p>Im November 2018 besuchte ich den <a href="https://reactday.berlin" target="_blank">React Day Berlin</a>  und habe am React Advanced Workshop teilgenommen. Meine persönlichen Highlights stelle ich in diesem Artikel vor.</p><h2>Hooks, Hooks und nochmal Hooks</h2><p>Am Ende der Konferenz war es ein Running Gag bei jedem Talk: Wenn man in seinem Vortrag nicht das Wort „Hooks“ verwendet hatte, war man out! Und ich muss sagen, dass mir Hooks auch wirklich sehr gut gefallen. Was sind Hooks? – Es sind eine Handvoll vordefinierter Funktionen in React, mit denen sich Dinge wie State, Seiteneffekte, Referenzen oder Context etc. sehr elegant und vor allem wiederverwendbar nutzen lassen. Anders ausgedrückt: Man kann mit Hooks nun alles in funktionalen Komponenten umsetzen, was vorher nur mit Klassen möglich war.</p><p>Kleines Beispiel: Wenn man eine Komponente mit State ausstatten wollte, musste man bisher Folgendes machen:</p><p></p><p>Man braucht also eine Klasse, um die state-Variable zu definieren, und man muss die Methode <code>setState()</code> aufrufen, um den State zu ändern. Das funktioniert eigentlich ganz gut. Wie sieht das ganze jetzt mit Hooks aus? Voilà:</p><p></p><p>Wir haben eine funktionale Komponente und rufen zu Beginn die Funktion <code>useState()</code> auf. <code>useState()</code> ist der Hook. Als Parameter setzt man den initialen Wert. Erlaubt sind alle primitiven Werte sowie Arrays und Objekte. In unserem Fall starten wir bei 0. Als Rückgabewert bekommen wir ein Array mit zwei Elementen zurück, welches wir mittels Array-Destrukturierung zerlegen. Das erste Element ist der aktuelle Wert des States, also am Anfang die 0. Das zweite Element ist eine Funktion, um den State neu zu setzen, ähnlich der <code>setState()</code>-Methode in der oberen Klasse. Der Rest ist dann selbsterklärend.</p><p>Wo ist nun der Vorteil? – Zum einen brauchen wir keine Klassen mehr. Yay! Die Syntax ist kompakter, und wir können die Variablen für unseren State sowie der Funktion, die den State verändert, selbst wählen. <code>count</code> und <code>setCount</code> sind hier beliebige Beispiele. Gerade bei vielen State-Variablen in einer Komponente ist das besser lesbar als mit der setState-Variante. Aber der wichtigste Vorteil ist, dass wir den gesamten Code zum State-Management auch in eine eigene Datei refaktorieren und wiederverwenden können. Und genau das macht momentan die Community und hat bereits eine Unzahl von sog. „Custom Hooks“ erstellt: <a href="https://nikgraf.github.io/react-hooks" target="_blank">https://nikgraf.github.io/react-hooks</a> </p><p>Ein weiterer sehr praktischer Hook ist <code>useEffect()</code>. Übrigens: Alle Hook-Namen – auch die selbst erstellten – fangen per Konvention mit „use…“ an. Das macht es leichter, sie zu erkennen. Mittels <code>useEffect()</code> werden Seiteneffekte umgesetzt. Das heißt, wir führen immer dann eine Funktion aus, wenn bestimmte äußere Änderungen eintreten. Hier ein Beispiel:</p><p></p><p>Dieser Code ist bereits in eine eigene Datei ausgelagert, sodass wir ihn in verschiedenen Komponenten wiederverwenden können. Um ihn zu verwenden, rufen wir einfach die Funktion <code>useWindowMeasure()</code> in einer Komponente auf.</p><p><code>useEffect(...)</code> hat zwei Parameter: Der erste ist die Funktion, die ausgeführt werden soll. Der zweite ist ein Array von Werten. Sobald sich in dem Array einer der Werte ändert, wird die Funktion erneut ausgeführt. In unserem Fall gebe ich ein leeres Array rein. Das führt dazu, dass unsere Funktion nur einmalig beim Mounten der Komponente ausgeführt wird. Das simuliert also die Lifecycle-Methode <code>componentDidMount()</code> und das, obwohl wir keine Klassen für unsere Komponente nutzen müssen. Wenn der erste Parameter eine Funktion als Rückgabewert besitzt, wie in dem Beispiel hier (<code>return () => { window.removeEventListener('resize', handler)}</code>), dann wird diese beim Unmount der Komponente aufgerufen. Das ist dann wie <code>componentWillUnmount()</code>.</p><p>Mehr Details zu diesen beiden Hooks sind hier zu finden:<br /> <a href="https://reactjs.org/docs/hooks-state.html" target="_blank">https://reactjs.org/docs/hooks-state.html</a> <br /> <a href="https://reactjs.org/docs/hooks-effect.html" target="_blank">https://reactjs.org/docs/hooks-effect.html</a> </p><p>Leider sind Hooks noch nicht offiziell supported. Wahrscheinlich werden sie mit React 16.8 (aktuell haben wir 16.7) released werden. Mittels folgendem Import in der <code>package.json</code> könnt ihr jetzt schon damit spielen:</p><p><code>"dependencies": { "react": "^16.7.0-alpha.2", "react-dom": "^16.7.0-alpha.2" }</code></p><h2>Context API</h2><p>Eigentlich ist das Context API bereits seit React 16.3 (März 2018) offiziell nutzbar. Wer sich damit bisher nicht beschäftigt hat und stattdessen Redux oder MobX etc. einsetzt, sollte jetzt mal einen Blick darauf werfen. Es gibt übrigens auch einen Hook, der die Arbeit damit erleichtert 😉</p><p>Selbst Redux und MobX arbeiten unter der Haube seit eh und je mit dem Context API, um den globalen State darin zu verwalten und ihn den Komponenten zur Verfügung zu stellen. Und eines vorneweg: Das Context API ersetzt Redux etc. noch nicht komplett, jedoch ist es gerade für kleine Anwendungen meist völlig ausreichend. Der Vorteil von Redux ist z. B., dass durch die indirekte State-Manipulation über Actions und Reducer Dinge ermöglicht werden wie Zeitreisen durch die Historie der State-Änderungen, persistieren und rebooten des gesamten States und andere Features (siehe dazu <a href="https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367" target="_blank">https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367</a> )</p><p>Das Context API ist dagegen jedoch sehr simpel. Es funktioniert wie folgt:</p><p></p><p>Wir erstellen mittels <code>React.createContext()</code> ein neues Context-Objekt mit einem initialen Wert als Parameter. Der Wert kann alles sein: Ein Primitive, ein Objekt, Array etc. Hier nutzen wir den String “dark”. Dann verwenden wir die Context-Provider-Komponente (<code><ThemeContext.Provider value="light">...</ThemeContext.Provider></code>) als Higher Order Component für alle Kind-Komponenten, die später auf den State zugreifen sollen. Hier also für Header und Footer. Dabei setzen wir den value des Providers auf den Wert, der nach unten gereicht wird. Man kann auch mehrere Provider ineinander schachteln. Zum Auslesen des States nutzen wir entweder eine Consumer-Komponente (<code><ThemeContext.Consumer>...</ThemeContext.Consumer></code>) oder den Hook <code>useContext()</code>. In beiden Fällen wird in der Komponenten-Hierarchie nach oben gegangen und der nächstgelegene Provider gesucht. Dessen Wert wird zurückgegeben. In unserem Fall ist es der String „light“.</p><p>Durch das Context API sparen wir uns das Weiterreichen von Props über mehrere Komponenten. Um den State zu aktualisieren gibt es leider keine Funktion wie z. B. <code>ThemeContext.update('light')</code> etc. Deswegen muss der State manuell z. B. innerhalb einer State-Variablen einer Komponente gespeichert werden:</p><p></p><h2>React Portals</h2><p>Portals sind auch nicht so neu (seit React 16), aber vor dem React Day hatte ich davon noch nichts gehört und das, obwohl man sie in fast jeder App gebrauchen kann. Im Prinzip rendern wir mit einem Portal eine Komponente außerhalb unseres Root-DOM-Elementes, in der wir die React App rendern. Das ist z. B. interessant für Modals, Dialoge, Overlays etc. Die Verwendung ist recht simpel:</p><p></p><p>Im HTML-Dokument ist dann nicht nur ein typisches <code><div id="root"></div></code>, sondern noch ein weiteres <code><div id="modal"></div></code> enthalten.</p><h2>Fazit und Ausblick</h2><p>Mit den vorgestellten Features kann man seine nächsten React-Projekte noch um einiges eleganter gestalten als zuvor. Zudem lassen sich die Features in bestehende Projekte einfügen, ohne dabei die existierenden Tools zu behindern. Ach, und Render Props wurden übrigens schon wieder als outdated beschrieben, da man mittels Hooks und dem Context API die meisten Anwendungsfälle sehr einfach abbilden kann. Dazu auch mehr hier: <a href="https://medium.com/@IvanChukitow/render-props-vs-react-hooks-c3cf0162ed7b" target="_blank">https://medium.com/@IvanChukitow/render-props-vs-react-hooks-c3cf0162ed7b </a> </p><p>Das nächste Feature, das ich mir genauer anschauen würde, ist Suspense. Dieses ist jedoch erst für Mitte 2019 geplant. Schon jetzt kann man Suspense zusammen mit <code>React.lazy()</code> für Code Splitting nutzen. (<a href="https://reactjs.org/blog/2018/10/23/react-v-16-6.html" target="_blank">https://reactjs.org/blog/2018/10/23/react-v-16-6.html</a> )</p>

Top 3 React Features für 2019

<p>Wir beschäftigen uns bei der codecentric seit einiger Zeit mit dem Thema Sketchnotes. Anfangs war es ein spaßiges Thema für die künstlerisch begabten Mitarbeiter in ihrer 20% Zeit oder eine willkommene Abwechslung zum technischen Alltag für die anderen. Doch mittlerweile haben wir gelernt, dass sich Sketchnotes großartig für die tägliche Beratungsarbeit einsetzen lassen. Welchen Vorteil Sketchnotes gegenüber klassischen Text-Notizen und Bulletpoints bieten, beschreibe ich in diesem Artikel.</p><h2>Das Gehirn denkt in Bildern</h2><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/5QM3AppBREyC4IR9fZ6R"><img width="700" height="424" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/5QM3AppBREyC4IR9fZ6R" alt="Innere Bilder von Sketchnotes" /></a> <br /> <i>Das Gehirn denkt in Bildern</i></p><p>Wann immer wir kommunizieren, erzeugen die gesprochenen oder geschriebenen Worte in unserem Kopf innere Bilder. Wenn man das Wort „Pferd“ liest, dann sieht man mit ziemlich hoher Wahrscheinlichkeit auch das Bild eines Pferdes vor Augen. Noch klarer wird es wenn wir etwas lesen wie „Das Pferd springt über ein Hindernis“. Wer sieht in diesem Moment nicht ein springendes Pferd? Aber Moment. Was genau sehen wir eigentlich, wenn wir das Wort „Hindernis“ hören? Ist das eine Stange, wie beim Dressurreiten? Oder vielleicht ein kleiner Felsstein oder etwas ganz anderes?</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/pKsPsvHdQduMtSngTHCX"><img loading="lazy" width="700" height="719" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/pKsPsvHdQduMtSngTHCX" alt="Pferd springt über Hindernis" /></a> <br /> <i>Pferd springt über Hindernis</i></p><p>Das Problem mit den gesprochenen oder geschriebenen Wort ist, dass es nicht in jedem von uns die gleichen inneren Bilder erzeugt. Das wiederum kann dazu führen, dass wir zwar denken, jemand anderen verstanden zu haben, aber eigentlich gehen wir nur davon aus, dass der andere die gleichen inneren Bilder hat wie wir. Sicher sein können wir uns nicht. Und das führt leicht zu Missverständnissen.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/RXLj15hNTXeQT4RXrZP6"><img loading="lazy" width="700" height="566" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/RXLj15hNTXeQT4RXrZP6" alt="Sketchnotes vermeiden Missverständisse" /></a> <br /> <i>Worte führen zu unterschiedlichen inneren Bildern</i></p><p>In unserer Arbeit als Agile Coaches, Product Owner, Scrum Master und auch Entwickler kommunizieren wir ständig mit unseren Kunden sowie untereinander. Dabei wird über Vorgehensweisen, Produktfeatures, Architekturen, Programmier-Patterns und vieles mehr gesprochen. Das alles sind abstrakte Begriffe, die in jedem von uns unterschiedliche Bilder erzeugen. Manchmal geht es aber darum, dass wir wirklich das exakt gleiche Verständnis von den Dingen haben, denn sonst kann uns das schnell eine große Summe Geld kosten, z. B. wenn das Entwicklungsteam die falsche Architektur umsetzt oder das Management durch immer neue Feature-Requests das Team überfordert und demotiviert.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/byQRNbGVTQq4M2DJ5BFw"><img loading="lazy" width="700" height="476" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/byQRNbGVTQq4M2DJ5BFw" alt="Team wird demotiviert" /></a> <br /> <i>Geld wird verbrannt und Team demotiviert</i></p><p>Warum also nicht die inneren Bilder für jeden Beteiligten auf Papier bringen und damit explizit machen? Mit Sketchnotes machen wir genau das. Wir nutzen sehr simple Formen und grafische Elemente, um das gleiche Verständnis bei allen Beteiligten zu schaffen. Der abgegriffene Satz „Ein Bild sagt mehr als 1000 Worte“ ist hier doch genau der Punkt. Gleiche innere Bilder führen zu gleichem Verständnis.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Mz84eTPdTCSbMhiCVg75"><img loading="lazy" width="700" height="682" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Mz84eTPdTCSbMhiCVg75" alt="Gleiche Bilder = Gleiches Verständnis" /></a> <br /> <i>Gleiche innere Bilder = Gleiches Verständnis</i></p><p>Dabei ist die künstlerische Fähigkeit jedes einzelnen ziemlich irrelevant. Jeder der einen Kreis und ein Strich zeichnen kann, kann auch sketchnoten. Denn es geht nicht um die Schönheit der Bilder sondern darum, wie die Dinge auf dem Papier in Beziehung zueinander stehen. Wir zeichnen Prozesse, Ideen oder Zusammenhänge und keine Stillleben einzelner Objekte. Natürlich ist es trotzdem hilfreich, sich ein wenig damit zu beschäftigen, wie man bestimmte Dinge grafisch darstellen kann, um zum einen schneller zu werden und ggf. auch komplizierte Sachverhalte prägnant darstellen zu können. Aber für den Einstieg reichen Grundformen wie Kreis, Strich und Punkt. Denn „Punkt, Punkt, Komma, Strich, fertig ist das Mondgesicht“ 😀</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/e7tTmgFQeqT9umjMBCEz"><img loading="lazy" width="700" height="566" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/e7tTmgFQeqT9umjMBCEz" alt="Mondgesicht" /></a> <br /> <i>Mondgesicht und einfache Formen</i></p><h2>Wann nutzen wir Sketchnotes?</h2><p>Wann lassen sich Sketchnotes nun genau einsetzen? Wie bereits erläutert, ist es immer dann sinnvoll, wenn wir mit jemand anderem kommunizieren und etwas erklären wollen. Also z. B. in einer Diskussion, bei einem Vortrag oder während einer Gruppenmoderation. Deswegen profitieren besonders die Agilen Coaches und Scrum Master davon. Aber auch ohne Kommunikation mit anderen sind Sketchnotes ein interessantes Instrument. Denken wir zurück an den Fakt, dass das Gehirn in Bildern denkt und sich Bilder leichter merken lassen als Worte. Damit eignen sich Sketchnotes auch für persönliche Notizen bzw. immer wenn wir etwas aufschreiben, dass wir uns merken wollen. Ich sketchnote beispielsweise bei Vorträgen auf Konferenzen oder Workshops und auch um meine Ideen festzuhalten. Ich tue mir damit selbst einen Gefallen, weil die Notizen so viel motivierender zu lesen sind als die alten Bulletpoints und Text-Mitschriften, die man sich von oben bis unten durchlesen muss, um alle Inhalte zu erfassen. Bei den Bildern werden viel schneller die verknüpften Informationen in meiner Erinnerung abgerufen, was das Lesen der Notizen wesentlich beschleunigt. Und noch eine Kleinigkeit: Bild-Mitschriften lassen sich meist leichter ergänzen als Text-Mitschriften, da man viel weniger Platz benötigt und Ergänzungen auch über Pfeile und Umrahmungen hergestellt werden können.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/VOzoHodToqllXKDanZqD"><img loading="lazy" width="700" height="251" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/VOzoHodToqllXKDanZqD" alt="Sketchnotes Schnelligkeit und Erweiterbarkeit" /></a> </p><h2>Fazit</h2><p>Wir haben in diesem Artikel gelernt, dass es bei Sketchnotes um die inneren Bilder geht. Genauer gesagt geht es darum, dass jeder Beteiligte bei der Kommunikationssituation die gleichen inneren Bilder hat und damit auch das gleiche Verständnis. Innere Bilder sind die universelle Sprache des Gehirns und Sketchnotes sind ein ideales Mittel, um diese Sprache zu sprechen.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/26lCLMfySruYvHei8Rlo"><img loading="lazy" width="700" height="453" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/26lCLMfySruYvHei8Rlo" alt="Sketchnotes universelle Sprache" /></a> <br /> <i>Bilder sind eine universelle Sprache</i></p>

Sketchnotes – Es geht um innere Bilder

<p>Im <a href="/wissens-hub/blog/webseiten-mit-alexa-und-websockets-navigieren">ersten Teil</a>  dieser Serie haben wir uns angesehen, wie wir das Alexa Skills Kit nutzen können, um einen Alexa Skill zu erstellen. In diesem Teil erstellen wir eine Deployment Pipeline für die Lambda Funktion, die die Funktionalität unseres Skills ausmacht. Dazu werden wir <a href="https://aws.amazon.com/de/codestar/" target="_blank">AWS CodeStar</a>  nutzen, denn durch CodeStar bekommen wir einerseits eine komplette Pipeline erzeugt und wir erhalten bereits Boilerplate Code in unserer Lambda, um direkt in die Entwicklung unseres Alexa Skills einzusteigen. Die Deployment Pipeline können wir dann in dem für uns erstellten CloudFormation Template nach unseren Wünschen anpassen.</p><p>Die Pipeline wäre für eine einfache Lambda nicht unbedingt nötig. Man könnte auch die Kommandozeile nutzen, um die Lambda zu deployen oder sie manuell per Zip-Datei in der <a href="https://www.codecentric.de/partner/aws">AWS</a>  Konsole hochladen. Wenn das Projekt jedoch größer wird und mehrere Personen an der Lambda arbeiten, ist es von Vorteil, wenn z.B. Unit-Tests per CodeBuild ausgeführt werden und man auch mehrere Stages für Produktion und Development einrichten kann.</p><h2>CodeStar Projekt erstellen</h2><p>Eines gleich vorneweg: Wir müssen das CodeStar Projekt in der Region “EU (Ireland)” erstellen, weil wir sonst als Trigger der Lambda nicht das Alexa Skills Kit auswählen können.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/2n6uaZ4hREqHT6GtsJ1l"><img width="700" height="340" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/2n6uaZ4hREqHT6GtsJ1l" alt="AWS CodeStar Startseite" /></a> </p><p>Wir erstellen in CodeStar ein neues Projekt.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Aw2PelmRnWLjIYvpx3ew"><img loading="lazy" width="700" height="218" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Aw2PelmRnWLjIYvpx3ew" alt="CodeStar Service Roller erstellen" /></a> </p><p>Wir werden aufgefordert, für CodeStar eine neue Rolle anzulegen, sodass CodeStar in der Lage ist, weitere Ressourcen wie die Lambda oder ein CodeCommit Repo zu erstellen. Wir können das einfach mit “Yes, create role” bestätigen.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/TwD0GKwQCSZ5wV2DbOIL"><img loading="lazy" width="700" height="234" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/TwD0GKwQCSZ5wV2DbOIL" alt="Alexa Skill als Codestar Template" /></a> </p><p>Im nächsten Dialog wählen wir das CodeStar Template. Dazu suchen wir links im Suchfeld nach “Alexa” und wählen dann den “Fact Skill” aus. Dieser bietet uns schon etwas Boilerplate Code innerhalb der Lambda und konfiguriert die Lambda Trigger entsprechend unserer Bedürfnisse. Man könnte auch einen der anderen Alexa Skill Templates nutzen und würde einfach einen anderen Boilerplate Code in der Lambda bekommen.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/yynZJV48RRum3be7nvaz"><img loading="lazy" width="700" height="432" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/yynZJV48RRum3be7nvaz" alt="Codestar Repository wählen" /></a> </p><p>Dann wählen wir den Projektnamen “WebsiteNavigator” und nutzen AWS CodeCommit für unser Git-Repository.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/BHOIFFZRVytaNfxeQoP0"><img loading="lazy" width="700" height="369" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/BHOIFFZRVytaNfxeQoP0" alt="CodeStar Review" /></a> </p><p>Anschließend sehen wir, wie die Pipeline aussehen wird, was wir mit einem Klick auf “Create Projekt” wohlwollend hinnehmen.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/WjBPLFyQV26lONIOog86"><img loading="lazy" width="700" height="433" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/WjBPLFyQV26lONIOog86" alt="Codestar Repository URL kopieren" /></a> </p><p>Im nächsten Dialog sehen wir bereits die URL für unser Repository am unteren Ende. Die Konfiguration einer IDE können wir überspringen durch einen Klick auf “Skip”.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/4rD87JXQSjvOELcbYYeQ"><img loading="lazy" width="700" height="327" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/4rD87JXQSjvOELcbYYeQ" alt="CodeStar Pipeline Fortschritt" /></a> </p><p>Das war auch schon Alles. In den nächsten Minuten wird unsere Deployment Pipeline das erste Mal durchlaufen und unsere Lambda wird erzeugt und mit dem Boilerplate Code initialisiert. Wir können dem Status der Pipeline zusehen, wenn wir im Dashboard des CodeStar Projektes nach unten scrollen. Alternativ können wir in der linken Navigationsleiste auch auf den Punkt “Pipeline” klicken und sehen dort noch ein paar mehr Details.</p><p>Wenn die Pipeline durchgelaufen ist und alle Boxen grün sind, können wir uns einmal die Lambda anschauen, die für uns angelegt wurde. Wir wechseln dazu auf den AWS Service “Lambda” im Hauptmenü.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/xICVRodQuSOqY15DPm8t"><img loading="lazy" width="700" height="347" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/xICVRodQuSOqY15DPm8t" alt="Codestar Lambda umbenennen" /></a> </p><p>Die Lambda hat einen etwas kryptischen Namen, aber den können wir noch anpassen. Leider sind die Einstellungen für die Lambda noch nicht optimal. Zum Beispiel läuft die Lambda standardmäßig mit Node.js 4.3, obwohl es schon die neuere Version 8.10 gibt. Dies und andere Sachen werden wir noch kurz anpassen.</p><h2>Die template.yml anpassen</h2><p>Wir klonen uns nun das neu erstellte CodeCommit Repository mit dem Befehl:<br /> <code>git clone https://git-codecommit.eu-west-1.amazonaws.com/v1/repos/WebsiteNavigator</code></p><p>Damit das funktioniert, müssen wir zuerst die AWS CLI und unsere Credentials richtig eingerichtet haben. Hier nochmal der Link mit einer Anleitung: <a href="https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up.html" target="_blank">https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up.html</a> </p><p>Wenn wir uns den Code dann ansehen, ist alles noch recht übersichtlich:</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/RMSp3d49QFCqkJJLiAIJ"><img loading="lazy" width="608" height="458" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/RMSp3d49QFCqkJJLiAIJ" alt="Codestar Alexa Template Struktur" /></a> </p><p>Wir öffnen nun die <em>template.yml</em>, um die Einstellungen für die Lambda anzupassen.</p><div>

```yaml
AWSTemplateFormatVersion: 2010-09-09
Transform:
- AWS::Serverless-2016-10-31
- AWS::CodeStar
 
Parameters:
  ProjectId:
    Type: String
    Description: AWS CodeStar projectID used to associate new resources to team members
 
Resources:
  AlexaSkillFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs8.10      Timeout: 10      FunctionName: website-navigator      Role:
          Fn::ImportValue:
              !Join ['-', [!Ref 'ProjectId', !Ref 'AWS::Region', 'LambdaTrustRole']]
      Events:
          AlexaSkillEvent:
                Type: AlexaSkill
```

</div><p>Was wir hier sehen, ist ein CloudFormation Template, das Codestar für uns erzeugt hat. Es ist mit dem Serverless Application Model, kurz SAM, geschrieben. Die Befehle sind ein wenig kompakter gegenüber den normalen CloudFormation Befehlen. Dieses Template definiert unsere Lambda Funktion als Resource und konfiguriert als Trigger das Event mit dem Typ “AlexaSkill”. Dadurch wird unsere Lambda mit dem Alexa Skill Kit Trigger erstellt. Weitere Infos zu SAM gibt es hier: <a href="https://github.com/awslabs/serverless-application-model" target="_blank">https://github.com/awslabs/serverless-application-model</a> </p><p>Wir ändern den Wert für die Runtime von <code>nodejs4.3</code> auf <code>nodejs8.10</code> und fügen die Werte <code>Timeout: 10</code> und <code>FunctionName: website-navigator</code> hinzu.</p><p>Warum ändern wir die Werte? Mit Node 8.10 haben wir mehr ES6 Features, die uns beim Programmieren das Leben etwas leichter machen. Das <em>Timeout</em> von 10 Sekunden ist notwendig, da wir Requests zu externen Servern machen werden und dafür Promises nutzen. Wenn die Promises resolved werden, erzeugen wir die Antwort für Alexa. Bei zu geringem Timeout (der Default sind 3 Sekunden) könnte unsere Lambda-Funktion sonst Gefahr laufen, vorzeitig beendet zu werden, ohne dass eine Antwort an Alexa gesendet wurde. Der <em>FunctionName</em> benennt unsere kryptische Lambda Funktion einfach um.</p><p>Wenn wir den Code einchecken und pushen, geht unsere Pipeline wieder los und die Lambda Funktion wird aktualisiert.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/UetfHz82RyyHEcGogSIb"><img loading="lazy" width="700" height="327" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/UetfHz82RyyHEcGogSIb" alt="Lambda Übersicht neuer Name" /></a> </p><p>Nach der Aktualisierung hat unsere Funktion in der Liste der Lambda Funktionen den erwarteten Namen.</p><p>Damit ist unsere Pipeline komplett. Im <a href="/wissens-hub/blog/per-lambda-fuer-alexa-eine-webseite-steuern">nächsten Schritt</a>  werden wir die Lambda anpassen und die Logik für unseren Alexa Skill implementieren.</p><p>Bei Fragen oder Anregungen freue ich mich über einen Kommentar.</p>

Eine Pipeline für Lambda mit AWS CodeStar erstellen

<p>In dieser Artikelserie werde ich praxisnah zeigen, wie man mithilfe eines Alexa Skills eine Webseite fernsteuern kann. Dabei werde ich zeigen, wie man:</p><ol><li>einen eigenen Alexa Skill mit dem Alexa Skill Kit erstellt (in diesem Artikel)</li><li><a href="/wissens-hub/blog/eine-pipeline-fuer-lambda-mit-aws-codestar-erstellen">eine Deployment Pipeline für Lambda mit AWS CodeStar erzeugt</a> </li><li><a href="/wissens-hub/blog/per-lambda-fuer-alexa-eine-webseite-steuern">den Lambda Code für Alexa erzeugt und WebSockets nutzt, um eine Webseite damit zu navigieren.</a> </li></ol><p>Die Architektur des Skills wird am Ende die Folgende sein:</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cShvc6lsTP6xNIpJNSlV"><img width="672" height="320" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cShvc6lsTP6xNIpJNSlV" alt="Architektur Alexa Websockets Webseite" /></a> </p><h2>Alexa Skills Kit 101</h2><h3>Voraussetzungen</h3><p>Bevor wir uns mit der Entwicklung eines Skills beschäftigen können, müssen folgende Voraussetzungen erfüllt sein:</p><ul><li>Ein Amazon Developer Account ist eingerichtet (<a href="https://developer.amazon.com" target="_blank">https://developer.amazon.com</a> )</li><li>Ein <a href="https://www.codecentric.de/partner/aws">AWS</a>  Account ist eingerichtet und man kann Code in AWS CodeCommit einchecken. (<a href="https://aws.amazon.com" target="_blank">https://aws.amazon.com</a>  & <a href="https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up.html" target="_blank">https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up.html</a> )</li><li>Ein Node.js Webserver zum Testen muss verfügbar sein (z. B. <a href="https://zeit.co/now" target="_blank">https://zeit.co/now</a> )</li></ul><h3>Einen Skill erstellen</h3><p>Für das Erstellen eines Alexa Skills verwenden wir das sog. Alexa Skills Kit (ASK). Dieses finden wir in der Amazon-Developer-Konsole (<a href="https://developer.amazon.com/home.html" target="_blank">https://developer.amazon.com/home.html</a> ).</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/vNrhjG1SFmVAxolOSJPQ"><img loading="lazy" width="700" height="202" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/vNrhjG1SFmVAxolOSJPQ" alt="Amazon Developer Console" /></a> </p><p>Wir klicken hier auf “Alexa Skills Kit” und kommen zur Übersicht unserer Alexa Skills.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/kbdl5ADRDG3bfmzZ7lF4"><img loading="lazy" width="700" height="145" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/kbdl5ADRDG3bfmzZ7lF4" alt="Create new Alexa Skill" /></a> </p><p>In der rechten oberen Ecke klicken wir auf den Button “Create Skill”.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/uhOgRc0gTtGRcRuFnfdg"><img loading="lazy" width="250" height="183" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/uhOgRc0gTtGRcRuFnfdg" alt="Name und Sprache vom Alexa Skill" /></a> </p><p>Auf der folgenden Seite wählen wir unseren Namen für den Skill. In unserem Beispiel entscheide ich mich für <em>“Webseiten Navigator”</em>. Als Sprache wähle ich “German”.</p><p>Auf Konferenzen und Vorträgen wird häufig gefragt, ob der Skill-Name einzigartig sein muss. Die Antwort ist nein. Es kann im Skill-Store auch Skills mit gleichem Namen geben. Jeder Nutzer muss die Skills für seine Alexa sowieso manuell aktivieren. Aktiviert man zwei Skills mit demselben Namen, wird Alexa den Skill verwenden, der zuerst aktiviert wurde. Trotzdem ist es natürlich sinnvoll, aus Marketinggründen ggf. einen eindeutigen eigenen Namen zu finden.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/XfNP0qqfRFqyreeoN5Ch"><img loading="lazy" width="700" height="312" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/XfNP0qqfRFqyreeoN5Ch" alt="Model des Alexa Skills" /></a> </p><p>Mit einem Klick auf “Next” kommen wir zur Auswahl des Skill Models. Hier entscheiden wir uns, ob wir einen eigenen “Custom Skill” oder einen vordefinierten Skill erstellen wollen. Vordefinierte Skills sind z.B. Skills für die tägliche Zusammenfassung (“Flash Briefing”), Smart Home Skills oder Video-Skills für neuere Echo-Geräte mit Bildschirm. Wir entscheiden uns für den Custom Skill, da wir hier die meisten Möglichkeiten haben, den Skill nach unseren Vorlieben zu gestalten und wir in die anderen Modelle mit unserem Anwendungsfall auch nicht hineinpassen.<br /> Dann klicken wir oben rechts auf “Create Skill”.</p><h4>Invocation Name</h4><p>Wir werden nun zu unserem Model Editor weitergeleitet, wo wir definieren, was unser Skill alles kann. Wir beginnen damit, den “Invocation Name” festzulegen. Das ist der Name, den der Nutzer sagen muss, um unseren Skill zu starten.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/1tNqXvTxTpKoMf3hylXe"><img loading="lazy" width="700" height="350" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/1tNqXvTxTpKoMf3hylXe" alt="Invocation Names des Alexa Skills" /></a> </p><p>Beim Invocation Name müssen wir beachten, dass Alexa in der deutschen Ausführung auch versucht, alles, was der Nutzer sagt, auf deutsche Wörter zu mappen. Sollten wir einen englischen Firmennamen haben, kann das dazu führen, dass Alexa nicht immer versteht, was wir von ihr wollen. Deswegen kann es Sinn ergeben, anstelle des englischen Namens eine Art deutsche phonetische Bezeichnung zu nutzen. Also anstatt “christmas” als Invocation Name zu nutzen, könnten wir “kris mäss” nehmen. Meistens funktionieren solche phonetischen Namen besser als die englischen Originale. Aber das muss man im Einzelfall einfach testen.<br /> <a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/9ce6f7PRv65fXDWN0yUw"><img loading="lazy" width="700" height="132" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/9ce6f7PRv65fXDWN0yUw" alt="Invocation Name des Alexa Skills German" /></a> </p><p>In unserem Fall habe ich bereits die deutschen Begriffe <em>„webseiten navigator“</em> gewählt, weshalb es nicht zu Problemen kommen sollte.</p><h4>Intents, Utterances und Slots</h4><p>Als nächstes kümmern wir uns um die sog. “Intents”. Das sind im Grunde die unterschiedlichen Funktionen unseres Skills, die ein Nutzer verwenden kann. Ein Intent besteht aus einem Intent-Namen und den sog. “Utterances”. Die Utterances sind die Sätze oder Wortgruppen, die der Nutzer sagen muss, um den Intent aufzurufen. Es gibt in jedem Skill vordefinierte Intents, auf die Amazon besteht. Diese heißen <code>AMAZON.StopIntent</code>, <code>AMAZON.HelpIntent</code> und <code>AMAZON.CancelIntent</code>. Wie der Name schon vermuten lässt, sind die Intents dazu da, den Skill zu beenden (AMAZON.StopIntent), eine Hilfe aufzurufen (AMAZON.HelpIntent) oder Alexa bei der aktuellen Konversation zu unterbrechen, ohne den Skill zu verlassen (AMAZON.CancelIntent).</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/P187rZzTTu6OM4SwXayS"><img loading="lazy" width="700" height="191" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/P187rZzTTu6OM4SwXayS" alt="Alexa Intent erstellen" /></a> </p><p>Wir legen nun unseren eigenen Intent an durch Klick auf die Schaltfläche “+ Add Intent” im Intents-Dialog.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/9HRL8xLUQ26EOze447iR"><img loading="lazy" width="700" height="282" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/9HRL8xLUQ26EOze447iR" alt="Alexa Intent Name vergeben" /></a> </p><p>Wir wählen einen Custom Intent und vergeben den Namen <em>“NavigateToPage”</em>.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/y5FxGCSaqhz5BMw2kbvw"><img loading="lazy" width="700" height="285" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/y5FxGCSaqhz5BMw2kbvw" alt="Alexa Utterances erstellen" /></a> </p><p>Im folgenden Dialog werden wir dazu aufgefordert, die Utterances anzugeben. Wir tragen dort folgenden Satz ein: <em>“Navigiere zur Seite {PAGE_NAME}”</em>. Wenn wir die öffnende geschweifte Klammer eintragen, zeigt uns der Editor ein Overlay für die sog. “Slots” an.<br /> Wir erstellen in diesem Overlay einen neuen Slot mit dem Namen <em>“PAGE_NAME”</em> und klicken auf die Schaltfläche “Add”. Anschließend bestätigen wir den Satz noch mit <em>Enter</em> im Eingabefeld und sehen dann, dass die Utterance hinzugefügt wurde und auch der Slot dem Intent zugewiesen wird:</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/nEoqyd0nSpaPhmwFTPKl"><img loading="lazy" width="700" height="259" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/nEoqyd0nSpaPhmwFTPKl" alt="Alexa Utterance erstellt" /></a> </p><p>Slots sind im Prinzip so etwas wie Variablen in unserem Satz. Der Nutzer kann also z.B. <em>“Navigiere zur Seite <strong>Home</strong>”</em> oder <em>“Navigiere zur Seite <strong>Impressum</strong>”</em> sagen. In beiden Fällen würde unser Intent aufgerufen werden und der Slot wird als Parameter an unsere Funktion übergeben – dazu später mehr.</p><h4>Einen eigenen Slot Type anlegen</h4><p>Jeder Slot muss einen bestimmten Slot Type haben. Es gibt vordefinierte Slot Types wie z.B. <code>AMAZON.NUMBER</code> oder <code>AMAZON.DATE</code> oder wir erstellen unseren eigenen Slot Type. Slot Types sind in der Regel feste Datentypen wie Date oder Number oder endliche Aufzählungen von Werten, ähnlich eines Enums. Ein Sonderfall ist der vordefinierte Slot Type <code>AMAZON.SearchQuery</code>. Dieser erlaubt so etwas wie Freitexteingaben, ohne dass feste Werte vorgegeben werden müssen.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/G6YZbhIrR3OKmD6q2Oem"><img loading="lazy" width="700" height="205" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/G6YZbhIrR3OKmD6q2Oem" alt="Alexa Custom Slot Type" /></a> </p><p>Bisher hat unser Slot <em>“PAGE_NAME”</em> noch keinen Slot Type. Diesen werden wir jetzt erstellen. Dazu wechseln wir in den Unterpunkt “Slot Types (0)” in der linken Navigationsleiste. Anschließend klicken wir auf den Button “+ Add Slot Type”. Wir vergeben den Namen <em>“LIST_OF_PAGES”</em> und bestätigen mit einem Klick auf “Create custom slot type”.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/ctUIU81wQ5OkFLFLDgfw"><img loading="lazy" width="700" height="232" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/ctUIU81wQ5OkFLFLDgfw" alt="Alexa List of Pages Slot" /></a> </p><p>Im Anschluss geben wir die Werte ein, die unser Slot Type annehmen kann. Ich beschränke mich hier auf die beiden Werte <em>“Home”</em> und <em>“Impressum”</em>.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/ozW2H5ScSvG3qg8bIEAn"><img loading="lazy" width="700" height="261" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/ozW2H5ScSvG3qg8bIEAn" alt="Select Slot Type" /></a> </p><p>Wir weisen nun diesen Slot Type unserem Slot <em>“PAGE_NAME”</em> zu. Dazu gehen wir zurück in unseren Intent <em>“NavigateToPage”</em> und wählen dort unseren neu erstellen Slot Type <em>“LIST_OF_PAGES”</em> aus.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/L7KCafsQRsWAqbyX85zC"><img loading="lazy" width="700" height="307" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/L7KCafsQRsWAqbyX85zC" alt="Save Alexa Model" /></a> </p><p>Jetzt ist ein guter Zeitpunkt gekommen, unser Model zu speichern und bauen zu lassen. Wir klicken dazu auf den Button “Build Model” im oberen Bereich.</p><h4>Endpoint definieren</h4><p>Als letztes müssen wir in diesem Editor noch unseren Endpoint festlegen. Der Endpoint ist die Funktion, die auf die Intents unseres Skills reagiert und dafür verantwortlich ist, die richtigen Antworten zu geben und im Hintergrund Aktionen auszuführen. Wir klicken also auf den Punkt “Endpoint” in der linken Navigation und wählen dann die Option “AWS Lambda ARN” aus.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/UKAPOPgAR822bci4MFSd"><img loading="lazy" width="700" height="279" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/UKAPOPgAR822bci4MFSd" alt="Set Endpoint for Alexa Lambda" /></a> </p><p>Hier muss nun die ARN, also die ID der Lambda-Funktion, eingetragen werden. Jedoch haben wir die Lambda bisher noch nicht erstellt. Dies machen wir im <a href="/wissens-hub/blog/eine-pipeline-fuer-lambda-mit-aws-codestar-erstellen">folgenden Teil</a>  dieser Serie mithilfe von <a href="https://www.codecentric.de/partner/aws">AWS</a>  CodeStar.</p><p>Habt ihr bis hierhin Fragen oder Anregungen, dann freue ich mich über einen Kommentar von euch.</p>

Webseiten mit Alexa und Websockets navigieren

<p>Bei allen agilen Software-Projekten, die ich in den letzten vier Jahren bei codecentric erlebt habe, wurde immer mit Scrum gearbeitet. Es gab u.a. die typischen Scrum Events (Sprint, Daily, Review, Retro, Planning) sowie zusätzlich ein oder mehrere Backlog Refinements während des Sprints. Die Tickets haben wir mit Storypoints geschätzt. Soweit, so gut. Normalerweise klappt das immer recht gut und selten wurde etwas am Prozess geändert.</p><p>Trotzdem hatte ich besonders als Entwickler immer wieder mit folgenden „Problemen“ zu tun:</p><ul><li>Der Product Owner (PO) wollte wissen, warum ein Ticket so lange gedauert hat, obwohl es doch nur mit einer „3“ geschätzt wurde. Als Entwickler muss man sich dann rechtfertigen. Meistens gab es unvorhergesehene Dinge, die den Aufwand erhöht haben.</li><li>Aus der Schätzung in Storypoints (= relative Komplexität) wurde über die Zeit immer mehr eine Schätzung der Umsetzungsdauer der Tickets. Je mehr Erfahrung man als Entwickler im Projekt sammelt, desto besser wird das Bauchgefühl wie groß ein Ticket ist (= wie lange es dauert). Storypoints und Dauer haben aber wenig miteinander zu tun und es erhöht sich die Chance daneben zu liegen.</li><li>Zum Sprintende staute sich eine große Menge an Tickets, die darauf warteten, gereviewed und dann gemerged zu werden. Das erzeugte häufig Stress vor dem Sprintwechsel, weil sich der Stau nicht so schnell auflösen ließ wie gewünscht.</li><li>Die Velocity mehrerer Sprints glich mehr einer Achterbahnfahrt als einem stabilem Verlauf, weil Tickets von einem Sprint in den nächsten genommen wurden und die Story Points dann im Folgesprint zu Buche schlugen.</li></ul><p>Das sind alles keine Probleme, die das Projekt gefährden, aber es sind Aspekte, welche die Stimmung im Team beeinflussen und hin und wieder Unzufriedenheit und Stress erzeugen. Deswegen haben wir Anpassungen an unserem Prozess vorgenommen, die ich im Folgenden beschreibe.</p><h2>Das sind die Ergebnisse</h2><p>Bevor ich beschreibe, was wir genau geändert haben, hier erst einmal die nackten Zahlen, die wir nach 6 Sprints á 2 Wochen beobachten konnten (im Vergleich zu den letzten 14 Sprints vor der Umstellung):</p><table><tbody><tr><td><b>Metrik</b></td><td><b>Vorher</b></td><td><b>Nachher</b></td><td><b>Änderung</b></td></tr><tr><td>∅ Umgesetzte Storypoints im Sprint</td><td>26,8 SP</td><td>43 SP</td><td>+62%</td></tr><tr><td>∅ Cycle Time<br /> (Zeit bis zur Fertigstellung eines Tickets)</td><td>4t 8h</td><td>1t 8h</td><td>-325%</td></tr><tr><td>∅ Throughput<br /> (Anzahl der gelieferten Tickets pro Sprint)</td><td>15,6 Tickets</td><td>23,3 Tickets</td><td>+50%</td></tr></tbody></table><p>Also wenn diese Zahlen das PO-Herz nicht höher schlagen lassen 🙂</p><p>Neben diesen Zahlen hat sich aber auch aus Entwickler-Sicht eine entscheidende Sache geändert: Der Sprint verläuft viel entspannter als vorher. Das klingt im ersten Moment widersprüchlich, ist es am Ende aber nicht.</p><h2>Kanban to the Rescue</h2><p>Also was steckt hinter diesem Performance Boost? Red Bull?</p><p>Nein, es sind ein paar Elemente aus Kanban, die wir ohne Änderungen am bisherigen Scrum-Prozess hinzugefügt haben. Das ist auch ein wichtiger Punkt: Scrum selbst ist nicht das Problem und kann genau so bleiben, wie es war. Der wirkliche Knackpunkt ist der Fokus auf den Flow der Tickets von links nach rechts auf dem Ticket Board. Übrigens heißt die Zeit von <b>ToDo</b> bis <b>Done</b> im Kanban „<b>Cycle Time“</b>.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/95Gy4lm2QNW0PG4D4Q9x"><img width="1024" height="603" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/95Gy4lm2QNW0PG4D4Q9x" alt="Scrum Kanban Flow Cycle Time" /></a> </p><p>Unser Fokus lag also darauf, die Zeiten, die ein Ticket auf dem Board verbringt zu reduzieren. Das bringt kleine aber feine Änderungen im täglichen Doing mit sich. Man kümmert sich z.B. eher darum, einem Kollegen bei seinem Ticket zu helfen, als selbst ein neues Ticket anzufangen.</p><p>Um die Zeit überhaupt reduzieren zu können, muss man sich den typischen Lifecycle eines Tickets klarmachen. Es gibt Zeiten, an denen am Ticket gearbeitet wird und Zeiten, bei denen das Ticket rumliegt und auf den nächsten Schritt wartet:</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/OHLvaPemSveUsvTVP3JI"><img loading="lazy" width="1024" height="593" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/OHLvaPemSveUsvTVP3JI" alt="Arbeitszeit vs. Wartezeit" /></a> </p><p>In dieser Grafik sieht man ein Beispiel, in dem die Wartezeit satte 40 % ausmacht. Häufig ist das Verhältnis sogar noch größer und geht laut <a href="https://www.everydaykanban.com/2016/09/25/flow-efficiency/" target="_blank">Statistiken</a>  eher in Richtung 85 % Wartezeit, 15 % Arbeitszeit! Es macht also enorm Sinn, sich eher auf die <strong>Reduktion der Wartezeiten</strong> zu fokussieren als auf die der Arbeitszeit. Zudem braucht die Arbeit am Ticket soviel Zeit wie sie nunmal braucht. Das heißt, man kann den Entwicklungsprozess nicht wesentlich beschleunigen, ohne die Qualität der Lösung negativ zu beeinflussen.</p><p>Ein wichtiger Punkt, der die Wartezeiten negativ beeinflusst, ist die Anzahl der Tickets, die gleichzeitig in Bearbeitung sind. Je mehr Tickets gleichzeitig von einer Person bearbeitet werden, desto …</p><ul><li>öfter muss man den Kontext wechseln und sich neu reindenken (das kostet Zeit).</li><li>eher können Abhängigkeiten von aufeinanderfolgenden Tickets entstehen (manchmal ist es auch nur die CI-Pipeline, die hier ausbremst).</li><li>länger dauert es insgesamt, bis ein Ticket fertig wird.</li><li>eher sind die Kollegen nicht erreichbar, weil sie in einem komplett anderen Kontext arbeiten.</li></ul><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/TM3NXVnmQjecFfS29LuS"><img loading="lazy" width="1024" height="597" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/TM3NXVnmQjecFfS29LuS" alt="An einer Sache arbeiten" /></a> </p><p>Um diesem Problem zu begegnen, gibt es in Kanban das WIP Limit (Work in Progress Limit). Wir haben das so hoch gewählt, wie die Anzahl der Personen im Team ist (bei uns sind wir zwei Entwickler), sodass jeder eigentlich nur <b>1 Ticket gleichzeitig pro Spalte </b>auf dem Board bearbeiten darf.</p><p>Apropos Board … die nächste wesentliche Änderung waren die Spalten im Board.<br /> <strong>Vorher sah das Board so aus:</strong></p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/sExGfvVLQfWLeHj8in9M"><img loading="lazy" width="1024" height="436" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/sExGfvVLQfWLeHj8in9M" alt="Scrum Board" /></a> </p><p>Kompakt und übersichtlich würde man sagen. Allerdings ist diese kompakte Form ungeeignet, wenn man seinen Flow optimieren möchte, denn man sieht einfach zu wenig, wo die meiste Zeit verloren geht.</p><p><strong>Das neue Board sieht so aus:</strong></p><p><img loading="lazy" width="1024" height="352" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/T6kmlpaSSWAWTSH3WUSU" alt="Scrum Kanban Board" /> </p><p><strong>Hier sind folgende Änderungen wichtig:</strong></p><ul><li>Wenn ich fertig bin mit meiner Arbeit, schiebe ich das Ticket in eine „Done“-Spalte, sodass das System (bei uns JIRA) tracken kann, wie lange ein Ticket in dieser wartenden Position verharrt.</li><li>Mehr Spalten heißt hier mehr Transparenz. Ich kann nach ein paar Sprints genau sehen, wo die meiste Wartezeit entsteht und diese dann gezielt mit Maßnahmen angehen.</li><li>Jede Spalte hat ein WIP Limit. Somit wird verhindert, dass zu viele Tickets gleichzeitig bearbeitet werden.</li></ul><p>Die Spalten sind von Team zu Team natürlich unterschiedlich und sollten einfach immer genau den Prozess widerspiegeln, der auch tatsächlich gelebt wird. Das Kanban Board ist ein Instrument und kein Selbstzweck. Es dient dazu, Wartezeiten aufzudecken und so den Flow der Tickets zu fördern (= niedrige Cycle Time). Das heißt auch, dass wir in der Retro darauf schauen müssen, wo die meiste Zeit verbraucht wird.</p><h2>Was haben wir nicht geändert?</h2><p>Wie schon vorher erwähnt: Den Scrum-Prozess haben wir nicht angefasst. Oft hört man ja vom sog. „Scrumban“, bei dem man einzelne Elemente von Scrum und Kanban nimmt und daraus ein individuelles Format erzeugt. Dabei wird meistens das Arbeiten in festen Sprint-Zyklen mit vorher definierten Sprint-Umfängen zugunsten eines kontinuierlichen Ziehens von Tickets aus einem priorisierten Backlog ersetzt.</p><p>Wir hingegen machen nach wie vor alle Scrum-Events und wir schätzen weiterhin in Storypoints. Wir haben die Größe der Tickets und die Art der Schätzung nicht willentlich verändert (die genauen Zahlen sagen, wir schätzen die Tickets durchschnittlich um 7 % größer als vorher, also im Mittel 1,9 SP statt 1,7 SP). Es gibt bei uns sowohl 1er Stories als auch max. 8er Stories. Wir versuchen so gut es geht, die Tickets zu splitten, damit sie schneller bearbeitet werden können. Aber auch das haben wir vorher schon so gemacht.</p><h2>Wo müssen Entwickler umdenken?</h2><p>Der wohl wichtigste Erfolgsfaktor in unserem Team ist jedoch die Zusammenarbeit der Entwickler. Neben dem Daily schauen wir mehrmals am Tag, ob wir uns Hilfe von einem Kollegen holen können und machen sehr viel häufiger kurze Pair Programming Sessions. Das bringt den Vorteil, dass die Arbeitszeit am Ticket meist verkürzt wird, weil sowohl die Implementierung als auch das Review schneller gehen.</p><p>Sehr oft hab ich es bislang erlebt, dass Entwickler ein Ticket nach dem anderen implementieren und in die nächste Spalte schieben oder sich den halben Sprint lang an einem Ticket festbeißen und nicht zum Ende kommen. Beides ist der Killer für die Performance im Team, weil der Flow fehlt und Staus entstehen.</p><h2>Fazit</h2><p>Auf den Punkt gebracht, sind es nur wenige Änderungen gewesen, die wir gemacht haben: <b>Detailliertes Kanban Board</b> mit <b>WIP Limits</b> und mehr <b>Kollaboration</b> im Team sowie <b>Fokus auf Flow</b>. Aber die Auswirkungen haben uns sogar selbst überrascht.</p><p>Und was sich neben der reinen Performance noch viel besser anfühlt, ist die entspannte Arbeitsweise während des Sprints. Anstatt immer wieder etwas Neues anzufangen und „beschäftigt“ zu sein, machen wir mehr Pausen und warten z.B. auf Tickets bzw. helfen dem Kollegen, um die WIP Limits nicht zu überschreiten. Es klingt paradox, aber dieses langsame und fokussierte Arbeiten hat uns schneller gemacht.</p><p>Perspektivisch könnten wir sogar ohne Schätztermine auskommen, davon müssen wir nur noch den PO überzeugen 🙂 Denn statt der Storypoints kann der PO jetzt die Metriken Throughput und Cycle Time für den Forecast der Sprints nutzen. Somit sparen wir noch mehr Zeit beim Refinement bzw. der Sprintplanung.</p><p>Zum Abschluss noch ein lustiges und zugleich anschauliches Video, warum die Erhöhung der Auslastung von Personen das Gegenteil von Flow und Performance erzeugt: <a href="https://www.youtube.com/watch?v=CostXs2p6r0" target="_blank">https://www.youtube.com/watch?v=CostXs2p6r0</a> </p>

Performance-Boost im Scrum Team – Ein Erfahrungsbericht

<p>Immer mehr Webseiten werden heutzutage als Single Page Applications (SPA) umgesetzt. Ein Problem, das vielen Entwicklern dabei Kopfzerbrechen bereitet, ist die Optimierung der Page nach SEO-Gesichtspunkten (SEO = Search Engine Optimization). Was bei statischen Webseiten keine große Herausforderung ist, wird bei SPAs um einiges komplizierter. Fast der gesamte SEO-relevante Content einer Seite ist in einer oder mehreren JavaScript-Dateien gekapselt und damit nicht mehr so trivial von den Suchmaschinen-Crawlern auslesbar. Das Problem wurde in der Vergangenheit oft durch serverseitiges Rendering gelöst. Allerdings bedeutete dies auch viel Aufwand.</p><p>Ich werde in diesem Artikel beleuchten, welche Fähigkeiten die aktuellen Crawler besitzen und ob das serverseitige Rendering überhaupt noch notwendig ist.</p><h2>Was können die Crawler von heute?</h2><p>Suchmaschinen-Anbieter wissen natürlich um die Bedeutung von SPAs und die Wichtigkeit von JavaScript, welches Inhalte dynamisch im Browser rendert. Demzufolge sind die aktuellen Crawler auch fast alle in der Lage, den JavaScript-Code auszuführen und Inhalte so anzuzeigen, wie es der Browser macht. Selbst dynamische Inhalte, die z.B. über einen API-Request zeitverzögert nachgeladen werden, kann der Crawler erfassen. Für mehr Informationen dazu siehe: <a href="https://medium.freecodecamp.org/seo-vs-react-is-it-neccessary-to-render-react-pages-in-the-backend-74ce5015c0c9" target="_blank">„SEO vs. React: Web Crawlers are Smarter Than You Think“</a> .</p><p>Man kann das auch leicht für die eigene App ausprobieren, indem man die <a href="https://www.google.com/webmasters/tools/googlebot-fetch" target="_blank">Google Search Console</a>  nutzt. Mit dem Tool kann man eine beliebige URL seiner Page rendern und sieht dann in Form von zwei Screenshots, wie der Bot die Seite wahrnimmt und wie ein User die Seite sieht.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/m5bmdgSXQbKu7PinUWvm"><img width="700" height="405" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/m5bmdgSXQbKu7PinUWvm" alt="Search Console Ergebnis - SEO + SPA = serverseitiges Rendering" /></a> </p><p>Etwas Vorsicht ist geboten bei Googles <a href="https://search.google.com/structured-data/testing-tool/u/0/?hl=de" target="_blank">Testtool für strukturierte Daten</a> . Dieses rendert die SPA nicht wie der Google-Bot, weshalb man auch keine dynamisch generierten Meta-Tags oder Open-Graph-Tags in den Analyseergebnissen findet. Davon sollte man sich aber nicht beirren lassen.</p><p>Bisher sieht also alles gut aus. Warum denn nun noch serverseitiges Rendering?</p><h2>Leider steckt der Teufel im Detail</h2><p>In diesem <a href="https://www.onely.com/blog/javascript-seo-experiment/" target="_blank">aufschlussreichen SEO-Experiment</a>  wurden im Mai 2017 die verschiedenen SPA Frameworks getestet und die Fähigkeiten des Google-Bots analysiert. Das Ergebnis: Es gibt nach wie vor Probleme, z.B. hat das genutzte Framework einen Einfluss auf die SEO-Tauglichkeit der Seite. Angular schneidet am schlechtesten bei allen Tests ab, obwohl es von Google entwickelt wird. React und Vue.js werden momentan am besten unterstützt. Weiterhin macht es einen Unterschied, ob der JavaScript-Code in einer <em>bundle.js</em> zusammengefasst und extern referenziert wird oder komplett inline im HTML eingebunden ist. Inline-Skripte werden besser verarbeitet als extern referenzierte. Bei extern eingebundenen Skripten werden z.B. dynamisch generierte Links vom Google-Bot nicht erfasst.</p><p>In dem Artikel: <a href="https://www.seo-suedwest.de/2818-google-nicht-alle-dynamisch-gesetzten-meta-tags-erkannt.html" target="_blank">„Google: Nicht alle dynamisch gesetzten Meta-Tags werden erkannt“</a>  wird beschrieben, dass bei dynamisch generierten Meta-Tags das <code>"noindex, follow"</code>-Attribut nicht zuverlässig interpretiert wird. Somit tauchen dann Seiten im Google-Index auf, die man dort nicht sehen will.</p><p>Google weist <a href="https://developers.google.com/search/docs/guides/rendering" target="_blank">in seinen Developer Guides</a>  darauf hin, dass bestimmte Features aktuell nicht unterstützt werden, wie z.B. WebSockets, IndexedDB, WebSQL, ServiceWorkers etc. Webseiten werden vom Bot auf Basis der Chrome 41 Engine gerendert. Die aktuelle Version von Chrome ist 62 (Stand November 2017). Man muss also in jedem Fall beachten, dass ggf. nicht alle JavaScript-Features zuverlässig funktionieren und man mit Polyfills und Feature Detection für Abhilfe sorgen muss. Um herauszufinden, welche JavaScript-Features Chrome 41 unterstützt, ist <a href="https://caniuse.com/#compare=chrome+41" target="_blank">caniuse.com</a>  sehr hilfreich.</p><p>Und am Ende muss man natürlich auch berücksichtigen, dass Google mit seinem Bot technologischer Vorreiter ist und andere Suchmaschinen-Bots unter Umständen noch weniger Inhalte parsen können.</p><h2>Fazit</h2><p>Auch wenn die Bots heutzutage JavaScript rendern und die meisten Inhalte indiziert werden können, gibt es bei bestimmten Details noch Probleme. Um also bei einer SEO-kritischen Seite auf Nummer sicher zu gehen, ist das serverseitige Rendering nach wie vor die beste Alternative.</p><p>Wer wissen möchte, wie man das serverseitige Rendering (SSR) mit React umsetzt, kann dies in folgendem Artikel nachlesen: <a href="/wissens-hub/blog/tutorial-serverseitiges-rendering-mit-react-teil-1-einfuehrung">„Tutorial: Serverseitiges Rendering mit React“</a> . Darin baue ich eine einfache clientseitige App Schritt für Schritt in eine serverseitig gerenderte App um. Ich zeige, wie man den Redux-Store richtig auf dem Server initialisiert, React-Router so konfiguriert, dass es auch auf dem Server die richtige Seite rendert und wie man mit React-Helmet seine Meta-Tags ins statische HTML integriert.</p>

SEO + SPA = serverseitiges Rendering?

Gehirngerechte Trainings mit den 4Cs

Agile Basics: Kanban Boards richtig nutzen

<p>Let’s say we have a certified Amazon Alexa Skill that has an endpoint pointing to an AWS Lambda function. We want to update the Lambda function but the update contains breaking changes for the current live version of the Alexa Skill. It is necessary to update the Alexa Skill Model to work with the new Lambda function. As each change on the Alexa Skill Model needs to be certified by the Alexa Team – and this may take several days – we have a time gap where our existing live Skill would break if we deploy the new version of our Lambda function. How do we deploy the new Lambda code without risking that our skill is broken for the time of certification? In this tutorial I’m going to use Lambda Versions and Aliases to set up a non-breaking Lambda deployment strategy.</p><h2>Using Versions for Lambda Deployments</h2><p>Whenever new code is deployed to a Lambda function, the current one will be replaced. The only way to avoid this is using versions. When creating a version for a Lambda the current code and all configurations are frozen and cannot be modified any more. This is exactly what we need for our Alexa Skill endpoints.</p><p>To create a version go to your Lambda function in the AWS console and click on <em>“Actions -> Publish new version”</em>.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/IEbtODXtRFSgySAj3Z12"><img width="700" height="201" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/IEbtODXtRFSgySAj3Z12" alt="Publish new Lambda Version" /></a> </p><p>Each version gets a unique id starting from 1. When you push new code to the Lambda function it will be mapped to the predefined version $LATEST by default.</p><p>Note: You need to set the Alexa Skills Kit trigger again for the each created Lambda version.</p><p>You can reference the Lambda function with version 1 by adding the version to the Lambda ARN at the end:</p><p><code>arn:aws:lambda:eu-west-1:ACCOUNT_ID:function:FUNCTION_NAME:1</code></p><p>You can use this ARN in your Alexa Skill endpoint and you will never risk breaking your Lambda when pushing new changes.</p><p>You can find more information about versions in the AWS documentation: <a href="https://docs.aws.amazon.com/lambda/latest/dg/versioning-aliases.html" target="_blank">https://docs.aws.amazon.com/lambda/latest/dg/versioning-aliases.html</a> </p><h2>Using Aliases for flexibility</h2><p>But wait, what if I want to fix a small bug in my Lambda and don’t want to recertify my Alexa Skill again? Remember, even changing only the endpoint of your Alexa Skill would mean a new certification roundtrip for the Skill as the endpoint is part of the Alexa Skill Model. To solve that problem the Lambda Aliases are a perfect solution. An Alias gives you the opportunity to point to a specific version of a Lambda and change the reference at any time.</p><p>To create an Alias go to <em>“Actions -> Create alias”</em> in your Lambda function:</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Um88F1EPSXK4V2WVgV4q"><img loading="lazy" width="700" height="173" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Um88F1EPSXK4V2WVgV4q" alt="Create new Lambda Alias" /></a> </p><p>In the following dialog specify the name of the Alias, i.e. PROD1 and which version the alias should reference.</p><p>Note: After creating the Alias you need to set the Alexa Skills Kit trigger for that Alias again. Otherwise the Alias cannot be used for the Alexa Skill endpoint.</p><p>The Alias can be referenced by adding the Alias name at the end of the Lambda ARN:</p><p><code>arn:aws:lambda:eu-west-1:ACCOUNT_ID:function:FUNCTION_NAME:PROD1</code></p><p>Create another Alias with the name PROD2 and point it to the version $LATEST. This is necessary if you want to certify a new Alexa Skill version. Whenever you are ready to certify a new Skill version you will create a new Lambda version and change the reference for the Alias PROD2 to this version and use the Alias PROD2 for the endpoint of your skill to be certified.</p><p>The Alias can be edited in the dropdown <em>“Qualifiers -> Aliases”</em>:</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/C8h7qUgcQsSRzWo3pknO"><img loading="lazy" width="462" height="403" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/C8h7qUgcQsSRzWo3pknO" alt="Edit Lambda Alias" /></a> </p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/AOsDFucaQsqGe8y8JklK"><img loading="lazy" width="700" height="353" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/AOsDFucaQsqGe8y8JklK" alt="Change Lambda Alias Version" /></a> </p><p>You need to rotate the aliases PROD1 and PROD2 for each certification process.</p><h2>Summary</h2><p>By using Lambda versions you can easily deploy new code to your Lambda function without breaking the current live Alexa Skill. You can even deploy bug fixes without the need to recertify the Skill when using Lambda Aliases. Here is an overview of the whole process:</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/lfS9h4uQhqImd0GSQkOA"><img loading="lazy" width="700" height="421" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/lfS9h4uQhqImd0GSQkOA" alt="Lambda Alias Versions Overview Architecture" /></a> </p><p>By the way, you can use this strategy together with an API Gateway, too. There need to be two API Gateway endpoints that are pointing to the Lambda Aliases PROD1 and PROD2.</p><p>If you have any questions or new ideas, feel free to use the comment section below. Check out my last blog post where I explained <a href="/wissens-hub/blog/eine-pipeline-fuer-lambda-mit-aws-codestar-erstellen">how to quickly setup a Alexa Skill using AWS Codestar </a></p>

Non-Breaking Lambda Deployments for Alexa Skills using Versions and Aliases

Agile Coach | People Lead

IT Consultant (Product, UX)

Mit Hilfe von Exceptions robuste Software für stabilen Betrieb schreiben

<h1>Test the basics</h1><p>There are multiple reasons for tests. Two major reasons are:</p><ol><li>To prove that a change of the software adds the desired functionality.</li><li>To ensure that a change does not break the existing functionality (regression testing).</li></ol><p>It is possible in these two cases that the tests are executed by hand, in an automatic way or with a mix of both. But automated tests provide a big benefit in terms of effort for regression tests.</p><p>In addition to these major reasons there is a third one, which is especially important for agile development. To fully understand this additional reason I have to digress first.<br /> <span></span></p><h1>No perfect design</h1><p>Software is malleable (meaning it is easy to change its form). This has advantages and disadvantages. One disadvantage is that each change can make the software worse (e.g. add a bug, remove some existing functionality unintentionally, …). The advantage is that the internal design can be changed. In particular, it means that the internal design can be improved. Why is this important? Because it is not possible to design the software in a perfect way at the start. Like the Spiral model the agile development model is an iterative model. This means that new requirements are added step by step and so almost ensuring that the initial design will not be the best design once the full list of requirements is known and implemented. Another reason for the inability to create a perfect design front-up is that during the implementation developers get new insights into the domain and this usually also means a design change. So it is an ongoing task to improve the design of the software to make it reflect the domain in a good way, to be easy to understand and to extend. You ask but how is this related to tests?</p><h1>Full freedom?</h1><p>One can view a program under development as the space, which the developer(s) can form between two fixed ends. On the bottom end are the things the developer and so the new program depend on. These might be the JDK, 3rd-party libraries, a data base, the operation system or the file system. This bottom is fixed because the developer can not change these interfaces (easily). On the top end are the requirements. They are fixed, too, and are in the best case encoded in some automatic acceptance tests. One can describe the primary task of the developer to fill this space with some code to use the existing components (e.g. JDK) to provide the requested functionality. In this primary task the developer has full freedom. She can create a huge god class. Or, even more drastic, she can write an i386 simulator in Java and write the business code in assembler. As long as the requirements are met the customer (usually) doesn’t care.</p><h1>Bringing all together</h1><p>But there is another aspect in the job of the developer (which distinguish a coder from a software engineer): to provide a software with a good internal quality (design, code layout, names, OO design, loose coupling,…) to make the software easy to understand and maintain. To achieve and keep such a good internal quality the internal quality of the software needs to be constantly monitored and improved with smaller or larger re-designs.</p><p>Because such re-designs are required by new requirements and insights, AND such re-designs require code changes, AND because software is malleable, such changes can break existing functionality. So without tests it is time-consuming to improve the internal quality because extensive manual re-tests are required. If there are no or only limited automatic tests, usually the re-design is not executed and the internal quality of the software will degenerate over time with the known effects of increased cost for maintenance and reduced adaptability regarding new features.</p><p>To sum up, automatic tests (whether they are written before or after the implementation) are indispensably for achieving and maintaining a high internal software quality when an agile development model is used.</p>

Why agile development needs automatic tests

Using Exceptions to Write Robust Software for Stable Production

<p><span>In modern stacks, the application often consists of multiple microservices. For one of our projects we had to manage about 20 of these. Not only because of the <a href="https://www.codecentric.de/2017/02/15/codecentric-wird-offizieller-standard-partner-von-amazon-web-services-aws/">partnership</a>  between codecentric and AWS we decided to use the AWS platform. That also led to the decision to use infrastructural components provided by AWS like <a href="https://aws.amazon.com/codecommit/" target="_blank">CodeCommit</a>  and <a href="https://aws.amazon.com/codepipeline/" target="_blank">CodePipeline</a> . In this blog post we want to speak about our experience with CodePipeline.</span></p><p><span>Unfortunately, the web interface of CodePipeline is rather basic. It is difficult to get an overview which pipelines are running, building or failing when you have a pipeline for each microservice. Failing? Yes, that happens! And that is exactly what we want to see immediately. To summarize: We found the existing web interface </span><span>insufficient</span><span> to help us in our daily work and looked at alternatives. </span></p><p><span>Before we dive into the graphical user interface (UI) we prefer, we want to mention alternatives to visualize pipeline issues. Sometimes you may prefer getting an email or notification on <a href="https://slack.com/" target="_blank">Slack</a>  when something goes wrong. This kind of feedback can be implemented by using the <a href="http://docs.aws.amazon.com/codepipeline/latest/APIReference/" target="_blank">CodePipeline API</a> .</span></p><p><span>Why do we prefer a graphical UI to visualize our set of pipelines? One reason is that human beings can easily work with graphical representations and their changes. The latter one is the reason that makes GUIs so intuitive. The following example comes from our daily project work. Please note that some information has been blurred to protect the privacy of the customer. Imagine a screen like this one:</span></p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/LRldmwJhR6Kynh3VoZZU"><img width="2798" height="1678" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/LRldmwJhR6Kynh3VoZZU" alt /></a> </p><p><span>Do you see anything special? No? You’re right! This screen shows a pipeline system without any problems. It shows all implemented pipelines with their build steps, the last date of being built and their status in colours. Green means that everything is okay. Just imagine this on a big screen: a short glance tells you “Everything is green, no problems.”. Great!</span></p><p><span>Now check this screen:   </span></p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/I4L6DxemRaaWiZSsMPJr"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/I4L6DxemRaaWiZSsMPJr" alt width="2808" height="1580" /></a> </p><p><span>Ah, there is something different: First of all, there is this red bar in the middle. This project needs your attention. The build step failed. </span></p><p><span>And of course you also noticed the blue bar on the bottom. Well, it’s not that eye-catching. That’s by intention: there is a build in progress. The takeaways are: Everything is fine, the pipelines are working and something is currently working there.</span></p><p><span>Summary: you can see this information with one glance. Just react on red bars and the blue bars show that the whole system is alive.</span></p><p><span>Of course, we don’t want to just show you this tool in a blog post. You can also use it. The application is available on <a href="https://github.com/codecentric/aws-codepipelines-dashboard" target="_blank">github</a> .</span></p><p>We also provide a docker container for this application on <a href="https://hub.docker.com/r/codecentric/aws-codepipelines-dashboard/" target="_blank">docker-hub</a> .  Please read the instructions in our README file for further information.</p>

AWS CodePipeline Dashboard

<div><div><p>In the <a href="#techStuff">second half</a>  I show how you can test your Logstash configuration. However first I want to show why automatic tests for configuration files are important. Feel free to <a href="#techStuff">skip</a>  this part if you already know this.</p><h1>Configuration is source code and should be tested</h1><p>Writing automatic tests for source code is one of the core activities of a software developer. One reason is that such automatic tests allow the developer to express the expected semantic of the code under test. Another reason is that such tests will make sure that future code changes will not break existing behavior. While there is some discussion if tests should be written before or after the code it is generally accepted that source code should be tested in an automatic way.</p><p>The above statement is true for cases which are obviously source code. There are however other cases. Besides source code are pure data files like <code>/etc/passwd</code> which can be judged “correct” or “incorrect” by a human just by looking at it. But there are also files which are processed by a program and it is harder for a human to decide if the file content in question exhibits the desired semantics. One large group of such processed files are configuration files. The expressive power does of course varies between simple (like a crontab) and complex which may have variables and control flow (i.e. sendmail, emacs, puppet, mule). In general the expressive power of the config file depends on the configuration demand of the application. More and complex configuration options yield a more complex config file.</p><p>Should configuration files be tested in an automatic way? Yes for the same reasons as other source code: automatic tests verify that the first version has the expected behavior and that later changes do not break any of this behavior.</p><p>Are configuration files tested as often as “classical” source code? The answer is sadly: no, not as frequent. One reason is that the changes occur less frequent. While one can image that “classical” code changes all the time the situation of configuration files may be perceived differently: the config has to be only checked if there are some new requirements (rarely) or after some update (application or OS) which also occur not this often. Because such changes are infrequent a manual approach looks plausible to also avoid the setup costs of automatic tests. However such statements about the frequency are loosing their validity these days:</p><ul><li>Because of horizontal scaling (scale out) multiple instances in a very similar configuration are required. To meet this goal provisioning tools like puppet and ansible have been created. With these tools however it is easy to roll out changes and therefore usually the change frequency increases.</li><li>For common tasks the problem domain is better understood these days. Therefore COTS and open source software can be used and customized using configuration. This leads to larger and more complex configurations. In such cases software engineering procedures like refactoring become important. But the application of such procedures is dangerous without tests in general and slow and costly if such changes must be tested manually.</li></ul><p><a> </a> </p><h1>Enter Logstash</h1><p>There is Logstash and Logstash has a configuration file (or directory). How can these be tested? An internet search shows that Logstash <a href="https://www.elastic.co/blog/logstash-functionality-through-testing">supports</a>  <a href="http://rspec.info">RSpec</a> . One can embed the config in the RSpec file (<a href="http://svops.com/blog/testing-your-logstash-configuration/">two</a>  <a href="http://koendc.github.io/2013/10/11/logstash-test-configuration.html">projects</a> ) or load the config files during test execution time (one project). It is also possible to run the test inside docker (<a href="https://github.com/tcnksm/rspec-logstash-filter">another</a>  <a href="https://github.com/gaspaio/logstash-tester">two</a>  projects and a <a href="https://github.com/magnusbaeck/logstash-filter-verifier">third</a>  one which uses Go in addition).</p><p>Being not a ruby person I have some problems with the RSpec. Especially with the escaping. In addition there are quite a few statements required to construct a test case. Additionally there is also the point of dependencies. RSpec requires rake. And some solutions as mentioned above need Docker and one even Go.</p><p>What properties does an ideal solution have?</p><ul><li>the format of the test cases is easy to understand and hard to make a mistake</li><li>the test execution is not complex to avoid problems caused by the test runner</li><li>the test execution is very similar to the real non-test execution of Logstash</li><li>no extra dependencies (e.g. there is no native support for docker on Mac)</li></ul><p>I have sketched down a <a href="https://github.com/rfalke/testing-logstash-configuration">variant</a>  which IMHO comes close to such an ideal solution. Key points are:</p><ul><li>the Logstash config is adjusted in a minimal and controlled way</li><li>Logstash is run like in production</li><li>test cases sources and expected output are JSON files of the events you drop in a directory</li><li>the test runner compares the complete output with the expected output (after both formatting them)</li><li>only depends on Logstash, bash and vanilla python installation</li></ul><h2>Usage</h2><ol><li>clone the repo</li><li>run the demo: <code>./run_demo.sh</code></li><li>change the Logstash config in <code>config/</code></li><li>add new test cases in <code>test/test_cases/</code></li><li>rerun the test: <code>cd test; ./run_tests.sh</code></li></ol><p>There are two points worth mentioning:</p><ol><li>Where are the input JSON files coming from? One approach is to disable any filter configuration in Logstash, restart Logstash and copy the JSON from Kibana. This is advised for the first contact with a new log source. Afterwards it is possible to create new test cases using copy, paste and modify.</li><li>The code in the repository is not a final framework or application but more like a sketch. Depending on how you distribute your Logstash configuration/deploy the Logstash server(s) more adjustments are needed. There are too many ways how deployment is done today to try to cover them. There are at least:<ul><li>creating a package of the software and install it on the target server</li><li>use a custom script to copy the config files to the target and restart Logstash</li><li>use tools like puppet or chef to perform the copy and restart tasks</li><li>create a virtual container (like a docker image) and deploy it on a host</li></ul><p>In addition there multiple ways to trigger the deployment:</p><ul><li>manually</li><li>something like<a href="https://github.com/openshift/source-to-image"> source to image</a>  from OpenShift</li><li>a CI server</li></ul><p>In this regard some manual adjustment are required to fit your specific case.</p></li></ol><h1>Test Test Test</h1><p>Configuration files should be tested to make sure that the behavior is the expected one and that changes to the application or configuration will not break the behavior. Also as shown above the Logstash configuration can be tested easily. Or in other words: there is nothing preventing you from just doing it.</p></div></div>

Automatic Testing of Logstash Configuration

<p>When a new project is set up in the cloud these days, this usually means that AWS is used, that the backend is split into multiple services (e.g. microservices), the frontend and backend communicate using REST and multiple managed AWS services are used. Such a setup allows to easily leverage many services AWS provides and reduces the effort and time to implement the desired functionality. To fully use this potential, the development process has to be reviewed and adjusted.</p><p>In the old days, a single monolith was developed locally on the developer computer. Dependencies like database, message queue or SMTP server were mostly installed locally or, if this was not possible, mocked or a central installation was used. In most cases the developer could be certain that if the application runs on his computer it will also run on other environments (e.g. test stage or production environment). This approach is not feasible with how applications are developed these days. The differences stem from multiple sources:</p><ul><li><b>Splitting the application into multiple parts</b> (e.g. microservices) creates a fully distributed application in which the glue which connects the parts is becoming more important. One side effect is, for example, that the glue also has to be tested. Another consequence of a distributed application is that the application becomes unwieldy in the way that multiple programs have to be running to experience the full application. The development team also has to think about distributed failures and aspects like <a href="https://www.codecentric.de/publikation/resilient-software-design-robuste-software-entwickeln/">resilience</a>  are getting important.</li><li><b>Using cloud services</b> introduces new APIs and a new way of thinking. So, for example, the database is not just there, but you also have to think about request capacities for your database access.</li><li><b>Using AWS</b> especially adds the burden of not being able to install the cloud solution on your local computer(s). Other solutions like <a href="https://kubernetes.io">Kubernetes</a>  allow you to do this. While not a real limitation these days, you lose the ability to develop offline. More important is that the development becomes more expensive since these AWS services also have to be paid for the developers, and this sometimes means that the cost will scale with the number of developers.</li></ul><p>DevOps can solve the first two issues, but the last one could be described as vendor lock-in.</p><p>Let’s take a look at some scenarios and assess them. In the following, “stage” means a self-contained version of the software under development. This could be (for AWS): a set of EC2 instances, an ECS cluster, a unique URL, a set of DynamoDB tables identified by a prefix, a set of CodePipelines and other AWS services.</p><h2>Use a shared dev stage</h2><p>In a very easy setup, there is one stage for development. If you want to do a change, you commit and push your change, wait for the build and deployment and then test your change. While it’s easy to get this setup running, it has certain drawbacks:</p><ul><li><span>The long turnaround times since you have to wait for the build and deployment. This usually takes a few minutes.</span></li><li><span>Debugging your services is cumbersome or impossible.</span></li><li><span>Since AWS CodePipelines do not support branches, the commit has to be performed in the master. This may be O.K. if the team develops in the master using feature toggles. This, however, prevents other teams to use feature branches and perform code reviews using pull requests.</span></li><li><span>Potential problems because of conflicts between developers which use the same code areas and the same stage.</span></li></ul><h2>Use personalized stages</h2><p><span>One idea to reduce the drawbacks it to create a stage for each developer. This also means the code pipelines have to be duplicated and adjusted to listen to developer-specific branch names. This allows us to review the code with pull requests in addition to developing independently. This is especially important if there are incompatible code changes in the backend services or changes in the state itself. However, there are some existing drawbacks and a new one:</span></p><ul><li><span>Long turnaround times</span></li><li><span>Debugging is hard or impossible</span></li><li><span>Extra costs for each stage</span></li></ul><h2>Run application services locally</h2><p><span>To improve the turnaround times and allow for debuging of the application services easily, it is possible to run the application services locally. This may mean that only the one service under development is started or that all services are running locally. While it’s easy to run the application services locally, it’s not that easy or even impossible to get the AWS services (i.e. SQS, S3) running on the local machine. So the AWS services of one stage have to be used. While this setup can be combined with one shared dev stage or with the personalized stages mentioned above, the shared dev stage has two disadvantages:</span></p><ul><li><span>If there are structural changes to the AWS services or the data stored / transferred extra effort is required to ensure that other developers using the same stage are unaffected. It may not be worth the effort and a personalized stage is the better solution.</span></li><li><span>There may be too little control over the execution: if during the test one application service adds a message to a queue (e.g. SQS) and another locally running application service is the consumer of this queue, it is not guaranteed that the locally running consumer will get this message.</span></li></ul><p><span>Another aspect is how these application services are reached:</span></p><ul><li><span>Accessed by the frontend or other application services: This is usually through a load balancer. In such a case a locally running load balancer replacement is required. We have successfully used </span><a href="https://nginx.org/en/"><span>nginx</span></a> <span> for this with a script which converts AWS load balancer rules into a nginx config file.</span></li><li><span>Activated by AWS services: An example here is SQS consumption. This is a problem with a shared stage but works for personalized stages.</span></li></ul><p><span>In general this approach is possible and is recommended if the conditions are right (low frequency of structure changes, either no AWS service activation or personalized stages are used).</span></p><h2>Running as much as possible local</h2><p>It is possible to run more, in addition to the load balancer, AWS services locally. This allows to further reduce the dependency for AWS services during development and reduce the costs. Besides DynamoDB which is <a href="http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBLocal.html"><span>available for local installation</span></a> <span> the other AWS services are not available for local installation. One can view a replacement software as locally running AWS service or one can also see it as a mock for the real AWS service. This also depends on how sophisticated the service implementation has to be to successfully run the application on the local computer. In general it also means that the fact that the application works locally doesn’t mean necessarily that it also works on a full AWS stage.</span></p><p><span>There are replacements for multiple AWS services:</span></p><ul><li><a href="https://github.com/spulec/moto"><span>moto</span></a> <span>: Originally a mocking library but also allows to start as a separate server.</span></li><li><a href="https://github.com/localstack/localstack"><span>localstack</span></a> <span>: “A fully functional local AWS cloud stack. Develop and test your cloud apps offline!”</span></li><li><a href="https://github.com/eucalyptus"><span>Eucalyptus</span></a> <span> (</span><span>doc</span><span>): complete private cloud implementation which claims to be API compatible with AWS.</span></li></ul><p><span>Out of these three Eucalyptus looks not active maintained. It also looks like the owner of the backing company changed recently. LocalStack uses moto but aims to provide a more complete solution. There is also the beginning of a commercial company backing LocalStack.</span></p><p><span>For specific services (</span><a href="https://medium.com/@takezoe/how-to-develop-aws-based-application-in-the-local-environment-3e36eb705adf"><span>an older list</span></a> <span>):</span></p><ul><li><span>For Kines</span><span>is: </span><ul><li><a href="https://github.com/mhart/kinesalite"><span>kinesalite</span></a> <span>: “An implementation of Amazon’s Kinesis built on LevelDB”</span></li></ul></li><li><span>For S3:</span><ul><li><a href="https://www.minio.io"><span>minio</span></a> <span>: “Minio is an open source object storage server with Amazon S3 compatible API. “ It supports multiple underlying storage providers.</span></li><li><a href="http://docs.ceph.com/docs/master/"><span>ceph</span></a> <span>: “Ceph is a unified, distributed storage system designed for excellent performance, reliability and scalability.” It also offers an S3 interface.</span></li><li><a href="https://github.com/jubos/fake-s3"><span>Fake S3</span></a> <span>: “A lightweight server clone of Amazon S3 that simulates most of the commands supported by S3 with minimal dependencies”</span></li></ul></li><li><span>SQS:</span><ul><li><a href="https://github.com/adamw/elasticmq"><span>elasticmq</span></a> <span>: “Message queueing system with an actor-based Scala and Amazon SQS-compatible interfaces”</span></li><li><a href="https://github.com/p4tin/goaws"><span>goaws</span></a> <span>: “AWS (SQS/SNS) Clone for Development testing”</span></li></ul></li><li><span>Lambda and API gateway:</span><ul><li><a href="https://github.com/dherault/serverless-offline"><span>serverless-offline</span></a> <span>: “Emulate AWS λ and API Gateway locally when developing your Serverless project”</span></li><li><span>emulambda</span><span>: “Python emulator for AWS Lambda”</span></li></ul></li></ul><h2>Conclusion</h2><p><span>There are surprisingly few experience reports about local AWS development. LocalStack, on the other hand, was developed by </span><a href="https://atlassian.com"><span>Atlassian</span></a> <span> and while there is </span><a href="https://adtmag.com/articles/2017/03/27/aws-localstack.aspx"><span>no official press release</span></a> <span> it is reasonable to assume that they felt a problem and developed a solution for it.</span></p><p><span>If money is not a concern, the recommendation is to provide a personalized stage for each developer and run the application services locally. In such a case a stripped down stage without the active application services is enough.</span></p><p><span>If the number of developers is larger or a stage consists of many costly elements, the recommendation is to try to use replacements which run locally, for example LocalStack. If there is a setup which avoids AWS services, you may also want to consider using this setup in CI/CD. Still plan for the case that the real AWS services may behave differently.</span></p>

How development for AWS changes the local setup

A/B Testing: An introduction

A/B Testing: Tool support and testing GrowthBook

Senior IT consultant

Senior IT Consultant / Operations Engineer

<p>In der Software-Entwicklung sind Atlassian Produkte wie JIRA und Confluence heute weit verbreitet. Aber auch in anderen Bereichen werden diese Tools immer häufiger eingesetzt. Atlassian bietet seine Anwendungen mittlerweile auch als Cloud Produkte (SaaS) an, welche von Atlassian gehostet werden. Für den Anwender ist dieser Ansatz sehr einfach, er kann die Anwendungen nutzen, muss sich aber nicht um Installation und Betrieb kümmern.</p><p>Allerdings sind die vielen bereits vorhandenen Add-ons für die Server Variante nicht in den Cloud Anwendungen verfügbar *1. Mit Connect liefert Atlassian daher ein eigenes Framework zur Erweiterung der Cloud Anwendungen mittels Add-ons. Unterstützt werden aktuell JIRA Cloud, Confluence Cloud, HipChat und Bitbucket Cloud.</p><p><span></span></p><h3>Add-ons mit Connect</h3><p>Die <a href="/wissens-hub/blog/jira-plugins-addons-erweitern-vom-hacker-zum-entwickler" target="_blank">bisherigen Server Add-ons</a>  sind in Java implementierte OSGi Bundles, welche direkt in die Anwendung installiert werden. Diese Art der Installation ist in den Cloud Anwendungen nun nicht möglich. Stattdessen sind Connect Add-ons eigenständige Webanwendungen. Sie kommunizieren mit der Anwendung (z.B. JIRA) über REST Schnittstellen und können Inhalte liefern, welche in die Anwendungsoberfläche eingebunden werden.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/d7djI96TRCPAjJTPi4l3"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/d7djI96TRCPAjJTPi4l3" alt="AtlassianConnectDiagram" width="650" height="600" /></a> </p><p>In der Grafik (Quelle: <a href="https://developer.atlassian.com/docs/" target="_blank">Atlassian</a> ) wird das Kommunikationsschema sehr gut verdeutlicht.</p><p>Die Registrierung der verschiedenen Funktionen des Add-ons geschieht mittels eines Descriptors, welcher diese an bestimmten Stellen der Anwendung anmeldet. So gibt es die Möglichkeit, dass das Add-on Elemente zu der Oberfläche hinzufügt. Dazu wird eine URL zum Add-on hinterlegt, zusammen mit der Information an welcher Stelle der Inhalt eingebunden werden soll. JIRA ruft dann die URL auf und bindet das zurückgelieferte HTML mit Hilfe eines iframes in die Seite ein. Außerdem können auch Funktionen ohne grafische Oberfläche angemeldet werden. So kann das Add-on auf verschiedenste Ereignisse (z.B. Ändern eines Vorganges) reagieren oder Post Functions zum Workflow beisteuern. Auch in diesem Fall wird im Descriptor eine URL (webhook) angegeben, welche die aufzurufende Funktion definiert. Grundsätzlich kann das Add-on per REST-API Funktionen in der Anwendung aufrufen und damit z.B. weitere Daten erfragen aber auch Änderungen vornehmen.</p><p>Da das Add-on eine eigenständige Webanwendung ist, welche über REST Schnittstellen aufgerufen wird, ist man nicht mehr an die Technologien der eigentlichen Anwendung gebunden. Stattdessen können Programmiersprachen, Frameworks etc. frei gewählt werden. Atlassian und die Community bieten auch Bibliotheken und Tools für verschiedene Sprachen und Technologien an, um die Entwicklung weiter zu vereinfachen und grundlegende Aufgaben abzunehmen. Auch der aktuelle Trend zu Microservices hat neue Bibliotheken und Tools hervorgebracht, welche dieses Modell hervorragend unterstützen.</p><p>Der Add-on Anbieter betreibt und administriert bei dieser Variante aber auch die Anwendung, das heißt, er hat deutlich mehr Aufgaben als die reine Entwicklung. Er muss sich zusätzlich auch um Themen wie Hosting und Verfügbarkeit kümmern. Dafür hat er den Vorteil der größeren Kontrolle über die Anwendung. So können beispielsweise Updates einfach durchgeführt werden und gelten automatisch für alle Kunden. Kein Kunde muss mehr manuell die neue Version installieren, wie es bei Server Add-ons der Fall ist.</p><p>Im Gegenzug bedeutet dies aber auch, dass der Kunde weniger Kontrolle hat und dem Anbieter noch mehr Vertrauen entgegenbringen muss. Stellt dieser nicht den durchgehenden Betrieb sicher oder führt inkompatible Aktualisierungen durch, dann kann der Kunde das Add-on nicht verlässlich nutzen.</p><p>Einschränkungen gibt es beim Funktionsumfang der Connect Add-ons im Vergleich zu den bisherigen Add-Ons. Da diese nicht so tief in die  Anwendung integriert sind wie die direkt installierte Variante, können sie auch nicht an so vielen Stellen eingreifen. So können beispielsweise nur Workflow Post Functions erstellt werden, aber keine Workflow Validatoren. Auch Internationalisierung (i18n) wird noch nicht unterstützt. Während einige Funktionen vorgesehen sind und irgendwann eventuell unterstützt werden, ist dies bei anderen nicht zu erwarten. So ist es kaum vorstellbar, dass ein Add-on mit eigenem HTTP-Filter über Connect umgesetzt werden kann.</p><h3>Installation</h3><p>Die Installation erfolgt wie gewohnt über den Marketplace. Die Add-ons können sowohl kostenpflichtig als auch kostenfrei angeboten werden. Auch ein privates Listing ist möglich, sodass das Add-on nur innerhalb der eigenen Organisation verfügbar ist. Die Bezahlung kostenpflichtiger Add-ons ist genau wie bei Server Add-ons sowohl über Atlassian als auch über den Anbieter selbst möglich.</p><h3>Fazit</h3><p>Mit Connect bietet Atlassian grundsätzlich eine gute Möglichkeit zur Erweiterung der angebotenen Anwendungen.</p><p>Für Add-on Entwickler (im Sinne von Programmierern) gibt es eine deutlich größere Flexibilität in Bezug auf den Technologiestack, was auch den potentiellen Entwicklerkreis stark erweitert. Dafür ist das Framework nicht so mächtig und bietet eine weniger tiefe Integration.  Für Add-on Anbieter im Allgemeinen steigt der Aufwand durch neue Herausforderungen wie den Betrieb der Anwendung.</p><p>Atlassian hat <a href="https://developer.atlassian.com/docs/" target="_blank">angekündigt</a> , dass Connect nicht für JIRA Server und Confluence Server verfügbar sein wird. Das bedeutet aber auch doppelten Pflegeaufwand für Add-ons, welche auf Server und Cloud verfügbar sein sollen. Außerdem kann es für eine Zersplitterung der Community sorgen, mit Auswirkungen auf Dokumentation, Tutorials, Hilfeseiten usw.</p><p>Für Nutzer ist der Unterschied zu den Server Anwendungen eher gering. Die Add-ons erreichen noch nicht den kompletten Funktionsumfang und es sind nicht alle Erweiterungen verfügbar, aber die Entwicklung in diese Richtung geht voran. Das größte Risiko besteht darin, dass der Anbieter sein Add-on einfach abschalten könnte und es plötzlich nicht mehr verfügbar ist. Atlassian selbst gibt auch <a href="https://de.atlassian.com/licensing/marketplace#generalmarketplacequestions-6" target="_blank">Hinweise</a>  zur Auswahl vertrauenswürdiger Add-ons.</p><p>Im nächsten Artikel werden wir untersuchen, wie es um die <a href="/wissens-hub/blog/atlassian-connect-die-sicherheit-von-add-ons">Sicherheit von Connect Add-ons</a>  bestellt ist.</p><p>Wie sieht es bei Ihnen aus? Kommt die Cloud Variante für Ihr Unternehmen in Frage? Schreiben Sie gerne in die Kommentare, ob Sie bereits gute oder schlechte Erfahrungen mit Connect Add-ons gesammelt haben.</p><p>*1 Einzelne Server Add-ons werden in Cloud Instanzen vorinstalliert, aber das ist ein Sonderfall, auf den man nicht spekulieren sollte. Dies ist wohl eher als temporäre Lösung zu betrachten bis Connect diese Funktionen abbilden kann.</p>

Einführung in Atlassian Connect

<p>In der <a href="/wissens-hub/blog/einfuehrung-atlassian-connect">Einführung in Atlassian Connect</a>  haben wir gesehen, dass Add-ons eigene Anwendungen sind, die von verschiedenen Anbietern betrieben werden und über das Internet mit der Atlassian-Anwendung kommunizieren. Besonders im Unternehmenskontext stellt sich die Frage nach der Sicherheit und Vertraulichkeit der Daten. Diese Aspekte wollen wir in diesem Artikel genauer beleuchten.</p><p><span></span></p><p><span>Wir benutzen JIRA als Beispiel, die Überlegungen treffen aber auf alle Connect-Anwendungen (z.B. Confluence, HipChat, Bitbucket) zu.</span></p><h2><span>Der Überblick</span></h2><p><span>Wir betrachten im weiteren Verlauf vier verschiedene Bereiche, in denen der Sicherheitsaspekt eine Rolle spielt. Einen Überblick gibt das folgende Bild:</span></p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/hv50r3KSTMC4uLs5elqd"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/hv50r3KSTMC4uLs5elqd" alt="blog_atlassian_connect_security_groß" /></a> </p><p><span>Insbesondere wollen wir im Zusammenhang mit Sicherheit die folgenden Punkte genauer beleuchten:</span></p><ol><li><span>die Kommunikation zwischen Atlassian-Anwendungen und Add-ons</span></li><li><span>das Berechtigungskonzept der Atlassian-Plattform</span></li><li><span>die Anforderungen an das Connect Add-on</span></li><li><span>Schutz privater Add-ons</span></li></ol><h2><span>Kommunikation zwischen den beiden Anwendungen</span></h2><p>Wie bereits beschrieben, interagieren die Anwendungen über öffentliche Netze, daher muss die Kommunikation zwischen den beiden Systemen abgesichert werden. Die Daten werden über das Internet gesendet und dürfen weder verfälscht noch von Dritten ausgelesen werden. Connect unterstützt zwei Sicherheitsmechanismen für die Kommunikation: HTTPS und <a href="/wissens-hub/blog/json-web-token-jwt-im-detail">JWT</a> .</p><p>Bevor wir näher auf diese beiden Mechanismen eingehen, muss zum Verständnis noch ein anderer Punkt erwähnt werden. Ein Connect-Add-on unterliegt einem Lifecycle, für dessen Phasen Webhooks registriert werden können. Während der Installation des Add-ons findet über einen solchen Webhook der Austausch der Sicherheitsinformationen statt. Diese enthalten auch ein Geheimnis, welches im weiteren Verlauf wichtig wird.</p><p>Für Add-ons, die im Marketplace gelistet werden sollen, ist die gesicherte Übertragung mittels HTTPS verpflichtend. Damit werden die Daten verschlüsselt übertragen und können nicht von Unbefugten ausgelesen werden. Die Verschlüsselung muss die gesamte Kommunikation umfassen, also auch die Übertragung des Add-on Descriptors und ganz besonders den Austausch der Sicherheits-Informationen bei der Installation.</p><p>Außerdem wird zur Signierung der Nachrichten <a href="/wissens-hub/blog/json-web-token-jwt-im-detail">JWT</a>  eingesetzt. Damit wird eine Authentifizierung umgesetzt, denn es kann für jede Nachricht geprüft werden, ob sie vom angegebenen Absender stammt. Für die Erstellung dieser Signatur wird das bei der Installation ausgetauschte Geheimnis genutzt.</p><p><span>REST-Anfragen an die JIRA-API müssen immer signiert sein, ansonsten werden sie wie anonyme Nutzer behandelt, die keinen oder nur minimale Berechtigungen haben. Durch die Signatur weiß die Anwendung, von wem die Anfrage kommt und kann weitere Sicherheitsprüfungen durchführen (siehe nächster Abschnitt).</span></p><p><span>Auch bei eingehenden Nachrichten im Add-on sollte die Signatur geprüft werden. Die Atlassian-Anwendung signiert jede Nachricht, die Prüfung dieser Signatur liegt aber in der Verantwortung des Add-on Entwicklers. Nur wenn er diese verifiziert, kann er sicher sein, dass die Anfrage von einem authentifizierten Partner kommt. Für die Erstellung und Prüfung der Token bietet Atlassian fertige Bibliotheken an.</span></p><h2><span>Berechtigungen</span></h2><p><span>Atlassian Connect unterstützt die Vergabe von Berechtigungen an einzelne Add-ons. Dies wird über einen eigenen Add-on Nutzer realisiert, der genau wie ein normaler Nutzer konfiguriert werden kann. Dieser Nutzer wird jedoch nicht auf die in der Lizenz freigeschalteten Nutzer aufgerechnet.</span></p><p><span>Grundlegende Anforderungen wie “Lesen” und “Schreiben” von Daten können die Add-ons in ihrem Descriptor angeben, diese werden “Scopes” genannt. Um beispielsweise Daten in der Anwendung zu verändern, muss zwingend der zugehörige Scope “write” angegeben sein. </span></p><p><span>Die angeforderten Scopes werden bei der Installation aufgelistet und müssen vom Administrator bestätigt werden. Auch wenn bei einer Aktualisierung neue Scopes hinzukommen, muss der Administrator erst bestätigen, dass diese gewährt werden sollen.</span></p><h2><span>Sicherheit des Add-ons</span></h2><p><span>Nachdem wir nun die Kommunikation und den Zugriff auf die Kern-Anwendung betrachtet haben, wird es Zeit sich der Sicherheit in der zweiten Anwendung zu widmen. Was nützt die sichere Kommunikation, wenn das Add-on selbst offen wie ein Scheunentor ist?</span></p><p>Ein für Anwender kritischer Punkt ist die Speicherung von Kundendaten im Add-on. Dazu müssen Anbieter eine Erklärung zur Datensicherheit im Marketplace veröffentlichen. Atlassian gibt auch hierfür Empfehlungen und Richtlinien vor, die Umsetzungsverantwortung liegt aber beim Anbieter des Add-ons. Bei der Speicherung ist grundlegend zu beachten, dass die Daten getrennt nach Mandanten (verschiedene Cloud-Instanzen verschiedener Kunden) gespeichert werden. Die Daten selbst müssen natürlich gegen Zugriffe und Manipulationen durch Dritte geschützt werden.</p><p><span>Dieser letzte Punkt gilt ganz allgemein für die ganze Webanwendung und das zugrundeliegende System. Aufgrund der vielfältigen Möglichkeiten, solch eine Anwendung zu implementieren und zu betreiben kann es an dieser Stelle nur ganz allgemeine Hinweise zur Absicherung geben. Es gibt einige bekannte <a href="https://www.owasp.org/index.php/Top10#OWASP_Top_10_for_2013">Angriffszenarien</a> , die immer nach dem gleichen Prinzip ablaufen und für deren Vermeidung Empfehlungen vorhanden sind. Details können den <a href="https://security.berkeley.edu/secure-coding-practice-guidelines">verlinkten Seiten</a>  entnommen werden.</span></p><p><span>Neben dem Schutz vor direkten Angriffen auf das Add-on ist für den Anwender auch die Ausfallsicherheit bedeutsam. Wenn ein Add-on nicht verfügbar ist, kann dies die Arbeit des Kunden deutlich einschränken. Deshalb muss der durchgehende Betrieb sichergestellt werden. Da ein Add-on von mehreren Cloud-Instanzen aufgerufen wird, können auch keine individuellen Wartungsfenster vereinbart werden. Im Gegenteil, die Kunden können weltweit verstreut sein und in völlig unterschiedlichen Zeitzonen arbeiten. Auch hier liegt es wieder in der Verantwortung des Anbieters, für die ständige Verfügbarkeit zu sorgen.</span></p><p><span>Weiterhin muss der Schutz vor Datenverlust bei Hardwareausfällen gewährleistet werden. Dazu müssen beispielsweise Redundanzen und Backups eingerichtet werden.</span></p><h2><span>Private Add-ons im Marktplatz</span></h2><p><span>Für Kunden, die ihre intern genutzten Add-ons selbst schreiben wollen, bietet Atlassian einen Weg, diese als “private Add-ons” im Marktplatz zu listen. Für den Fall, dass das Add-on gar nicht im Marktplatz auftauchen soll, gibt es außerdem noch einen weiteren Weg. </span></p><p><span>Dreh- und Angelpunkt für alle Add-ons ist der Atlassian Marktplatz. Speziell für den Fall privater Add-ons gibt es nun zwei Optionen:</span></p><p><span>Das Add-on wird als “privat” im Marketplace gelistet und ist somit nur für den Anbieter sichtbar. Für die Installation in JIRA wird ein separates Token benötigt, mit dem das Add-on sichtbar gemacht werden kann. Die Token können auf einer eigenen Seite verwaltet werden und gelten jeweils nur für eine Instanz. </span></p><p><span>Zur Einbindung des Add-ons in JIRA muss der Administrator außerdem explizit private Add-ons erlauben. Danach kann die eigene Erweiterung wie gewohnt über den Marktplatz installiert werden. </span></p><p><span>Diese erste Option bedeutet einen gewissen Aufwand. Sie bietet den Vorteil, dass Atlassian ein Monitoring für die Verfügbarkeit des Add-ons durchführt und warnt, wenn ein Plugin nicht erreichbar ist. </span></p><p><span>Die zweite Option besteht darin, das private Add-on im Entwicklungsmodus einzubinden. Dieser erlaubt die Installation ohne eine Registrierung im Marktplatz. Allerdings ist dieser Weg von Atlassian nicht für den Livebetrieb vorgesehen. So gibt es beispielsweise kein Monitoring und auch die Absicherung des Add-ons gegen die Nutzung durch Dritte ist schwieriger, da keine gültigen Lizenzinformationen übertragen werden können.</span></p><p><span>Zusammengefasst gibt zwei Pfade, mit denen private Add-ons in Applikationen eingebunden werden können. Während die Nutzung von privaten Add-ons bei geschäftskritischen Prozessen die bessere Wahl ist, bietet die Einbindung von unkritischen Add-ons über den Entwicklungsmodus einen schnellen und unkomplizierten Einstieg.</span></p><p><span>Der letzte Blick gilt noch einmal der Frage, wie private Add-ons bereit gestellt werden. Auch wenn der Name „privates Add-on“ dies vielleicht nicht suggeriert, muss dennoch auch dieses Add-on über eine Internet-Schnittstelle eingebunden werden wie jedes andere öffentliche Add-on auch. Es ist daher unabdingbar, auch bei privaten Add-ons auf die richtige Absicherung zu achten. </span></p><h2><span>Ergebnis</span></h2><p><span>Wie man im Artikel sieht, gibt es sehr viele Punkte, die einen Einfluss auf die Sicherheit des Add-ons haben. Es ist aber auch zu bedenken, dass Server-Add-ons nicht pauschal als sicher eingestuft werden können. Auch diese können große Sicherheitslücken beinhalten. Und auch das Hosting einer JIRA Server Instanz durch den Anwender birgt Risiken, wenn er sich nicht damit auskennt.</span></p><p><span>Die Frage, ob Connect-Add-ons sicher(er) sind, lässt sich also nicht pauschal beantworten. Atlassian unterstützt die Anbieter durch die Bereitstellung von Bibliotheken und den Zwang zu verschlüsselter Kommunikation. Es werden Empfehlungen gegebenen, und in der Dokumentation gibt es einen eigenen Punkt zum Thema Sicherheit. Der größte Teil der Verantwortung liegt aber beim Anbieter der Erweiterung. Dieser muss auf viele Dinge achten und vieles richtig machen, dann können die Add-ons durchaus als sicher gelten. Die Überprüfung für den Nutzer ist hier aber sehr schwer, er muss dem Anbieter vor allem Vertrauen entgegenbringen.</span></p>

Atlassian Connect: die Sicherheit von Add-ons

Learning from experiments: Implementing an Atlassian Connect add-on with Mule

<p>In software development, Atlassian products like JIRA and Confluence are widely used today. But these days such tools are also applied in other areas. Meanwhile, Atlassian offers the applications also as cloud products (SaaS), hosted by Atlassian. For the user this is a simple approach, as he can just use the application without having to worry about installation and operations.</p><p>Unfortunately, the many already existing add-ons for the server version are not available in these cloud variants *1. With Connect, Atlassian delivers its own framework to extend their cloud applications with add-ons. Currently JIRA Cloud, Confluence Cloud, HipChat and Bitbucket Cloud are supported.</p><p><span></span></p><h3>Add-ons with Connect</h3><p>Technically the existing server add-ons are OSGi Bundles which are implemented in Java and are also directly installed into the application. This type of installation is not possible for cloud applications. Instead, Connect add-ons are autonomous web-applications, which communicate with the application (e.g. JIRA) via REST interfaces. They may also render content like HTML, which will be included in iframes.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/d7djI96TRCPAjJTPi4l3"><img width="650" height="600" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/d7djI96TRCPAjJTPi4l3" alt="AtlassianConnectDiagram" /></a> </p><p>The picture (by <a href="https://developer.atlassian.com/docs/" target="_blank">Atlassian</a> ) shows this communication scheme.</p><p>The different functionalities of the add-on are declared through a descriptor, which assigns  them to certain places in the application. Connect offers the opportunity to add elements to the user interface. Therefore, the descriptor contains  URLs pointing to the add-on, together with the information where to place the contents. JIRA will call this URL and integrate the returned HTML in the surrounding page. Furthermore, functionality without a graphical user interface can be registered. This way, the add-on can handle various events (like updating an issue) or add Post Functions to Workflows. Also in this case there is an URL (webhook) pointing to the functionality added to the descriptor.</p><p>As the add-on is an autonomous webapp, being called using a REST interface, it does not depend on the technologies used by the main application (e.g. JIRA). The programming language, frameworks and so on can be chosen freely instead. Atlassian and the community additionally offer libraries and tools for different languages and technologies, making development easier and taking responsibility of the ground work. Additionally the current trend for microservices brought up libraries and tools supporting this integration approach.</p><p>The add-on vendor also operates and administers his webapp in this model, meaning he has much more tasks following development. He is responsible for hosting and availability. In exchange he gains the advantage of having more control over his application. Updating the add-on becomes much simpler and apply automatically to all customers. No customer administrator needs to manually install the new version, as it is with server add-ons.</p><p>But in return this also means, that the customer has less control and needs to trust the vendor even more. If the vendor does not ensure continuous operation or performs incompatible updates, the customer cannot use the add-on anymore.</p><p>Compared to server add-ons, there are also limitations on Connect add-ons regarding possible range of functions. Because they are not that deeply integrated as the directly installed variant, they cannot interfere at so many points. An example is the support of Workflow Post Functions, but not of Workflow Validators. Internationalization (i18n) is also not supported at the moment. Whereas some features are planned and might be supported in the future, this is not likely for others. So it is not imaginable to implement an add-on with a custom HTTP filter with Connect.</p><h3>Installation</h3><p>As with server add-ons, installation takes place through Marketplace. Add-ons can be offered free or paid, private listings for internal use in organisations are also possible. For chargeable add-ons, payment via Atlassian is supported as well as direct payment via vendor.</p><h3>Conclusion</h3><p>In general, Connect offers a good way to extend the applications of Atlassian.</p><p>For add-on developers (in the sense of programmers) there is a notable higher flexibility regarding technology stack, which also enlarges the circle of possible developers. On the other hand the framework is not that powerful and offers a decreased level of integration. For add-on vendors in general there is increased effort, due to new challenges like operation of the application.</p><p>Atlassian <a href="https://developer.atlassian.com/docs/" target="_blank">stated</a>  that Connect will not be available for JIRA Server and Confluence Server. This results in duplicate implementation and maintenance work for add-ons which should be available for server and cloud. This could also lead to a fragmentation of the community, with impacts on documentation, tutorials, help forums etc.</p><p>For users, the difference to server applications is way much smaller. The add-ons do not reach the complete functionality and not all add-ons are available for cloud but there is much work happening in this direction. The biggest risk is that the vendor could stop his add-on which makes it suddenly no more available. Atlassian gives <a href="https://de.atlassian.com/licensing/marketplace#generalmarketplacequestions-6" target="_blank">some hints</a>  on selecting trustable add-ons.</p><p>In the <a href="/wissens-hub/blog/security-atlassian-connect-add-ons">next article</a>  we will investigate, how security needs are fulfilled by Connect add-ons.</p><p>How about you? Would you use the cloud variant in your enterprise? Share your positive and negative experiences with Connect add-ons in the comments.</p><p>*1 There are selected server add-ons preinstalled in cloud instances. This is a special case and should not be considered as option for own plugins. It is more a temporary solution, until these features can be implemented with connect.</p>

Introduction to Atlassian Connect

<p>As we saw in the <a href="/wissens-hub/blog/introduction-atlassian-connect">Introduction to Atlassian Connect</a> , add-ons are stand-alone web applications, operated by different vendors. They communicate with the Atlassian application through the internet. Especially for enterprises this may raise questions about security and data protection. We will investigate on these aspects in this article without going too much into detail, but instead by showing how many points need to be considered.</p><p>We use JIRA as example, but the considerations can be applied to other Connect applications (Confluence, HipChat, BitBucket) as well.</p><h2>Overview</h2><p>In the following, we will examine four different areas, where security aspects are relevant. The image gives an overview to structure them.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/hv50r3KSTMC4uLs5elqd"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/hv50r3KSTMC4uLs5elqd" alt="blog_atlassian_connect_security_groß" /></a> </p><p>We will focus on the following topics:</p><ol><li>The communication between the Atlassian application and the add-on</li><li>The authorization concept of the Atlassian product</li><li>Requirements on the Connect add-on</li><li>Protection of private add-ons</li></ol><h2>Communication between the two applications</h2><p>As described, both applications interact via public network, which requires protection of their communication. Data is sent through the internet and must not be manipulated or read by others. Therefore Connect is using two mechanisms to secure the communication: HTTPS and JWT.</p><p>Before giving a deeper insight into these mechanisms, we would like to give a short introduction into add-ons’ life cycle: A Connect add-on can provide webhooks. These webhooks are registered for different activities and application phases. During installation of the add-on, an exchange of security information takes place. This also includes a shared secret, which will be important later in this section.</p><p>For add-ons which should be listed in marketplace, secured communication with HTTPS is mandatory. This way, transmitted data is encrypted and cannot be read by unauthorized persons/programs. Encryption has to covers every kind of communication, including the installation of the add-on descriptor and especially the exchange of security information during installation.</p><p>Furthermore, JWT is used to sign messages, which offers an authentication mechanism. For every message, the originator can be validated. Therefore the formerly exchanged secret is used.</p><p>Requests to the JIRA REST API have always to be signed, or they will be treated like anonymous users, who have only minimal or even no permissions. By reading the signature, the application can infer the related user and can perform further security checks (see next section).</p><p>For every incoming message on the add-on, the signature should also be validated. The Atlassian application signs every message, but the responsibility to check this signature stays on add-on vendor’s site. Only if he verifies it, he can be sure that the request came from an authenticated partner. Atlassian supports the developer by providing libraries for the creation and validation of JWT tokens.</p><h2>Permissions</h2><p>Atlassian Connect supports granting of permissions on single add-ons. This is realized through an add-on-user, which can be configured like a normal user (but will not be accounted on the user budget of your license).</p><p>Permissions like “reading” and “writing” data can be specified in the add-on descriptor. These are called “scopes”. If the add-on wants to change data in the application, the write scope is required.</p><p>The requested scopes are shown during the installation process of the add-on and have to be confirmed by the administrator. This also applies to updates in case they require new scopes.</p><h2>Security of the add-on</h2><p>Now that we have seen how the communication and the access to the core application are protected, it’s time to have a look at the add-on application itself. Secure communication is no use if the add-on itself is completely vulnerable for attacks.</p><p>For vendors, it is mandatory to provide a “Data Security & Privacy Statement“ in the Marketplace listing. Atlassian has recommendations and guidelines on that, but the responsibility of implementation is on add-on vendor’s site. When storing data, add-ons should handle tenants’ data separately. The plugin instance can be used by different cloud instances of different customers, who must not access each other’s data. Of course, the storage itself has to be protected against access and manipulation by third parties.</p><p>This last point applies in general to the whole web application and the underlying system. As such an application can be built and operated in various ways, we can provide only very general hints for security here. There are some well known <a href="https://www.owasp.org/index.php/Top10#OWASP_Top_10_for_2013">attack scenarios</a> , following some basic principles. <a href="https://security.berkeley.edu/secure-coding-practice-guidelines">Recommendations</a>  to prevent such attacks exist and can be found in the linked pages.</p><p>Besides the protection from direct attacks, for users the availability and stability are also important factors. Unavailability of the add-on can limit or even block processes at the customer. Therefore, a continuous running add-on application is crucial for them. Even individually planned maintenance windows are nearly impossible, as the add-on can be used by different cloud instances of customers around the world, residing in different time zones. So again, the vendor has the responsibility to ensure this aspect of security/availability.</p><p>Another import point in this area is protection against loss of data, e.g. on hardware failures. So there is a need for backups and redundant systems.</p><h2>Private add-ons in marketplace</h2><p>For customers that want to write their own add-ons for internal use, Atlassian offers the possibility to list them as “private add-on” in the Marketplace. Additionally there are ways to bypass the marketplace completely. We will describe both options in the following section.</p><p>The add-on can be listed as “private” in Marketplace and is then visible only within the vendor’s organization. For the installation in JIRA a separate token is needed to make the add-on visible. Tokens can be managed on a separate page by the vendor. They are valid for a single JIRA instance.</p><p>To install the add-on, the administrator of the JIRA instance needs to explicitly allow integration of private add-ons. Afterwards, the installation can happen through marketplace with the token.</p><p>This first option produces some effort, but has the benefit of being the official way and offering some support by Atlassian, like monitoring of availability.</p><p>The second option is to include the plugin in development mode. This allows installation without registration in marketplace, but is not intended by Atlassian to be used for production usage. There is no automatic monitoring and a critical point is the missing transmission of license information which hinders the protection against unauthorized usage by third parties.</p><p>In conclusion there are two ways to include private add-ons in the cloud application. For mission critical processes, the official way with private marketplace listing is highly recommended. But for a fast and simple start, there is also the option to use the development mode.</p><p>Here we want to provide a last hint about publicity: Even if the name “private add-on” does not suggest this at first glance, these add-ons (their REST API) need to be publicly available through the internet like every other public add-on. So all the concepts discussed before apply also to these ‘private’ cloud add-ons.</p><h2>Conclusion</h2><p>As the article shows, there are many aspects that influence the security of a cloud add-on. One also needs to be aware of the fact, that server add-ons cannot be stated as secure in general. They can also contain huge security leaks and also hosting an own JIRA instance by a customer can bring its risks if he has no experience in doing so.</p><p>The question, if Connect add-ons are (more or less) secure, can not be answered in general. Atlassian supports the vendor by providing libraries and enforcing encrypted communication. There are also recommendations and the documentation of Connect contains a part about security. But the main responsibility remains in the hand of the add-on vendor. He has to consider many things and needs to handle them correctly, then the Connect add-ons can be seen as secure. The review by the user is very hard here, so in the end, the decision whether to trust a cloud add-on vendor or not remains a customer’s responsibility and a serious question.</p>

Security of Atlassian Connect add-ons

<p><a href="https://www.codecentric.de/standorte" target="_blank">Erik Petzold</,Sebastian Nemak  and <a href="https://www.codecentric.de/standorte" target="_blank">Raimar Falke</a> .</p><p>We all know the getXxx() and setXxx() methods in languages like Java. They appear in almost every project and everybody uses them. But why do we cling to these methods? Do we need them? What about just making the fields public? If you are also asking yourself these questions please read on.</p><p><span></span></p><h2>Object Inspection</h2><p>Where are these methods coming from? For different purposes there was the need to inspect objects at runtime. The JDK 1.1 therefore brought the <span>Reflection API</span>, which allows to examine and manipulate objects. This new API is used by the <a href="http://www.oracle.com/technetwork/articles/javaee/spec-136004.html"><span>JavaBean Specification</span></a> , which amongst other things defines a standard how to use reflection to access properties of objects.</p><p>JavaBeans are often mentioned in discussions about Java objects that simply hold values. Usually it is said that a Java object has to meet three conditions to be considered a JavaBean:</p><ul><li>a constructor without any arguments (aka default constructor)</li><li>private attributes with their accessor methods (getters and setters)</li><li>implements the java.io.Serializable interface</li></ul><p>The original specification is much more than these three lines — it’s about 114 pages — and it has a completely different focus:</p><blockquote><p>The goal of the JavaBeans APIs is to define a software component model for Java, so that third-party ISVs [Independent Software Vendors] can create and ship Java components that can be composed together into applications by end users.</p></blockquote><blockquote><p>A Java Bean is a reusable software component that can be manipulated visually in a builder tool.</p></blockquote><p>When reading these two quotes (or even better the whole spec), one can see, that the document is about composable components (often graphical), that have properties and behaviour. The properties of these components should be editable in a graphical tool (builder), which leads to the requirements listed above. The building tool can then use introspection as defined in the JavaBean specification to manipulate the properties and serialization to store the beans. But the spec is much more than that, JavaBeans should support many more features, e.g. events. Properties of JavaBeans can be much more complex than just storing and returning a value of a private field. The value can be computed, there are bound properties which perform notifications on changes and there can even be constrained properties, whose value changes can be rejected through vetoes.</p><p>In conclusion we can see that JavaBeans is a specification for (visual) application components with behaviour. So it is surprising that it is regularly mentioned in the context of data objects without behaviour. So we have to ask: is the spec really the best fit for such objects?</p><p>The reason behind the widespread use of the bean specification might be, that the standardized way of accessing properties (originally intended for builder tools) is also a basic requirement for other tools like mappers and marshallers, which work with the data part of objects.</p><p>So nowadays, getters and setters are everywhere, especially when objects are processed by standard frameworks or libraries. The accessor methods do not even have to be hand-written, but can be generated quite easily by the IDE or even more convenient at compile-time by tools like <a href="https://projectlombok.org/"><span>Project Lombok</span></a> , <a href="http://www.joda.org/joda-beans/"><span>Joda Beans</span></a>  and the <a href="http://docs.scala-lang.org/tutorials/tour/case-classes.html"><span>case</span></a>  <a href="http://www.scala-lang.org/files/archive/spec/2.11/05-classes-and-objects.html#case-classes"><span>objects</span></a>  of Scala. But on the other side this creates the risk, that programmers don’t think about these methods and simply generate all possible accessors without asking if they are indeed needed. And these methods may be harmful, as they can break basic principles of object-orientation.</p><h2>The Object Oriented Perspective</h2><p>The basic idea of object-oriented programming is to have objects, which combine state and behaviour. The state is owned by the object and therefore internal and encapsulated. Encapsulation means that the structure and details of the internal data are not part of the public interface.</p><p>On the other side are data objects like entities and value objects (as defined in <span>Domain Driven Design</span>) or data transfer objects (<a href="http://martinfowler.com/eaaCatalog/dataTransferObject.html"><span>DTO</span></a> s), which typically have private instance variables and public getter/setter methods. These methods commonly mirror the internal structure and directly access all internal variables without further logic. This leads to two issues (see <a href="http://www.javaworld.com/article/2073723/core-java/why-getter-and-setter-methods-are-evil.html"><span>also</span></a> ) :</p><ol><li>These objects do not follow the general idea of object orientation, as there is no data hiding within these objects.</li><li>As a consequence, developers tend to create anemic domain models, which do not provide domain specific operations, but only hold data. A consequence is that the interaction with the “data holding objects” is through getter and setter invocations.</li></ol><p>For example an address change of a customer should be performed by calling <code>customer.changeAddress(...)</code> instead of <code>customer.setAddress(...)</code>. The difference is that <code>changeAddress()</code> can perform other actions e.g. change verification flags or send notifications. Unfortunately the existence of the accessor methods allows the developer to easily solve his problem (change the address) without being required to think about proper method names and semantics. You are not alone in this: we see the widespread usage of accessor methods in all projects. Because our mind is shaped to use accessor methods it requires a lot of effort to avoid this pattern.</p><p>We have already mentioned that frameworks and libraries may require to use setter and getter methods. But how often is it really required by the 3rd-party software?</p><h2>Frameworks as a Cause?</h2><p>Usually in each project different frameworks are used to handle objects. So there is for example Jackson to process JSON and Hibernate as an ORM (Object-Relational Mapper). Because we find these two frameworks in almost every Java project we want to take a closer look whether these frameworks do need accessor methods and how the JavaBeans Specification is related to this. A simple data model has been chosen to examine these questions:</p><p>A company has an address and an unsorted set of customers. Each customer also has an address. An address consists of a street, house number, zip code and city. All the attributes of an address are strings.</p><p>Let’s consider three variant: private fields with and without accessor methods and public fields. We examine both <span>Jackson</span> (version 2.7.0) and <a href="http://hibernate.org/orm/"><span>Hibernate</span></a>  (version 5.0.7) in our tests.</p><p>We start with private fields. Jackson and Hibernate work fine with accessor methods. That is the standard way (<a href="https://github.com/rfalke/simple-value-objects/tree/master/jackson-normal"><span>jackson-normal</span></a> , <a href="https://github.com/rfalke/simple-value-objects/tree/master/hibernate-normal"><span>hibernate-normal</span></a> ). Without these methods, Jackson requires a configuration statement to set and access the fields (<a href="https://github.com/rfalke/simple-value-objects/tree/master/jackson-normal-without-accessors"><span>jackson-normal-without-accessors</span></a> ):</p><div>

```java
  objectMapper.setVisibility(PropertyAccessor.FIELD, Visibility.ANY);
```

</div><p>Hibernate also supports objects without accessor methods:</p><blockquote><p>Although not required, it is recommended to follow JavaBean conventions by defining getters and setters for you entities persistent attributes. Hibernate can also directly access the entity’s fields.</p><p>Attributes (whether fields or getters/setters) need not be declared public. Hibernate can deal with attributes declared with public, protected, package or private visibility.</p></blockquote><p>After verification we can confirm that Hibernate works without additional adjustments. Such objects (private fields and no accessor methods) are only useful if you have domain methods which work with the private fields. These methods of course may also return some of the fields directly or a computation based on the private fields (like a view). In this regard such objects match closely the ideal we described in the object-oriented section above.</p><p>Making your fields public is unconventional but not a problem for Jackson and Hibernate (<a href="https://github.com/rfalke/simple-value-objects/tree/master/jackson-public-fields"><span>jackson-public-fields</span></a> , <a href="https://github.com/rfalke/simple-value-objects/tree/master/hibernate-public-fields"><span>hibernate-public-fields</span></a> ). In such a case the accessor methods are rendered superfluous and the source code can shrink. Please note that in the <a href="http://download.oracle.com/otndocs/jcp/persistence-2_1-fr-eval-spec/index.html"><span>JPA</span></a>  <a href="http://download.oracle.com/otndocs/jcp/persistence-2_1-fr-eval-spec/index.html"><span>specification</span></a>  public fields are forbidden (from section 2.2): “The instance variables of a class must be private, protected, or package visibility independent of whether field access or property access is used.“ So it turns out that the behaviour we observe with Hibernate contradicts the JPA specification by supporting public fields. This deviation from the specification is also the reason why the Eclipse IDE shows errors for public fields: “The Java field for attribute ‘name’ is public/final”. These errors can be disabled by changing the JPA settings under: <em>project settings / JPA / Errors/Warnings / Attribute / The java field for attribute is final/public</em> – error to warning, info or ignore.</p><p>As a last experiment we made the fields final in addition to public to reflect the intention of value objects. The fields are initialized in the constructor which therefore gets all values as parameters. Jackson supports this but requires an annotation for the constructor (<a href="https://github.com/rfalke/simple-value-objects/tree/master/jackson-final-public-fields"><span>jackson-final-public-fields</span></a> ):</p><div>

```java
  @JsonCreator
  public Customer(@JsonProperty("firstName") String firstName,
                  @JsonProperty("lastName") String lastName,
                  @JsonProperty("customerAddress") Address customerAddress) {
  …
  }
```

</div><p>Java 8 supports the discovery of parameter names using reflection. Jackson can use such data and with an additional maven dependency the annotation shown above is unnecessary (<a href="https://github.com/rfalke/simple-value-objects/tree/master/jackson-final-public-fields-no-annotations"><span>jackson-final-public-fields-no-annotations</span></a> ).</p><p>Hibernate is used mostly for storing and retrieving entities. These types of object do not benefit from final fields and therefore we did not test Hibernate with public final fields.</p><p>The following table shows how the two frameworks deal with different field visibilities and/or the existence of accessor methods.</p><table><tbody><tr><td><b>Framework</b></td><td><b>Jackson</b></td><td><b>Hibernate</b></td></tr><tr><td><b>Field Visibility</b></td><td><b>Accessor Methods</b></td></tr><tr><td><b>Private</b></td><td><b>existent</b></td><td> ✓</td><td>✓</td></tr><tr><td><b>non-existent</b></td><td> ✓</td><td><span>✓*</span></td></tr><tr><td><b>Public</b></td><td><b>non-existent</b></td><td> ✓</td><td><span>✓**</span></td></tr></tbody></table><p>* Hibernate supports this but the scenario is only useful if domain methods are present.<br /> ** Hibernate supports this but internal structure of entity is disclosed.</p><p>We found that the Jackson and Hibernate framework do not require accessor methods. So you can choose to either make the fields public (and maybe even final) to allow easy interaction with value objects. Or you can make the fields private for entities and ensure that object orientation is followed.</p><p>Be careful that frameworks (like Hibernate) may differ from other implementations of the Specification (like JPA) and that additional effort is required if you switch to another implementation.</p><h2>Alternative Approach</h2><p>How would an alternative approach without getters and setters look like? As stated above, domain objects should fulfill business needs with domain-specific methods and apply real object orientation. Thus, the internal data is protected from direct access, but instead the object offers business related methods which operate on the data. Here is a simple example:</p><div>

```java
  public class Employee {
    enum EmploymentState{
      CURRENT_EMPLOYEE, FORMER_EMPLOYEE;
    }
 
    private boolean accessToOfficeBerlin;
    private boolean accessToWebapp;
    private double salary;
    private EmploymentState employmentState;
    private Date dismissalDate;
 
    public void dismiss(){
      if(employmentState == EmploymentState.FORMER_EMPLOYEE){
        throw new IllegalStateException("employee already dismissed");
      }
 
      employmentState = EmploymentState.FORMER_EMPLOYEE;
      dismissalDate = new Date();
 
      accessToOfficeBerlin = false;
      accessToWebapp = false;
 
      salary = 0.0;
    }
  }
```

</div><p>If the dismissal would be done via setter-methods, the developer could forget to set a property. This could break invariants, like having a dismissal date for former employees.</p><p>A special type of data objects are value objects. These represent a value without identity, rather than an entity. A value object is characterized only by its attributes. Examples are colors, dates or amounts of money. They are often used  as parameters. Value objects should be immutable for several reasons. It simplifies development, since instances could be easily shared and passing them as parameters has no risk of unintentional manipulation. Being immutable also stresses the meaning of a value, represented by an instance. Manipulation of the value results in a new value and therefore in a new instance. An immutable object can not have setters. Instead it has methods with meaningful names to construct new objects.</p><p>The Java 8 Date/Time API is an example built around immutable instances:</p><div>

```java
  LocalTime now = LocalTime.now();
  System.out.println(now);
  LocalTime in15Minutes = now.plusMinutes(15);// creates a new object
  System.out.println(now);// prints the same as the statement above
```

</div><p>In addition to value objects there are also DTOs. Such objects are used on system boundaries to transfer pure data between systems. Examples might be a mapping to a database or transferring data as XML/JSON. As shown above, you should verify that the framework you use really needs getters and setters. If an object can be completely created by its constructor, then such an object doesn’t even have to be mutable. If you can not make the fields final it may still be possible to reduce the source code size and decrease the complexity by avoiding the accessor methods and use just public fields. Such mutable public fields should not be a problem for DTOs, as these objects have a very short lifetime and are not used in other parts of the application. Be aware that there is a risk that DTOs in general are used not only on the system boundaries but also within the application to a larger extent which may lead to bad design.</p><h2>Conclusion</h2><p>So does it mean you can avoid writing getters and setters at all? Not really. There are situations where they can be used safely. Especially for the display of data (the V in MVC) there is a need to access data and a simple getter does this job very well. Getters may be more relevant at this place than setters — you don’t need to generate both together!</p><p>To have these accessor methods is also fine if a framework really needs them. But in such cases  it is possible to decouple this code from the rest of the application to prevent setters from being used in other parts.</p><p>You should always be aware of the risks involved when accessor methods are added and ensure that you clearly understand the need, before you add and use such methods. Don’t accept the reasons “they are easy to generate” and “everybody does it this way”. Use domain-specific terminology and business logic and by doing so avoid anemic domain models.</p>

Why do you write accessor methods?

Software Craftsman

IT Consultant

<p><a href="https://en.wikipedia.org/wiki/Domain-driven_design" target="_blank">Domain-Driven Design</a>  (DDD) is an approach to software development for complex scenarios: scenarios where we cannot get to the right implementation at first attempt. This is far more common than one might think. Often, what we experience in software development projects on a daily basis, is the assumption that it is possible to build software systems based on reliable requirements. But this disregards both the fact that business needs constantly change and evolve over time and the reality of fragmented knowledge: Even only two business experts in the same domain will hardly ever have the exact same understanding of the problem they are trying to solve. In order to deliver true business value, we need to build software in ways, which allow and enable us to engage in a constant discovery process, rather than match an elaborate upfront design.<br /> With DDD, everyone involved in the business can contribute to collaborative discovery: domain experts, software developers, stakeholders and customers.</p><p>Within a codecentric-internal 4-day workshop, a group of 10 software developers, architects and product owners had the chance to dive deep into the Domain Driven Design world, guided and supported by Alberto Brandolini, the inventor of <a href="https://en.wikipedia.org/wiki/Event_storming" target="_blank">EventStorming</a> , a popular collaborative workshop format.</p><p>Needless to say, it is impossible to touch every aspect of a 4-day training, therefore I will focus on aspects of EventStorming, general learnings and the benefits of attending one of Alberto’s workshops.</p><h2>EventStorming: A Brief Introduction</h2><p>EventStorming actually refers to a family of workshop formats, which allow for collaborative exploration and modelling of complex business domains.</p><p>The following EventStorming workshop formats are distinguished and often used within the field of DDD*:<br /> <br /></p><ul><li><strong>Big Picture EventStorming:</strong><br /> allows collaborative exploration of an entire business flow, looking for diverging perspectives and interests of the several stakeholders involved.</li><li><strong>Process Modelling EventStorming:</strong><br /> focuses on collaboratively designing effective processes, leveraging a non-specialistic notation, in order to allow interdisciplinary collaboration of business, technical and UX-CX stakeholders.</li><li><strong>Software Design EventStorming:</strong><br /> adds a level of depth on the previous format by exploring the moving parts of a software implementation of the solution and progressively injecting a more rigorous grammar.</li></ul><p>On day 1, we started with Big Picture EventStorming. It involves a larger group of people (usually 10-15, but sometimes up to 30 people), who collaboratively explore everything that happens within a line of business by creating a timeline of events out of sticky notes on an “infinite” modeling area (usually a very long wall).</p><p>The Big Picture EventStorming helps to identify <em>Bounded Contexts</em> together with the dev team: Units of homogenous language and model consistency, which together form a heterogeneous whole. Within a bounded context, we define a <em>Ubiquitous Language</em>, where every term has exactly one, and only one, meaning. By designing our system out of bounded contexts, we can solve one problem at a time, without making our life harder than necessary by having to implement expensive compromises and trade-off solutions.</p><p>It is a good strategy to detect the core domain, and identify “bottleneck” candidates, whose improvement might significantly benefit the whole system.</p><p>Important to say: The result of a Big Picture EventStorming workshop is a large map of the group’s understanding of the business at the time of the modeling, never a final result. It can only be interpreted as a snapshot of the participants’ knowledge, and therefore serves as a starting point for further exploration, rather than a goal in and of itself.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/4L3XYcdJR6nz4gZc4tFQ"><img width="250" height="167" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/4L3XYcdJR6nz4gZc4tFQ" alt="Big Picture EventStorming" /></a> </p><p>Based on the Big Picture, we then rolled up our sleeves and went on with Process Modelling and Software Design on days 2 and 3, and even implemented hands-on a part of our model, using <a href="https://martinfowler.com/eaaDev/EventSourcing.html" target="_blank">Event Sourcing</a>  with the <a href="https://axoniq.io" target="_blank">Axon</a>  framework. If you are interested in a more detailed explanation of the respective phases, please see the following blog post (sorry, German only):<a href="/wissens-hub/blog/event-storming-gemeinsam-die-domaene-entdecken" target="_blank"> Event Storming – Gemeinsam die Domäne entdecken</a> .</p><h2>General Learnings</h2><p>Alberto’s training was my first contact with the DDD universe, besides some conversations with developer colleagues about this topic. It has been an intense four days, filled with a lot of information in a short amount of time. I would in no way call myself an expert in this field now, the workshop was a condensed first step into the topic and has sparked my motivation to learn even more. One key insight that will have a profound impact on my daily work is the distinction of domain types, and their importance to project implementation.</p><p>Eric Evans, thought leader in software design, domain driven design and domain modeling, states:</p><blockquote><p>The heart of software is its ability to solve domain-related problems for its user.</p></blockquote><p>(Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software). This means when developing software we should not primarily focus on technology, but rather on the business side, therefore the functional area which we would like to support: the domain.<br /> DDD distinguishes between three types of domains*:<br /> <br /></p><ul><li><strong>Core Domain:</strong><br /> What makes you special, the small portion of your expertise and software that gives you an edge on the market.</li><li><strong>Generic Subdomains:</strong><br /> The ones which are necessary for your company to survive, but which are not intrinsically a competitive factor.</li><li><strong>Supporting Subdomains:</strong><br /> Something which is not enough general purpose to be available off-the shelf, and needs to be developed in a custom way.</li></ul><p>Understanding whether we are in the core or not is vital, it helps us make important decisions regarding investment and development effort.<br /> In the core domain it is extremely beneficial to work with few internal developers that have a long-term understanding of the problem as well as easy access to key domain experts in order to foster a successful collaboration: more quality generates more revenues.<br /> Besides, quality above a given level won’t turn into more revenues in supporting subdomains, which are usually cost-driven. If we are in the generic subdomain it is recommended to use an existing software solution as it won’t be much of a differentiator.</p><p>Learning about these different areas and their distinction increased my awareness<br /> regarding what to focus on and what questions to ask in the future by a lot. In my role as a product owner together with the development team and domain experts, we need to ask ourselves whether the respective software development project is a game changer or if it is may just playing a supporting role. Although everything is important to the business, not everything is equally important.* DDD allows us to constantly learn about the business, and translate our findings into working software, which delivers true business value.</p><h2>Benefits of attending a workshop with Alberto</h2><p>I can highly recommend joining one of Albertos workshops. Not getting tired of our questions -and we had a lot- Alberto always came up with real-life examples that he himself had experienced. This made the training extremely enjoyable and insightful, but also the presented methodologies and practices applicable for the daily challenges that we often face as software engineers, architects and product owners.</p><p>In Alberto’s workshops you will not only learn about DDD and EventStorming, but also about collaboration, interpersonal connections, political issues in organizations and how to tackle them as well as frameworks and best practices.</p><p>One learning, which at first glance seemed like a no-brainer, but really had an impact on me, was the following statement:</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/zMk5RztJTwqoGIrfrqi7"><img loading="lazy" width="250" height="170" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/zMk5RztJTwqoGIrfrqi7" alt="statement about the importance of simply taking a first step" /></a> </p><p>It underlines the importance of simply taking a first step, starting with what you have and what you know at a given point in time, instead of giving in to the urge of modeling everything at once and upfront.</p><p>Our workshop was equally divided between theory and exercises, where the participants had the chance to apply the theoretical parts on real-life problems. In small groups, we worked together, had discussions, experienced typical group dynamics caused by different personalities and also encountered some moments of frustration. You may think that is something negative, but this is what I liked most about the 4 days: Alberto gave us the chance to really learn and get insights. He did not present a solution first-hand, but gave us the time and the support for figuring it out on our own. That is how you learn, right?</p><p>There aren’t a ton of articles and even less books on the market covering the topic of DDD and EventStorming, which makes it hard to gain a comprehensive view just by studying in private. So if you ever have the chance to see Alberto in action, take it – it is truly worth it.</p><p>*from: Alberto Brandolini: “Domain Driven Heuristics, Complementary info for the Domain-Driven Design Modelling class”, 08/2019</p>

EventStorming meets Domain-Driven Design with Alberto Brandolini:  A workshop review

IT Consultant (Product & Agile)

<p><span>Sketchnotes sind ein</span><a href="/wissens-hub/blog/sketchnotes-es-geht-um-innere-bilder"> <span>tolles Mittel</span></a> <span>, um Informationen sehr schnell mnemonisch aufzufangen und vorzuhalten. Sie entstehen in der Regel mit einigen unterschiedlichen Stiften auf Papier. Für Apple-Nutzer gibt es mit Procreate eine tolle App, um Sketchnotes mit iPad und dazugehörigem Stift zu entwerfen. Im Windows-Umfeld gibt es aktuell viele tolle Convertible-Laptops, die sowohl als Tablet als auch als Laptop fungieren können. Da es Procreate leider nicht außerhalb des iOS-Universums gibt, habe ich mich auf die Suche nach möglichen Alternativen speziell für Windows begeben.</span></p><p><span>TL;DR Es gibt einige schöne Apps, die alle ihre speziellen Stärken und Schwächen haben. Mein Favorit für die tägliche Nutzung ist die vorinstallierte OneNote-App. Ihre Stärken liegen in der Einfachheit der Benutzung und der sehr guten Verwaltung verschiedener Seiten. Schwächen hat sie beim Funktionsumfang. Für kreativere und anspruchsvollere Sketchnotes bietet sich Sketchable an. Viele kreative Funktionen wie Spiegelungen, Objekte und Masken sowie sehr frei konfigurierbare Pinsel machen es zu einem tollen Produkt.</span></p><p>Für meinen Test habe ich mir die folgenden fünf Programme angesehen: <a href="https://www.getleonardo.com" target="_blank">Leonardo von Xade Software</a> , <a href="https://siliconbenders.com" target="_blank">Sketchable von Silicon Benders</a> , <a href="https://www.onenote.com" target="_blank">OneNote von Microsoft</a> , <a href="http://madewithmischief.ru/" target="_blank">Mischief von The Foundry</a>  und <a href="https://www.wacom.com/de-de/products/apps-services/bamboo-paper" target="_blank">Bamboo Paper von Wacom</a> .</p><h2>Das Vorgehen</h2><p><span>Der Fokus in diesem Artikel liegt auf der Benutzung der Anwendungen im Business-Kontext. </span><span>Das bedeutet: Künstlerische Aspekte sind wichtig, Funktionen für Effektivität und Effizienz werden jedoch noch ein wenig höher gewertet. </span><span>Ein weiterer wichtiger Kontext ist die Strukturierung von Daten. Wie schnell finde ich meine Sketchnotes zu bestimmten Themen? Weiterhin lege ich Wert auf eine einfache Benutzeroberfläche, um möglichst schnell und effizient direkt ins Sketchen zu kommen. Der dritte wichtige Punkt ist die Kooperationsmöglichkeit der Anwendung. Wie einfach ist es, Dateien zu exportieren, zu teilen oder vielleicht weiter zu bearbeiten?</span></p><p> </p><table><tbody><tr><td></td><td><a href="#Leonardo">Leonardo</a> </td><td><a href="#Sketchable">Sketchable</a> </td><td><a href="#OneNote">OneNote</a> </td><td><a href="#BambooPaper">Bamboo Paper</a> </td><td>ProCreate</td></tr><tr><td>Pixel / Vektor</td><td>P</td><td>P</td><td>V</td><td>P</td><td>P</td></tr><tr><td>Unendliches Canvas</td><td>✔</td><td>✖</td><td>✔</td><td>✖</td><td>✖</td></tr><tr><td>Bibliothek / Ordnungssystem</td><td>✖</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td></tr><tr><td>Pinsel</td><td>8</td><td>7</td><td>3</td><td>6</td><td>∞</td></tr><tr><td>Fingergesten</td><td>✔</td><td>✔</td><td>✖</td><td>✖</td><td>✔</td></tr><tr><td>Lineal</td><td>✔</td><td>✖</td><td>✔</td><td>✖</td><td>✔</td></tr><tr><td>schnelles ausmalen</td><td>✔</td><td>✔</td><td>✖</td><td>✖</td><td>✔</td></tr><tr><td>Ebenen</td><td>✔</td><td>✔</td><td>✖</td><td>✖</td><td>✔</td></tr><tr><td>Symmetrie</td><td>✔</td><td>✔</td><td>✖</td><td>✖</td><td>✔</td></tr><tr><td>Perspektive</td><td>✔</td><td>✖</td><td>✖</td><td>✖</td><td>✖</td></tr><tr><td>Strichglättung</td><td>✔</td><td>✔</td><td>✖</td><td>✔ (fix)</td><td>✔</td></tr><tr><td>Pinsel konfigurieren</td><td>✔ (nicht speicherbar)</td><td>✔</td><td>✔</td><td>✖</td><td>✔</td></tr><tr><td>Objektmanipulation</td><td>✔</td><td>✔</td><td>✔</td><td>✖</td><td>✔</td></tr><tr><td>Export Formate</td><td>PNG, JPG, TGA, BMP, PSD</td><td>PNG, JPG,, TIFF, BMP, PSD</td><td>PDF (Druck)</td><td>PDF</td><td>JPG, PDF, PSD, PNG, PRO</td></tr><tr><td>Fotoimport</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td></tr><tr><td>Preis</td><td>$ 39</td><td>25,49 €</td><td>0,00 €</td><td>4,99€</td><td>10,99€</td></tr><tr><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>besonders Erwähnenswert</td><td>Funktionsumfang</td><td>UI</td><td>Koop<br /> OCR</td><td>versch. Papierarten</td><td>frei konfigurierbare Pinsel</td></tr></tbody></table><h2><h2><a href="https://www.getleonardo.com" target="_blank">Leonardo</a> </h2><p><span>Leonardo wird von einem sehr kleinen schwedischen Studio namens Xade Software entwickelt und befindet sich aktuell noch im Beta-Status. Das Programm versucht schlicht und einfach, die beste Sketchnotes-App zu werden. Leonardo ist pixelbasiert und bietet von Haus aus sehr viele Funktionen. Auf einem endlosen Canvas kann man sich beliebig breit austoben. Acht verschiedene Pinsel, aktive Linienglättung, symmetrisches und perspektivisches Zeichnen sind nur ein paar der mannigfaltigen Optionen. Auch das UI ist einfach genug, um einen schnellen Einstieg zu ermöglichen. Nutzer von Programmen wie Photoshop fühlen sich hier schnell zu Hause. Ein sehr nützliches Werkzeug ist der Farbeimer. Er erkennt automatisch, ob eine Form geschlossen ist und kann sie mit Farbe ausfüllen. Das erspart dem Zeichner langwieriges Ausmalen und klappt auch in den meisten Fällen problemlos. Die Farben sind frei im RGB-Raum wählbar, eine Vielzahl von Farbselektionswerkzeugen (z. B. Pipette, RGB, HSV, HSL, …) bietet jedem eine komfortable Lösung.</span></p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/2gE6M0lfSHu4UFAxCU3N"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/2gE6M0lfSHu4UFAxCU3N" alt="Leonardo" width="250" height="140" /></a> <p>Leonardo von Xade Software AB</p></div><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Bkg1QezVSWKVhIg0GAe8"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Bkg1QezVSWKVhIg0GAe8" alt="Gut zum Abpausen" width="250" height="138" /></a> <p>Die Transparenz der Anwendung ist wählbar</p></div><h3>Was fehlt?</h3><p><span>Genau diese Frage stellen die Entwickler in der Software an die Nutzer. Durch kurze Lieferzyklen folgen sie konstant ihrer Vision. Aktuell fehlt sehr wenig. Da Leonardo mit Pixeln anstatt Vektoren arbeitet, gibt es keinen unendlichen Zoom. Dies ist aber bei Sketchnotes auch nur bedingt nützlich.</span></p><p><span>Als Standard-Sketchwerkzeug fehlt eine Dateiverwaltung. Das bedeutet, dass Leonardo jedes Bild als eine eigene Datei betrachtet. Die Struktur und Ordnung muss der Nutzer über das Betriebssystem selber pflegen.</span></p><h3>Fazit</h3><p><span>Wer es ernst meint mit digitalen Sketchnotes, findet in Leonardo sicher einen neuen besten Freund. Der gigantische Funktionsumfang und die Geschwindigkeit ermöglichen es, fast ohne Grenzen zu zeichnen. Gelegenheitssketcher sind vielleicht etwas überfordert von den vielen Optionen und der flachen, aber existenten, Lernkurve. Auch fehlt ein Ordnungssystem wie z. B. bei Bamboo Paper, welches die Metapher des SKizzenbuchs stärker transportieren könnte.</span></p><p><a href="#overview">Zurück zur Übersicht</a> </p><h2><a href="https://www.microsoft.com/de-de/p/sketchable/9wzdncrfjcjw?cid=SiliconBendersWebsiteTraffic&rtc=1&activetab=pivot:overviewtab" target="_blank">Sketchable</a> </h2><p><span>Sketchable bringt einen hohen Funktionsumfang mit einem einfachen UI und einer schönen Ordnungsfunktion mit sich. All das kostet aktuell einmalig rund 25 €. </span><span>Einige Funktionen können in einer kostenlosen Probeversion umfangreich getestet werden.</span><span> Die Pro-Funktionalitäten werden leider nur per Video vorgestellt und können erst nach Erwerb der Lizenz wirklich ausprobiert werden. Es gibt insgesamt sieben Pinsel, die in großem Umfang konfigurierbar und sehr einfach über die Grundleiste aufrufbar sind. Darüber hinaus gibt es unzählige Vorkonfigurationen der Pinsel, die natürlich noch nach eigenen Vorlieben angepasst und erweitert werden können.</span></p><p><span>In der Vollversion gibt es auch viele Spezialfunktionen. Wie zum Beispiel einen Farbeimer zum Ausmalen, frei konfigurierbare Schablonen für akkurate Strichformen sowie verschiedene Spiegel-Modi. Die Farben sind generell frei wählbar. Zusätzlich gibt es noch einen konfigurierbaren Bereich in der Fußleiste für acht vordefinierte Kernfarben.</span></p><p><span>Eine sehr schöne Funktion ist die Ordnung der einzelnen Kunstwerke in mehreren Journalen. Dieses sind virtuelle Bücher, die in einer eigenen View angelegt und verwalten werden können. Sowohl das Journal als auch einzelne Seiten können über soziale Medien freigegeben werden und ermöglichen so spannende Kooperationen.</span></p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/wQIcG2tRUigkoqRakvPd"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/wQIcG2tRUigkoqRakvPd" alt="SketchableUI" width="250" height="140" /></a> <p>Sketchable von Silicon Benders</p></div><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/FBfBCMQuQWazjzLwzp6d"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/FBfBCMQuQWazjzLwzp6d" alt="Sketchable Bibliothek" width="250" height="138" /></a> <p>Die Journalansicht</p></div><h3><h3><h3><h3><h3>Was fehlt?</h3><p><span>Durch die Bildmetapher gibt es festgelegte Größen für die einzelnen Seiten eines Journals. Diese können pro Journal unterschiedlich definiert werden (z. B. DIN A4). Jedoch schließen sie ein unendliches Canvas aus. Durch das pixelbasierte Rendern der Zeichnungen ist auch ein unendlicher Zoom nicht verfügbar.</span></p><p><span>Am Funktionsumfang und der Präsentation gibt es allerdings nicht wirklich etwas zu meckern.</span></p><h3>Fazit</h3><p><span>Sketchable ist ein tolles Produkt. Es vereint ein Ordnungssystem für alle Sketchnotes mit einem sehr großen Funktionsumfang, der eigentlich keine Wünsche offen lässt. Die einfache Benutzeroberfläche ist sehr schnell erfasst. An Detailfunktionen kommt man allerdings nur etwas mühsamer, da sie teilweise versteckt sind. Hingegen sind die sehr frei konfigurierbaren Pinsel ein weiteres Plus. Alles in allem ein Werkzeug, mit dem sowohl Gelegenheitssketcher als auch Profis viel Spaß haben werden.</span></p><p><a href="#overview">Zurück zur Übersicht</a> </p><h2><a href="https://products.office.com/de-de/onenote/digital-note-taking-app" target="_blank">OneNote</a> </h2><p><span>Microsoft OneNote geht das Thema Sketchnotes von einer komplett anderen Seite an. Das Programm ist ein kollaboratives Notizbuch, das rudimentäre Zeichenfähigkeiten einbindet. Dabei legt OneNote den Fokus auf Kollaboration. Es ist möglich, mit mehreren Nutzern gleichzeitig auf einer Seite zu arbeiten. Dafür können einzelne Seiten, oder auch ganze Notizbücher mit Kollegen geteilt bzw. direkt online zusammen bearbeitet werden. Die Nutzung von OCR (Optical Character Recognition – Texterkennung) zur Erkennung und Umwandlung von Schreibschrift in Maschinenschrift macht OneNote zu einem extrem starken Werkzeug. Dies gilt auch für die tiefgehenden Katalogisierungsmöglichkeiten. Das unendliche Canvas sowie die automatische Gruppierung von gerade Gezeichnetem helfen hier zusätzlich.</span></p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/QX1Uu1WTRveDodGYZLJM"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/QX1Uu1WTRveDodGYZLJM" alt="OneNote" width="250" height="110" /></a> <p>OneNote von Microsoft</p></div><h3>Was fehlt?</h3><p><span>OneNote unterstützt nur drei verschiedene Pinseltypen. Diese können lediglich mit ausgewählten Farben und einer Stärke konfiguriert werden. Es ist nicht möglich, etwas Gezeichnetes per Farbeimer auszumalen. Perspektivisches oder gespiegeltes Zeichnen ist ebenfalls nicht vorhanden. Ohne Smoothing wird es nicht einfach, runde Formen zu zeichnen. Einfache Formen wie Rechtecke, Kreise und Ovale werden allerdings unterstützt, sogar mit einer semi-automatischen Erkennung.</span></p><h3>Fazit</h3><p><span>Ein tolles virtuelles Notizbuch. Die Informationen sind gut geordnet. Kollaboration wird sehr einfach ermöglicht. Das Zeichnen funktioniert gut, ist dennoch im Funktionsumfang stark eingeschränkt.</span></p><p><a href="#overview">Zurück zur Übersicht</a> </p><h2><a href="https://www.wacom.com/de-de/products/apps-services/bamboo-paper" target="_blank">Bamboo Paper</a> </h2><p><span>Bamboo Paper von Wacom ist eine simple Zeichensoftware, entworfen für das gleichnamige Zeichentablet. Die App startet mit einer schön gestalteten Übersicht der eigenen Notizbücher. Ein Notizbuch kann dabei beliebig viele Seiten enthalten. Die Größe der Seiten ist stets konstant. Die unterschiedlichen Bücher können mit unterschiedlichen Arten von Papier bestückt werden – kariert, liniert, rein-weiß oder leicht meliert. Dies bietet eine sehr schöne Bibliothek, um Bücher zu kategorisieren. Die Bücher können aus der Bibliothek direkt gedruckt oder auch als PDF exportiert werden.</span></p><p><span>Das Wichtigste zum Zeichnen neben dem Papier sind natürlich die Stifte. Bamboo Paper bietet insgesamt sechs verschiedene Stifte an. Zwei (Kuli & Markierer) gibt es in der freien Version. Über einen In-App-Purchase können unter anderem noch vier weitere Stifte hinzugefügt werden. Die Erkennung der Stifte fühlt sich sehr natürlich an. Die Strichstärke wird durch den Pen (ich nutze den DELL active pen</span><a href="https://www.dell.com/de-de/shop/accessories/apd/750-aavp" target="_blank"> <span>PN557W</span></a> <span>) gut übersetzt und kann darüber hinaus noch in je drei Strichstärken vordefiniert werden. Ein Stift braucht natürlich eine Farbe. Bamboo Paper bietet dazu eine frei konfigurierbare Farbpalette von insgesamt 72 Farben an. Hierbei können mehrere Farbschemata definiert und universell verwendet werden. Auf den einzelnen Seiten gibt es weiterhin die Möglichkeit, Bilder aus Dateien oder von der Geräte-Kamera zu importieren.</span></p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/m8LdqRk8R2NxBUIhX5g6"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/m8LdqRk8R2NxBUIhX5g6" alt="Bamboo Paper" width="250" height="140" /></a> <p>Bamboo Paper von Wacom</p></div><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/1hJpSxL0QGqyipVDsFiE"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/1hJpSxL0QGqyipVDsFiE" alt="Bamboo Paper Bibliothek" width="250" height="140" /></a> <p>Die Übersicht der Notizbücher</p></div><h3><h3><h3><h3><h3>Was fehlt?</h3><p><span>Bamboo Paper möchte ein einfaches Sketchbook sein. Aus dem Grund bietet es auch keine weiteren Komfortfunktionen. So gibt es keine Möglichkeit, geometrische Formen zu zeichnen, außer natürlich frei Hand. Außerdem ist es nicht möglich, gezeichnete Formen einfach mit einem Klick auszumalen. Die App verfügt nicht über die Möglichkeit, Ebenen oder Masken zu benutzen. Des Weiteren gibt es zwar eine Handballenerkennung, aber keine Unterscheidung zwischen Finger und Stift. Es gibt lediglich zwei rudimentäre Fingergesten: Pinch-to-zoom und das Verschieben mit dem Handwerkzeug durch zwei Finger. Ganz im Sinne eines gedruckten Buches ist es in Bamboo Paper auch nicht möglich, einmal Gezeichnetes noch anzupassen. Auswählen, Transformieren oder Verschieben von bereits gezeichneten Elementen ist nicht möglich.</span></p><h3>Fazit</h3><p><span>Bamboo Paper ist ein sehr simples virtuelles Buch zum Sketchen. Die Einfachheit ermöglicht einen sehr schnellen Einstieg. Wacoms virtuelle Tinte sieht toll aus. Durch eine Bibliothek mit unterschiedlichen Büchern ist es sehr übersichtlich. Für Sketchnotes, bei denen es in der Regel auf die Zeit ankommt, ist es allerdings nur bedingt für den täglichen Gebrauch zu empfehlen. Das Ändern der Farbe oder des Stiftes (Art oder Stärke) benötigt jeweils drei Klicks und die Verwendung eines Popup-Menues. Schnelle Hilfen wie einfache Formen (Kreis, Viereck) sowie schnelles Ausfüllen sucht man vergeblich.</span></p><p><a href="#overview">Zurück zur Übersicht</a> </p><h2>Meine Favoriten für digitale Sketchnotes</h2><p><span>Das hängt stark von der gewünschten Nutzung ab. In meinem Alltag hat sich OneNote durch seine Vielseitigkeit und Einfachheit durchgesetzt, da es zum Beispiel auch auf mobilen Geräten verfügbar ist. Wenn es um explizites Sketchnotes-Zeichnen geht, kann ich mit Leonardo und Sketchable alles erreichen. Die Journals und das simple UI lassen mich meist zu Sketchable greifen. Bamboo Paper macht mit seinen unterschiedlichen Büchern und Papierarten sehr viel Spaß. Es fühlt sich am ehesten wie ein echtes Buch an.</span></p></h3></h3></h3></h3></h3></h3></h3></h3></h2>

Apps für digitale Sketchnotes unter Windows

<p><span>Backlog Refinement Meetings können schnell zäh und unbefriedigend werden, wenn man 20 Stories in zwei Stunden durcharbeiten muss. In diesem Artikel stelle ich ein etwas angepasstes Format vor, mit dem es möglich ist, mit 100 % Energie jede Story zu bearbeiten und dabei noch die Flexibilität der Planung zu steigern: die Story Time. Kurz gesagt, eine Story Time ist eine tägliche 10-Minuten-Timebox nach dem Daily, die für das Refinement genau eines Items genutzt wird. In diesem Artikel werde ich auf die Grundregeln eingehen und dann basierend auf meinen Erfahrungen damit eine Übersicht über Vor- und Nachteile erarbeiten.</span><span></span></p><h2>Das Problem</h2><p><span>Scrum Teams wenden in der Regel circa 10 % der Sprintzeit für das Refinement des Backlogs auf. Die Empfehlung wurde zwar aus dem <a href="https://scrumguides.org/scrum-guide.html" target="_blank">Scrum Guide</a>  entfernt, ist aber immer noch weit verbreitet. Aus meiner Erfahrung als auch der anderer Kollegen handelt es sich dabei in der Regel bei Zwei-Wochen-Sprints um ein bis zwei einstündige Termine (teilweise auch zweistündige).</span></p><aside><h3>Ein Termin, mehrere Namen</h3><p>Oft heißt dieser Termin <em>Backlog Refinement Meeting</em>. Vor ein paar Jahren gab es noch den Begriff des Backlog Groomings, der heute aber nicht mehr oft verwendet wird, da er namentlich extrem nah am <a href="https://de.wikipedia.org/wiki/Cyber-Grooming" target="_blank">Cyber-Grooming</a>  liegt. Eine schöne Formulierung ist für mich <em>Story Time</em>. Da die meisten Scrum Teams aus gutem Grund mit User Stories arbeiten, bietet sich diese Formulierung an, um den Fokus auf die Analyse von Kundenstories zu legen – im Gegensatz zu abzuarbeitenden Aufgaben/Anforderungen. Ein Team, das von den großen klassischen Terminen zu dem unten beschriebenen Format gewechselt ist, hat auch die Namensänderung mit dem neuen Format verknüpft. Daher führe ich dieses neue Format gerne unter dem Namen <em>Story Time</em> ein.</p></aside><p><span>In diesen Backlog Refinement Meetings präsentiert die PO dem Team Backlog Items. Im gemeinsamen Dialog werden diese besprochen und bearbeitet, bis sie die <a href="https://www.scruminc.com/definition-of-ready/" target="_blank">Definition of Ready (DoR)</a>  des Teams erfüllen. Im Idealfall sind alle Kollegen konstant in die Diskussion involviert, um alle möglichen Aspekte einzubringen. In der Realität ist es in solchen Terminen oft der Fall, dass einige wenige zu bestimmten Items etwas beitragen und die anderen eher still teilnehmen und eventuell beim Schätzen (falls praktiziert) mit eingreifen. Dies führt aufgrund eigener Erfahrungen und Feedback von Teilnehmern zu sehr trägen, ermüdenden und besonders ineffizienten Meetings. Die letzten Items werden oft einfach nur noch durchgeschoben, um den Termin schnell zu Ende zu bringen oder aber noch die gewünschte Anzahl an Items abzuarbeiten.</span></p><div><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/UKUIUD0WRAK1WLskuB2W" alt="Lange Refinement Meetings können sehr anstrengend sein" width="1024" height="683" /><p>Foto von Andrea Piacquadio von Pexels</p></div><p><span>Um die Termine zu optimieren, habe ich Refinements mehrerer Teams analysiert und herausgefunden, dass die durchschnittliche Zeit für ein Item sich bei knapp unter zehn Minuten einpendelt. Eine Diskussion später entstand der erste Versuch für die zehn Minuten Story Time. Viele weitere sollten folgen. </span></p><p><span>Um die Termine möglichst kurz und effizient zu gestalten, starte ich in den Teams in der Regel mit einem sehr restriktiven Regelwerk. Wenn das Team einige Erfahrung damit gesammelt hat, passt es den Termin teilweise leicht an, eben <a href="https://www.scrum.org/resources/blog/three-pillars-empiricism-scrum" target="_blank">inspect and adapt</a> .</span></p><aside><h3>Backlog Item oder User Story?</h3><p>In diesem Artikel benutze ich die Begriffe Backlog Item (oder kurz Item) und User Story parallel. <a href="https://scrumguides.org/scrum-guide.html" target="_blank">Der Scrum Guide</a>  bezeichnet Anforderungen im Backlog als Backlog Items. Dies sind die Anforderungen, die in Refinements aufbereitet werden müssen. <a href="http://www.extremeprogramming.org/rules/userstories.html" target="_blank">User Stories</a>  sind ein Artefakt aus dem <a href="http://www.extremeprogramming.org/" target="_blank">Extreme Programming (XP)</a> , einem agilen Prozess, der sich perfekt zur Kombination mit Scrum eignet. Der Grundgedanke ist, in der Anforderung keine Problemlösung zu beschreiben, sondern die Geschichte des Endnutzers zu verstehen, um für seine Aspekte passende Lösungen in der Entwicklung zu finden. Die User Story ist ein weit verbreitetes und sehr zu empfehlendes Werkzeug, um vom Ausführen zum Gestalten zu gelangen.</p></aside><h2><span>Die Regeln:</span></h2><ol><li><span>Jeden Tag direkt nach dem Daily findet eine zehnminütige Story Time statt. Hierdurch findet kein Extra-Termin im Kalender mehr statt. Die Kollegen sind durch das Standup gerade zusammen aktiv und nutzen die Energie für weitere zehn Minuten.</span></li><li><span>Es wird genau ein Item bearbeitet. Ist die Story schnell bearbeitet, kann direkt zur täglichen Arbeit übergegangen werden.</span></li><li><span>Wenn es sich abzeichnet, dass das Item nicht innerhalb der Timebox abgeschlossen werden kann, unterbricht ein Zeitnehmer (z. B. der Scrum Master) die Diskussion nach ca. acht Minuten. Die letzten beiden Minuten werden dafür genutzt, Analysen/Fragen/etc. auf der Story zu vermerken, so dass die fehlenden Informationen asynchron besorgt werden können. Dann kann das Item an einem anderen Tag weiter bearbeitet werden. Alternativ ist es oft sinnvoll, sehr große User Stories (vielleicht ist es ja sogar ein verstecktes Epic) in der Timebox lediglich in kleinere Stories zu schneiden, um die einzelnen dann in weiteren Story Times zu bearbeiten.</span></li></ol><h2><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/NWgyeaAkTril1qtqc284" alt="Story Time Regeln" width="920" height="1024" /></h2><p> </p><h2><span>Die Vorteile:</span></h2><p><span>Die Vorteile für die PO liegen auf der Hand. Sie ist deutlich flexibler und kann schneller auf neue Anfragen von Stakeholdern oder neue Informationen reagieren, da sie täglich neu bestimmen kann, welches Backlog Item besprochen werden soll. Stories, welche die PO kurz vor einer neuen Iteration erreicht haben, passten oft nicht in den Refinement-Zyklus. Sie mussten entweder im Planning besprochen werden oder um mindestens einen Sprint verschoben werden. Mit den Story Times ist es möglich, diese noch zu besprechen und im Idealfall in den nächsten Sprint zu planen.<br /> </span><span>Die Energie sinkt nicht. Selbst mit einem voll ausgenutztem Daily von 15 Minuten vor der Story Time ergibt sich eine Gesamtzeit von maximal 25 Minuten. Dies ist im Gegensatz zu ein- oder zweistündigen Terminen ohne Einbußen in der Aufmerksamkeit durchführbar. </span><span>Der Fokus auf ein Item pro Tag vermeidet den Verlust, der in großen Refinement-Terminen durch den Kontextwechsel zwischen unterschiedlichen Items entsteht und normalerweise stark an der Energie der Teilnehmer zehrt. </span><span>Dem Grundgedanken des fokussierten und ununterbrochenen Sprints wird besser Rechnung getragen. Es wird ja kein größerer Termin mit starken Kontextwechseln im Sprint verplant. Das Scrum-Team kann sich dadurch voll auf den Sprint fokussieren. </span><span>Die asynchrone Informationsbeschaffung zwischen Story Times entschlackt den oft verspürten Druck deutlich.</span></p><p> </p><h2><span>Die Nachteile:</span></h2><p><span>Wie fast alle Werkzeuge ist auch die Story Time kein Allheilmittel. Mehrere zusammengehörige Items müssen auf mehrere Tage getrennt bearbeitet werden. Dies kann zu Redundanzen in den Gesprächen führen, weil sich gewisse Fakten mehrmals in Gedanken neu erarbeitet werden müssen. Wenn das Backlog sehr fragmentiert ist, kann es passieren, dass durch die täglichen Kontextwechsel Informationen vergessen werden, die nicht explizit in der Story verortet wurden. Das Gleiche passiert theoretisch auch mit den großen Refinement-Terminen, fällt da aber oftmals nicht so explizit auf. Dieser Effekt zeigt auf der anderen Seite sehr schön auf, wo es noch implizites Wissen und Kopfmonopole gibt und dass es sinnvoll ist, diese möglichst transparent und persistent zu bearbeiten.<br /> </span><span>Größere Themen können nicht von Anfang bis Ende bearbeitet werden, da dafür die Timebox zu klein ist. Hier haben sich unterschiedliche Verfahren etabliert. Bei größeren Items haben Teams die Timebox für das rudimentäre Schneiden in kleinere User Stories genutzt, um dann in den folgenden Tagen die einzelnen Teilaspekte zu bearbeiten. Bei extrem großen Themen, wie zum Beispiel einem neuen Produkt oder Thema, ist in der Regel ein Workshop o. ä. (z. B. Kickoff, Story Mapping, Lean Canvas, … ) sinnvoll. Hier kann das Thema gesondert und in Tiefe bearbeitet werden.<br /> Für den PO kann es unter Umständen herausfordernd wirken, sich für ein Item entscheiden zu müssen. Dieser Aspekt wiegt aus Erfahrung in der Praxis nicht so stark, da die deutlich höhere Kadenz der Meetings den Druck von der Entscheidung nimmt. Am nächsten Tag ist dann eben die andere Story dran. </span></p><p><span> </span></p><h2><span>Fazit:</span></h2><p><span>Bisher hat jedes Team, das vorher mit klassischen Refinements gearbeitet hat, begeistertes Feedback zur Story Time gegeben. Die Vorteile überwiegen in der Praxis klar die Nachteile. Die Flexibilität wird von den POs gelobt und die Teammitglieder freuen sich über einige Meetings weniger.</span></p><div><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/gQyZ1wX3RPCrtwigXNXQ" alt="Alle Teams haben den neuen Ansatz beibehalten" width="1024" height="683" /><p>Foto von Thirdman von Pexels</p></div><p><span>Dieser Artikel ist Teil der noch losen Reihe “Agile Toolbox” (weitere Artikel habe ich unten verlinkt). Habt ihr Fragen oder Erfahrungen mit diesem oder ähnlichen Formaten? Lasst es uns gerne in den Kommentaren wissen. Wir werden weitere Artikel zu unterschiedlichen agilen Werkzeugen hier auf dem Blog veröffentlichen. Habt ihr vielleicht selbst Themen, zu denen ihr euch Informationen oder Erfahrungsberichte wünscht? Nennt sie uns!</span></p><p>Weitere Artikel aus der Agilen Toolbox:</p><ul><li><a href="/wissens-hub/blog/moderationswerkzeug-parkplatz">Moderationswerkzeug Parkplatz</a> </li><li><a href="/wissens-hub/blog/wir-machen-uns-die-welt-wie-sie-uns-gefaellt-wie-uns-der-positive-loesungsorientierte-ansatz-zum-ziel-bringt">Wie uns der positive lösungsorientierte Ansatz zum Ziel bringt</a> </li><li><a href="/wissens-hub/blog/event-storming-gemeinsam-die-domaene-entdecken">Event Storming – Gemeinsam die Domäne entdecken</a> </li><li><a href="/wissens-hub/blog/tuckmans-4-phasenmodell">Tuckmans 4-Phasen-Modell</a> </li><li><a href="/wissens-hub/blog/sketchnotes-komplexe-zusammenhaenge-einfach-visualisieren">Sketchnotes – komplexe Zusammenhänge einfach visualisieren</a> </li></ul><p> </p><p>Bildquellen:</p><ul><li>F<a href="https://www.pexels.com/de-de/foto/junge-genervte-freiberuflerin-mit-laptop-zu-hause-3808008/">oto von Andrea Piacquadio von Pexels</a> </li><li><a href="https://www.pexels.com/de-de/foto/mann-im-grauen-rundhals-hemd-das-frau-im-roten-hemd-halt-5684562/">Foto von Thirdman von Pexels</a> </li><li><a href="https://pexels.com/de-de/foto/foto-von-leuten-die-einander-die-hande-halten-3184436/">Titelbild von fauxels von Pexels</a> </li><li>eigene Zeichnung</li></ul><p> </p>

Agile Toolbox: Story Time

<p><span>Die Produktivität von Arbeitnehmer*innen profitiert vom Mobile Office. Dies zeigen unterschiedliche Studien aus den vergangenen Jahren. Unternehmen sollten diesen Effekt zielführend nutzen.</span><span></span></p><div><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/KDhRmEURSZgK4MoiRpQ4" alt="mobile office" width="700" height="393" /><p>Quelle: Pixabay</p></div><p><span>Im März 2020 fanden viele Führungskräfte ihre Teams plötzlich im Homeoffice wieder, ohne darauf vorbereitet zu sein. Und es ist etwas passiert, was viele für nicht möglich hielten – meist funktionierte es. In jedem Fall besser als ohne diese Möglichkeit, auch wenn es erst einmal eine Notfallmaßnahme war und manchmal mit der heißen Nadel gestrickt werden musste. Aber in geschäftskritischen Zeiten sind viele Dinge möglich oder werden möglich gemacht. </span></p><p><span>Besonders in traditionell geführten Unternehmen spülte dieser Homeoffice-Tsunami alle vorherigen Bedenken einfach beiseite. Von heute auf morgen wurden tausende Unternehmens-Arbeitsplätze in den privaten Lebensraum verlegt. Führungskräfte, die gestern noch auf Sicht und Zeit führten und Homeoffice skeptisch gegenüber standen, mussten nun darauf vertrauen, dass ihre Mitarbeiter*innen auch ohne Anwesenheitsroutinen arbeiteten. Einige Führungskräfte konnten leichter mit dieser neuen Situation umgehen als andere. Der skurrilste Fall für uns war eine Führungskraft, die alle 30 Minuten einen schriftlichen „Bericht“ über die Tätigkeit verlangte. Andere, die auch schon vor den Covid-19-Kontakbeschränkungen auf eine vertrauensvolle Zusammenarbeit und viel Eigeninitiative setzten, hatten es leichter, Remote-Zusammenarbeit produktiv zu nutzen. In dieser Zeit haben wir von codecentric mit unserer Aktion „<a href="/wissens-hub/blog/home-office-akut-3-erfolgreiche-schritte-fuer-ploetzliche-remote-arbeit">Plötzlich Homeoffice</a>  – 30 Minuten Coaching für Führungskräfte“ Unternehmen dabei unterstützt, schnell zielführende Strukturen aufzubauen.</span></p><p><span>War das Stricken mit der heißen Nadel in den ersten Wochen überlebenswichtig, wird es nun darum gehen, die Arbeitswelt an die neuen Gegebenheiten anzupassen und teilweise neu zu gestalten. Wie soll der Status jetzt, in Zeiten schrittweiser Wiederöffnung der Gesellschaft, in Unternehmen sein, wenn Beschäftigte mehr und mehr an ihre Arbeitsplätze zurückkehren werden und Mobile Office weiter nutzen wollen? Werden wir wieder für jedes Vertriebsmeeting in den Flieger steigen oder alle Planungstreffen in Hotels um den Erdball verstreut durchführen, auch wenn sich gezeigt hat, dass dies online sehr gut möglich ist? Wird die Arbeit im Mobile Office der Vergangenheit angehören oder wird es integraler Teil der Arbeitswelt sein so wie Heiner Thorborg im Manager Magazin schreibt: “</span><a href="https://www.manager-magazin.de/unternehmen/artikel/coronavirus-fuehren-aus-dem-homeoffice-vertrauen-wird-belohnt-a-1305915.html" target="_blank"><span>… das Homeoffice geht genauso wenig wieder weg wie das Internet</span></a> <span>”. </span></p><p><span>Die Arbeitskultur wird sich verändern. Theo Sommer nennt diese Krise auf Zeit Online nicht bloß eine “</span><a href="https://www.zeit.de/gesellschaft/zeitgeschehen/2020-03/lektionen-corona-krise-globalisierung-outsourcing-5vor8" target="_blank"><span>Betriebsstörung. Es ist die größte Durchwirbelung unseres Alltagslebens seit dem Pestausbruch des 17. Jahrhunderts</span></a> <span>”. Insofern ist dieser Stresstest für unsere Unternehmen auch eine Chance, unterschiedliche Arbeitsmodelle zu analysieren und moderne Technologien mit auf die Agenda zu nehmen. Und nach jeder Krise gibt es immer die Phase der Neuorientierung und später dann der neuen Balance. Unternehmen und Führungskräfte sind gut beraten, diesen Prozess aktiv zu gestalten, damit er produktiv bleibt. </span></p><p><span>Wie gut jemand mit dieser Situation im Mobile Office zu arbeiten oder zu führen umgeht und sich nach dem Lockdown wieder umstellt, ist auch eine Typfrage. Manche Kolleg*innen und Führungskräfte werden auf die gewohnten Arbeitsroutinen zurückgreifen. Das kann sinnvoll sein. Ob es für ihren Betrieb, ihr Unternehmen passt, ist festzustellen. Andere werden viel Gutes an der Möglichkeit, im Homeoffice zu arbeiten entdeckt haben und vieles nicht mehr missen wollen. Es wird nicht um ein „entweder – oder“ gehen. Nur Mobile Office oder doch nur wieder im Büro sein. Es wird darum gehen, Gutes auszubauen und den Umfang dessen, was sich in den vergangenen Wochen als möglich gezeigt hat, jetzt und für die Zukunft auszubauen. Dafür gibt es nicht DAS Patent-Rezept. Jedes Unternehmen hat seine eigenen Produktionsabläufe und Kultur. Jede Führungskraft ist anders. Was passt und was weiter gefördert werden soll, gilt es herauszufinden. Jetzt.</span></p><h2><b>Verstärken, was gut läuft – Retrospektiven zum Homeoffice danach</b></h2><p><span>Wie es zukünftig sein soll, kann Stück für Stück herausgefunden und implementiert werden. Das Gute an diesem Vorgehen ist, dass sich Unternehmen in kurzen Zyklen an neue Methoden herantasten können. Zum Beispiel, indem Führungskräfte mit ihren Teams sichtbar machen, was gut läuft und warum. Dies am besten mit lösungsfokussierten Fragen wie: Mit welchen Techniken können wir gut zusammenarbeiten? Welche technischen Möglichkeiten sind schnell erlernbar und bieten Vielfältigkeit in der Zusammenarbeit? Welche Arbeitsmethoden online sind sicher? Wie hat unsere Kommunikation funktioniert? Welche Organisationsabläufe müssen wir verändern und welche Absprachen treffen? Wie sind unsere Arbeitsergebnisse?</span></p><p><span>In der agilen Softwareentwicklung nutzen wir für genau solche Prozesse das Instrument der Retrospektive. Mit bestimmten Fragestellungen und Abläufen gehen wir Dingen detaillierter auf den Grund und machen für alle sichtbar, was ist. Wir sammeln Informationen und Erfahrungen einer bestimmten Zeitspanne. </span></p><p> </p><div><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Bv7WQ1SMCOasXk0OBAfk" alt="Mobiles Arbeiten erfolgreich einbinden" width="700" height="495" /><p>Quelle: Pixabay</p></div><p><span>Im nächsten Schritt werten wir aus. Warum ist was passiert und wer trug dazu bei? Wo hakte es, für wen und warum? Wodurch lief es in anderen Bereichen gut? Dadurch entsteht ein Bild dessen, was passierte und welche Hintergründe eine Rolle spielten. Dieses Bild ist nachvollziehbar für alle: Für Führungskräfte und Teammitglieder und ist die Basis für Entscheidungen, die darauf entwickelt werden. Und die von einer großen Mehrheit mitgetragen werden können. </span></p><p><span>Dann geht es zum nächsten Schritt. Wie soll es in der nächsten Zeitspanne weitergehen? Was wollen wir implementieren und mit welchem Ziel? Was soll neu eingerichtet oder ausgebaut werden? Wie werden unsere Organisationsabläufe im Mobile Office abgebildet? Wie wollen wir mit wem über was kommunizieren? Welche Aufgaben will ich meinen Mitarbeitern übertragen und welche will ich auf welchem Weg nachvollziehen? </span></p><p><span>Sind die Entscheidungen getroffen, werden sie implementiert. Führungskräfte, Mitarbeiter*innen und Teams leben nun das, was in der Retrospektive erarbeitet wurde und machen neue Erfahrungen. Dies in einer definierten Zeit. Denn es gilt in Schritten immer das Beste in den nächsten Schritt zu implementieren. Die einzelnen Experimente, denn um nichts anderes handelt es sich bei den für eine Zeit getroffenen Entscheidungen, werden in der nächsten Retrospektive auf den Prüfstand gestellt. Haben sie die Erwartungen erfüllt? Werden sie beibehalten, angepasst oder zugunsten eines anderen Experiments ganz fallen gelassen? Das trägt in der Regel dazu bei, Veränderungen leichter einzuführen, denn sie gelten erst einmal nur für eine bestimmte Zeit. Viele Change-Prozesse scheitern, weil genau das nicht passiert: eine offene genaue Analyse dessen, was ist und die konkrete und sukzessive Umsetzung weiterer Schritte, die von vielen getragen wird. Gut beraten sind Unternehmen und Führungskräfte, die Kräfte bündeln und Unternehmens-Ressourcen zielbringend einsetzen wollen, Mitarbeiter*innen die Möglichkeit zu geben mitzuarbeiten, sich einzubringen, Kritik zu äußern und ernstgenommen zu werden. Passiert das nicht, ist es nicht selten, dass aller Vorsprung verspielt wird. Das ist teuer und macht Frust. Zu wissen, dass einzelne, kleine Veränderungen erst einmal für eine begrenzte Zeitperiode gelten und dann wieder reflektiert werden, kann es leichter für Mitarbeiter*innen machen, sie anzunehmen. Und genau damit können Sie diesen Veränderungsprozess für Ihr Unternehmen erfolgreich machen.  </span></p><p> </p><section><h2><b>Höhere Produktivität im Homeoffice – Einige Ergebnisse aus Studien</b></h2><p><span>Studien aus den letzten Jahren haben gezeigt, dass der Anteil von Beschäftigten, die das Mobile Office regelmäßig nutzen, gestiegen ist (<a href="https://www.zew.de/de/presse/pressearchiv/homeoffice-bietet-beachtliche-vorteile-hat-aber-auch-tuecken/" target="_blank">Studie Institut für Arbeitsmarkt- und Berufsforschung 2019</a> ). Die Beschäftigten kamen hauptsächlich aus den Bereichen Dienstleistung, Verwaltung, Marketing & Vertrieb. Betriebe sehen die Vorteile, auf diese Art zu arbeiten, in einer höheren Produktivität (46 %), einer besseren Vereinbarkeit von Beruf und Familie (55 %), einer höheren Flexibilität für ihre Mitarbeiter*innen sowie eine bessere Erreichbarkeit (47 % ). Beschäftigte sind der Meinung, dass sie ihre Tätigkeit besser ausüben können (56 %), die Vereinbarkeit von Job und Familie besser gelingt (52 % ), die Fahrzeit gespart werden kann (55 %) und eine höhere Arbeitszeit möglich ist (38 %).</span></p><p><span>Auch </span><span>eine Studie der Universität Stanford (2015)</span><span> kam zu dem Ergebnis, dass die Produktivität von Arbeitnehmern im Homeoffice um 13 Prozent stieg. Hintergründe waren weniger Ablenkung, sondern die Möglichkeit, konzentrierter zu arbeiten und selbst zu entscheiden, wann es ins Büro oder ins Mobile Office geht. </span></p><p><span>Die internationale Arbeitsorganisation (IAO) </span> fand 2017 heraus <span>, dass Beschäftigte im Homeoffice innovativer arbeiten und in ihrer Arbeit verstärkt neue Wege gehen. Beim Thema Gesundheit sind die Antworten differenzierter. Einige stellten fest, dass sie weniger Pausen machten und es stressiger sein kann im Homeoffice, weil es keine Trennung mehr zwischen Arbeit und Privatem gibt. Für andere war es genau nicht so. Gerade in der aktuell sehr uncharakteristischen Zeit erzeugt das erzwungene Jonglieren von Job, Erziehung, Haushalt, Freizeit und Beziehung teils sehr hohe Stresslevel. Dies gilt es bei all den positiven Aspekten stets im Auge zu behalten, zu adressieren und experimentell zu bearbeiten. Auf der anderen Seite werden Office Hours hinfällig. Das heißt, es ist in gewissen Rahmen für die Kolleg*innen möglich, die Zeit für sie optimaler zu gestalten. Wenn es der Kalender erlaubt, kann man zum Beispiel nachmittags mit den Kindern spielen und später in Ruhe noch einzelne Arbeiten erledigen.</span></p><p><span>Auch die Produktion versucht Neues. Bei Continental, einem Hersteller für Reifen und Autozulieferer, testen seit 2018 auch Fabrikarbeiter Homeoffice in der Elektronikfertigung. Sie prüfen mit Hilfe von Fotos am PC zuhause fehlerhafte Leiterplatten. </span></p><p><span>Im Recruiting ist in vielen Branchen Homeoffice nicht mehr nur Goody, sondern Pflicht, um gute Mitarbeiter zu bekommen. So wurden Menschen der sogenannten Generation Z, die nach 1994 geboren sind, befragt, was für sie der wichtigste Wert im Berufsleben ist. Über 70 Prozent wollen Zufriedenheit im Job und die Möglichkeit, im Homeoffice zu arbeiten. („Recruiting Trends“-</span><a href="https://media.newjobs.com/id/hiring/419/page/Recruiting_Trends_2020/Studien_2020_Generation-Z.pdf" target="_blank"><span>Studie</span></a> <span>, CHRIS der Universitäten Bamberg und Erlangen-Nürnberg).</span></p></section><section><h2><b>Homeoffice und mobiles Arbeiten sind definiert</b></h2><p>Homeoffice unterliegt in Deutschland bestimmten Richtlinien und ist in der <a href="https://www.bundestag.de/resource/blob/516470/3a2134679f90bd45dc12dbef26049977/WD-6-149-16-pdf-data.pdf" target="_blank">Arbeitsstättenverordnung</a>  definiert. Denn Homeoffice bedeutet, dass ein Büro zu Hause vom Arbeitgeber eingerichtet ist. Besonders die Bereiche Arbeitssschutz und Datenschutz sind hier betroffen. Anders beim mobilen Arbeiten. Hier gibt es keine Bindung an einen festen Arbeitsplatz. Darum kann er auch nicht von jeder Branche, die mit besonders sensible Daten arbeitet, genutzt werden.</p></section>

Verstärken, was gut läuft – Retrospektive zum Mobile Office

Estuarine Mapping – Wie komplexe Organisationen von natürlichen Ökosystemen lernen können

<p><span>Backlog refinement meetings can become unrewarding and tedious really fast if you have to work through 20 stories in two hours. Wouldn’t it be nice if there was a format where a team could use its full energy while at the same time upping their flexibility in planning? I think there is, and I like to call it <em>story time</em>. In short, a story time is a daily 10-minute timebox after the daily standup that is used to refine exactly one backlog item. I’ll explain the basic rules as well as some advantages and disadvantages based upon my experience with it.</span><span></span></p><h2>The problem</h2><p><span>Usually, a Scrum team blocks roughly 10% time of their sprint for backlog refinement. This amount of time was once advocated as an upper limit in the Scrum Guide, but has been removed now for some time. Still, it is quite present. In my experience and that of my colleagues, this is mostly done within one or two  meetings that last one or two hours in a two-week sprint.</span></p><aside><h3>One meeting, many names</h3><p><span>This meeting is mostly known under the term “backlog refinement” meeting. There is also the term “backlog grooming” to emphasize the fact that a backlog needs to be groomed like a garden. This naming has been largely abandoned as its name is a little too close to</span><a href="https://www.childsafenet.org/new-page-15" target="_blank"> <span>cyber-grooming</span></a> <span>. I always liked the name “story time” best. Coined by</span>Kane Mar <span>, it beautifully shows the focus on telling customer stories instead of solution tickets. A team with which I moved from a classic 2-hour refinement to this new format connected the name “story time” with the new format. It helped them separate the two formats; since then I’ve been introducing the new format to teams as story time.</span></p></aside><p><span>The PO will discuss backlog items with the team in a normal backlog refinement meeting. The story will be told and the item is worked on until it fulfills the team’s</span><a href="https://www.scruminc.com/definition-of-ready/" target="_blank"> <span>definition of ready (DoR)</span></a> <span>. Ideally all colleagues are constantly engaged in discussion so that all aspects of the topic can be brought up. In reality, though, some team members contribute to some stories, some to others and some keep quiet most of the time. They may participate in estimation (if practiced) but otherwise abstain from the discussion. This is usually the main reason why those meetings are perceived as tiresome, inefficient and sluggish. On top of that, it is not uncommon that the last items in the timebox get rushed through because everyone just wants to get it over with.</span></p><div><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Hf0oKL6lScukKZIHwGsU" alt="Long refinement meetings can be very tiresome" width="1024" height="683" /></div><p><span>In order to understand the workings and see if this could be optimized, I’ve tracked the time during some of those meetings for each story. It turns out that most of the items generlly took slightly less than ten minutes. One discussion later there was the first experiment for a ten-minute story time meeting and many more would follow.</span></p><p><span>To keep those meetings short and efficient, I usually start with a very restrictive rule set. As soon as the teams have had the chance to gather some experience with the format, some small adjustments are made, in other words:</span><a href="https://www.scrum.org/resources/blog/three-pillars-empiricism-scrum" target="_blank"> <span>inspect and adapt</span></a> <span>.</span></p><aside><h3>Product backlog item (PBI) or user story (US)?</h3><p><span>I’m using <em>product backlog item</em> or <em>short backlog item </em>and <em>user story </em>interchangeably. The</span><a href="https://scrumguides.org/scrum-guide.html" target="_blank"> <span>Scrum Guide</span></a> <span> refers to those things as product backlog item or PBI. Those are requirements that have to be refined in order to be worked upon.</span><a href="http://www.extremeprogramming.org/rules/userstories.html" target="_blank"> <span>User story</span></a> <span> is a term from</span><a href="http://www.extremeprogramming.org/" target="_blank"> <span>extreme programming (XP)</span></a> <span>, an agile process that perfectly combines with Scrum. The gist is that requirements shouldn’t describe a solution to be implemented but rather understand the end users’ story in order for the development team to find a matching solution as the subject matter experts. User stories are widely used and absolutely recommended in order to get from doing to creating.</span></p></aside><p> </p><h2>The rules</h2><ol><li><span>Every day after the daily there will be a 10-minute story time slot. This ensures that there won’t be an extra meeting in the team’s calendar. Since the team gathered for the daily, they are active and energized enough for a ten-minute session.</span></li><li><span>Exactly one item will be discussed per session. If the team finishes early, rejoice and move on.</span></li><li><span>If it looks as though the timebox won’t do for the current issue, have a break issued by a timekeeper (e.g. the Scrum Master) after about eight minutes. Use the last two minutes to gather the questions/todos/research needed to get this story ready. Write those items on the card/into the ticket and solve them asynchronously before continuing this topic in a later story time session. Alternatively, if the presented story is clearly too large, you may use the timebox to simply split it into multiple smaller stories and use later story time slots to go over them piece by piece according to your priority.</span></li></ol><h2><img loading="lazy" width="1024" height="1165" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/VupPlmhSnCdvaz4pua0x" alt="rules check list for story time" /></h2><p> </p><h2>Benefits</h2><p><span>There are immediate and obvious benefits for the PO. She gains a lot of flexibility and speed in dealing with stakeholders and their new ideas/issues as well as newly uncovered information. This is because she can plan anew each day which story to refine next. A common issue with only occasional refinement meetings was a story uncovered right after the last meeting in the sprint. Even with a high priority, such issues had to either be refined in a planning or pushed to a later sprint. Story time now enables the team to at least talk about it and see if it is ready and can be planned for the next sprint.</span></p><p><span>Another benefit is the endless energy that is released. Even after a fully utilized daily of 15 minutes the combined meeting time won’t exceed 25 minutes. Unlike long meetings with a lot of context switches, this can be accomplished without losing a relevant amount of energy. Speaking of context switches: one of the major reasons for wasting energy is completely eliminated compared to longer refinement sessions, since only one item will be discussed. This goes very smoothly with the idea of a sprint as a focussed timebox since there is no additional meeting anymore. The asynchronously gathered information between story times also eases the pressure often perceived by the teams to discuss a story out of the blue.</span></p><p> </p><h2>Some caveats</h2><p><span>As with most tools, story time is not a silver bullet. There are some drawbacks. Many items that belong together have to be refined over several separate days. This can lead to some redundancies in the ensuing discussions, some facts will be uncovered a couple of times over. If the backlog is very fragmented, the team might forget certain facts that have not been explicitly written down (which is a necessity anyhow). The same thing does happen in big refinement meetings as well but tends to be overlooked. On the other hand, this beautifully shows where there is still implicit knowledge and silos, which in turn should be addressed, made transparent and be worked upon with utmost urgency.</span></p><p><span>Bigger topics cannot be refined from start to finish in such a small timebox. There are at least two ways to deal with those. For bigger items the story time can be used to split those into smaller stories. Those can then be refined in further installments. If we are talking about really big topics like themes, major epics and such, it usually makes sense to have a separate workshop to get a grip on the topic before diving into multiple story times (e.g. kick-off, story mapping, lean canvas, …).</span></p><p><span>It can feel challenging for a PO to decide which item to work on. However, this aspect usually doesn’t matter so much in daily business due to the higher cadence of the story time meetings. It rather takes pressure off the PO since she can just tackle the other story on the next day.</span></p><p> </p><h2>Conclusion</h2><p><span>So far, every team that had previously worked with classic refinements has given enthusiastic feedback after their first story times. The benefits by far outweigh the caveats. The POs love the flexibility and the team members rejoice in more focus time during their sprints.</span></p><div><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Ex2XRWXCRTyJxsQUlxFp" alt="All teams kept pursuing the new approach" width="1024" height="683" /></div><p><span>This article is part of a still loosely connected series dubbed “Agile Toolbox”. I’ve put the links to more articles down below. If you have any questions or experiences with this format, or something similar, please let us know. If you happen to have stumbled over a topic you would like to read more information or stories about, leave us a note. We’ll be happy to tap into our vast combined experience to share it with you.</span></p><p>Other articles from the Agile Toolbox:</p><ul><li><a href="/wissens-hub/blog/eventstorming-meets-domain-driven-design-with-alberto-brandolini">Eventstorming meets Domain Driven Design with Alberto Brandolini</a> </li><li><a href="/wissens-hub/blog/mob-programming-shared-everything">Mob programming and shared everything</a> </li><li><a href="/wissens-hub/blog/retrospective-on-the-value-stream-of-your-software-delivery">Retrospective on the value stream of your software delivery</a> </li></ul><p> </p><p>Image sources:</p><ul><li>F<a href="https://www.pexels.com/de-de/foto/junge-genervte-freiberuflerin-mit-laptop-zu-hause-3808008/">oto by Andrea Piacquadio from Pexels</a> </li><li><a href="https://www.pexels.com/de-de/foto/mann-im-grauen-rundhals-hemd-das-frau-im-roten-hemd-halt-5684562/">Foto by Thirdman from Pexels</a> </li><li><a href="https://pexels.com/de-de/foto/foto-von-leuten-die-einander-die-hande-halten-3184436/">main image by fauxels from Pexels</a> </li><li>my own drawing</li></ul>

Agile Toolbox: 10-minute story time

Agile Consultant

The universal recommender in Action(ML)

Data Scientist

Senior IT Consultant

# Feature-Sliced Design und was wir für eine gute Frontend-Architektur brauchen

Während zum Thema Softwarearchitektur im Backend schon viel publiziert wurde und es gut erprobte Best-Practices gibt, is dieses Thema für Frontend-Anwendungen weniger präsent und wird häufig eher vernachlässigt.

Angesichts der gestiegenen Komplexität von Frontend-Anwendungen durch erhöhte Anforderungen an UX und UI in den letzten Jahren, ist eine solide Anwendungsarchitektur unerlässlich, sofern die Weiterentwicklung auch die nächsten Jahre noch Spaß machen soll.

Die Methodik Feature-Sliced Design kann eine Lösung sein, um komplexe Frontend-Anwendungen mit einer sauberen Software Architektur zu strukturieren.

## Was ist eine gute Software Architektur im Frontend?

Die Tage, an denen ein Frontend lediglich dazu da war, Daten zu formatieren und im Client anzuzeigen, sind lange vorbei. Ein modernes Frontend muss komplexe Statusänderungen, Benutzerinteraktionen und diverse Schnittstellen verarbeiten. Oft arbeiten mehrere Entwickelnde am selben Code und Änderungen müssen zeitnah umgesetzt werden können.

Mit einer “gewachsenen” Segmentierung der Anwendung in zweckgebundene Gruppen wie Services, Shared, UI, Api, o.ä. und ungeordneten Abhängigkeiten zueinander wird man den Anforderungen an eine saubere Architektur schnell nicht mehr gerecht. Man riskiert Wildwuchs, neue Mitarbeitende tun sich damit schwer, sich mit dem Quellcode vertraut zu machen und jede Änderung wird zu einem Risiko.

Für eine “saubere Anwendungsarchitektur” im Hinblick auf die Anwendungsstruktur sollten folgende Qualitätskriterien gelten:

- **Klarheit und Verständlichkeit**: Softwarearchitektur sollte klar und leicht verständlich sein. Entwickelnde und Stakeholder sollten sie leicht verstehen und navigieren können.
- **Skalierbarkeit**: Eine Anwendung sollte in der Lage sein, mit der Zeit zu wachsen und sich zu erweitern, um neue Anforderungen und Funktionen zu erfüllen.
- **Flexibilität**: Anpassungen an neue Anforderungen sollten mit geringstmöglichem Aufwand umgesetzt werden können, ohne dass das gesamte System neu gestaltet werden muss.
- **Wartbarkeit**: Eine Anwendung sollte so gestaltet sein, dass sie leicht gewartet und aktualisiert werden kann. Fehler können schnell lokalisiert und behoben werden.
- **Konsistenz**: Die Struktur einer Anwendung sollte konsistent sein, d.h. sie sollte einheitliche Muster und Praktiken verwenden.

Oder wie es Douglas Crockford gesagt hat:

> “Good architecture is necessary to give programs enough structure to be able to grow large without collapsing into a puddle of confusion.”

Um das zu erreichen, hilft uns ein Korsett aus Regeln und Leitplanken, die uns bei der Erweiterung einer Anwendung unterstützen.

Eine Antwort hierfür bietet die Methodik **Feature-Sliced Design**.

## Wie funktioniert Feature-Sliced Design (FSD)

Im Grunde ist FSD nur eine Strukturvorgabe für Anwendungen mit einem Regelsatz, wie Elemente miteinander in Abhängigkeit stehen dürfen.

Dabei ist die Einteilung der Anwendung in 3 Ebenen ein zentraler Bestandteil: **Layers**, **Slices** und **Segments**.

<img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/4aykmzDUQ0S3CBHLAckg" alt="Feature-Sliced Design Layers, slices and Segments" width="840">

Die Unterteilung erfolgt in einer Hierarchie von links nach rechts. D.h. ein _Layer_ ist in _Slices_ unterteilt und ein _Slice_ ist wiederum in _Segments_ unterteilt.

_App_ und _Shared_ bilden dabei eine Ausnahme insofern, dass sie keine _Slices_, sondern nur _Segments_ unter sich haben.

Eine Beispielhafte Ordnerstruktur in einer Anwendung könnte also so aussehen:

<img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/HAPTb1OdTuKJkatY5KNR" alt="Feature-Sliced Design Folders and Slices" width="640">

Während die Wahl der _Slices_ die Geschäftslogik der Anwendung abbildet und in der Benennung keine Konvention vorgibt, gibt es bei der Auswahl der _Layer_ und _Segments_ gewisse Vorgaben.

## Layers

Die in der Grafik genannten Layer _App_, _Pages_, _Widgets_, _Features_, _Entities_ und _Shared_ sind von FSD vorgegeben, müssen aber nicht alle verwendet werden.

Neben der Benennung gibt FSD eine weitere wichtige Regel vor: **Jeder Layer darf nur von Layern unterhalb seiner Hierarchie wissen**. D.h. _Pages_ darf nur _Widgets_, _Entities_ und _Shared_ nutzen. _Shared_ dagegen darf selbst keine Abhängigkeiten zu anderen Komponenten haben, auch nicht innerhalb des eigenen Layers.

Diese Vorgabe macht weiter Sinn, wenn man sich den Zweck der unterschiedlichen Layer anschaut:

### App

Ist für die Laufzeitumgebung bzw. Bootstrapping der Anwendung zuständig. Konfigurationen, Style Definitionen und State Management auf globaler Ebene passen hierher. Darüber hinaus macht es Sinn, das Routing hier zu verorten. Typischerweise gibt es hier keine weitere Unterteilung in Slices, da sich hier keine Fachlogik befinden sollte.

### Pages

Unterhalb _Pages_ sollten komplette Ansichten, z.B. verknüpft durch Top-Level-Routing in dedizierten _Slices_ angelegt werden.

Typischerweise sind die _Slices_ in _Segments_ unterteilt, da hier viele Seiten-spezifische Komponenten, Services und Konfigurationen organisiert werden müssen.

Im Prinzip alles, was nicht an anderer Stelle wiederverwendet wird, ist innerhalb eines Seiten-_Slice_ und damit eng angebunden an ihren Verwendungszweck gut aufgehoben.

In der weiter unten skizzierten E-Commerce Anwendung wären das z.B. Seiten wie Warenkorb, Checkout, Produktübersicht- und Produktdetailseite.

### Widgets

In sich gekapselte, größere Sektionen auf einer Seite können als Widgets angelegt werden.

Wenn ein UI-Block nicht seitenspezifisch, also generisch und wiederverwendbar ist, macht es Sinn ihn als Widget anzulegen.

Da Widgets eigene Fachlogik, spezifische Konfigurationen und Services besitzen und aus mehreren Komponenten bestehen können, macht es Sinn diese in _Slices_ einzuteilen, die wiederum in _Segments_ zu unterteilt sind.

Header und Footer wären typische Beispiele für ein Widget oder auch Sektionen mit ähnlichen Produkten.

### Feature

Ein _Feature_ beschreibt eine konkrete Funktionalität der Anwendung. Typischerweise eine Nutzerinteraktion, die wiederverwendbar ist, oder so auch an anderer Stelle genutzt werden könnte. Ein erster Blick in den Feature-Layer sollte einem direkt einen Überblick über die wichtigste Funktionalität bzw. Nutzer Mehrwert der Anwendung geben.

Auch hier macht die Unterteilung in _Slices_ und dann weiter in _Segments_ Sinn.

Interaktionselemente wie ein "Kaufen"- oder "Favoriten"-Button oder die Warenkorbvorschau im Headerbereich machen als Feature Sinn.

### Entities

_Entities_ sind alle Objekte, die für die Geschäftslogik unerlässlich sind.

Dabei geht es hier nicht nur um die Typdefinitionen, sondern auch um die damit verbundene Geschäftslogik und Backend-Anbindung. Sollte eine _Entity_ eine spezifische Darstellung in der Anwendung haben, macht es Sinn, diese hier zu verordnen.

Bei einer E-Commerce Anwendung wären das z.B. Produkt, Warenkorb oder Kunde.

### Shared

Der _Shared_ Layer ist nicht in _Slices_ unterteilt, da sich hier nur sehr generische Komponenten, Bibliotheken und Services mit hoher Wiederverwendbarkeit und minimalen äußeren Abhängigkeiten befinden sollten und keine Einteilung in Fachlogik.

Innerhalb der _Segments_ von _Shared_ darf es, wie in allen anderen Layern auch, Abhängigkeiten geben.

In der Praxis finden wir hier z.B. Formatierungshelfer und sehr generische UI-Komponenten wie Dialoge, Buttons oder Tooltips. Genauso wie wiederverwendbare Abstraktionen für die Anbindung an Schnittstellen.

## Slices

_Slices_ stellen die Gruppierung nach Fachlichkeit in jedem _Layer_ dar. Über die Benennung gibt es keine Vorgaben, jedoch sollte der fachliche Kontext dabei berücksichtigt und darauf geachtet werden, dass der Code gut navigierbar ist. _Slices_ sollten lose gekoppelt und weder Abhängigkeiten im selben noch auf darüberliegende _Layer_ haben. Der Grad der Kohäsion dagegen sollte hoch sein.

## Segments

Im Gegensatz zu _Slices_ sind _Segments_ nicht nach ihrem fachlichen Zweck gruppiert, sondern nach ihrem technischen.

Es gibt hier keine strikten Vorgaben darüber, welche _Segments_ in einer Anwendung verwendet werden sollten oder über deren Benennung. Als Leitlinie macht aber eine einheitliche Segmentierung über alle _Slices_ der Anwendung Sinn.

**FSD schlägt folgende Segments vor:**

| Ordner     | Beschreibung                                                    |
| ---------- | --------------------------------------------------------------- |
| **ui**     | Benutzeroberflächen, UI-Komponenten mit Styles und Formatierung |
| **api**    | Backend Anbindungen oder Schnittstellen zu externe Services     |
| **model**  | Datentypen und Schemata State-Management                        |
| **lib**    | Hilfs-Bibliotheken, die von mehreren Modulen verwendet werden   |
| **config** | Konfigurationen und Feature-Flags                               |

## Abhängigkeiten mit klarer Richtung

Als praktisches Beispiel habe ich hier eine [Angular Anwendung](https://github.com/felixabele/pizza-sliced-design-shop/tree/main) erstellt, die eine rudimentäre E-Commerce-Lösung abbildet:

<img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/leHkmP4fQ6msCJ3klSNw" alt="Feature-Sliced Design Sample project structure" width="640">

Hier sehen wir, dass alle Pfeile zwischen den _Layern_ strikt von oben nach unten verlaufen. Außerdem gibt es zwischen den _Slices_ eines _Layers_ keine Beziehungen.

Dadurch, dass die Abhängigkeiten aller Komponenten zueinander klar geregelt sind und nur in eine Richtung erfolgen darf, beseitigen wir Risiken von zirkulären Abhängigkeiten und zu enger Kopplung.

Im Sinne einer “ordentlichen Anwendungsarchitektur” kommen wir unseren Zielen schon etwas näher:

- **Klarheit und Verständlichkeit**: Die Einteilung in _Layer_, _Slices_ und _Segments_ ist sowohl fachlich als auch technisch geregelt, so sollte das Was und Wie einer Komponente klar und die Navigation innerhalb der Struktur erleichtert sein.
- **Skalierbarkeit**: FSD hat ein klares Konzept, wie Anwendungen zerteilt und in wiederverwendbaren Komponenten organisiert werden können. Außerdem eignet sich die Struktur hervorragend für besonders große und komplexe Anwendungen.
- **Flexibilität**: Durch Entkopplung von Abhängigkeiten können Komponenten verändert oder entfernt werden, ohne unvorhersehbare oder schwer zu durchschauende Seiteneffekte.
- **Wartbarkeit**: Auch hier ist die Entkopplung von Abhängigkeiten ein entscheidender Faktor. Darüber hinaus hilft die klar definierte Richtung der Abhängigkeiten Fehler einzugrenzen.
- **Konsistenz**: Dadurch, dass FSD einige Regeln und Namenskonventionen vorgibt und gleiche Konzepte auf verschiedenen Ebenen anwendet, haben wir eine einheitliche Anwendungsstruktur.

Diese Effekte setzen natürlich ein einheitliches Verständnis im Team über die Architekturvorgaben und FSD voraus, so wie das _Commitment_ diese einzuhalten.

## Regeln brauchen Kontrolle

Glücklicherweise müssen wir uns bei der Entwicklung nicht darauf verlassen, dass alle Beteiligten die Regeln kennen und sich daran halten. _ESLint_, das in den meisten Frontend Projekten ohnehin schon zur Kontroller der Einhaltung von Code-Styles und -Standards eingesetzt wird, kann mit [feature-sliced/eslint-config](https://www.npmjs.com/package/@feature-sliced/eslint-config) so erweitert werden, dass Verstöße gegen die Beziehungsregeln von FSD moniert werden.

Noch einen Schritt weiter geht dabei die Bibliothek [steiger](https://www.npmjs.com/package/steiger). Hier werden über die Kontrolle der Abhängigkeiten hinaus auch Namens-Konventionen und allgemeine FSD-spezifische _Best Practices_ überprüft, wie z.B. ob ein Widget wiederverwendet wird, ob _Slices_ im entsprechendem _Layer_ erlaubt sind oder zu viele davon verwendet werden uvm.

Um die Erstellung von Ordnern zu erleichtern und gleich Barrel-Files an der richtigen Stelle anzulegen, kann eine praktische [CLI-Bibliothek](https://github.com/feature-sliced/cli) genutzt werden. Es gibt auch schon Plugins für IntelliJ und VS Code.

## Ist Feature-Sliced Design die Rettung?

Nur wenige Frontend-Frameworks und Bibliotheken geben einen strikten Regelsatz vor, wie Anwendungen organisiert sein sollten. Und das ist auch gut so. Führt aber auch dazu, dass Anwendungen mit der Zeit zum Wildwuchs tendieren, schwer wartbar werden und für neue Teammitglieder undurchdringlich erscheinen. Fehlerraten häufen sich und die Entwicklungszeit für neue Features steigt mit der Komplexität der Software.

Selbst wenn für das Projekt schon Regeln und Konventionen definiert wurden, sind diese oft nur projektspezifisch und müssen beim Onboarding erst noch verinnerlicht werden.

FSD schreibt sich auf die Fahne eine projekt- und technologie-übergreifende Methodik bereitzustellen, die sich an gängigen Best-Practices orientiert und in der Praxis bewährt hat.

Wird diese Projektübergreifend angewendet, spart man sich Diskussionen über Architektur-Entscheidungen und hat eine einheitliche Projektlandschaft, in der sich Mitarbeitende schnell zurechtfinden.

Ganz so einfach ist es natürlich nicht und das wird schnell klar, wenn man sich Referenzprojekte nach FSD anschaut oder eigene Praxiserfahrungen damit sammelt.

Diese Projekte sind in der Regel nicht so einheitlich, wie man sich das wünschen würde. Man merkt schnell, dass die Frage, ob etwas ein _Feature_, ein _Widget_ oder doch besser eine _Entity_ ist, manchmal etwas Interpretationsspielraum zulässt.

Gerade die Einschränkung, nur Code in andere Layer zu extrahieren, wenn dieser auch an mehreren Stellen wiederverwendet wird und ansonsten im entsprechenden _Slice_ der _Page_ zu halten kann dazu führen, dass Komponenten umher geschoben werden oder eben nicht mehr einheitlich navigierbar sind.

Bei manchen Vorgaben macht es durchaus Sinn, im Team bewusst über Abweichungen zu sprechen und diese schriftlich im Projekt festzuhalten.

## Was lernen wir aus Feature-Sliced Design und sollten wir es in unserem nächsten Projekt einsetzen?

Die Ansätze von FSD sind für jedes Frontend-Projekt enorm wertvoll!

Gerade wenn man sich noch keine Gedanken über eine grundlegende Architektur gemacht hat und nicht weiß, wie man man seine Anwendung strukturieren sollte.

Eine klare Gliederung in Features, also was der Code tut, und in Technologie, also wie der Code etwas tut, macht in jedem Fall Sinn. Die Kohärenz dabei hochzuhalten, ist ebenso ein sehr sinnvoller Ansatz.

Abhängigkeiten von Modulen über Regeln klar zu definieren, hilft dabei wartbare und robuste Anwendungen zu entwickeln und wird von einigen Frameworks wie [NX](https://nx.dev/features/enforce-module-boundaries) out-of-the Box unterstützt oder kann schnell über eine Bibliothek wie [eslint-plugin-boundaries](https://www.npmjs.com/package/eslint-plugin-boundaries) in jedem Projekt eingesetzt werden.

Ob es gleich eine umfangreiche Methodik wie FSD sein muss, hängt auch davon ab, wie groß und wie langlebig das Projekt sein wird. Wenn man eine kleinteilige Micro Frontend Architektur, eine Website ohne komplexere Business-Logik oder einen kurzlebigen Proof-Of-Concept aufbaut, ist die Granularität von FSD vielleicht überdimensioniert.

In jedem Fall sollte man sich bei jedem Projekt Gedanken über die Architektur machen und dabei hilft es sicherlich, sich an erprobten Best Practices, wie sie z.B. in FSD definiert sind, zu orientieren.

Weiterführende Informationen zu FSD finden sich auf der [Informationsseite der Community](https://feature-sliced.design/).


Feature-Sliced Design und was wir für eine gute Frontend-Architektur brauchen

# Feature-Sliced Design and what we need for good frontend architecture

While a lot has been published on the topic of software architecture in the backend, and there are well-established best practices, this topic is less prominent for frontend applications and is often neglected.

Given the increased complexity of frontend applications due to higher demands on UX and UI in recent years, a solid application architecture is essential if the development is to remain enjoyable in the coming years.

The Feature-Sliced Design methodology can be a solution for structuring complex frontend applications with a clean software architecture.

## What is good software architecture in the frontend?

The days when a frontend was merely there to format data and display it in the client are long gone. A modern frontend must handle complex state changes, user interactions, and various interfaces. Often, multiple developers work on the same code, and changes need to be implemented promptly.

With a "grown" segmentation of the application into purpose-bound groups like Services, Shared, UI, Api, etc., and unordered dependencies between them, one quickly fails to meet the requirements of a clean architecture. One risks chaos, new team members struggle to familiarize themselves with the source code, and every change becomes a risk.

For a "clean application architecture" in terms of application structure, the following quality criteria should apply:

- **clarity and understandability**: Software architecture should be clear and easy to understand. Developers and stakeholders should be able to easily understand and navigate it.
- **scalability**: An application should be able to grow and expand over time to meet new requirements and features.
- **flexibility**: Adjustments to new requirements should be possible with minimal effort, without the need to redesign the entire system.
- **maintainability**: An application should be designed so that it can be easily maintained and updated. Errors can be quickly located and fixed.
- **consistency**: The structure of an application should be consistent, i.e., it should use uniform patterns and practices.

Or as Douglas Crockford put it:

> “Good architecture is necessary to give programs enough structure to be able to grow large without collapsing into a puddle of confusion.”

To achieve this, a framework of rules and guardrails helps us in extending an application.

One answer to this is the **Feature-Sliced Design** methodology.

## How does Feature-Sliced Design (FSD) work?

Basically, FSD is just a structural guideline for applications with a set of rules on how elements may depend on each other.

A central part of this is the division of the application into 3 levels: **layers**, **slices**, and **segments**.

<img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/4aykmzDUQ0S3CBHLAckg" alt="Feature-Sliced Design Layers, slices and Segments" width="840">

The subdivision follows a hierarchy from left to right. That is, a _layer_ is divided into _slices_, and a _slice_ is further divided into _segments_.

_App_ and _Shared_ are exceptions in that they do not have _slices_ but only _segments_ under them.

An example folder structure in an application could look like this:

<img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/HAPTb1OdTuKJkatY5KNR" alt="Feature-Sliced Design Folders and Slices" width="640">

While the choice of _slices_ reflects the business logic of the application and does not prescribe any naming conventions, there are certain guidelines for the selection of _layers_ and _segments_.

## Layers

The layers mentioned in the graphic, _app_, _pages_, _widgets_, _features_, _entities_, and _shared_, are prescribed by FSD but do not all have to be used.

In addition to naming, FSD prescribes another important rule: **Each layer may only know about layers below it in the hierarchy**. That is, _pages_ may only use _widgets_, _entities_, and _shared_. _Shared_, on the other hand, may not have dependencies on other components, not even within its own layer.

This guideline makes further sense when one considers the purpose of the different layers:

### App

Is responsible for the runtime environment or bootstrapping of the application. Configurations, style definitions, and state management at a global level belong here. In addition, it makes sense to locate routing here. Typically, there is no further subdivision into slices here, as no business logic should be located here.

### Pages

Below _pages_, complete views, e.g., linked by top-level routing, should be created in dedicated _slices_.

Typically, the _slices_ are divided into _segments_, as many page-specific components, services, and configurations need to be organized here.

In principle, everything that is not reused elsewhere is well placed within a page _slice_ and thus closely tied to its purpose.

In the e-commerce application outlined below, these would be pages such as shopping cart, checkout, product overview, and product detail page.

### Widgets

Self-contained, larger sections on a page can be created as widgets.

If a UI block is not page-specific, i.e., generic and reusable, it makes sense to create it as a widget.

Since widgets have their own business logic, specific configurations, and services, and can consist of multiple components, it makes sense to divide them into _slices_, which are in turn subdivided into _segments_.

Header and footer would be typical examples of a widget, as well as sections with similar products.

### Feature

A _feature_ describes a concrete functionality of the application. Typically, a user interaction that is reusable or could also be used elsewhere. A first look at the feature layer should immediately give an overview of the most important functionality or user value of the application.

Here, too, the subdivision into _slices_ and then further into _segments_ makes sense.

Interaction elements such as a "Buy" or "Favorites" button or the shopping cart preview in the header area make sense as features.

### Entities

_Entities_ are all objects that are essential for the business logic.

This is not only about type definitions but also about the associated business logic and backend connectivity. If an _entity_ has a specific representation in the application, it makes sense to locate it here.

In an e-commerce application, these would be, for example, product, shopping cart, or customer.

### Shared

The _shared_ layer is not divided into _slices_, as only very generic components, libraries, and services with high reusability and minimal external dependencies should be located here, and no division into business logic.

Within the _segments_ of _shared_, there may be dependencies, as in all other layers.

In practice, we find here, for example, formatting helpers and very generic UI components such as dialogs, buttons, or tooltips. As well as reusable abstractions for connecting to interfaces.

## Slices

_Slices_ represent the grouping by business context in each _layer_. There are no guidelines for naming, but the business context should be taken into account, and care should be taken to ensure that the code is easy to navigate. _Slices_ should be loosely coupled and have no dependencies within the same or higher _layers_. The degree of cohesion, on the other hand, should be high.

## Segments

In contrast to _slices_, _segments_ are not grouped by their business purpose but by their technical one.

There are no strict guidelines on which _segments_ should be used in an application or on their naming. However, as a guideline, a uniform segmentation across all _slices_ of the application makes sense.

**FSD suggests the following segments:**

| Folder     | Description                                                    |
| ---------- | --------------------------------------------------------------- |
| **ui**     | User interfaces, UI components with styles and formatting       |
| **api**    | Backend connections or interfaces to external services          |
| **model**  | Data types and schemas, state management                        |
| **lib**    | Helper libraries used by multiple modules                       |
| **config** | Configurations and feature flags                                |

## Dependencies with clear direction

As a practical example, I have created an [Angular application](https://github.com/felixabele/pizza-sliced-design-shop/tree/main) that represents a rudimentary e-commerce solution:

<img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/leHkmP4fQ6msCJ3klSNw" alt="Feature-Sliced Design Sample project structure" width="640">

Here we see that all arrows between the _layers_ strictly go from top to bottom. Also, there are no relationships between the _slices_ of a _layer_.

By clearly regulating the dependencies of all components on each other and allowing them to occur only in one direction, we eliminate the risks of circular dependencies and too tight coupling.

In terms of a "clean application architecture," we are getting closer to our goals:

- **clarity and understandability**: The division into _layers_, _slices_, and _segments_ is regulated both technically and in terms of business, so the what and how of a component should be clear, and navigation within the structure should be facilitated.
- **scalability**: FSD has a clear concept of how applications can be divided and organized into reusable components. Also, the structure is excellent for particularly large and complex applications.
- **flexibility**: By decoupling dependencies, components can be changed or removed without unpredictable or hard-to-understand side effects.
- **maintainability**: Here, too, the decoupling of dependencies is a decisive factor. In addition, the clearly defined direction of dependencies helps to limit errors.
- **consistency**: Since FSD prescribes some rules and naming conventions and applies the same concepts at different levels, we have a uniform application structure.

These effects, of course, presuppose a uniform understanding in the team of the architectural guidelines and FSD, as well as the _commitment_ to adhere to them.

## Rules need control

Fortunately, in development, we do not have to rely on all participants knowing the rules and adhering to them. _ESLint_, which is already used in most frontend projects to control compliance with code styles and standards, can be extended with [feature-sliced/eslint-config](https://www.npmjs.com/package/@feature-sliced/eslint-config) so that violations of the relationship rules of FSD are flagged.

Going one step further is the library [steiger](https://www.npmjs.com/package/steiger). Here, in addition to controlling dependencies, naming conventions and general FSD-specific _best practices_ are also checked, such as whether a widget is reused, whether _slices_ are allowed in the corresponding _layer_, or too many of them are used, etc.

To facilitate the creation of folders and to place barrel files in the right place, a practical [CLI library](https://github.com/feature-sliced/cli) can be used. There are also already plugins for IntelliJ and VS Code.

## Is Feature-Sliced Design the savior?

Few frontend frameworks and libraries prescribe a strict set of rules on how applications should be organized. And that's a good thing. But it also leads to applications tending to grow wild over time, becoming difficult to maintain, and appearing impenetrable to new team members. Error rates increase, and development time for new features grows with the complexity of the software.

Even if rules and conventions have already been defined for the project, they are often project-specific and must first be internalized during onboarding.

FSD aims to provide a project- and technology-independent methodology that is based on common best practices and has proven itself in practice.

If this is applied across projects, discussions about architectural decisions are saved, and there is a uniform project landscape in which employees can quickly find their way around.

Of course, it's not that simple, and this becomes clear quickly when looking at reference projects according to FSD or gathering practical experience with it.

These projects are usually not as uniform as one would wish. It quickly becomes apparent that the question of whether something is a _feature_, a _widget_, or better an _entity_ sometimes allows for some interpretation.

Especially the restriction to extract code into other layers only if it is reused in multiple places and otherwise to keep it in the corresponding _slice_ of the _page_ can lead to components being moved around or no longer being uniformly navigable.

For some guidelines, it makes sense to consciously discuss deviations in the team and document them in writing in the project.

## What do we learn from Feature-Sliced Design, and should we use it in our next project?

The approaches of FSD are enormously valuable for every frontend project!

Especially if you haven't yet thought about a basic architecture and don't know how to structure your application.

A clear division into features, i.e., what the code does, and into technology, i.e., how the code does something, makes sense in any case. Keeping the coherence high is also a very sensible approach.

Defining module dependencies through rules helps to develop maintainable and robust applications and is supported out-of-the-box by some frameworks like [NX](https://nx.dev/features/enforce-module-boundaries) or can be quickly used in any project via a library like [eslint-plugin-boundaries](https://www.npmjs.com/package/eslint-plugin-boundaries).

Whether it has to be a comprehensive methodology like FSD also depends on how large and long-lived the project will be. If you are building a fine-grained micro frontend architecture, a website without more complex business logic, or a short-lived proof-of-concept, the granularity of FSD may be overdimensioned.

In any case, you should think about the architecture in every project, and it certainly helps to orient yourself to proven best practices, such as those defined in FSD.

Further information on FSD can be found on the [community page](https://feature-sliced.design/).

Feature-Sliced Design and what we need for good frontend architecture

IT Consultant / Developer

Head of Berlin, Erfurt, Hamburg, Leipzig, Münster

Senior IT Consultant / DevOps Engineer

Die 5 größten Risiken für deine IT-Sicherheit – und wie du dich davor schützen kannst

Public Cloud im regulierten Sektor: Das ist zu beachten

Cloud-Lösungen in der Architekturrichtlinie des Bundes

AWS European Sovereign Cloud: Die wichtigsten Informationen

Cloud Transformation Consultant

<p>Lasst uns ein agiles Projekt starten. Von der fachlichen wie von der technischen Seite werden Spezialisten abgestellt, um ein gegebenes Problem zu lösen. Der Rahmen ist gesetzt, die Entwicklung kann also beginnen. Das Team ist frisch, die Anforderungen sind klar, was kann jetzt noch schiefgehen? Einiges, lehrt uns die Erfahrung. Gerade am Anfang ist die Leistungsfähigkeit eines Teams eingeschränkt. Diese Tatsache ist nicht neu. Zur Erklärung wird oft das 4-Phasen-Modell von Tuckman herangezogen. Genau dieses Modell wollen wir in diesem Blogartikel beleuchten.</p><h2>Tuckmans Phasenmodell (1965/1977)</h2><p>Die vier Phasen <em>forming</em>, <em>storming</em>, <em>norming</em> und <em>performing</em> werden erstmals 1965 von Bruce W. Tuckman beschrieben.<sup>[1]</sup> Es handelt sich bei dieser Arbeit um eine Review anderer wissenschaftlicher Artikel. Die Artikel beschäftigen sich mit Gruppendynamik und Teamperformance. Tuckman postuliert als Zusammenfassung ein Modell, in dem ein Team bestimmte Phasen durchwandern muss, bevor es seine optimale Leistungsfähigkeit erreicht.</p><p>1977 führte Tuckman zusammen mit Mary Ann C. Jensen eine Review seiner damaligen Arbeit durch.<sup>[2]</sup> Als Ergebnis wurde eine weitere Phase “adjourning” (hier: “unterbrechen”, “aussetzen”) hinzugefügt.</p><h3>Tuckmans postulierte Phasen</h3><table><tbody><tr><th>Phase</th><th>Charakterisierung</th></tr><tr><td>forming</td><td>“Die Teammitglieder kommen das erste Mal zusammen. Dieses Kennenlernen und erste Beschnuppern ist oft mit Unsicherheit verbunden: Werde ich vom Team akzeptiert? Kann ich mich in diesem Team voll entfalten? In dieser Phase sind die Beziehungen der Teammitglieder untereinander noch völlig offen und unklar.”</td></tr><tr><td>storming</td><td>“Die Teammitglieder versuchen, über Aufgaben- und Rollenkonflikte ihr Revier abzustecken. Diese Phase ist besonders kritisch. Stoßen hier dominante Charaktere aufeinander, kann dies den gesamten Arbeitsprozess des Teams beeinflussen. Deshalb sollte diese Phase mitunter durch einen Moderator begleitet werden.”</td></tr><tr><td>norming</td><td>“Nachdem die Machtkämpfe abgeschlossen sind, kann das Team zusammenwachsen. Das Festlegen von Regeln und die gemeinsame Definition von Rollen (<em>norming</em>) im Team unterstützen diesen Prozess.”</td></tr><tr><td>performing</td><td>“Die sich anschließende eigentliche Arbeitsphase beginnt und wird durch die Regeln gesichert.“</td></tr><tr><td>adjourning (1977)</td><td>“Für temporäre, nur vorübergehend zusammenarbeitende Teams schließen sich Ablösungsprozesse an. Die Teammitglieder lösen sich voneinander und auch von der gemeinsamen Aufgabe. Im Idealfall reflektieren sie gemeinsam oder auch individuell über ihre Teamerfahrungen und lernen daraus für folgende Gruppenarbeiten.“</td></tr></tbody></table><p>Quelle: Arbeits-, Organisations- und Personalpsychologie für Bachelor <sup>[3]</sup></p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/H6wvOawRsGTmE76FbfFQ"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/H6wvOawRsGTmE76FbfFQ" alt="Phasenmodell von Tuckman" width="700" height="393" /></a> <p>Phasenmodell von Tuckman</p></div><p>Das Modell sagt voraus, dass diese Phasen nicht nur einmal, sondern potenziell wiederholt durchwandert werden. Als Auslöser für diesen ‚Neustart‘ finden sich u.a. diese Gründe:</p><ul><li>offene Teams, die einem Mitgliederwechsel ausgesetzt sind</li><li>stabile Teams, mit wechselnden Rollen- und Aufgabenteilungen</li></ul><h2>4-Phasen-Modell: Grenzen und Kritik</h2><p>Ein wichtiger limitierender Faktor wurde bereits erwähnt: Das Modell behandelt kleine Gruppen oder Teams. Die Größenordnung selbst wurde von Tuckman et al. keineswegs festgelegt. Andere Quellen nennen eine Größe von fünf bis acht Personen.</p><p>Tuckman selbst äußerte eine gewisse Skepsis an seinem Modell, da seiner Ansicht nach die genutzten Quellen als nicht repräsentativ angesehen werden können. Er begründete dies mit der deutlich höheren Zahl an Artikeln über Therapie- und Trainings-Gruppen gegenüber Artikeln über natürliche oder experimentelle Gruppen.</p><p>Weitere Autoren kritisieren den statischen Charakter des Modells. Demnach müssten alle Phasen durchwandert werden, bevor die komplette Leistungsfähigkeit wiederhergestellt sei. In späteren Erweiterungen des Modells werden Möglichkeiten eingeräumt, in denen das Team in frühere Stadien zurückfallen können.<sup>[4][5]</sup></p><p>Weiterhin beschreibt das Modell, dass die storming-Phase kritisch sei. Es lässt aber offen, ob und wie diese beendet werden kann. Ebenfalls ist offen was passiert, wenn die storming-Phase “niemals” endet und ggf. das Team zerbricht.<sup>[5]</sup> Diese Punkte hier mit zu betrachten würde den Rahmen dieses Blogartikels sprengen.</p><h2>Zusammenfassung</h2><p>Das Tuckman-Modell ist das mit Abstand bekannteste Modell zur Teambildung. Obwohl es durchaus Hinweise aus Beobachtungen gibt, die sich mit dem Modell erklären lassen, sollte man nicht außer Acht lassen, dass die Datenlage nicht als gesichert gilt. Interessanterweise hat die fünfte Phase “adjourning” sehr selten Einzug in die spätere Literatur gehalten. Bis heute wird daher häufig vom 4-Phasen-Modell gesprochen.</p><p>Das Modell lässt bestimmte Fragen offen. Beispielsweise müssen sich nicht alle Teammitglieder in der selben Phase befinden oder die Wirkung von einer lang andauernden <em>storming</em>-Phase.</p><p>Als Alternative zum 4-Phasen-Modell wollen wir hier nur in aller Kürze und beispielhaft das kybernetische Modell erwähnen.<sup>[6]</sup> Dieses Modell basiert auf der Theorie von geschlossenen Systemen, das durch Rückkopplungsmechanismen auf innere Störungen reagiert. Die Teamdynamik wird daher durch das Verhalten der Teammitglieder selbst bestimmt. Ein Durchlaufen festgelegter Phasen wird dadurch in Frage gestellt.</p><p>Abschließend kann gesagt werden, dass das 4-Phasen-Modell eine gute Grundlage für die Erklärung vieler Gruppendynamiken ist. Man sollte jedoch im Kopf behalten, dass das Modell längst nicht alle Fälle abdeckt. Es können damit auch Gruppendynamiken auftreten, die dann nicht mehr durch das 4-Phasen-Modell erklärt werden können.</p><h2>Quellen</h2><ol><li>Tuckman B. W. Developmental sequence in small groups. In: Psychological Bulletin. 63, 1965, 384–399.</li><li><a href="https://www.staff.science.uu.nl/~daeme101/Stages%20of%20Small-Group%20Development%20Revisted.pdf" target="new">Tuckman B. W., Jensen M. A. C. (1977). Stages of Small-Group Development Revisited. Group & Organization Management, 2(4), 419-427.</a> </li><li><a href="https://lehrbuch-psychologie.springer.com/sites/default/files/atoms/files/web-exkurs.008.05.pdf" target="new">Kauffeld, S. (2014). Arbeits-, Organisations- und Personalpsychologie für Bachelor. Springer-Verlag: Berlin, Heidelberg.</a> </li><li>Brodbeck, F. C. (2004). Analyse von Gruppenprozessen und Gruppenleistung. In H. Schuler (Ed.), Lehrbuch Organisationspsychologie (pp. 415-438). Bern: Hans Huber.</li><li><a href="http://www.fernuni-hagen.de/wirtschaftswissenschaft/studium/download/lp_31711.pdf" target="new">Weibler J., Neuenfeld M, Serhane W., Bergin M. (2003) Organizational Behavior III. Kurs 41712. Fernuniversität Hagen</a> </li><li><a href="http://www.zrm.ch/images/stories/download/pdf/wissenschftl_arbeiten/seminararbeiten/seminararbeit_herold_20030502.pdf" target="new">Herold F. (2003) Seminararbeit: Der Weg der Gruppe. Universität Zürich, Pädagogisches Institut, Pädagogische Psychologie I</a> </li></ol>

Tuckmans 4-Phasen-Modell

<p>Wie komme ich zur Lösung meines Problemes? Eine doch recht simple Frage. Jedoch auch einfache Fragen können es in sich haben und deren Antwort ist teilweise um so komplexer. Die beiden Begriffe “Beratung” und “Coaching” sind heutzutage in aller Munde und werden in diversen Branchen und Kontexten verwendet. Jedoch habe ich festgestellt, dass das Verständnis und damit die einhergehenden Erwartungen unterschiedlich sind. Möglicherweise hängt dies damit zusammen, dass beide Begriffe nicht gesetzlich geschützt beziehungsweise nicht einheitlich definiert sind. Im Folgenden wird meine persönliche Sichtweise daher maßgebend einfließen.<br /> <span></span></p><p>Schauen wir uns die beiden Begriffe nun genauer an und nehmen ein fiktives Beispiel zur Hand. Jemand hat verschiedene fantastisch schmeckende & erfrischende Limonaden entwickelt. Die Person hat einen kleinen selbst erstellten Webshop und ein paar Angestellte, mit denen die Kommunikation gelegentlich schwierig ist (z.B. bei <a href="/wissens-hub/blog/konflikte-in-teams-loesen">Konflikten</a> ). Die Herausforderungen in dieser Position können vielfältig sein. An welchen Stellen und wie können hier Berater und Coaches unterstützen?</p><h2>Der Berater</h2><p>In unserem Beispiel soll eine neue Variante der Limonade in den Markt gebracht werden. Das Einstellen des neuen Produkts in den Webshop könnte der Inhaber selbst erledigen. Jedoch ist der Webshop insgesamt nicht ansprechend gestaltet. Der Shop ist in der Konfiguration stark eingeschränkt und weist eine geringe Performance auf. Der Limonadenladeninhaber sucht einen Berater auf. Dabei achtet er darauf, dass der Berater eine entsprechende fachliche Kompetenz besitzt.</p><p>Der Berater erteilt dem Ladenbesitzer entsprechende Ratschläge in der Beratung. Ziel dabei ist es, die Unsicherheit des Ratsuchenden, also dem Limonadenladeninhaber, zu minimieren. Das Bedürfnis der Unsicherheitsminimierung tritt primär in neuen oder schwierigen Situationen und bei komplexen Entscheidungen auf.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/J5QfkkhRRmheqi7IAOtA"><img width="250" height="95" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/J5QfkkhRRmheqi7IAOtA" alt="Bereiche der Beratung" /></a> <br /> Bereiche der Beratung</p><p>Bei der Beratung findet die Kommunikation zwischen mindestens zwei Personen statt und bezieht sich auf ein in der Zukunft liegendes Vorhaben des Ratsuchenden. Ein klassisches Format ist dabei ein Training, bei welchem das notwendige Wissen vermittelt wird. Der Ratsuchende kann mit dem neu erworbenem Wissen selbst entscheiden, was er genau tun möchte.</p><p>Heutzutage sind die Kontexte häufig sehr komplex, deshalb wird neben dem Training auch über mögliche andere Lösungsvarianten des Problems gesprochen. Zum Beispiel im Rahmen eines Workshops werden die Lösungsoptionen erarbeitet und gemeinsam bewertet. Dabei fließt das Expertenwissen des Beraters weiterhin ein.</p><p>Der Berater-Begriff wird häufig noch dahingehend erweitert, dass der Berater auch aktiv Teile der Umsetzung mit übernimmt. Dabei ist der Ratsuchende für die Entscheidung und Umsetzung verantwortlich und der Berater kann weiterhin unterstützend tätig sein. Je nach Umfang des Vorhabens, kann ein Berater Teil eines Teams sein oder es wird gar ein gesamtes Beraterteam mit der Umsetzung eines Vorhabens beauftragt. Um so stärker ein Berater-Team in die Umsetzung involviert ist, desto stärker sollte im Vorfeld die jeweiligen Erwartungen und Befugnisse, die auf beiden Seiten existieren, abgeklärt werden. Im oberen Fall könnte zum Beispiel gemeinsam der bestehende Webshop angepasst oder neu entwickelt werden.</p><p>Wir sehen, dass der Berater ein breites Leistungsspektrum mit konkreten Hinweisen, Ratschlägen und aktiver Unterstützung anbieten kann.</p><h2>Der Coach</h2><p>Als Coach kann sich jede Person bezeichnen. Es gibt eine große Anzahl an unterschiedlichen Coaches wie zum Beispiel Gesundheitscoach, Beautycoach, Hundecoach, Stimmcoach, Karrierecoach, Teamcoach, Agile Coach und Führungskräftecoach.</p><p>Im Kern ist ein Coaching die Begleitung einer Person, dem Coachee, bei einem Veränderungsprozess. Die Begleitung kann sowohl im geschäftlichen, als auch im persönlichen Kontext angesiedelt sein. Im Folgenden lege ich den Fokus auf den geschäftlichen Bereichen, obwohl beide Bereiche stets miteinander verknüpft sind. In einem Coaching werden die Themen des Coachee gemeinsam konkretisiert, priorisiert und bearbeitet. Diese Themen können beispielsweise Fragestellungen zur Zielerreichung, Wirkungs- und Führungsfragen, Umgang mit bestimmten Situationen oder das Lösen von Konflikten sein.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/b1zjSuZAQeytXFXQgRZf"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/b1zjSuZAQeytXFXQgRZf" alt="Coaching - Themenbereiche einer Führungskraft" /></a> <br /> Coaching – Themenbereiche einer Führungskraft</p><p>Der Coach führt mit verschiedenen Fragen, Methoden und Interventionen durch den Coaching-Prozess, um das jeweilige Ziel des Coachee zu erreichen. Er unterstützt den Coachee bei der Lösungsfindung, aber trägt nicht inhaltlich bei. Der Coachee findet damit eine für ihn passende, individuelle Lösung. Im Gegensatz zum Berater braucht der Coach kein thematisches Experten-, sondern ein tiefgreifendes Prozesswissen.</p><p>Bezogen auf das Beispiel bedeutet es, dass ein Coach bei vielen unterschiedlichen Fragen und Zielen des Limonadenladeninhabers helfen kann. Das sind beispielsweise:</p><ul><li>Wie kommuniziere ich meine Erwartungen verständlicher an meine Mitarbeiter?</li><li>Was kann ich tun, um meine Mitarbeiterführung an die unterschiedlichen Mitarbeiter anzupassen?</li><li>Weshalb fühle ich mich in Konfliktsituationen mit Kunden unwohl?</li><li>Wie treffe ich Entscheidungen in für mich herausfordernden Situationen?</li><li>Welche Maßnahmen kann ich ergreifen, um eine ausgeglichene Balance zwischen Privatleben und meinen beruflichen Aufgaben zu erhalten?</li></ul><h2>Zusammenfassung</h2><p>Festhalten können wir, dass Berater und Coaches ein breites Spektrum an Unterstützung liefern. Der Berater vermittelt direktes Wissen, Best Practices und unterstützt teilweise auch in der Umsetzung. Coaches hingegen arbeiten vor allem auf der Prozessebene, in der persönlichen Weiterentwicklung und fokussieren dabei die individuellen Bedürfnisse des Coachee. Die vom Coachee entwickelte Lösung ist auf ihn und seine aktuelle Situation inklusive seines Entwicklungsstandes zugeschnitten.</p>

Was steckt hinter Beratung und Coaching?

People Lead & Agile Consultant

Next Generation: Input Management 3.0 – Zukunftsorientierte Input-Management-Systeme bei großen Organisationen

Key Account Manager 

Sprintziele: Fokus schärfen und Teamerfolg steigern

Die schaurigen Gestalten der Agilität – und warum sie oft zum Scheitern führen

Scrum Master & IT Consultant

Customer Success Manager / Sales Operations

IT Consultant and Developer

IT Consultant (Tech & Product)

Das ultimative Tool für Ingenieure und Entwickler: Compass Premium

The Ultimate Tool for Engineers and Developers: Compass Premium

Berlin | Team

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

Willkommen im Team Berlin

Jetzt für unseren Newsletter anmelden