Referenzen

Was ich tolles getan habe

Hier ist eine kleine Sammlung meiner öffentlichen bzw. privaten Projekte zu finden. Gerne darf man sich durch die Verweise klicken und mir Feedback oder Anregungen geben. Für weitere Informationen kann man mich natürlich ebenso gerne kontaktieren.

Simple Regex Language
Reguläre Ausdrücke sind unglaublich mächtig. Und verwirrend. Man macht viel zu einfach Fehler. Man vergisst, einen Punkt zu escapen, oder verwechselt ^ mit $. Simple Regex Language – kurz SRL – schafft Abhilfe. Und das in vielen Programmiersprachen. Bonus: Jede SRL-Abfrage lässt sich in eine herkömmliche Regular Expression konvertieren.

Release Monitor
Ich denke jeder weiß wie nervig es ist über einen Veröffentlichungstermin auf dem Laufenden gehalten zu werden. Erst gibt es keinen genauen Termin, dann wird er verschoben, dann ändert sich nochmal etwas und bald hat man den Überblick verloren. Mit dem Release Monitor wird man nun über jede Änderung persönlich informiert.

kANBNkANBN
Wer gerne strukturiert arbeitet und seine Aufgaben als Post-Its verteilt hat, wird kANBN lieben. Das Aufgabenverwaltungstool ordnet Aufgaben mit dem Kanban-Prinzip an.

Nothing for Android
Dass man auch mit nichts Erfolg haben und über 20.000 Downloads bekommen kann, zeigt diese App. Des weiteren wurde sie mehrmals bei AndroidPIT sowie in einem Video von iBlali erwähnt.

Sonstiges (GitHub)
Auf GitHub habe ich ein paar öffentliche Projekte, die hauptsächlich aus Langeweile entstanden sind.

 

Fehler, die mir passiert sind

Failure is a friend dressed up like an enemy. – Jeff Goins

Dieses Zitat finde ich besonders gut und ich merke immer wieder, wie viel Wahrheitsgehalt darin steckt. Ein ähnlicher Grundsatz ist bei den Werten von GoDaddy zu finden, welche den Mitarbeitern vermittelt werden: “Own Outcomes” – Bedeutet soviel wie: Stehe zu deinem Ergebnis, egal ob gut, oder schlecht.

Niemand ist perfekt und jeder macht Fehler. Trotzdem fällt es uns meist schwer, das zuzugeben. Ich finde, dass Fehler nichts Schlechtes sind und sie uns helfen, unsere Stärken zu erkennen und unsere Schwächen zu verbessern. Deswegen möchte ich zu all meinen Ergebnissen stehen. Darunter fallen die oben aufgezählten positiven Ergebnisse, aber eben auch die Folgenden, in welchen ich erklären möchte, was ich falsch gemacht, und was ich daraus gelernt habe.

 

2017: Rechtegruppen sind überbewertet

Ein Sync-Job zwischen Datenbank und Active Directory hatte die Aufgabe, alle Rechtegruppen aller Mitarbeiter zu synchronisieren. Wird eine Gruppe in der Datenbank entfernt, wird sie von dem Job auch aus dem AD entfernt. Problematisch wird es, wenn die verwendete AD-Library bei einem Update einen Bug aufweist, welcher als Gruppenname immer einen Leerstring zurückgibt. Als Resultat wurden bei einem Durchlauf nach dem Update alle Gruppen aller Mitarbeiter des Unternehmens aus dem AD entfernt und somit der Zugriff auf sämtliche Services verweigert.

Was ich gelernt habe:

  • Unit-Tests sind kein Allheilmittel und stellen nicht sicher, dass keine Fehler auftreten können. Deswegen ist es wichtig, darauf zu achten, dass die Entwicklungsumgebung so genau wie möglich mit der Live-Version übereinstimmt. Automatische Library-Updates sollten deswegen auch mit Vorsicht genossen werden.
  • Bei Jobs mit sensiblen Aufgaben an vielen Objekten ist es sinnvoll, eine Prüfung auf ungewöhnliche Aktionen zu implementieren (Sanity Checks). So könnte der Job beispielsweise abbrechen, wenn mehr als 20% der Nutzer aus Gruppen entfernt werden, und damit einen Totalschaden verhindern.
  • Gute Dokumentation ist sehr wichtig. Darüber habe ich in 2016 schon gebloggt, und es zeigt, dass auch ich noch einen langen Weg zu gehen habe. Zwar sind viele Teile der Anwendung gut dokumentiert gewesen, die Verwaltung und das Debugging von Jobs jedoch nicht, was dazu führte, dass wir eine Verzögerung von etwa einer halben Stunde hatten, da ich zum Zeitpunkt des Auftretens nicht erreichbar war.

Was ich schon gelernt hatte:

  • Rollbacks sollten schnell gehen und auch von unterwegs möglich sein. Das ursprüngliche Problem wurde deswegen binnen einer halben Stunde nach Erkennung behoben und die Synchronisation konnte erneut angestoßen werden.
  • Unit-Tests helfen, solche Fehler vorzubeugen, weswegen ein ähnlicher Fehler in der Vergangenheit verhindert werden konnte. Leider habe ich in diesem Szenario zu viel Mocking betrieben.
  • Das Finden der genauen Ursache ist elementar. Wenn nur Vermutungen über den Fehler angestellt werden können, er aber nicht reproduzierbar ist, läuft man Gefahr, einen solchen Fehler zu wiederholen. Glücklicherweise konnte ich den Bug auf den genauen Commit in der Library runterbrechen und somit sicherstellen, dass das Verhalten wieder normal ist.

 

2014: DELETE FROM ….

Im Leben eines jeden ITlers kommt einmal der Tag, an dem er eine Produktivdatenbank radikal aufräumt. In meinem Fall war es die Zeiterfassungsdatenbank, welche die erfassten Arbeitszeiten der Mitarbeiter festhält. Statt eines SELECTs habe ich versehentlich ein DELETE ausgeführt. Glücklicherweise mit entsprechendem WHERE-Statement, weswegen nur ein paar Mitarbeiter davon betroffen waren. Das Ende vom Lied war allerdings, dass einige ihre Zeiten nachtragen mussten, weil das Backup nicht zuverlässig funktionierte.

Was ich gelernt habe:

  • Backups sind ungeheuer wichtig und müssen auf ihre Funktionsfähigkeit geprüft werden. Ein kaputtes Backup ist kein Backup.
  • Vorsichtig mit Berechtigungen umgehen. Zwar ist es schön, viele Möglichkeiten zu haben, aber mit viel Macht kommt viel Verantwortung. Jedem User sollte daher nur die Rechte zugeschrieben werden, die er auch wirklich benötigt. Auf einer Live-Umgebung sollten diese entsprechend eingeschränkt werden. Ein Read-Only-Zugang per Default ist ebenfalls eine gute Idee. So muss explizit ein anderer gewählt werden, wenn Änderungen durchgeführt werden sollen.
  • Für Tests sollten immer Entwicklungsumgebungen verwendet werden, und diese sollten keinen Zugriff auf die Produktiv-Systeme haben.

Was ich schon gelernt hatte:

  • Backups sind wichtig, weswegen ein Backup vorhanden war. Leider war es – wie erwähnt – unvollständig und somit unbrauchbar.
  • Kommunikation ist entscheidend. Der Fehler wurde kommuniziert, die betroffenen Mitarbeiter wussten Bescheid und konnten ihre Zeiten nachtragen, weswegen sich der Schaden auf ein Minimum begrenzte und die Arbeitszeiten am Ende des Tages korrekt abgerechnet wurden.