🏷️ personal  🏷️ programming  🏷️ tech  🏷️ plans 
📆 28.12.2025

Ideen für 2026

Womit soll ich mich befassen?

Nachdem mein Jahr 2025 zwar einigermassen produktiv aber leider unfokussiert war, möchte ich für 2026 einen anderen Ansatz wählen. Da ich aufgrund meiner beruflichen Situation derzeit nicht längerfristig planen kann, möchte ich zu einer Quartalsplanung übergehen.

Erstes Quartal 2026

Das erste Quartal 2026 kann ich jetzt schon grob planen. Ich möchte mich mit folgenden Themen befassen:

  1. Das Semester endet nach drei weiteren Schulwochen im Januar. So werde ich mich die ersten Jahreswochen einerseits mit dem Abschluss der bestehenden Module befassen, muss andererseits bereits einen Plan für das neue Semester haben, in dem ich nur das Modul 426 (Software mit agilen Methoden entwickeln) unterrichte. Hierfür habe ich bereits damit begonnen, das Buch Agile! The Good, the Bad, and the Ugly von Bertrand Meyer zusammenzufassen. Diese kritische Betrachtung soll einen Ausgleich zum Buch Clean Agile von Robert C. Martin schaffen, worauf mein Unterricht dieses Moduls die letzten drei Durchführungen basierte. Für die Programmierbeispiele werde ich weiterhin auf TypeScript und Deno setzen. In dieser Durchführung möchte ich aber das Thema Verantwortung mehr hervorheben, wobei auch die Idee hinter Explaining Software hineinspielt: Wir müssen in der Lage sein, unsere Software (Anforderungen, Design-Entscheidungen, Code, Testfälle) zu erklären, damit wir die Verantwortung dafür übernehmen können.
  2. Zum Ausbau vom Cloud Castle muss ich mich mit LDAP befassen; genauer möchte ich mich durch die hierzu relevanten Kapitel von OpenLDAP in der Praxis durcharbeiten. Wenn ich dann ein LDAP aufgebaut und die Benutzerverwaltung darauf umgestellt habe, kann ich Guacamole und später Nextcloud besser integrieren. Neben anderen Erweiterungen von Cloud Castle wäre das wohl der grösste Brocken. Ansonsten werde ich mich in diese Kontext weiter mit Go und Ansible befassen, aber wohl eher pragmatisch als systematisch.
  3. Im Januar erscheint die vierte Ausgabe von The Book of PF. Dies möchte ich zu einem guten Teil durcharbeiten, damit ich anschliessend basierend auf OpenBSD eine Netzwerk-Übung an der Berufsschule veranstalten kann. Diese soll dann Ende erstes oder Anfang zweites Quartal 2026 stattfinden. Das lasse ich mir noch offen. Die Vorbereitung der Übung muss zumindest schon weitgehendst im ersten Quartal erfolgen.
  4. Den Kommandozeilenclient achim möchte ich gerne in Go mithilfe der Libraries Cobra und Egoscale neu schreiben. Einerseits sind gewisse Datenstrukturen und deren Aufbau in der Python-Implementierung zu unübersichtlich geworden. Andererseits kann ich das Python-Dependency-Management kaum einem grösseren Benutzerkreis zumuten. Hier ist Go mit seinen statisch kompilierten Binärartefakten wesentlich besser geeignet. Das neue Projekt soll im GitHub-Account meiner Firma gehosted werden. Als Lizenz werde ich die GPLv3 und nicht mehr wie bei der Python-Version von achim die MIT-Lizenz verwenden.
  5. Das Modul 319 habe ich dieses Semester mit C unterrichtet. Dabei habe ich nach mehreren Jahren Beschäftigung mit der funktionalen Programmierung wieder Lust auf Low-Level-Programmierung bekommen. Ich habe bereits im Dezember damit angefangen, K&R C durchzuarbeiten. (Dies habe ich schon einmal vor vielen Jahren gemacht, aber sicherlich nicht sehr konsequent.) Die ersten beiden Kapitel und einige recht anspruchsvolle Übungen habe ich bereits durchgearbeitet. Ich möchte das Buch bis Ende Januar komplett bearbeitet haben. Hierzu erkläre ich es zu meinem Morgenthema. Das Buch beschreibt ANSI C, d.h. ungefähr den Stand von C89. Dementsprechend kompiliere ich den Code jeweils mit dem Flag -std=c89. Anschliessend möchte ich mich mit modernerem C befassen, d.h. mit C99 ‒ und den Unterschieden zwischen C89 und C99. Hierzu habe ich das Buch C Programming. A Modern Approach, welches ich dann im Februar/März durcharbeiten möchte.

Viel mehr dürfte nicht drinliegen. Sollte sich in der Firma noch ein Projekt ergeben, müsste ich umplanen und v.a. Cloud Castle sowie die Netzwerkübung etwas nach hinten schieben. Aber Modul 426 in einer überarbeiteten Version ist gesetzt. Auch achim sollte ich besser früher als später anfangen umzuschreiben, möglichst bevor ich das Projekt weiter ausbaue. Vielleicht wäre ein Start in den Weihnachtsferien sinnvoll.

Im zweiten Quartal wird sich dann auch die Planung für das nächste Schuljahr ergeben, was mir die Planung von Q3 und Q4 erlauben wird.

Jahresübergreifendes Thema

In den über 22 Jahren, in denen ich mittlerweile in der Informatik tätig bin, habe ich selten grössere neuere Sachen von Grund auf aufgebaut. Ich war meistens mit der Wartung und Weiterentwicklng bestehender Software und Infastruktur beschäftigt. Diese Aufgaben waren nicht immer schön, zumal ich schon einiges an Code in schlechtem Zustand übernehmen und erweitern musste. Ich habe das immer gehasst. Da ich aber solche Aufträge immer wieder erhalten habe, bin ich offenbar einigermassen gut darin.

