Über Softwarekomplexität

Dienstag, 25 April 2017 10:44 by Christoph

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.

MusicDb v1.0 veröffentlicht

Sonntag, 23 März 2014 12:00 by Christoph

Man hat ja über die Jahre so eine Musiksammlung auf dem PC angelegt und zwischenzeitlich auch mal vergessen, was man in grauer Vorzeit alles mochte. Vor bereits etwa 12 Jahren habe ich dazu das Konsolenprogramm "listmp3" geschrieben, das die Dateien in einem Verzeichnis in eine schicke HTML-Übersicht formatiert. Über das Auslesen der ID3-Tags (eingebettete Meta-Daten wie Interpret und Album) hatte ich einen Artikel im PC Magazin verfasst.

Nun, nach so langer Zeit, habe ich MusicDb v1.0 als Quasi-Nachfolger veröffentlicht. Natürlich ist alles viel besser!1!! Aber im Ernst - da ich mich weiterentwickelt habe, ist in MusicDb nur noch wenig vom alten Programm übergeblieben. Eigentlich nur noch die Idee von der HTML-Übersicht. MusicDb ist eine Windows-Anwendung und indiziert Verzeichnisse in eine Sqlite Datenbank. Die Meta-Daten dafür extrahiert die Taglib und für das Vorhören per Doppelklick ist die BASS-Bibliothek zuständig.

Für mehr Interaktion ist nun ein Webserver integriert, nämlich Civetweb. Im Browser wird es dann richtig interessant. Ein HTML5-Frontend erlaubt die rasend schnelle Suche nach Datennamen oder Bestandteilen der Meta-Daten (das Backend ist C++ via Civetweb). Dank HTML5-Audio lassen sich Suchergebnisse in Playlisten einordnen und da es sich um einen Webserver handelt auch auf anderen PCs im Netzwerk anhören. Fast schon ein richtiger Mediaserver!

MusicDb ist ein Experiment, wie sich die Programmierung bei mir in 12 Jahren verändert hat. Die Sprache ist immernoch die Gleiche: C++, sonst ist aber alles anders. Open-Source wird viel stärker eingesetzt, in MusicDb allein 7 Bibliotheken. Eine sinnvolle Architektur zur Integration ist viel wichtiger geworden als die Ersterfindung des Rades. Diese Form von Komplexitätsbewältigung erlaubt die Konzentration auf das, was wirklich wichtig ist: coole Features.

Doch genug philosophiert. MusicDb gibt es hier zu Download: https://christoph.stoepel.net/ViewSoftware.aspx?id=0126

Bibliotheken, die man kennen muss (C++)

Donnerstag, 12 Mai 2011 12:41 by Christoph

Das mag einige jetzt überraschen aber: das Rad wurde bereits erfunden. Softwareentwicklung macht Spaß, aber kreative Leistung ist dadurch gekennzeichnet, dass sie eben neu ist. Dass man die vorhandenen Resourcen nutzt, um etwas nicht Dagewesenes zu erstellen. In diesem Post möchte ich einige dieser Resourcen vorstellen, die in meiner Werkzeugkiste einen festen Platz gefunden haben und die die stabile Basis für Neuentwicklungen bilden.

  • Die Windows Template Library (aktuell v8.1) ist eine sehr schlanke Alternative zur MFC, der Bibliothek für grafische Oberflächen unter MS Windows. Die Lernkurve ist etwas steil. Wie der Name bereits andeutet, setzt die WTL massiv auf Templates. Sie stellt aber trotzdem eine deutliche Vereinfachung der GUI-Entwicklung im Vergleich zur nackten WinAPI dar ohne den Bloat der MFC.
  • Die Cairo Grafikbibliothek (aktuell v1.10.2) ist für mich unverzichtbarer Bestandteil geworden, wenn es um 2D-Visualisierungen geht. Wie GDI oder GDI+ kapselt Cairo alles: von der Textausgabe über Punkte, Linien bis hin zu Polygonen. Und das schöne: plattformunabhängig und mit verschiedenen Ausgabezielen wie zum Beispiel PNG, PDF, SVG oder eben ein Windows Fenster. (Democode im Github)
  • Kryptographie gefällig? Verschlüsselung? Symmetrisch, asymmetrisch? Prüfsummen, Base32-Codierung? Die Crypto++ Library (aktuell v5.6.1) hat sie alle! Wann immer Kryptographie benötigt wird, ist das die Bibliothek meiner Wahl. Zum Beispiel bei Software-Lizensierung über Produktschlüssel. Weiterhin sehr gut, dass Kompression über die ZLib (aktuell v1.2.5) bereits eingebaut ist. Diese nutze ich meist auch in ihrer ungekapselten Rohform, wenn es mal ohne Verschlüsselung geht.
  • SQLite (aktuell v3.7) hat sich für mich als Allzweckwaffe für Datenspeicherung etabliert. In diese dateibasierte embedded Datenbank passt einfach alles. Und der Zugriff funktioniert allerbequemst mit standardisierten SQL-Queries. Das beste: die Datenbanken lassen sich auch aus .NET ansprechen und dass sie auch auf anderen Betriebssystemen als MS Windows lesbar sind, muss garnicht mehr erwähnt werden.

Mir fallen noch viel mehr ein, aber man sollte Aufzählungen aus didaktischen Gründen nicht wuchern lassen. Deswegen erwähne ich nur kurz und zum selbst weiterrecherchieren noch cURL (aktuell v2.20) zum Herunterladen von Daten aus dem Web (und zum Beispiel cachen mit SQLite s.o.) sowie Googles v8 (aktuell v3.5), der rasenden Javascript-Engine aus dem Chrome Browser (Democode im Github).