May 272016
 

In this post I introduce a continuous database migration mechanism for MongoDB using Java and Spring Boot.

Intro

When you look at a development with Continuous Deployment the database is also continuously adapted. Typical database adaptions are e.g. initialising new attributes for all documents with proper values or performing cleanups. It is advantageous to store those change scripts in the version control system. This way the database can stay in sync with the source code once the database scripts are executed in the correct order.

For many SQL databases it is possible to use one of the powerful Java libraries Liquibase or Flyway to manage database changes (like adding columns or modifying existing table rows).
Regarding MongoDB however, things tight up. MongoDB is a non-relational database, thus Liquibase or Flyway can’t be used for it.
A MongoDB database looks like a JSON file and consists of collections and documents (comparable to tables and rows in SQL). To add a new attribute to a document you will just need to change the document-related POJO in the source code. However a new attribute will only be written to the database when a new document is inserted or an existing document is updated. This means that a new attribute will default to null, false or 0. You may want to set your own default values or apply other changes directly to the database. The common way is to manually connect to the database and perform JavaScript code to apply changes.

Once you work on a larger project though, you cannot rely on manual changes anymore. You will need a database management. For this problem of a missing database migration mechanism I have worked out a solution: The idea is to scan a folder containing update scripts and to apply them to the database if needed. The database will store executed scripts to distinguish them from not executed scripts. This feature will then be attached to the application launch, so whenever the application is started, it’ll check for new scripts. The mechanism is fully integrated into the Spring Boot environment and uses helpful key features like @Service and @Autowired annotations. Continue reading »

Jul 082015
 

Gestern war ich mit einem Kollegen auf der XConf. Die XConf ist eine Konferenz von ThoughtWorks. Es ist deutlich mehr als eine Verkaufsveranstaltung. Die Themenauswahl und die Erfahrungsberichte machen es interessant: Womit beschäftigt sich die Branche, was sind die aktuellen Technologien, Vorgehensmodelle und Anwendungsfälle?

thoughtworks xconf logo

Die Entscheidung für den Kongress fiel leicht: Die Themen klangen spannend und der Ort war dieses Jahr das Betahaus; wir konnten also vom Büro aus mit dem Fahrstuhl zur Veranstaltung fahren. Es gab zwei Tracks, mit insgesamt zehn Vorträgen, dazu eine Keynote und ein OpenSpace. Gefühlt waren es vielleicht 80 Teilnehmer. Die Stimmung war locker und entspannt, die anderen Teilnehmer diskussionsfreudig und kommunikativ, die Vorträge durchweg gut und das Catering lecker.

Das waren meine Highlights:

1. Keynote: You can’t be agile when you are knee deep in mud – Rachel Laycock: In ihrer einstündigen kurzweiligen Präsentation sprach sie mir aus der Seele: Scrum alleine hilft nicht. Um fortlaufend schnell Erweiterungen und Änderungen an der Software ausliefern zu können (Continuous Delivery) muss die Software nicht nur eine gute Architektur aufweisen, sondern das Team auch viele der Extreme Programming (XP)-Praktiken anwenden und beherrschen, z.B. Continuous Integration, Test-Driven-Development, Refactorings. Und das machen wir bei cronn.

2. Building Microservices in the cloud – Christian Deger & Wolf Schlegel (autoscout24.de): Ein Erfahrungsbericht aus einem Projekt, bei dem ein Monolith parallel zum Betrieb in Microservices zerteilt wurde. Mit Hilfe von Consumer-Driven Contracts (CDC) ist es ihnen gelungen, die Teams noch weiter zu entkoppeln, auf Testumgebungen wie QA und Stage zu verzichten und die Services erst in der Produktion zu integrieren. Darüber werde ich nachdenken. Das kann – nach Risikoabwägung – die Komplexität deutlich verringern und die Entwicklung beschleunigen.

3. Tech Lead skills for developers – Patrick Kua: Er eröffnet seinen Vortrag mit einer Anregung: Wie kann man als Tech Lead erkennen, das man gut ist? Und fährt fort: Man braucht nur eine Frage zu beantworten: Sieht der Code aus, als ob er von einem Entwickler geschrieben wurde?

Ein weiteres wichtiges Thema war die Sicherheit: Worauf muss man achten, um die Kette vom Entwicklungsrechner bis in die Produktion sicher zu gestalten?

Ich kann die XConf empfehlen. Sie ersetzt keinen der etablierten Java Kongresse, aber sie hat ein großartiges Preis-Leistungsverhältnis und bietet Informationen auf hohem Niveau. Die Kontaktmöglichkeiten sind optimal, um die Themen mit anderen Teilnehmern oder den Sprechern zu vertiefen.

Feb 232015
 

In der letzten Zeit bin ich mehrfach auf das Agile Mindset angesprochen worden. Was ist das überhaupt? In diesem Post versuche ich eine Antwort darauf zu geben.

