Release It!

Design and Deploy Production-Ready Software

Release It!

Michael Nygard erzählt wirklich spannende Geschichten, die sich wie ein Krimi lesen lassen. Er gibt Tipps, was man alles beachten muss, wenn man Software in Produktion bringen möchte.

Das Buch fängt mit dem Thema Stabilität an, dann kommt Kapazität, gefolgt von allgemeinen Design Richtlinien und Operation, also Dingen die beim Betrieb wichtig sind. Der Abschnitt mit den Stability Pattern ist wirklich stark und umfangreich. Hier wird z.B. das Circuit Breaker Pattern beschrieben, welches die Basis für Netflixs Hystrix Library ist. Jedoch werden im weiteren Verlauf des Buches die Kapitel dann immer kürzer. Die Kapitel bleiben trotzdem gehaltvoll. Der Autor versucht eine Art Pattern-Familie zu entwickeln. Das gelingt Nygard aber nur für den Punkt Stabilität.

Mir gefällt die einfache Definitionen, die Nygard dem Leser anbietet. Der Schreibstil ist einfach und das Buch ist gut zu lesen. Die Dinge, die in diesem Buch beschrieben werden, haben nach wie vor Relevanz. Das Buch ist definitiv ein Klassiker. Es ist absolut lesenswert und gehört für jeden Software-Architekten auf jedenfall ins Buchregal oder auf den Tisch.

Hier der Link zu Amazon.

Reading and Writing JSON with JSON Processing API

As a big fan of Java EE 7, recently I had a look at the JSON Processing API.

As you know JSON is a data exchange format widely used in web services and other connected applications. The new JSON Processing API (JSR 353), is a lightweight API to parse, transform, and query JSON data using a object model or streaming model.

You can easily build an JSON Object:

[code]
JsonObject model = Json.createObjectBuilder()
.add("title", "Building Microservices")
.add("author", "Sam Newman")
.add("publisher", "O’Reilly")
.add("pages", 278)
.add("ISBN", "978-1491950357")
.add("price", 12.0)
.add("currency", "EUR")
.build();
System.out.println(model);
[/code]

And writing an JSON model to a stream are just a few lines.

[code]
StringWriter stringWriter = new StringWriter();
writeModel(stringWriter, model);

try (JsonWriter jsonWriter = Json.createWriter(stringWriter)) {
jsonWriter.writeObject(model);
} catch(JsonException je)
{
je.printStackTrace();
}

String jsonData = stringWriter.toString();
System.out.println(jsonData);
[/code]

An JSON file you can read like this:

[code]
InputStream is = getClass().getResourceAsStream(fileName);
try(JsonReader reader = Json.createReader(is))
{
JsonStructure jsonStructure = reader.read();
System.out.println(jsonStructure);
} catch(JsonException je)
{
je.printStackTrace();
} finally {
IOUtils.closeQuietly(is);
}
[/code]

And there is even a streaming model for parsing and writing JSON. Here you can see the parsing.

[code]
InputStream is = …

try(JsonParser parser = Json.createParser(is))
{
while (parser.hasNext()) {
JsonParser.Event event = parser.next();
switch(event) {
case START_ARRAY:
case END_ARRAY:
case START_OBJECT:
case END_OBJECT:
case VALUE_FALSE:
case VALUE_NULL:
case VALUE_TRUE:
System.out.println(event.toString());
break;
case KEY_NAME:
System.out.print(event.toString() + " " +
parser.getString() + " – ");
break;
case VALUE_STRING:
case VALUE_NUMBER:
System.out.println(event.toString() + " " +
parser.getString());
break;
}
}
} catch(JsonException je)
{
je.printStackTrace();
}

[/code]

And here comes the writing example.

[code]
FileWriter writer = new FileWriter(fileName);

try(JsonGenerator generator = Json.createGenerator(writer))
{
generator.writeStartObject()
.write("title", "Building Microservices")
.write("author", "Sam Newman")
.write("publisher", "O’Reilly")
.write("pages", 278)
.write("ISBN", "978-1491950357")
.write("price", 12.0)
.write("currency", "EUR")
.writeEnd();
}

[/code]

It was fun playing around with the API. I think the fact that JSON Processing (Project) does not explicitly support JSON binding limits the usage. I read that a future JSR may consider a JSON Binding similar to JAXB. So you can use the Java API for JSON Processing with JAX-RS resource methods, but when does it make sense?

In my opinion, if you are not the owner of the bounded context and model then you can use the JSON Processing API. Otherwise I would use JAXB with annotations. Jersey, the reference implementation for JAX-RS supports for binding JSON data from Restful resource methods to Java objects using JAXB. With JAXB you can automatically read and write XML and JSON.

I hope you had fun reading my article.

GitHub-Mark-32px Examples on Github: https://github.com/claudioaltamura/javaee/tree/master/jsonp

