Da schrieb ich noch vor fast zwei Jahren: Ich bin drauf und dran, von der Blogengine zu einer selbstgebauten Lösung zu wechseln. Ich habe es dann nicht gemacht, weil der Autor löblicherweise anfing, etwas Bloat (Angular!!!) zu entfernen. Hat er dann aber leider nicht weitergeführt, sondern geschrieben, dass er keine Lust mehr auf die Blogengine hat und stattdessen mit etwas Neuem rumspielt. Damit muss man natürlich rechnen - unangenehm ist es aber trotzdem.

Da hat es mich also wieder in den Fingern gejuckt. Doch was tun? Habe mich wieder im Microsoft-Umfeld umgeschaut, wie ich das am besten selber baue. Microsoft hat mich ziemlich früh in der Uni mit dem Studentenprogramm drangekriegt. Seit Visual Studio 2002 bin ich beim .NET Framework dabei, das müsste Version 1.1 gewesen sein. Doch mit dem .NET Framework ist es nun aus. 16 Jahre waren echt eine lange Zeit. MS ist ja verdammt, die Kompatibilität zu erhalten (Developers! Developers! Developers!).

Der neue hippe Kram ist .NET Core und damit ASP.NET Core, ein modularisiertes Framework, das immer noch C# versteht und schwer auf den Paket-Manager Nuget setzt. Habe ich also den Schritt gemacht und die Blogengine einfach mal komplett weggeworfen. Mehrere tausend Dateien. Ich habe nur die 39 Blog-Beiträge und darin referenzierte Resourcen behalten, ansonsten alles from scratch neu geschrieben (insgesamt ein Aufwand von drei Tagen, ich habe viel Bloat einfach weggelassen, wie Trackbacks, Pingbacks, Kommentare, Bewertungen). Das Ergebnis läuft hier gerade.

Dann habe ich auch gleich noch Geogen v4 auf .NET Core portiert. Das soll ja angeblich auch schneller laufen. Eigentlich ging es mir aber um die Zukunftssicherheit - ich will nicht auf dem Trockenen sitzen, wenn Windows Server irgendwann kein .NET Framework mehr mitbringt. Manchmal ist das auch schade, wie Microsoft so durch die Technologien huscht. Als sie den SQL Server Compact mit ASP.NET Unterstützung eingeführt haben, war ich wirklich glücklich, eine In-Process Alternative zum SQL Server zu haben. Leider haben sie die Unterstützung inzwischen komplett eingestellt. Argh! Hätte ich nur gleich auf Sqlite gesetzt.

Ich mag Komplexität nicht. Die kann man nicht dauerhaft beherrschen. Kontrollverlust.

Das ist mir beim Aktualisieren der Blogsoftware wieder ganz enorm aufgefallen. Ich hoste ja ungewöhnlicherweise auf einem Windows-Server und bevorzuge serverseitig ASP.NET. Für das Devlog habe ich auf den Platzhirschen zurückgegriffen, die Blogengine.NET. Die war mal schlank, übersichtlich und recht wartbar. Aber die Security. Darf man auf Updates verzichten? Eher nicht. So habe ich in Abständen die Updates mitgemacht und war immer mehr ernüchtert. Was vorher schlank, übersichtlich und recht wartbar war, wurde nun zu Angular, Bootstrap und Webgrease. Leute, mal echt: muss das sein? Ich war ganz nah dran, das alles wegzuschmeißen und einen statischen Seitengenerator zu verwenden. Oder mir selber einen zu schreiben. Dieses Jahr dann jedoch die erfreuliche Nachricht. Das Pendel schwingt wieder zurück. Man rückt ab vom Bloat.

Ich habe das durch meine recht eigentümliche Updatestrategie bemerken dürfen. Die offizielle Anleitung besagt, die neuen Dateien einfach in die alte Installation integrieren. Nein! Dann bleibt doch nicht mehr verwendeter Code rumliegen, stellt schlimmstenfalls Sicherheitsrisiken dar. Ich mache das anders: Neue Installation anlegen und Dateien aus der alten, von denen ich weiß, dass sie gebraucht werden, dort integrieren (Konfigurationen, Themes, Blog-Beiträge). Dann mit Git vergleichen: 1000 Änderungen, davon jedoch 500 echtes Löschen - also nicht jQuery 2.1 entfernen und jQuery 2.4 hinzufügen, sondern wirklich weg! Das ist gut. Es zeigt, dass die Autoren erkannt haben, wie sie übertrieben. Die Abhängigkeitsübertreibung war nicht gut, der Erkenntnisgewinn schon.

