Ich bin schon sehr lange im Microsoft-Umfeld unterwegs. Das fing an mit Windows 95 und Turbo Pascal, wechselte dann über Borland Delphi zu Visual C++ 6. In der Uni ging es dann per Visual Studio.NET (2002-2005) zum .NET Framework mit allem Drum und Dran: Windows Forms, Remoting, XML Webservices.

Eines war die ganze Zeit aber klar: Unter Linux kannste das komplett vergessen. Es gab da zwar schon Mono, ich tat das aber als Frickler-Kopie ab. Die haben sich irgendwie die Funktionalität angeguckt und daraus Code engineered. Das kippte in den letzten Jahren. MS hat quasi alles .NET Core als Open Source rausgehauen, hat Github gekauft und unterstützt die Runtime selbst und offiziell auf Linux.

Da ich alle meine Web-Projekte (just for the fun of it) zwischenzeitlich auf ASP.NET Core (aktuell v2.1 LTS) umgestellt habe, reizte es mich natürlich, das mal mit eigenen Augen unter Linux sehen. Was soll ich sagen? Läuft!

Die Dokumentation, um das mit den offiziellen Docker-Images zu erreichen, ist leider nicht die Beste. Auf mich wirkt es sehr umständlich, immer ein eigenes Image zu erzeugen um da sein Zeug reinzupacken, aber es geht natürlich dabei um Produktions-Deployments. Da will man genau ein Image irgendwo hinkopieren. Ich dagegen wollte nur mal schnell die Bits meines Windows-Deployments (vom Server kopiert) unter Linux ASP.NET testen. Dazu findet man nichts, aber das geht auch:

docker run --name devlog -p 8080:80 -v $(pwd):/app -w /app \
  --rm --entrypoint dotnet mcr.microsoft.com/dotnet/core/aspnet:2.1 \
  devlog.dll

Oder etwas eleganter und archivierbarer als docker-compose.yml:

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.

Ich schrieb es bereits zum zehnjährigen von Geogen, dass ich mit der vierten Generation der Namenskartierungssoftware experimentiere. Vor drei Monaten war das hauptsächlich aus Spaß und ich wusste noch nicht genau, wo es hinführen sollte. Jetzt ist es immer noch Spaß, aber ich weiß, was das werden soll.

Die Version 4.0 ist öffentlich zugänglich. Sie ist Namenskartierung im modernen Gewand, mit besserer Übersicht und erhöhter Performance. Ich bin in den letzten Monaten ein Fan von Continuous Delivery geworden, d.h. ich habe kleine Features und Verbesserungen sofort nach bestandenen Tests auf das Live-System ausgerollt. Am letzten Wochenende war das zum Beispiel eine coole "Game of Thrones"-Animation der 3D-Karte. Womit ich auch schon bei den Details von Geogen 4.0 bin.

Die Software ist eine komplette Neuentwicklung. Ich habe wirklich keine einzige Codezeile der Vorversionen übernommen. Sie setzt auf aktuelle Webtechnologien und hier jeweils auf etablierte Hilfsbibliotheken. Das Grundgerüst ist HTML5 mit jQuery (was sonst?). Dazu kommen WebGL via three.js, Canvas und SVG via D3.js. Im Backend tummeln sich illustre Gäste wie MS SQL Server Compact, Json.NET und ZXing.Net.

Geogen 4.0 gibt es in zwei Fassungen:

• Bleeding Edge Graphics: geogen.stoepel.net
• PuristicTerminal: geogen.stoepel.net/console.html

Es gibt derzeit keine Bestrebungen Geogen 3.1 abzuschalten. Ich entwickle aber dort keine neuen Features mehr und deaktiviere höchstens Gadgets, die vor Jahren einfach schlecht implementiert wurden.

Update 07.03.2015: Ich habe begonnen, die neue Engine international parametrisierbar zu machen. Die Geogen-Konsole funktioniert jetzt auch für Österreich: http://geogen-at.stoepel.net/console.html und phonetische Namensgraphen gibt es ebenso.

Geogen ist in der Version 3.1 online verfügbar. Die interne Datenbank-Zugriffsschicht ist nun unabhängig von einem bestimmten Hersteller. Vorher war die Verwaltung von Ranglisten, Nutzerkommentaren und Geograpphie nur mit dem MS SQL-Server via System.Data.SqlClient möglich. An dessen Stelle treten konsequent die Factory-Methoden aus System.Data.Common. Im derzeit stattfindenden Testlauf liegen alle Daten in einem SQL-Server Compact Edition 4.0 - also im selben Prozess wie ASP.NET. Dadurch sollte die Mehrzahl der Nur-Lese-Zugriffe etwas performanter sein.

Im Rahmen dieses Refactorings habe ich auch gleich die MS Ajax Bibliothek samt Ajax Control Toolkit entsorgt. Diese wird von Microsoft zwar noch ausgeliefert aber nicht mehr weiterentwickelt. Das Pferd ist also tot. Man muss sich da auch nichts vormachen: MS Ajax war zu aufgebläht, zu langsam und (was das Control Toolkit betrifft) zu fehleranfällig. Ich habe die Webseite daher komplett auf jQuery umgestellt. Es ist enorm was da grade in der Entwicklung abgeht.