Here you can get an overview: http://docs.oracle.com/javaee/7/tutorial/jsonp002.htm.
This is the project site: https://jsonp.java.net
and here you can have a look a API Javadoc: https://json-processing-spec.java.net/nonav/releases/1.0/fcs/javadocs/index.html

Continuous Delivery

Warum sollte ich ein Buch über Continuous Delivery lesen, wenn Jez Humble schon ein bahnbrechendes Buch zu diesem Thema geschrieben hat?

Der Untertitel von Eberhard Wolffs Buch aber hat mich neugierig gemacht:
„Der pragmatische Einstieg“. Genau das ist der Fokus des Buches. Der Leser lernt praxisorientiert und pragmatisch den Aufbau einer Continuous Delivery Pipeline kennen. Es umfasst alles von:

der Automatisierung der Infrastruktur mit Chef, Docker, Vagrant

Build-Automatisierung mit Maven und Gradle

Akzeptanz-, Kapazitätstest

Deployment

bis zum Betrieb der Software.

Dabei vermittelt Eberhard Wolff ebenfalls Informationen wie Continuous Delivery (CD) in Unternehmen eingeführt werden kann, wie das Thema und DevOps „zusammenspielen“ und welche Auswirkungen CD auf die Softwarearchitektur haben kann.

Das Buch ist sehr gut gegliedert und lässt sich gut lesen, auch wenn hier einige anderer Meinung sind. Viele Themen werden nur angerissen. Aber das liegt auch in der Natur von Continuous Delivery. Besonders gut fand ich die einzelnen Aufgaben in den „Selberausprobieren und Experimentieren“-Abschnitten, wo der Leser sich noch tiefer mit Punkten vertraut machen kann, die ihm am Herzen liegen.  Toll finde ich auch das dazugehörige Github-Projekt.

Mein Fazit ist: unbedingt lesenswert. Der Leser versteht nach der Lektüre, welche Vorteile CD bietet und welche Werkzeuge zur Etablierung notwendig sind. Ein praxisorientiertes und pragmatisches Buch, welches einen hervorragenden Überblick über Continuous Delivery bietet.

Hier der Link zu Amazon.

Building Microservices

DESIGNING FINE-GRAINED SYSTEMS

Jeder kennt die Vorteile von Microservices. So was wie neue Technologien leicht ausprobieren, einfache Modernisierung des Technologie-Stack, Resilience, d.h. Fehler in einem Service haben wenig Einfluss auf andere, skalierbare Services, einfachere Deployments, Kombinierbarkeit von Services, kurze Time-to-Market Dauer für neue Funktionalität. Das hört sich toll an. Aber beim Lesen des Buches wird einem schnell klar, dass diese Technologie wiederum selber ihre eigenen Herausforderungen mit sich bringt.

„Building Microservices“ ist gespickt mit Lösungen für die Modellierung, Integration, Testen, Deployment, Monitoren und Absichern von Microservices. Es enthält viele Bespiele und praktische Ratschläge für Entwickler, die für das Bauen, Managen und Ausbauen von Microservice Architekturen wichtig sind:

Welche Vorteile habe ich von Microservices?
Wie können diese mir fehlen, meine Geschäftsanforderungen zu erfüllen?
Wie zerlege ich eine monolithische Codebasis mit Bounded Contexts?
Welche Refactorings auf Ebene der Datenbank ergeben sich daraus?
Welche möglichen Lösungen gibt es hier?
Wie verändern Microservices die Continuous Delivery Pipeline?
Welche Herausforderungen bezüglich der Komplexität gibt es z.B. beim Testen?

Der eine oder andere kritisiert, dass Sam Newman in dem Buch nicht in die Tiefe geht. Ich denke, dass der Autor das auch absichtlich gemacht hab. Die Microservice Technologie entwickelt sich rasant weiter. Bei Sam Newman hat man als Leser das Gefühl, dass er ganz genau weiß, wo von er spricht. Das Buch ist sehr ausgewogen und gibt einem einen sehr guten Überblick mit vielen Lösungen.

Ich kann das Buch jedem empfehlen, der sich mit Microservices auseinandersetzen will. Das Buch gibt einem eine perfekte Orientierung.

Hier der Link zu Amazon.

Top 3 Anti-Sprüche in der Softwareentwicklung

Dies ist meine persönliche Top 3 Liste an nervenden Sprüchen.

1. Das haben wir schon immer so gemacht.
2. Wir machen eine pragmatische Lösung.
3. Das brauchen wir nicht.

„Das haben wir schon immer so gemacht.“ ist unangefochten auf Platz 1. Es läuft (gut/schlecht). Das Problem ist gelöst. Warum sollten wir denn was ändern?

Nr. 2 ist dagegen neu aufgestiegen: „Wir machen eine pragmatische Lösung.“ Will heißen, wir ignorieren Grundsätze der objektorientierten Programmierung, Softwareengineering oder was auch immer. Und dann wird Müll geschaffen, der nicht temporär bleibt, sonder für immer.

