Changelogger: Open Source CLI Tool

Es gibt meines Erachtens zwei Dinge, die viele Entwickler nicht können gerne machen. Das ist zum einen (gute) Dokumentationen schreiben und zum anderen ein vernünftiges Changelog erstellen. Für das letztere habe ich nun ein Tool gebaut: Changelogger.

Das Tool habe ich für ChurchTools gebaut, die Firma wo ich aktuell arbeite. Denn wir brauchten eine einfachere Lösung um Changelogs über den Sprint hinweg zu sammeln. Aber fangen wir mal vorne an.

Change… was?

Ein Changelog ist ein Änderungsprotokoll. Sei es die App aus dem AppStore oder eine Bibliothek für Entwickler. Wenn etwas geändert wurde, ein Fehler behoben ist oder ein neues Feature hinzukam, so sollte das in einem Changelog beschrieben/erwähnt werden.

Sollte ich ein Changelog erstellen?

Ja! Ohne Ausnahme. Denn entweder es sind deine End-Nutzer, die gerne nachsehen wollen welches coole Feature du in deiner App nun eingebaut hast oder andere Entwickler möchten erfahren, ob ein Update auf die neue Version ohne Probleme machbar ist.

Gerade wenn eine Bibliothek so genannte „Breaking Changes“ beinhaltet, also Änderungen die das aktuelle Verhalten ändern und somit deine jetztige Verwendung kaputt machen könnten, dann müssen diese Änderungen erwähnt werden. Ein Changelog ist dafür die beste Lösung.

Keep a Changelog

Der Podcast „The Changelog“ hat ein Interview mit Oliver Lacan veröffentlicht. Oliver hat die Seite keepachangelog.com erstellt, wo er noch mal genauer auf die Fragen eingeht und auch eine gute Vorlage für einen Changelog anbietet. Diese Seite habe ich mir nun als Vorlage genommen um ein CLI Tool zu bauen.

Changelogger

Der Changelogger ist ein PHP CLI Tool um einfacher Changelogs für Änderungen zu erstellen und diese in Git zu tracken. Wenn eine neue Version fertig ist, kann das Tool alle Logs zusammenfassen und strukturiert in die CHANGELOG.md Datei schreiben.

Das Problem

Bei ChurchTools arbeiten wir mit GitLab-Issues und Merge Requests. Soweit so gut. Während eines Sprints kommen aber viele Änderungen zusammen. Von Bug Fixes hinzu Security Issues, neuen Features oder Library Updates. Das alles dokumentieren wir im Changelog für unsere User, dass diese nachlesen können was in der neuen Version so drin ist.

Die Logs haben wir immer im jeweiligen Issue in die Beschreibung gepackt. Das wurde aber auf Dauer etwas nervig. Denn beim Release musste einer manuell alle Issues durchgucken, die Changelogs rauskopieren und zusammenfassen.

Die Lösung

Ich habe etwas recherchiert und bin dabei auf diesen Beitrag von GitLab gestoßen. GitLab hat ein Bash Script geschrieben um Changelog Dateien zu erstellen. D.h. für jede Änderung wird eine YAML Datei erstellt, die mit dem Merge Request gestellt wird.

Warum nicht einfach direkt in die CHANGELOG.md Datei schreiben? Das führt sehr schnell zu Merge Conflicts, wenn mehrer Leute die gleich Zeile bearbeiten wollen, was am Anfang eines Sprints oft passiert.

Der Vorteil mit eigenen Dateien liegt somit auf der Hand. Keine Konflikte und man sieht sofort als Reviewer, ob ein Changelog mitgeliefert wurde oder ob der noch fehlt.

Release-Day

Wenn alles soweit fertig ist, dann kann der Changelogger alle unveröffentlichten Änderungen automatisch einlesen und in die CHANGELOG.md Datei schreiben. Das Ganz orientiert sich an keepachangelog.com und sieht somit immer sauber und einheitlich aus.

Verwendung

Ich könnt das Tool gerne in euren Projekt verwenden. Entweder ihr installiert es global oder ladet die PHAR Datei runter. Changelogger ist zwar in PHP geschrieben, aber wie viele andere guten CLI Tools kann man es in jedem Projekt verwenden.

changelogger new # Neuen Log Eintrag erstellen
changelogger release <tag> # Unveröffentlichte Logs in CHANGELOG.md schreiben
changelogger show # Liste alle unveröffentlichten Änderungen

Beta Hinweis

Wir verwenden das Tool schon bei uns, aber es ist noch im Beta Stadium. Es fehlen noch ein paar Dinge, die ich gerne hinzufügen möchte und auch der Code bedarf ein wenig an Refactoring. Wenn euch Dinge ein-/auffallen hinterlasst ein Issue.

Wenn euch das Projekt gefällt und ihr es in einem eurer Projekte verwendet lasst es mich wissen. Entweder hier als Kommentar oder auf Twitter.

Was du nicht als Programmierer tun solltest

