{devday.17}

Schon am Dienstag hatte ich die Gelegenheit wahrgenommen und den {devday.17} in der Börse Dresden besucht.

Der devday ist eine lokale von der Software Engineering Community der T-Systems-MMS organisierte Konferenz mit Fachvorträgen rund um Softwareentwicklung. Die Vorträge stammen dabei überwiegend von Referenten aus Dresdner Firmen. Das Publikum ist gemischt, aber klar von MMSlern dominiert.

DevOps war in diesem Jahr war eines der dominanten Themen. Wenngleich sich die meisten dieser Vorträge mit technischen Details und nicht mit dem philosophischen Hintergrund beschäftigten.

Den Auftakt machte mit der Eröffnungskeynote Christof Fetzer mit einem Überblick über das an der TU-Dresden entwickelte SCONE, einer Sicherheitsschicht für Docker Container auf Basis von Intels SGX Extension.

Vor Ort habe ich mir den Erfahrungsbericht von Daniel Trautman zum Thema DevOps angehört. Daniel ist Teil des Cloud & Heat Teams und Kern seines Vortrages war die Art wie bei Cloud & Heat DevOps gelebt wird. Sicher ist die Firma noch recht frisch und klein, aber gerade deshalb scheint dort ein tatsächlich so etwas wie DevOps nach Lehrbuch zu funktionieren.

Den zweiten Vortrag von Daniel Rohlfs zum Thema Gitflow, Maven und Jenkins hätte ich mir sparen können, da soll wohl der Vortrag von Githubs Johannes Nicolai besser gewesen sein. Inhaltlich stelle Marc ein Jenkins-Plugin vor mit dem sich das Branching nach Gitflow in Mavenprojekten mittels Jenkins realisieren lässt. Leider kannte die hälfte der Zuhörer kein Gitflow, die andere Hälfte kein Maven und mir selbst blieb unklar warum man für diese Arbeiten die man mit ein paar Zeilen Shellskript oder einem Mavenplugin auch lokal erledigen kann ein Jenkinsplugin bauen muss.

Im dritten Slot ließ ich mich von Frontend Jünger Peter Kröner überzeugen das ich definitiv auch mit RxJS kein Frontend programmieren möchte. Der Vortrag hat mir jetzt recht inhaltlich eher wenig gebracht, war aber sehr unterhaltsam.

Die Abschluss Keynote von Daniel Meixner war wiederum ein schönes Plädoyer für den Einsatz von DevOps Tools. Ein wirklich netter Vortrag bis zu dem Moment als der Abgesandte von Microsoft ein Macbook zur Demo von Azure rausholte und der Vortrag zur Alpaka-Decken-Show mutierte.

Alles in allem waren die Vorträge in Ordnung, nicht überragend aber ausreichend motivierend nächstes Jahr wieder hinzugehen.

Wer nicht da war oder wie ich natürlich nicht alle Tracks besucht hat, der kann Hoffnung haben, denn einige Tracks wurden aufgezeichnet und tauchen bestimmt irgendwann auf dem Youtube Channel der SECO auf.

PS.: Auch das Essen am Ende und das Kuchenbuffet waren sehr lecker ;)

{devday.17} stage

Can't fix

Can't fix
Quelle: turnoff.us

Dead Code = Evil Code

Coder sind Messis. Ich habe bisher kaum ein größeres Projekt in den Fingern gehabt das keine Leichen im Keller hatte.

Das gängige Problem ist natürlich der “gewachsene” Code. Ein Projekt wird den Wasserfall runter entwickelt, geht live, geht in die Wartung. Dann kommt ein Feature dazu, ein anderes wird abgeschaltet. Am besten gibt es noch zig Schalter und Properties mit denen Teile des Quellcodes aktiviert oder deaktiviert werden könnten. Theoretisch.

Böse wird es dann wenn man auf Basis eines alten Projektes ein neues aufsetzen muss. Dann hat man diese bestehende Code Basis. So richtig weiß man nicht was da so alles passiert und dann kommt der Onkel aus der Projektleitung uns meint das man dieses und jenes Feature ja dann in Phase 3 oder 4 vielleicht brauchen wird, daher soll man es doch bitte im Code lassen.