So sollte ich diese Not wohl zu einer Tugend machen. Das Buch Working Effectively with Legacy Code behandelt genau dieses Thema. Wie bekommt man alten Code unter automatische Tests, damit man ihn anschliessend furchtlos anpassen kann? Damit sollte ich mich einmal systematisch befassen.

Allgemein sollte ich konsequenter auf Automatisierung achten; sei es nun beim Testen von Software oder beim Betreiben von Infrastruktur. Hier sehe ich grosses Potenzial. Beim Durcharbeiten des K&R C-Buchs habe ich bisher versucht, konsequent jedes nicht-triviale Programm automatisch zu testen, wozu ich einfache Shell-Skripte schreibe. Hier gibt es sicherlich noch Optimierungsbedarf, denn die Skripte enthalten doch die eine oder andere Wiederholung. Gerne möchte ich hierzu mit tabellarischen Testdefinitionen arbeiten können, wo das sinnvoll ist (d.h. v.a. bei numerischen Aufgaben).

Auch wenn ich an Cloud Castle und achim arbeite, sollte ich auf Testautomatisierung achten. Da beide Projekte zu einem grossen Teil als API-Clients fungieren, möchte ich nicht sinnlos Mocks dafür schreiben. Aber alles, was unter “Programmlogik” geht, sollte ich automatisch testen. Bei Tests, die auf eine Datenbank oder auf das Dateisytem zugreifen, sollte Automatisierung ebenfalls möglich sein. Und Infrastrukturautomatisierung sowieso. Ich muss mir einfach Zeit dafür nehmen.

Weitere Ideen

Ich möchte wieder ein grösseres literarisches Werk gründlich lesen und dabei zusammenfassen, wie dieses Jahr Die Brüder Karamasow. Es muss dabei kein tausendseitiges Werk sein, aber doch gerne wieder ein längeres wie beispielsweise die Ilias oder einer der anderen grossen Dostojewskij-Romane.

Immer noch stelle ich mir die Frage, mit welchem Stack ich CRUD-Anwendungen umsetzen sollte, wenn wir einmal ein entsprechendes Kundenprojekt in der Firma haben. Derzeit sind Go (ohne Framework) und Angular unsere Standardtechnologien, wobei meine Verantwortung im Backend und somit bei Go liegt. Nun könnte ich mich 2026 auf Fortschritte im Frontend konzentrieren und mir auch endlich einmal Angular-Wissen aneignen.

Eine Alternative wäre Elixir und Phoenix, evtl. sogar wieder vermehrt mit serverseitig gerenderter Benutzeroberfläche. Hierzu gäbe es einen hervorragenden Online-Kurs: Phoenix on Rails. Da ich einerseits mittlerweile mit Rails gut umgehen kann und andererseits auch schon etwas in Elixir (und Erlang) programmiert habe, dürfte das für mich wunderbar passen.

Haskell und Rust reizen mich derzeit wenig. Zig wäre ein Kandidat für die eine neue Programmiersprache, die ich jedes Jahr lernen möchte. Hierzu soll im September endlich ein qualitativ hochwertiges Buch von Manning erscheinen. Derzeit gibt es für Zig meines Wissens noch keine stabilen Einführungsmaterialien, was die Einarbeitung unnötig erschwert.

Im Zusammenhang mit Zig bin ich auf Codeberg gestossen. Dies ist eine Organisation, die eine Alternative zu GitHub schaffen will. Technologisch basiert die Plattform auf Forgejo, was offenbar ein Fork von Gitea ist. Für CI/CD kommt Woodpecker CI zum Einsatz. Da ich nicht gerne proprietäre Sachen lerne, wäre das eine interessante Alternative zu GitHub und GitHub Actions. Sollte diese Plattform einigermassen solide sein, möchte ich vielleicht meine Sachen von GitHub auf Codeberg migrieren. Für den Kontakt mit der Aussenwelt werde ich aber weiterhin auf GitHub aktiv bleiben, aber dort keine eigene Entwicklung mehr anstossen. Microsoft muss nicht Zugriff auf all meinen Code haben.

Was das Rudern betrifft möchte ich wieder etwas konsequenter sein. Drei Trainings pro Woche sind sinnvoll. Am besten mache ich je eines am Dienstag und Donnerstag; das dritte dann entweder am Samstag oder Sonntag, wobei vier Trainings auch nicht falsch sind. Aber besser drei planen und konsequent durchziehen. An diesen Tagen habe ich morgens jeweils nichts anderes geplant und kann mich nach dem Rudern meinem jeweiligen Lernprojekt widmen. Bei 52 Wochen, abzüglich zweier Wochen für Ferien und evtl. Krankheit, sollte dies 150 Trainings und 1500 Kilometer ergeben.

Was Ablenkungen betrifft, möchte ich nächstes Jahr sehr konsequent sein und auf folgendes verzichten:

So werde ich weder die olympischen Winterspiele noch die Fussball-Weltmeisterschaft oder die Formel 1 verfolgen. Auch Videos möchte ich konsequent nicht mehr schauen. Lieber abonniere ich einige gehaltvolle Substack-Blogs. Zwar produziere ich noch gelegentlich Programmiervideos, da diese Form bei vielen Leuten wesentlich besser ankommt als Text. Den LinkedIn-Account werde ich wohl endgültig löschen.

Womit ich mich dann im zweiten Quartal befasse, hängt von meinem Erfolg bzw. Misserfolg im ersten Quartal ab.