Agilität

Für die Softwareentwicklung gibt es ein Leitbild, das Agilität definiert. Es ist das 2001 veröffentlichte agile Manifest [1]. Das Manifest beginnt mit vier Wertaussagen:

  • Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
  • Funktionierende Software ist wichtiger als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlung
  • Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans

Und weiter besagt es: „Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.“

Ergänzt werden die Werte durch zwölf Prinzipien, die greifbar machen, wie sich die Werte auf die tägliche Arbeit auswirken. Die genannten Prinzip sind zum Beispiel: Software kontinuierlich zu liefern, Änderungen willkommen zu heißen, nicht wertschöpfende Arbeit zu vermeiden, die direkte Kommunikation zu bevorzugen, die Selbstorganisation der Teams zu fördern, technisch exzellent zu sein, ein gutes Design zu wählen und den Prozess der Entwicklung regelmäßig retrospektiv zu prüfen und anzupassen.

Ein agiles Mindset besteht also mindestens aus den vier Werten. Das reicht aber nicht. Denn wie kommt man zu technischer Exzellenz, gutem Design, effizienten Entwicklungsabläufen, eleganten Lösungen?

Lernen

Für Linda Rising bedeutet Agilität Lernen und Wachstum [2]. Sie geht auf die psychologische Komponente des agilen Mindsets ein. Es handelt sich hierbei um Glaubenssätze, Normen und Gebote, die unser Handeln beeinflussen.

Sie beschreibt zwei Mindsets, das fixed Mindset und das Gegenteil dazu, das agile Mindset.

Das fixed Mindset fusst auf dem Glaubenssatz, geistige Fähigkeiten als angeboren zu betrachten – wie die Körpergröße – man „kann es“ oder man „kann es“ eben nicht. Menschen mit dem fixed Mindset haben das Ziel, gut da zu stehen. Sie vermeiden Herausforderungen, da diese immer auch ein potentielles Scheitern beinhalten. Fehler definieren ihre Identität. Anstrengungen sind zu vermeiden, denn Anstrengungen sind ein Zeichen dafür, dass Fähigkeiten fehlen. Menschen mit dem fixed Mindset reagieren auf Herausforderungen mit Hilflosigkeit.

Linda Rising beschreibt das agile Mindset als den Glaubenssatz, dass geistige Fähigkeiten trainierbar sind, wie Muskeln. Menschen mit dem agilen Mindset haben das Ziel zu lernen. Herausforderungen sind ihnen willkommen, Fehler liefern Informationen und Anstrengungen sind der Weg zu herausragendem Können. Menschen mit dem agilen Mindset passen sich Herausforderungen an.

Definition

Zusammengefasst ergibt sich: Ein Mensch mit einem agilen Mindset schätzt die Werte des agilen Manifests, trägt in sich den Glauben, dass man Fähigkeiten erlernen kann, dass man besser werden kann und hat den Wunsch, dies auch zu tun.

Ich denke, dass der Glaube an erlernbare Fähigkeiten und den Wunsch zu wachsen zwangsläufig zu einer agilen Entwicklungsweise führt. Denn nicht agil zu entwickeln bedeutet, Erfahrungen zu machen ohne daraus lernen zu dürfen.

Wie kann man das agile Mindset fördern?

Welche Werte wir wertschätzen, welchen Glaubenssätzen und Normen wir unterliegen, wird durch unsere Erfahrungen beeinflusst. Linda Rising verweist dabei auf die Wissenschaftlerin Carol Dweck. Diese zeige, dass die Art und Weise wofür Menschen gelobt würden, ein fixed oder agiles Mindset förderten. Würden Menschen für etwas gelobt, was sie haben, zum Beispiel ihre Begabung, dann fördere dies das fixed Mindset. Würden Menschen für ihre Bereitschaft, sich anzustrengen und sich zu bemühen gelobt, dann fördere dies das agile Mindset.

Linda Rising gibt diesen Gedanken zuallererst allen Eltern mit auf den Weg. Und sie zeigt auch auf, wie wichtig diese Erkenntnisse für Führungskräfte sind. Denn das Mindset ist wandelbar. Und Führungskräfte bekommen durch die Art und Weise, wie sie ihre Mitarbeiter loben, bzw. was sie honorieren, mehr Menschen mit fixed oder agilem Mindset.

Quellen

[1] Kent Beck, Mike Beedle, et. al., „Manifest für Agile Softwareentwicklung“, 2001, http://www.agilemanifesto.org/iso/de/
[2] Linda Rising, „The Power of an Agile Mindset“, 2014, http://www.infoq.com/presentations/agile-mindset

Oct 172014
 

