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.

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.

Schon etwas älter ist das Programm WebGraph, ein Dataminer der skriptgesteuert Links aus verschiedenen Webseiten extrahiert und daraus einen Verknüpfungsgraphen generiert. Das Originalprogramm basiert auf OpenGL und benutzt Googles v8-Javascript Engine.

Da man ja mit der Zeit geht und sich auf fortbilden will, habe ich die Applikation mal auf .NET in der Version 4.0 und WPF portiert. Das war erstaunlich einfach. Der Code ist im wesentlichen um ein Drittel kürzer geworden. Die grobe Architektur konnte beibehalten werden. Anstelle der v8-Engine ist Jint getreten. Sqlite wird immernoch für das Caching verwendet, allerdings in einer .NET Version. Schließlich konnte die CURL-Bibliothek für den Webzugriff komplett entsorgt werden, da das .NET Framework Standardklassen hierfür bereits mitbringt.

Der Quelltext von WebGraph.NET ist im Github unter https://github.com/Chrisso/WebGraph.NET einzusehen. Am besten einfach mal lossurfen und durch die Source klicken.

Besonders interessant ist an dieser Stelle vielleicht, wie das Grabbing funktioniert. Der Nutzer gibt in der WPF-GUI ein Schlagwort ein. Diese fragt im Cache nach, ob diese Abfrage (evtl. auch als Sub-Abfrage) schonmal ausgeführt wurde. Gibt der Cache einen Fehler zurück (Cache-Miss) wird beim Skript ein Download-URL angefordert. Der Webloader kümnert sich dann um das herunterladen, die GUI gibt das Resultat erneut an das Skript, das dort Schlagwörter (Links, Kindknoten im Graphen) extrahiert. Das Ergebnis landet im Cache und je nach eingestellter Rekursionstiefe beginnt der Prozess mit jedem neuen Schlagwort von vorn.

Oder als Sequenzdiagramm ausgedrückt:

Nach einem Port auf C# habe ich übrigens noch einen in JavaScript erstellt. Zur Anzeige des folgenden Beispiels benötigen sie einen HTML5-kompatiblen Browser, der das Canvas-Element unterstützt. Moderne Software wie Mozilla Firefox und Google Chrome können das von Haus, im Internet Explorer wird das Canvas mittels VML emuliert.

Graph layouten!