Die meisten Entwickler schaffen nur Schritt 1. Die Javascript- und Ruby-on-Rails-Leute sind so ein Beispiel. Es gibt da auch Gute, aber es gibt insgesamt einfach sehr viele, so dass die Schlechten absolut auch mehr sind. Die haben ein Problem und schauen nach einem Gem/ Node-Package. Wiederverwendung ist ja an sich nichts Schlechtes, es ist ein Mittel gegen Komplexität. Aber was die da gemacht haben, entbehrt wirklich allem was gut und rein ist. Ich habe das mal gesehen. Problem war: wir brauchen einen Datensatz aus der Datenbank via Web-API als JSON. Lösung: irgendein Rails-Exporter Gem ergoogelt. Das brauchte aber auch Authentifizierung (abhängiges Gem). Das wiederum sollte auch nebenläufig gehen (abhängiges Gem). Das wiederum musste synchroniert werden (abhängiges Gem). Die Synchronisation musste regelmäßig auf Konsistenz geprüft werden (abhängiges Gem). Bumm! Um einen Datensatz als banales JSON auszugeben wurden 10 MByte an Abhängigkeiten (geschätzte 30 Gems) installiert. Naja, immerhin hatte das System dadurch am Ende auch eine Schnittstelle für Cron-Steuerung.

Kurz: Schaut doch mal genau was ihr braucht. Fast nie benötigt man ein Framework. Beobachtet, welche Abhängigkeiten ihr euch einfangt. Oft findet man sehr spezifische und schlanke Lösungen. Wenn nicht, dann baut man sich eben eine. Software-Engineering ist eine kreative Tätigkeit und Verstehen ist der Schlüssel. Wenn man empfohlene Frameworks einfach von Stackoverflow kopiert, dann ist etwas extrem faul.

Normalerweiseweise verlinke ich nicht auf andere Blog-Posts oder Social-Media Krimskrams, aber hier hat sich jemand aus den USA die Mühe gemacht, Geogen mehr zu dokumentieren als ich selbst. Die Autorin Elise Ann Wormuth hat auch noch ein paar andere Erfahrungen eingestreut: livinginpast.com.

Die Seite ist recht webzweinullig - man muss Newsletter-Angebote, Cookie-Disclaimer, Übersetzungshilfen usw. wegklicken, aber dann ist sie sehr passioniert aufgemacht.

Bob war wieder unterwegs. Okay, ich war unterwegs - aber Bob war dabei und hat sich aufdringlich in die Fotos gedrängt. Das passiert nun zum wiederholten Mal!

Normalerweise baue ich eher Software aber vor einiger Zeit habe ich meinen Raspberry Pi auch auf die zweite Generation aktualisiert und wieder etwas in Hardware rumgespielt (wenn auch am unteren Ende der Bastelskala). Nun gibt es einen interessanten Aufsatz: das Astro-Pi Sensorboard oder auch Sense HAT.

Ich habe mir das mal zugelegt und montiert, damit ich auch bei mir zu Hause Temperatur, Luftfeuchtigkeit und Luftdruck messen kann. Für diese Zwecke braucht man selbstverständlich einen vollwertigen selbstgebauten Computer! Und natürlich das Coolste: eine LED-Matrix aus 8x8 Elementen. Der Aufsatz ist mit einer API in Python steuerbar. Diese Sprache ist normalerweise nicht so mein Ding, aber was solls. Da ich einen kleinen Webserver (nginx) auf dem Gerät laufen habe, schrieb ich mir ein kleines Web-Frontend, um die Sensoren auszulesen oder Lauftexte zum Beispiel vom Tablet aus auf die LED-Matrix zu packen. Damit braucht man dann auch kein Python mehr.

Jetzt zeichnet das Ding alle 10 Minuten sämtliche Sensordaten in eine Datenbank auf und zeigt mir ein nettes "Hallo Christoph" an, wenn ich das möchte. Das Projekt ist natürlich total hippstertrendy auf Github zu finden.

https://github.com/Chrisso/Astro-Pi-Web

Ich sammle Features ja nun nicht mehr für große Releases, sondern packe sie nach bestandenem Test sofort auf den Server. Für die Namenskartierungssoftware Geogen waren das in letzter Zeit drei Änderungen, weshalb ich als Zwischenstand mal die Version 4.0.3 ausrufe.

(4.0.1) Lokalisierung.

Nun gibt es Ausgaben auch in Deutsch und nicht mehr nur in Englisch. Zumindest die meisten Texte sind übersetzt, vom Server kommen noch manche extrem seltene Fehlermeldungen in Englisch, aber damit kann man leben. Die Übersetzung funktioniert mit i18next.

(4.0.2) Load-Control.

Ich habe bemerkt, wie eine IP systematisch Namenskarten in alphabetischer Reihenfolge abgerufen hat. Bei einer Frequenz von 5 Sekunden, kann das kein Mensch gewesen sein. Ich gehe von einem gescripteten Download der Datenbank aus. Ab jetzt kann man höchstens ein paar hundert Recherchen pro drei Stunden anstellen, dann wird man erstmal eine zeitlang gesperrt.

