Jug Saxony Day 2018

Hier noch meine verspäteten Mindnotes vom Jug Saxony Day.

Die Keynote von Shaun Smith - Serverless Java:

Challenges and Triumphs war im Vergleich zu anderen Keynotes angenehm realistisch und durch viel Demonstration geprägt. Mitgenommen habe ich die Hoffnung das es in Zukunft Wege geben wird den Ressourcenhunger von Java Applikationen zu bändigen. Projekte wie das vorgestellte fnproject.io geben zumindest Hoffnung irgendwann serverless Apps mit einer vernünftigen Sprache entwickeln zu können.

Markus Herrer - Software Analytics

Legacy Code ist immer ein Schrecken, mit statischer Codeanalyse und ein bisschen Code-Big-Data lässt sich den Monstern zumindest ein Wenig der Schrecken nehmen. Die vorgestellte Methodik der Notebooks ist ganz nett aber eigentlich nichts neues und vor allem auch nur ein weiteres Datengrab wie ich finde. Der Stack aus Jupiter, Pandas und Neo4J scheint mir auch alles andere als trivial. Auf jeden Fall mal anschauen werde ich mir aber jqAssistant.

Michael Wiedeking - Der eilige Graal

In der Keynote auf die GraalVM neugierig geworden ließ ich mich zum Vortrag von Michael verlocken. Es ist tatsächlich erstaunlich wie dieser Mann Dinge wie eine Virtual Machine soweit herunter brechen kann das man tatsächlich das Gefühl bekommt zu verstehen wie diese funktioniert. Key Learning aus der Session: Man kann den C2 Compiler der JVM austauschen, Graal macht vieles besser als der orgninale C2 und Graal geht nicht gut mit Ahead of Time compilation zusammen.

Jörg Domann - Warum man mit Visionen nicht zum Arzt gehen sollte

Sorry das war der einzige richtig schlechte Talk den ich hatte.

Yvonne Horn - Gedanken begreifbar machen

Der interaktive Workshop war gnadenlos überrannt. Dank meines Kollegen Sebastian bin ich aber dennoch pünktlich gewesen und es wäre Schade gewesen. In 20 Minuten konnte Yvonne ein paar simple Beispiele vermitteln wie man an einem Whiteboard oder Flipchart besser präsentieren kann. Zum Nachmachen empfohlen!

Sven Oppermann - State of the Art CI

Die CI Pipeline von Sven ist nett, leider fusst sie einmal mehr auf den Tools von Atlassian und diesem Monster der Integrationserver Jenkins. An dem Ding kommt man leider immer noch nicht vorbei. Was ich hier mitgenommen habe ist der feste Entschluss eines Tages Jenkins zu töten und wenn das nicht geht ihn zumindest auch bei uns in der Firma in einen Container zu sperren :P

Roland Meuel und Jan Mosig - Irgendwie agil

Ich hätte den Vortrag fast geskipped weil ich dachte, dass ist bestimmt wieder nur noch ein Vortrag wie toll agil ist (und das weiß ich selbst). Am Ende war es aber doch lohnend. Die beiden Referenten hatten einen Sack von 10 Antipatterns geschnürt, den sie locker garniert mit fetzigen Folien und einer guten Portion Optimismus vortrugen. Mein Keylearning: Meister Yoda wäre sicher ein guter Coach, denn er holt sicher nicht die Batterien für Luke Skywalkers Lichtschwert.

Jug Saxony Day 2018

{devday.18}

Hier nun meine Mindnotes zum DevDay 2018. Was die Tracks jetzt gezielt mit dem Thema Digital Reality zu tun hatten sei erst einmal dahingestellt. Die Mischung aus technischen und “psychologischen” Themen war meiner Meinung nach in Ordnung, wobei mich tatsächlich die technischen Parts eher weniger angesprochen haben.