Bullshit. Ehrlich das ist Bullshit. Vor 50 Jahren vielleicht als Quellcode noch auf Lochkarten gepresst wurde, da hat es Sinn ergeben alten Code aufzubewahren. Heute sollte es Teil eines jeden halbwegs soliden Refactorings sein das man unbenutzen Code rausschmeißt.

Warum?

  1. Toter Code gerät in Vergessenheit. Was man nicht wartet wird vergessen. Irgendwann ist der Schöpfer des lähmenden Brockens nicht mehr im Team, gar nicht mehr im Unternehmen und dann findet sich der neue Entwickler im Tal der WTF’s wieder.
  2. Ungenutzer Code wird allgemein schlechter getestet. Klar gibt Unit- und Integrationstests, aber wenn die Funktion nicht mehr im Testplan ist steigt die Wahrscheinlichkeit von Fehlern kontinuierlich an. Und spätestens wenn man ihn dann wieder einbinden will fängt man an im Nebel zu stochern weil irgend was nicht funktioniert.
  3. Ungenutzer Code liegt bei Refactorings im Weg. Wir eine Bibliothek angepasst oder etwas an der Codebasis verändert von welcher der tote Code abhängt entstehen unnötige Aufwände. Im schlimmsten Fall wird ein Refactoring gar als unmöglich eingestuft nur weil da ja noch eine Klasse von abhängt oder mit refactored werden müsste.
  4. Ungenutzer Code macht ein Projekt unübersichtlich und komplex. Dadurch wird es schwerer neue Funktionen zu integrieren, die Bibliothek an anderer Stelle zu verwenden und neue Entwickler in ein Projekt zu integrieren.

Alles in allem wiegen diese Probleme um so schwerer, je monolitischer und größer ein Projekt allgemein ist. Eine feine kleine Bibliothek wird von Natur aus dazu neigen weniger Leichen zu beinhalten als ein riesen eCommerce Framework. Nichtsdestotrotz möge ein jeder Entwickler und Projektleiter mal in sich gehen wenn er das nächste Mal ein Feature abschaltet ob der Code wirklich noch gebraucht wird.

Und ganz ehrlich, es tut niemandem weh einen Tag im Git zu machen und den Code rauszuwerfen. Denn wenn man wirklich in nem Jahr eine Funktion wieder braucht, dann schaut man nach was man da rausgeworfen hat und refaktoriert eben genau dann und spart der Weile eine Menge Arbeit und WTFs. Ob man dabei dann auf Basis des gelöschten neu implementiert oder direkt wieder verwendet ist dann auch egal.

Los Verschlüsseln - Let's Encrypt ?!

Vor 15 Jahren wäre ich ja fast auf die Idee Idee gekommen ein Trust-Center zu eröffnen. Zu diesem Zeitpunkt erschien mir das Geschäftsmodell ziemlich clever. Man lässt sich fürstlich dafür bezahlen ein paar Befehle auf der Kommandozeile auszuführen damit Webseiten mit Verschlüsselung zu versorgen.

Zu dieser Zeit waren es aber auch maximal Banken und Zahlungsanbieter oder offensichtlich mit sensiblen Daten arbeitende Seiten welche überhaupt verschlüsselten. Tatsächlich wusste mancher SEO ja auch aus Erfahrung das Google kein SSL kann und überhaupt Datenverlust oder Massenüberwachung waren damals kaum ein Thema.

Das Konzept dieser Trust-Center war (und ist) aber einfach geil. Ich konnte meine Seite zwar auch verschlüsseln, aber wenn ich nichts bezahlen wollte dann gab es jedes mal eine fette Warnung vom Browser das mein Zertifikat nicht vertrauenswürdig sei. Wenn ich mich nicht täusche gilt das gleiche auch immer noch für CAcert, ein Projekt das Authentizität und Verschlüsselung mittels eines Netzwerks von engagierten Assurern kostenlos zur Verfügung stellen wollte.

