MySQL Fehler: ERROR 2002 (HY00)

Ich entwickel lokal mit Valet, dabei wird PHP und MariaDB mittels Brew verwaltet. Nun hatte ich in letzter Zeit mehrmals das Problem, dass der Datenbankserver nicht erreichbar war, ergo keine Webseite funktioniert hat. Ich bekam nur folgende Fehlermeldung:

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)

Ich hab viel gesucht und fand die verschiedensten Lösung aber es hatte nichts funktioniert bis ich endlich die Lösung hatte. Es gab keinen Fehler mit dem Datenbankserver ansicht, sondern dieser lief einfach nicht. Ich konnte den aber über Brew auch nicht starten, wie es normalerweise Valet macht.

Die Lösung war:

$ mysql.start

Mit dem Befehl wir der Datenbankserver normal gestartet und der Socket wieder angelegt. Das war mal wieder so ein 🤦🏼‍♂️ Moment.

tmux: Befehl an Fenster senden

Tmux verwende ich inzwischen täglich. Ich habe mir mit tmuxinator ein Setup gebaut, wo ich verschiedene Fenster haben um bestimmte Befehle und Kontexte zu trennen. So habe ich zum Beispiel ein Radio Window. Dort läuft der VLC Player und spielt mein lieblings Radio als Webstream ab.

So schön so gut. Nun habe ich aber oft die Situation, dass ich da Radio an- bzw abschalten muss, weil ein Call rein kommt. Ich muss dann erst in das Fenster wechseln und dann den Process beenden. Und wenn der Call vorbei ist wechsel ich wieder in das Fenster und starte das Radio erneut. Das muss doch einfacher gehen!

Und tatsächlich man kann Befehle direkt an ein bestimmtes tmux Window schicken. Egal wo man ist.

tmux send-keys -t SESSION:WINDOW "echo Hello World" C-m

Damit habe ich mir 2 Aliase gebaut um einfach das Radio in dem Fenster zu kontrollieren:

# ~/.dotfiles/zsh/aliases.zsh
alias on='tmux send-keys -t Work:Radio "radio" C-m'
alias off='tmux send-keys -t Work:Radio C-z'

Meine tmux Session heißt Work und das Fenster habe ich Radio genannt. Ich hab einen Alias radio der mir den Webstream aufruft und im VLC Player abspielt.

Mit C-m wird der Befehl im Fenster auch ausgeführt. Wenn man das weg lässt wird der Befehl lediglich im Terminal eingetippt. C-z sendet ein SIGSTOP und beendet den Prozess und das Radio hört auf zu spielen.

Perfekte kleine Helfer. So kann ich nun von überall mit on und off das Radio kontrollieren.

Quelle: stackoverflow.com

Bilder (Dateien) aus Unterordnern holen und Ordner löschen

Heute mal ein wirklicher Quick Tip. Ich habe viele verschiedene Bilder und Videos in diversen Unterordnern gehabt. Die wollte ich jetzt alle in einen neuen Ordner verschieben und dann alle leeren Ordner löschen. Man kann das zwar händisch machen, aber in meinem Fall waren das mehrere Hundert Ordner. Da wäre ich heute noch nicht fertig gewesen. Zum Glück gibt es das Terminal.

# Alle Dateien in Unterordner die auf .jpg Enden verschieben in einen neuen Ordner
$ mv */**.jpg new/folder

# Finde alle leeren Ordner und listes sie auf
$ find . -type d -empty -print 

# Lösche alle leeren Ordner
$ find . -type d -empty -delete

(Quelle: Unix SE)

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.

Changelogger Banner

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.

Changelogger Demo

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