Auf dev.to wurde ein Artikel veröffentlicht, mit 8 Dingen, die du nicht als Programmierer tun solltest. Das sind weniger Anti-Patterns, die man beim Programmieren verhindern sollte, sondern viel mehr Einstellungen.

Einen Punkt finde ich sehr wertvoll und den habe ich vor Jahren für mich selber definiert, denn ich merke wenn ich danach lebe, geht es mir besser.

Do Not Worship Frameworks & Languages💎

Der haseeb, Autor des Artikels, schreibt folgendes:

„Was du nicht als Programmierer tun solltest“ weiterlesen

Neue Seite für hanshelgebuerger.de

Auf meiner Projektliste steht schon seit langer Zeit die Überarbeitung meiner Startseite hanshelgebuerger.de. Aber wie bei so vielen Dinge musste ich auch dieses Projekt lang vor mir herschieben. Nun habe ich den ersten Schritt getan und möchte euch kurz erzählen wie das vorgehen jetzt ist.

Warum der Wechsel?

Die alte Seite lief noch mit WordPress und dem Agent Theme.

Die alte Seite lief mit WordPress und war eine eigenständige Seite. Ich wollte diesen Blog und meine private Startseite trennen. Das hat auch wunderbar funktioniert.

Inzwischen muss ich aber sagen, dass ich mir (wieder) mehr vorgenommen habe mit dieser Seite als ich tatsächlich umgesetzt habe. Denn am Ende war ein veralteter Text drauf und auch die „Projekte“ waren mehr schlecht als recht representativ für meine Arbeit.

Sprich, ich habe die Seite nicht anständig gepflegt.

Daher kam der Wunsch in mir auf die Seite neu zu machen. Um das Problem der „Aktualität“ etwas in den Griff zu kriegen möchte ich dieses mal bewusst die Seite ganz minimal halten und keine Elemente drauf packen, die in paar Monaten schon wieder veraltet sind.

Mit diesem Minimalismus-Gedanken habe ich mir einige Seiten von Entwicklern angeguckt um herauszufinden was die machen und um rauszufinden was ich mag. Ich bin hier immer noch nicht am Ende mit der Suche, solltet ihr ansprechende Startseiten kennen postet die gerne mal in den Kommentaren.

Die neue Seite

Der Wunsch nach einer neuen Seite war da, aber wie gehe ich das jetzt ab besten an? Und genau dieser Punkt hat mich lange blockiert, sodass ich am Schluss … gar nichts tat. Doch damit ist jetzt Schluss.

Ich möchte Mut zur Lücke beweisen. Denn es muss nicht alles perfekt sein um es zu zeigen. Daher habe ich mich entschieden die neue Seite im laufenden Betrieb zu bauen. Die erste Version ist schon online.

Eine neue Seite ist schon online. Aber wirklich beeindruckend ist das noch nicht. Muss es aber auch nicht sein.

Tooling

Ich hätte natürlich wieder mit WordPress starten können. Das CMS ist nach wie vor meine erste Wahl, wenn ich ein CMS benötige. Aber für meine Landing Page brauche ich das nicht. Die Infos sollen ja gar nicht regelmäßig aktualisiert werden. Und falls sich doch was ändern, na dann ändere ich halt den Source Code – Ich bin schließlich Entwickler.

Somit steht mir die ganze Welt an Tools zur Verfügung und ich habe mich für eine simple VueJS Seite entschieden. Mit Vue CLI kann man sehr schnell seine Seite bauen.

Zweitens wollte ich gerne mehr mit Tailwind CSS machen. Das ist ein Utility-first CSS Framework und wird gerade vor allem von der Laravel Community gepusht. Ich würde mich nie als Frontend-Entwickler bezeichnen und daher habe ich immer gerne zu Frameworks wie Bootstrap oder Bulma gegriffen. Aber nachdem ich die Idee hinter Tailwind verstanden habe hat es mich gereizt mehr damit zu machen.

Also Vue und Tailwind. Mehr braucht es nicht. Am Schluss habe ich eine ganz einfach statische Seite. Die nicht mehr macht als zu existieren. Kein CSM dass mich behindert und auch keine lästigen Server und PHP Einstellungen. Denn HTML, JS und CSS haben sich bewährt.

Vorgehen

Wie schon geschrieben, der erste Schritt ist online. Ich würde es noch nicht mal als Version bezeichnen. Es ist nicht nicht mal ein Entwurf. Aber ich wollte dennoch starten. Der erste Schritt ist immer der schwierigste und ich bin daher froh einfach mal was online zu haben mit dem ich jetzt arbeiten darf.

Vielleicht tut sich erstmal Monate lang nichts, vielleicht ändere ich das Styling in den nächsten Wochen drei mal. Wer weiß das schon. Aber egal wie schnell sich die Seite entwickelt, ich möchte mir kein schlechtes Gewissen mehr machen!

Radio Titel im Terminal anzeigen

Seit geraumer Zeit beschäftige ich mich mit tmux. Neben den vielen Vorteilen, die ich ggf. mal in einem anderen Post erkläre, hat man in tmux auch eine Statusbar. Diese zeigt mir verschieden Informationen an z.B. über die aktuelle Session und die Windows. Allerdings kann man diese Statusbar auch selber gestalten.