Zwischendurch gab es noch StartSSL von welchen man neben bezahlten Zertifikaten auch kostenlose bekommen konnte. Letztere waren nur 1 Jahr gültig und die Authentizität wurde nur über E-Mails sichergestellt. Inzwischen verschiedentliche Probleme und Besitzerwechsel welche dazu führten das alle großen Browser diese Zertifikate inzwischen ablehnen.

Mit verschiedenen Exploits in Verschlüsselungsmechanismen, Datenpannen und unerwarteter Überwachung ging nun auch ein Wandel einher. Plötzlich ist es schick jede Seite zu verschlüsseln. Kosten darf das natürlich weiterhin nix und in diese Bresche ist nun Let’s Encrypt gesprungen. Bei dieser Initiative reicht es einen Client per Git auszuchecken, seine E-Mail und Domain anzugeben und zusätzlich noch seine Webserver Konfiguration anzupassen. Allein damit kann man sich in jedem Browser gültige Zertifikate unterzeichnen lassen.

Ich finde das geil und ich benutze es auch weil ich meinen Besuchern eine bequeme Möglichkeit bieten möchte verschlüsselt auf mein Blog zuzugreifen. Aber und das scheint bei Let’s Encrypt nie so richtig rüber zu kommen: Durch ein kleines Grünes Schloss sind Daten nur auf dem Weg vom Browser zum Server geschützt! Was dort damit passiert, wer den Server betreibt und was der damit macht, darüber sagt das Schloss bei Let’s Encrypt so gar nichts aus.

Warum? Wenn ich physischen Zugriff auf einen Server habe, dann kann ich dort E-Mails empfangen, Webseiten hosten und Let’s Encrypt Zertifikate installieren. Meiner Meinung nach ist Let’s Encrypt eine coole Idee, aber die versprochene Sicherheit sehe ich durchaus mit gemischten Gefühlen. Was den Part der Authentizitätsprüfung angeht war CAcert deutlich fortgeschrittener, leider haben die es aber nicht in unter die von den Browsern vertrauenswürdigen Trust-Center geschafft.

Am Ende lässt sich wohl mit der “Volksverschlüsselung” kein Geld verdienen. Echte Authentizität gibt es aber weiter nicht auf dem Grabbeltisch.

Schnüsch

Zur Abwechslung auch mal Foodbloggen, soll ja in sein ;) Die Schnüsch ist ein Gemüseeintopf aus dem Raum Schleswig. Zutaten sind klassisch Hülsenfrüchte, Kartoffeln, Kohlrabi, Karotten welche in Milch gekocht werden.

Zutaten

  • 500g Kartoffeln
  • 250g Möhren
  • 250g Grüne Bohnen
  • 250g Erbsen
  • 250g Kohlrabi
  • 1 Liter Milch
  • 125g Sahne / Schmand
  • 1 Bund Petersilie

Als zusätzliches tierisches Protein eignen sich kleine Hack- oder Fleischbällchen. Alle Zutaten am besten frisch besorgen oder wenn nicht Verfügbar durch gefrostete Version ersetzen.

Zubereitung

  • Gemüse ordnungsgemäß putzen und in kleine Würfel / Stücke / Streifen schneiden
  • Möhren und Kohlrabi 3-5 Minuten in Butter andünsten
  • Restliches Gemüse zugeben und knapp mit Wasser bedecken, salzen, aufkochen und ca 10-15 Minuten gar köcheln lassen
  • Den Topf von der Hitze nehmen und den Gemüsefond abgießen
  • Eine Mehlschwitze anrühren und mit Milch, Sahne und etwa der Hälfte vom Gemüsefond und der Petersilie aufkochen und dann wieder zum Gemüse geben
  • Das Ganze nochmals etwa 5 - 10 Minuten bei geringer Hitzer köcheln lassen
  • Am Ende ggf. noch mit Salz, Muskat und weißem Pfeffer abschmecken