Den Einstieg gabs von fefe mit einer langen Version seines Vortrags zu Antipatterns in der Softwareentwicklung. Alles in allem nichts wirklich neues für jemanden der den Entwicklungsprozess in verschiedensten Teams erlebt hat. Im Kern aber ist die Aussage für mich, dass von oben gesteuerte und von Budgets eingeengte Softwareentwicklung gepaart mit der natürlichen Faulheit des Entwicklers eine explosive Mischung sind.

In der Folge habe ich mir den Vortrag von Dennis Traum, Vom Bildschirm in die Notaufnahme - Performance, Perfektionismus und Burnout in der IT, angehört. Ich muss zugeben der Inhalt war so nicht erwartet und hart an der Herzschmerz Grenze, aber sein Plädoyer: “Wenn es nicht Perfekt sein muss, kannst du es auch schaffen” spricht dem Agilisten in mir aus der Seele.

Weniger gefallen hat mir der Vortrag von Torsten Weber unter dem Titel: Mehr Hirn im Team, bitte. Torsten verlor sich ziemlich stark in grundlegenden psychologischen Theorien mit sanftem Bezug zu Entwicklungsunternehmen. Nett fand ich, das er sehr intensiv herausgearbeitet hat das die Herangehensweise von HR Abteilungen und Rekrutern zu stark dem Schema: “Zahl für das was im CV steht” tendiert. Weniger nett fand ich den Start von konkreten Tipps als er schon die rote Karte bekommen und die Pause angefangen hatte.

Bevor es in die Abschlusskeynote ging habe ich mir dann aus aktuellem Interesse den Vortrag zur Integration von Springboot und Hashicorp Vault angehört. Ein schöner Überblick über die verschiedenen Backends. Was für mich fehlte waren Gedanken wie Vault in vollautomatischen Deploymentprozessen für mehr Sicherheit sorgen kann.

Sicherheit war dann zum Abschluss das Thema von Thomas Haase der in seinem Vortrag Hack me if you can! aus dem Nähkasten der Pentester geplaudert hat. Ein schöner Abschluss, in jedem Fall besser als der Clown von Microsoft im letzten Jahr.

Der Orga kann ich nur danken, denn in Summe war der Besuch wieder lohnend, auch wenn das Gedränge bei Kuchen und Suppen ein klares Indiz für die Kapazität der Location in dieser Konfiguration ist.

DevDay 2018 - Digital Reality

Agile Meetup in den DWH

Ein Agile Meetup, mal nicht in einem IT-Unternehmen mit eifrigen Recruitern im Hintergrund. Gibt’s nicht? Gibt’s doch!

Der Einheimische erinnert sich sicher noch an Möbel aus dem Vorzeige Unternehmen, Deutsche Werkstätten Hellerau made in GDR. Heute fertigt das Traditionsunternehmen komplette Inneneinrichtungen für Luxusyachten und Häuser an. Dabei verfolgt man eine sehr offene Philosophie, ein großes Office, eine große flexible Werkhalle. Die Show der letzteren war natürlich ein haptisches Highlight, spannend war aber auch die Feststellung der Unternehmer das sie mit den aktuellen Prozessen an die Grenzen des Machbaren stoßen.

Am Anfang steht nicht mehr als eine fixe Idee. Oft nur eine Skizze aus der am Ende eine 180 Meter Yacht entstehen soll, ganz nach den Wünschen des Kunden. Zum festen Preis, zum festen Termin.

Im aktiven Part des Meetups ging es dann auch darum Ideen für den Start in die Agilität zu finden. Als Brainstorming Game kam 1-2-4-All zum Einsatz, womit gleich auch Liberating Structures am praktischen Beispiel demonstriert wurde. Spannend war am Ende der Outcome der doch bei vielen sehr in Ähnliche Richtungen ging:

  • Vorleben und Einführen von agilen Methoden in kleinen Teams
  • Schnelles Liefern von Prototypen
  • Experimentieren mit Methoden wie Kanban