„Das brauchen wir nicht“ ist bei mir auf Platz 3. Wie kann man nur so beratungsresistent sein und Zahlen, Daten und Fakten ignorieren? Framework, Library oder Tool einsetzen? Nein, das können wir auch selber (?). Und dann wird das Rad neu erfunden (Verschwendung).

Warum nicht anders? Letztens habe ich ein Zitat von Dietrich Mateschitz, dem Gründer von Red Bull gelesen:

„Wir stellen aus Prinzip alles in Frage. Wir gehen davon aus, dass nicht alles, was schon immer irgendwie gemacht wurde, so auch richtig ist.“

Checkstyle, FindBugs and PMD Gradle Configuration

Configure Code Analysis Tools with Gradle

I’m really happy that configuring Checkstyle, Findbugs and PMD with Gradle is so easy. So if you want to see how I configured the tools than have a quick look at this code snippet gist: https://gist.github.com/claudioaltamura/a9e59c009db38d615dae

After you have configured your Code Analysis Tool, you just have to type in:

 gradle check

How do I configure Checkstyle, Findbugs or PMD?

Checkstyle
This is a checkstyle.xml file with one check.

[code language=“xml“]
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module PUBLIC
"-//Puppy Crawl//DTD Check Configuration 1.3//EN"
"http://www.puppycrawl.com/dtds/configuration_1_3.dtd">

<module name="Checker">
<module name="TreeWalker">
<module name="UnusedImports"/>
</module>
</module>
[/code]

So if you like to add available checks, go to this site http://checkstyle.sourceforge.net/checks.html and http://checkstyle.sourceforge.net/config.html for general configuration.

Findbugs
If you remove the property ‚includeFilter‘, you do a full findbugs check. If you are interested only into a few filter then check these two sites http://findbugs.sourceforge.net/bugDescriptions.html and
http://findbugs.sourceforge.net/manual/filter.html.

Just include findbugs.xml file and your filters like this:

[code language=“xml“]
<?xml version="1.0" encoding="UTF-8"?>
<FindBugsFilter>
<Match>
<Bug code="ODR" />
</Match>
</FindBugsFilter>
[/code]

PMD
Here you can see a typcial PMD ruleset.xml file.

[code language=“xml“]
<?xml version="1.0"?>
<ruleset name="Custom ruleset"
xmlns="http://pmd.sourceforge.net/ruleset/2.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://pmd.sourceforge.net/ruleset/2.0.0 http://pmd.sourceforge.net/ruleset_2_0_0.xsd">

<description>
This ruleset checks my code for bad stuff
</description>

<rule ref="rulesets/java/basic.xml" />
<rule ref="rulesets/java/design.xml" />

</ruleset>
[/code]

For configuration see https://pmd.github.io/pmd-5.3.3/pmd-java/rules/index.html
or https://pmd.github.io/pmd-5.3.3/usage/running.html

Have Fun!

Picture License: CC0 Public Domain / geralt

Do you understand what Continuous Integration is about?

While reading Sam Newman’s book about „Building Microservices“, I cam across Jez Humble’s three questions he asks people to test if they really understand what CI is about.

1. Do you check in to mainline once per day?

If you don’t check your code together with everyone else’s changes frequently, future integration will be harder. Even if you are using short-lived branches, integrate frequently into a single mainline branch.

2. Do you have a suite of tests to validate your changes?

Without tests, we don’t know if we have broken the system. CI  means also that we have verifications that our code behaves as expected.

3. When the build is broken, is it the #1 priority of the team to x it?

You need to stop all check-ins that aren’t involved in fixing the build. If you don’t stop, the time it takes to fix the build will increase drastically.

 

Image: CC0 1.0 Universal (CC0 1.0) Public Domain Dedication

BigData Tutorials and Tools

„Hadoop: the Definitive Guide.“ is the most important text on Hadoop. Online you’ll find other useful tutorials.

So here just a quick list of good Big Data tutorials:

Hadoop

https://developer.yahoo.com/hadoop/tutorial/

https://github.com/templedf/javaone14_handsonhadoop  (Slides)

Spark

http://ampcamp.berkeley.edu/big-data-mini-course-home/

Quick Start VMs

Cloudera and Hortonworks offers you VM Images (single-node cluster). That’s really cool.

Cloudera Quickstart VM

Hortonworks Sandbox

Reference: http://www.oraclejavamagazine-digital.com/javamagazine/march_april_2015#pg52

Vortrag Architektur Insights auf slideshare veröffentlicht

Folien jetzt veröffentlicht

Ich habe die Foilen zum Talk „Etracker Architektur Insights“, den ich im Oktober 2014 auf der code.talks gehalten habe, nun auf slideshare veröffentlicht.

Mit der Präsentation bekommt ihr eine umfangreiche Übersicht wie die Themen Big Data und NoSQL im Webanalyse-Umfeld gehandhabt werden und welche Architekturprinzipien Anwendung finden.

Hier ist der Link: http://bit.ly/1MiKIyo

Viel Spaß beim Lesen!

Consent Management Platform von Real Cookie Banner