Am 9. Und 10. Oktober fanden in Hamburg die code.talks 2014 statt. Dabei gab es neben den interessanten Vorträgen noch viel mehr zu entdecken. Abgesehen von der Nacho- und Popcorn-Flatrate gab es ein durchaus sehenswertes Catering der Kochfabrik und viele Sponsoren mit viel Engagement im Recruitment. Nur sehr wenige Dienstleiter waren vertreten – Zielgruppe waren eindeutig Entwickler. Davon gab es dementsprechend sehr viele – über 1500, den größten Teil stellten Webentwickler im Front- und Backend. Das konnte man das auch an den Themen ablesen. So gut wie kein Vortrag beschäftigte sich mit der „klassischen“ Anwendungsentwicklung oder gar systemnaher Entwicklung. Die für meine Wahrnehmung größten Themenkomplexe waren Responsive Design, Webtechnologien rund um PHP und JavaScript sowie Datenbanken, Skalierung, IT-Management und Softwarequalität. Mehrere Vorträge gingen auch in die Richtung gesellschaftlicher Bedeutung von Software und IT im Allgemeinen.

Was ich interessant fand, waren einige Vorträge, die einige weit verbreitete Prinzipien wie TDD, BDD, SOLID etc. auch kritisch hinterfragt haben und anhand der historischen Entwicklung den Kontext erklärten, in dem diese entstanden sind und warum nicht unbedingt jedes Projekt davon profitieren muss (Sebastian Bergmann: Eine kurze Geschichte der Testpraktiken; Marco Cecconi: Guerrilla software design: doing it wrong and getting it right).
Einige interessante Ideen gab es zum Thema Softwarequalität, wie z.B. „Visual Regression Testing“ (Milena Reichel). Dabei wird eine zu testende Webseite in ein Bild gerendert und die Differenz zu einem Referenzbild ermittelt. So lassen sich Darstellungsfehler insbesondere durch CSS gezielt ausschließen. Ein spannender Ansatz ist auch die „Datengetriebene Analyse und Verbesserung von Code“ (Andreas Dewes), bei der anhand von Syntaxstrukturen Quellcode analysiert wird und maschinell aus großen Datenmengen Strukturen gelernt werden, um häufige Fehler leichter als bisher auffinden zu können.
Viele Vorträge zeigten inhaltlich ähnliche Überzeugungen, wie die Bedeutung der Kommunikation, ein Bekenntnis zu qualitativ hochwertiger Software, und die allgemeine Zufriedenheit mit der eigenen Situation als Software-Entwickler.

Was ich mitgenommen habe, ist neben viel technischem Wissen die Erkenntnis, dass man als Entwickler bei allem, was man tut, nie den Kontext aus den Augen verlieren sollte, in dem man handelt, und nach dem Kontext zu fragen, aus dem heraus Techniken und Technologien entstanden sind. Ob es nun um SOLID oder NoSQL geht – neue Lösungen sind nicht allgemein „besser“ als alte, sondern nur in einem bestimmten Kontext. Bevor man neue, mit hoher Wahrscheinlichkeit fehlerbehaftetere Technologien einführt, sollte man diesen Kontext kennen und kritisch mit seinem eigenen vergleichen.
Wünschenswert wäre vielleicht noch eine Unterbrechung der vielen Vorträge durch kleine Workshops oder Diskussionsrunden, da durch den engen Zeitrahmen und die Kinoatmosphäre wenig Interaktion entsteht.

Sep 032014
 

Einführung

Mit Java 8 halten eine Menge neue Funktionen Einzug in die Sprache. Vieles davon kommt einem bekannt vor, wenn man sich die JVM-basierte Sprache Scala (http://www.scala-lang.org/) ein bisschen näher anschaut – ein guter Grund, sich mit den Grundlagen von Scala zu beschäftigen. In dieser Serie sollen einige grundlegende Sprachfeatures an praxisnahen Beispielen verglichen und die Unterschiede zwischen Java und Scala beleuchtet werden. Schließlich wird gezeigt, welche der Scala-Funktionalitäten mit Version 8 in die Java-Welt aufgenommen wurden.

In Teil II geht es um Streams als Kontrollstrukturen in Scala und Java 8. Ausgehend von der in Part I bereits vorgestellten und hier erweiterten Datenstruktur soll eine einfache Funktionalität umgesetzt werden. Continue reading »

Aug 222014
 

Einführung

Mit Java 8 halten viele neue Funktionen Einzug in die Sprache. Davon kommt einem einiges bekannt vor, wenn man sich die JVM-basierte Sprache Scala (http://www.scala-lang.org/) ein bisschen näher anschaut – ein guter Grund für mich, sich mit den Grundlagen von Scala zu beschäftigen. In dieser Serie sollen einige grundlegende Sprachfeatures an praxisnahen Beispielen vorgestellt werden und die Unterschiede zwischen Java 7, Java 8 und Scala herausgestellt.

In Teil I der Serie fangen wir an mit der Erstellung einer einfachen Datenstruktur an: Ein Kunde mit einem Namen.
Continue reading »