(4.0.3) Aktualisierte Abhängigkeiten.

Mit frischem jQuery, Three.js, D3.js und JSON.NET sollte die Seite schneller und runder laufen. In diesem Zuge habe ich auch kleine kosmetische Änderungen untergebracht, zum Beispiel sind die 3D-Balken jetzt heller.

Rundum zufrieden bin ich mit der vierten Generation von Geogen noch nicht, aber technisch immerhin zufriedener als mit der dritten. An der Benutzbarkeit kann man noch etwas feilen. Den meisten Besuchern ist zum Beispiel nicht auf Anhieb klar, dass man auf die 2D-Karte auch klicken kann und dann zu einer Landkreisdarstellung (v3) kommt. Gleiches für den Graphen mit ähnlichen Namen. Der zeigt auf Klick einen größeren Graphen mit noch mehr phonetisch naheliegenden Varianten an.

Eine Funktion ist leider von Anfang an flöten gegangen: mehrere Namen in einer Karte. Das habe ich schlichtweg vergessen - aber deswegen ist die alte Version ja auch noch online. Dafür normalisiert v4 jetzt Sonderzeichen weg: Süßé ist auf dem Server dasselbe wie Suesse. Analog Müller und Mueller.

Ein Scraper ist Software, die Webseiten ausliest und automatisch Informationen extrahiert, quasi ein hochspezialisierter Bot, der Quelltexte scannt und ausgewählte Links anklickt. Da der Onlineshop Amazon kürzlich 20jähriges Bestehen feierte, habe ich mich gefragt, wieviel Geld ich dort inzwischen gelassen habe. Auf der amerikanischen Webseite gibt es die Möglichkeit, alle Bestellungen herunterzuladen - auf der deutschen nicht. Und hier kommt der Scraper ins Spiel.

Ich habe das mal komplett als hippes Open-Source Projekt durchgezogen. Mit Visual Studio 2015 Community und als Github-Projekt. Es ist in C# für das .NET-Framework 4.5.2 geschrieben. Damit ist es sehr hipp, aber nicht zu hipp :)

Der Scraper navigiert die Seiten der eigenen Bestellhistorie, sofern in Firefox Anmelde-Cookies vorhanden sind. In wenigen Monaten wird die Version 1.0 wahrscheinlich nicht mehr funktionieren. Dann wird Amazon irgendwas an der Seitenstruktur geändert haben und die Bestellungen sind nicht mehr richtig extrahierbar. In einem Open-Source Projekt kann das aber jeder forken und fixen.

Kurz zu meinen Resultaten. Es ist eine erschreckende Menge zusammengekommen. Meine erste Bestellung war im Jahr 2000. Ich habe damals ganz skeptisch nur Produkte geordert, an die ich in meiner Umgebung partout nicht rankam: den Needful Things, den Planet der Affen und den Ghostbusters 2-Soundtrack. Mittlerweile hat sich das umgekehrt. Ich kaufe in meiner Umgebung nur noch ein, was es partout nicht bei Amazon gibt. Im Plot der jährlichen Ausgaben für den Insider zu erkennen: Wehrdienst, Studium, Diplomandenzeit, schlechter Job, guter Job, Sättigung.

Ich muss nochmal auf Cynthia Barcomis Backbuch eingehen. Weil das letzte Mal schon recht lang her ist, laufe ich auch nicht Gefahr, eine kommentierte Rezeptsammlung (neudeutsch Foodblog) zu werden. Ich habe auch gar keine Lust, das Rezept hier abzutippen und möchte stattdessen nur kurz den New York Cheesecake besonders lobend hervorheben. Den habe ich nämlich gebacken

Werkzeugmäßig bin ich vergleichsweise schlecht ausgestattet. Anstelle eines Handrührgerätes habe ich Frischkäse, Eier und Sahne mit einem Pürierstab vermixt. Anstelle eines tiefen Backbleches um die Springform, habe ich einfach eine Lasagne-Auflaufform geflutet. Ja, der Amerikaner backt Käsekuchen gut abgedichtet im Wasserbad. Komisch, dass es im 180°C heißen Ofen nicht vollständig verdampfte. Ich nehme an, das liegt an der Sättigung. Irgendwann ist die Luft schlichtweg feucht genug.

Typisch männlich habe ich dabei eine Menge Dreck gemacht. Aber hey, das Ergebnis zählt: ein supersaftiges süßes Meisterwerk mit Blaubeertopping (nur Kulturbeeren, Saison für Wildwuchs ist erst später). Arbeitsmäßig ist das Rezept eine Menge Aufwand - für mich als Amateur etwa 2-2,5 Stunden. Mit etwas Begabung oder alternativ auch Übung kann man das bestimmt auf die Hälfte reduzieren. Ich werde das in jedem Fall nochmal machen, dann aber mit besserer Ausrüstung.

Demächst gibt es aber erstmal wieder Fleisch.