„Radio Titel im Terminal anzeigen“ weiterlesen

Anleitung zum Fragenstellen auf WordCamps und anderen Konferenzen

Das Web ist voller schöner Artikel und gerade im Englischsprachigen Raum gibt es viele Perlen. David Bisset hat nun einen Blog Post geschrieben indem er 5 Tipps gibt, wie man besser Fragen stellen kann auf WordCamps (Konferenzen).

Ich selber hatte ja auch schon auf einigen WordCamps das Privileg als Sprecher aufzutreten und kenne daher die Situation ganz gut. Am Schluss gibt es immer noch die ein oder andere Frage aus dem Publikum. Da ich die Tipps von David sehr gut finde und euch nicht vorenthalten möchte übersetze ich kurzerhand David’s Artikel hier, natürlich mit David’s Erlaubnis. Das nachfolgende ist somit lediglich meine Übersetzung und bleibt David’s geistiges Eigentum. Den englischen Original Post findet ihr hier auf davidbisset.com.


Es ist wieder die Zeit im Jahr. In einem Monat werden wieder viele WordPress Interessierte zum WordCamp US pilgern (welches dieses Jahr in Nashville stattfinden wird) und anderen Events (Ich [David] zum Beispiel werde das WordCamp Orlando besuchen im November). Daher dachte ich mir es wäre eine gute Zeit sich die Frage zu stellen „Wie stellt man Fragen auf WordCamps?“.

Es gibt zwei Situationen, wo Fragen auf einem WordCamp gestellt werden auf die ich mich hier fokussieren möchte: Das ist zum einen (1) am Ende eines Talks, also bevor der Sprecher / die Sprecherin den Raum verlässt, da der Zeitplan sagt, dass die Session vorbei ist. Und zweitens (2) während der State of the Word Session auf dem WordCamp US, wo Matt Mullenweg typischerweise Fragen aus dem Publikum beantwortet. Meine Tipps sind für beide Situationen anwendbar, mögen auch für andere Zeiten nützlich sein und einige sind vielleicht für wieder andere Situationen gar nicht zutreffend.

  1. Halte dich kurz. Ich glaube das ist die wichtigste Regel. Egal was du tust. Viele Fragen benötigen KEINE komplexe Hintergrundgeschichte. Sollte es doch nötig sein, dann frag dich, ob die wenigen Minuten live vor dem Publikum, die du hast, dafür der passende Rahmen sind. Oftmals finde ich es effektiver, wenn man eine Frage stellt, die dich näher der Antwort bringt (oder eine Frage auf die man einfacher beantworten kann) und DANN kannst du den Sprecher / die Sprecherin fragen, ob du ihm / ihr eine längere Version schicken kannst. Vielleicht. Auf jeden Fall solltest du deine Frage kurz halten und Rücksicht auf die kurze Zeit nehmen aus Respekt anderer Fragesteller und Fragestellerinnen gegenüber.
  2. Bereite dich vor. Ich glaube einige der eher ungeschickten Fragen sind die, die sich Leute spontan überlegen. Was vollkommen in Ordnung ist, aber nicht jeder kann das. Schreibe deine Fragen präzise auf eine Karte. Das ermöglicht es dir die Frage so klar wie möglich zu stellen.
  3. Stell dich nicht in den Fokus. Stelle deine Frage so, dass andere Zuhörer auch davon profitieren. Sicherlich hast du das schon mal gehört: Jemand stellt eine Frage über ein spezifisches Problem welches kein anderer (zumindest im Raum) hat. Andere gehen sogar soweit und fragen lediglich nach technischem Support. HALT! Frag dich, ob du das nicht nach dem Vortrag fragen kannst oder einer anderen Zeit.
  4. Ich habe Leute gesehen, die so viele Fragen wie möglich reinquetschen wollen („Meine zweite Frage ist … Und eine Folgefrage wäre …“). Manchmal ist das ok, manchmal ist es eher egoistisch um ehrlich zu sein. Sprecher / Sprecherinnen und andere Fragesteller / Fragestellerinnen erwarten in der Regel EINE Frage pro Person. Manchmal ist eine Frage genug auf die man sich noch konzentrieren kann.
  5. Lass andere auch Fragen stellen. Wenn niemand weiteres Fragen hat und Zeit übrig ist, dann kannst du ggf. eine weitere Frage stellen.

Ich bin voll und ganz für Publikumsbeteiligung auf WordCamps. Aber es gibt einige Regeln die logisch sind und respektiert werden sollten.

Ich möchte WordCamp dazu ermutigen einen Ort einzurichten (z.B. eine Happiness Bar oder einen separaten Raum), wo Sprecher / Sprecherinnen verfügbar sind nach dem Vortrag um weitere Fragen zu beantworten oder um sich privateren Fragen zu stellen. Dort können Leute dann die Chance nutzen um etwas längere oder persönlichere Fragen zu stellen.