Die erste Änderung, die dadurch möglich wurde, ist ein Autocompleter auf dem Eingabetextfeld. Einfach ein paar Buchstaben eingeben und im Hintergrund werden per Ajax einige Vorschläge herausgesucht, welchen Namen man meinen könnte. Das Control-Toolkit enthielt auch einen Autocompleter, allerdings vertrug er sich nicht nicht mit den per Javascript abgerundeten Ecken. Mein Bug-Report dazu wurde damit abgetan, dass man sich nicht um die Z-Order kümmern kann und das Problem nicht lösbar sei. Die jetzigen runden Ecken kommen per CSS auf alle modernen Browser. Im Internet Explorer bleibt es kantig.

Die Kartenübersicht wurde verschlankt. Die Steuerelemente für Zusatzparameter, die sowieso niemand benutzt hat, habe ich entfernt. Eine derartig fortgeschrittene Konfiguration ist nur noch über die Kaufsoftware möglich. In diesem Zuge wurden die Karten auch gleich in die Ergebnisseite integriert. Mit Hilfe der Fancybox werden sie in Form eines Overlays vor leicht ausgegrautem Hintergrund angezeigt.

Weitere Änderungen sind eher Kleinigkeiten: zu selteneren Namen wird ein maschinenlesbarer Balkencode berechnet mit dem man irgendwelche Gegenstände bekleben (neudeutsch taggen) kann, auf der Startseite läuft ein Ticker zuletzt abgerufener Namen aller Besucher, der phonetische Namensgraph hat den Beta-Status verlassen und ist nun auch in der englischen Version verfügbar und ganz neu gibt es auch eine Fassung für Mobilgeräte. Das nächste Update soll dann ein größeres werden (Version 4.0 oder zumindest 3.5). Ich experimentiere dazu etwas mit HTML5 und Canvas...

Heute geht es um eine ganz andere Art der Informationsvisualisierung. Genauer: die Codierung von Information in Barcodes. Diese sind eigentlich bekannt, zum Beispiel in Form von Strichcodes auf fast allen Produktverpackungen. Strichcodes -eindimensional- sind die einfachste Form. Hier soll es um zweidimensionale Codes gehen, die in anderen Ländern schon stärker verbreitet sind und mehr Informationen fassen. In Japan ist der QR-Code (Quick-Response) bereits seit Jahren ein Renner. Im Rahmen des sog. Mobile Tagging fotografieren die Japaner alle möglichen Codes mit ihren Handys hinter denen sich Internetadressen, Mailadressen oder Kurznachrichten verbergen.

Doch wie erzeugt man diese Codes? Es gibt zahlreiche SDKs. Fast alle sehr sehr kostenpflichtig. Die günstigen ab 1700 Euro, der Schnitt bei 2500 Euro. Wir wollen es aber kostenlos haben ganz nach dem deutschen Motto Geil ist Geil (Häh? Sic!). Für C++ stößt man da auf die Zint-Bibliothek unter der GNU GPL. Diese kann alle möglichen Arten von Barcodes generieren, unter andem auch den begehrten QR-Code. Also auf gehts mit der ASP.NET Integration!

Zint ist in nativem C geschrieben, es wird also eine Brücke in die .NET-Welt benötigt. Diese wird in C++/CLI gebaut. Doch von Anfang an: Im Zint-Package enthalten ist eine Visual Studio Solution mit einer Konfiguration für den Bau ein statischen Bibliothek (lib). Diese ist auszuwählen und im Release-Modus zu erstellen. Ein neues C++/CLI Projekt referenziert diese Bibliothek und wrappt die Grundfunktionen für den Managed Sprachen wie C# und Visual Basic.NET. Das sieht im Detail dann auszugsweise so aus:

public ref class BarcodeFactory
{
private:
    array<bool>^ m_data;

public:
    BarcodeFactory();
    int Encode(String^ data, int type);
    bool GetAt(int x, int y);
};

Die zu codierenden Daten werden als (managed) String an die Methode Encode übergeben. Der Parameter type enthält die Kennung des zu erzeugenden Strichcodes und wird unverändert an Zint weitergegeben. Für den QR-Code ist 58 anzugeben. Nach dem Aufruf ist das Array m_data mit Flags belegt, ob bestimmte Pixel gesetzt sind oder nicht - damit lässt sich der Code dann zeichnen.

Die entstandene Mixed-Mode-Assembly kann in ASP.NET referenziert werden. Auf diesem Server übernimmt das ein Handler (ashx), der über den Querystring gesteuert wird und eine PNG-Grafik des Codes ausliefert. Es gibt nur 2 Get-Parameter und nur der erste davon ist obligatorisch.

1. q zu codierende Daten (Achtung: Url-Encoded!)
2. s Skalierung der Pixel, Standard ist 4, d.h. ein Pixel im Barcode wird als ein 4x4 großes Quadrat gezeichnet

Hier ein paar Beispiele für den Aufruf des Handlers:

1. https://christoph.stoepel.net/api/Barcode?q=Hallo+Welt (Hallo Welt mit Standard Einstellungen)
2. https://christoph.stoepel.net/api/Barcode?q=Hallo+Welt&s=6 (Hallo Welt mit 6x6 großen Quadraten
3. https://christoph.stoepel.net/api/Barcode?q=Hallo+Welt&s=2 (Hallo Welt etwas verkleinert)
4. https://christoph.stoepel.net/api/Barcode?q=https%3A%2F%2Fchristoph.stoepel.net%2F (die URL dieser Seite)

Achso, bezüglich der GNU GPL des Zint-Projektes: der Download des GPL-infizierten Quelltexts ist in obigem QR-Code codiert :)