Die zweite Session konzentrierte sich auf ein anderes Problem. Anett stellt die Frage in die Runde wie ein perfekter Moderationskoffer aussehen sollte. Für mich in Teilen war die Frage nur zum Teil interessant, denn meiner Meinung nach gibt es sowas wie den perfekten, standardisierten Koffer einfach nicht. Mir reichen Grundmaterialien, Schreibzeug, Stickies aus. Alles weitere liegt viel zu stark an den Nutzern.

Agile Meetup Dresden

Erfolg des Scheiterns

Neulich hörte ich eine These dazu, warum es in Israel so eine lebendige Startup Kultur gibt. In Israel so sagte der Interviewte, sei das Scheitern kulturell anerkannt und nicht verpönt wie hier in Deutschland.

Klar, sind wir hier doch schon von der Schule an auf maximale Leistung und beste Noten getrimmt. Willste den NC deines Traumstudiums schaffen müsste eben büffeln. Egal ob das gelernte einen probaten Mehrwert bietet oder nicht.

Klassischer Projektablauf nach Pflichtenheft und Wasserfall folgt ebenfalls diesem Prinzip. Alles muss vollständig geliefert werden. Egal ob die Hälfte eigentlich keinen echten Mehrwert liefert.

Agiles Vorgehen wiederum sieht das Scheitern als integralen Teil des Prozesses. Aus Fehlern kann man lernen, von daher sind sie auch nichts an sich schlechtes. Ein guter Scrummaster gar muss lernen sein Team Fehler machen zu lassen, selbst wenn er es eigentlich besser wüsste.

Und ganz tief am Boden unseres physischen Seins hat schon alte Darwin erkannt daß die ganze Evolution allein auf Fehlern basiert. Für das einzelne Gen ist es zwar total doof wenn es nicht überlebt, aber das gesamte System hat sich in der nächsten Generation verbessert, weil es eben ein bestimmtes Gen als Fehler erkannt und eliminiert hat.

Somit hat jeder Fehler seine Daseinsberechtigung, jeder Fehler hat durch zukünftige Vermeidung einen Mehrwert. Fehler in diesem Sinne also Grundlage von Erfolg im allgemeinen sind.

To squash or not to squash

Als Nutzer von GIT als Versionsverwaltung dürfte einem bewusst sein das die Historie nicht
in Stein gemeißelt ist. Commits können sowohl lokal als auch remote auf dem Server verändert
werden
. Eine recht verbreitete
Variante dieser Veränderung ist der “Squash”.

Tatsächlich kann man vortrefflich darüber streiten ob es sinnvoll oder vielleicht sogar
gefährlich ist die Historie in einem System zu verändern dessen elementare Aufgabe es ist
eben diese zu bewahren. Für mich ist der Squash in erster Linie ein Mittel um einen Feature-Branch
aufzuräumen, bevor dieser zurück in den master-Branch fließt.

Dabei ist es für mich ein absolutes No-Go blind sämtliche Commits zusammenzuführen nur damit die
Zahl der Commits gering gehalten wird. Wohl aber finde ich es sinnvoll über die Commits zu gehen,
eventuell logisch zusammenhängende Commits zusammenzuführen oder neu zu sortieren. Kleine Fehlercommits
ala “tippfehler korrigiert” interessieren im Nachgang auch niemanden.

Zwiespältig sehe ich das entfernen von Commits die einen Fehler produziert haben. Handelt es sich
um einen Flüchtigkeits- oder Tippfehler dann kann der mMn gerne weg. Bei Denkfehlern kann ein zweiter
Commit mit einer Korrektur und einem Hinweis auf diese vielleicht für einen Reviewer oder interessierten
Codeleser weiter helfen dieses Problem selbst zu vermeiden. Muss man also von Fall zu Fall entscheiden.

Was schon aufgrund technischer Gefahren nicht passieren sollte sind Änderungen der Historie auf dem
Master-Branch, oder auch auf Intergrations-Branches. Diese werden typischerweise von mehreren Entwicklern
verwendet, gar kontinuierlich geliefert und was geliefert wurde sollte sich nach der Lieferung auch
nicht mehr verändern.