Neues in der Kategorie Guter Code

Mein erster kurzer Beitrag vom Perl-Workshop 2009 (leider nur eingeschränktem Netzwerk):

Hier die Präsentation zu meinem Tutorial 42 Goldene Regeln für Perl-Applikationen - Oder: Wie sichert sich ein Perl-Entwickler vor dem Psychopathen mit der Kettensäge.

Kurzzusammenfassung:

Viele Anwendungen sind leider üble Hacks, oft mehrere tausend Zeilen Spaghetti-Code in einer Datei und so weiter. Dies ist auch bei in Perl geschriebenen Programmen nicht anders. Dabei werden damit oft missionskritische Aufgaben in Unternehmen betreut. Es geht ja - irgendwie - und es ist kein Geld da, um eine Qualitätssicherung durchzuführen. So mancher Entwickler wird daher von den Vorgesetzten angewiesen, nicht „zu viel Zeit in Qualitätssicherung zu stecken“. Dabei spart eine solche schon mittelfristig viel Entwicklungszeit und damit Geld.

Das Tutorial zeigt, mit welchen Mitteln man dies mit Perl erreichen und den Psychopathen ein wenig beruhigen kann.

Vor einiger Zeit habe ich über die gravierenden Mängel des Online-Petitions-Systems vom Deutschen Bundestag berichtet. In der Zwischenzeit wurden zwar einige kleine kosmetische Reparaturen vorgenommen, das Grund-Problem der gammeligen Software besteht aber weiterhin. Unter der „hohen“ Last von rund 16000 Unterzeichnern einer Petition ist der Spaß jetzt zusammengebrochen. (Updates unten: Probleme halten an)

Seit einigen Tagen ist die Petition zum Bedingungslosen Grundeinkommen sehr beliebt und hat viele Unterzeichner erhalten, der Zähler steht bei über 16000. Nun zeigen sich die ganzen Mängel des unzureichenden Systems, wie einige Leser berichteten und ich verifizieren konnte: Durch einen Fehler ist es nicht mehr möglich, dass sich neue Nutzer registrieren und ohne Registrierung ist es auch nicht möglich Petitionen zu unterzeichnen. Dies äußert sich darin, dass nur eine Fehlermeldung erscheint:

Fehler
(Nutzer) Dieser Name ist bereits in Verwendung.

Dies dürfte an einem Datenbank-Fehler liegen und eine Folge der Wahl der technischen Basis sein – die den grundlegenden Anforderungen des Bundesamts für Sicherheit in der Informationstechnik (BSI) widerspricht. Ein paar technische Hintergründe dazu weiter unten.

Das ist aber nicht alles: die PHP/MySQL-Software ist auch an anderer Stelle bei rund 16000 Unterzeichnern einer Petition überfordert, die Anzeige der Unterzeichner wurde daher generell auf 100 begrenzt. Das sieht wie eine schnell eingebaute Notmaßnahme aus, um die Last des Systems zu begrenzen. Denn laut diversen Berichten wurde das Petitionssystem zuvor immer langsamer. Auch das ist ein Zeichen für schlechten Code.

Die Beschwerden im Forum häufen sich, zumal die Zeichnungsfrist für die Grundeinkommens-Petition am 10. Februar abläuft. So fragt der Nutzer Thomas Köppel:

Tja, wie es aussieht ist das System auf dem die Petitionssoftware (Datenbank) aufgesetzt ist, an seine Grenzen gestoßen.
Es bedarf wohl einer besseren Infrastruktur, für das handling des großen Datenaufkommens, ich frage mich was passiert wenn über 1 Millionen Menschen gleichzeitig Zugriff auf das System nehmen.

Viele Grüße
T.K.

Eine Million gleichzeitiger Zugriffe würde zwar fast jedes System zum erliegen bringen; aber insgesamt bei einer Million Unterzeichnern (bzw. Datenbankeinträgen) hat ein anständiges Datenbanksystem keine Probleme. Schließlich sind Datenbanken dafür da, große Datenmengen effizient zu verwalten.

Und Nutzer16941 schreibt:

Das ist leider ein Armutszeugnis für unsere Demokratie (und damit für uns das Volk), wenn unsere Regierung davon ausgeht eine kleines(?) System reicht aus. Denn scheinbar hat es das ja seit Jahren.

Dazu ist anzumerken, dass die Anforderungen an das neue System u.a. waren, dass es im Peak 50000 Nutzer sowie Petitionen mit beliebig vielen Unterzeichnern aushalten muss. Hier zeigt sich wieder, dass das neue System wie beschrieben eben nicht den Anforderungen entspricht.

Denn all das erinnert an das alte Petitions-System, das noch vom schottischen Parlament erstellt wurde. Nun wollte man alles besser machen, aber es wurde nur ein tiefer Griff ins Klo in die Problemkiste: Eine Bundestagsverwaltung, die technische Angebote nicht lesen und verstehen kann (schließlich haben die dortigen Mitarbeiter normalerweise anderes zu tun) und sich daher auf die Behauptungen in den Angeboten verlassen muss, ein Ausschreibungsrecht, dass den günstigsten Anbieter verlangt und eine Firma, die alles mögliche behauptet aber nicht viel einhält – all das zusammen sind meines Erachtens die Hauptgründe für das Dilemma. Den Bundestag sehe ich dabei eher als Opfer.

Aus mehreren Quellen weiss ich, dass derzeit eine Studie zur Online-Petitions-Plattform für das Büro Technikfolgenabschätzung des Bundestages erstellt wird. Die Plattform wird vor Fertigstellung der Studie wohl kaum grundlegend überarbeitet werden – und es ist zu hoffen, dass sie danach komplett weggeworfen und ein ganz neues, sauberes System erstellt wird. Dem Petitionswesen wäre das zu wünschen.

Und woran liegen die Probleme aus technischer Sicht?

Das Problem, dass niemand mehr registriert werden kann, liegt vermutlich an einem Datenbank-Problem, das unter Last auftreten kann. Dazu muss man wissen, dass die Nutzer ihren Nutzernamen nicht frei wählen können, sondern einen Namen „Nutzer12345“ mit fortlaufender Nummer zugewiesen bekommen. Die Petitions-Software basiert auf dem „Simple Machines Forum“, das als Datenbank-Backend  MySQL mit MyISAM-Tabellen verwendet – was keine Transaktionen und Datensicherheit unterstützt und bei mehreren gleichzeitigen Zugriffen ohne besondere Maßnahmen sehr langsam wird und schon mal den einen oder anderen Fehler erzeugt. Aber auch wenn Transaktionen unterstützt werden können können ähnliche Probleme auftreten, beispielsweise zwei gleichzeitige nicht synchronisierte Zugriffe (zum Beispiel durch das fehlende Sperren einzelner Datensätze) und der Zähler für die Erstellung der Nutzernamen ist durcheinander gekommen. Dies nennt man Race Condition (Wettlaufsituation), zwei oder mehr Zugriffe rennen quasi um die Wette und greifen gleichzeitig auf eine Ressource zu, die nur einmal vorhanden ist.

Dumm gelaufen – bei professioneller Software darf sowas nicht passieren. Darum verlangt das BSI ja auch entsprechende Mechanismen und eine ACID-Konforme Datenbank bzw. Software, die diese Funktionen auch nutzt. Aber der Dienstleister hat sich nicht daran gehalten. (mehr zur Petitions-Software ...)

Die langsamen Antwortzeiten bei vielen Unterzeichnern hängen möglicherweise auch (aber nicht nur) mit MySQL und MyISAM zusammen, ein übliches Szenario ist: die Queries (Datenbank-Abfragen) dauern bei vielen Unterzeichnern (also vielen Daten) länger, sperren aber schon beim Lesen die ganze Tabelle für Schreibzugriffe. Schreibzugriffe müssen warten und wenn diese dran sind, müssen die Lesezugriffe warten. So schaukelt sich das ganze unter Last bis zur Unbenutzbarkeit hoch und schon bei relativ niedrigen Nutzerzahlen kann alles zusammenbrechen. Eine andere Möglichkeit ist, dass durch mehrere gleichzeitige lang laufende Datenbankabfragen die Performance in den Keller geht, dadurch mehr Abfragen gestartet werden und irgendwann der Speicher voll ist.

Zudem wurden in letzter Zeit wieder diverse gravierende Sicherheitslücken im verwendeten Simple Machines Forum bekannt. Auch das sorgt nicht gerade für Vertrauen in die Petitions-Plattform. Ebensowenig wie gelöschte Forums-Einträge und gesperrte Diskussionen. Beispielsweise ein gut implementiertes Bewertungssystem könnte das Löschen von Einträgen nahezu unnötig machen.

Die Probleme der Software sind meines erachtens eine große Schande für die Firma araneaNET GmbH, die groß damit wirbt BSI-Zertifiziert zu sein, aber dann MySQL und auch noch Software ohne Transaktionen verwendet, was eben nicht den BSI-Anforderungen entspricht und einer der Gründe der schwerwiegenden Probleme sein dürfte. Auch eine simple Änderung von MyISAM zu InnoDb ändert an der grundsätzlichen Problematik des Simple Machine Forums nichts. Da sieht man mal wieder: solche Zertifikate sind oft nur Schall und Rauch und sagen nur aus, dass da jemand ein wenig Geld in Marketing und vielleicht theoretische Fortbildung steckt.

[Nachtrag, 16:17:]

Ein weiterer Forums-Beitrag von Roswitha61 deutet auf mehr Probleme hin:

Bei mir erscheint "nur eine Mitzeichnung erlaubt". Ich habe mich aber gerade erst registriert und folglich noch gar nicht unterzeichnet.
Was ist das?

Sollte dies echt sein, könnte es sein, dass es noch weitere und massive Datenbank-Probleme gibt.

Die eingangs geschilderte Fehlermeldung erschien bei meinen Tests nun nicht mehr, aber es kommt bei einer Registrierung auch keine Bestätigungsseite und die Bestätigungs-E-Mail habe ich auch nicht erhalten.

[Nachtrag, 8. Februar, 12:15:]

In der Zwischenzeit scheint die Registrierung tatsächlich wieder zu funktionieren. Ich hatte es gestern Nachmittag und Abend mehrfach probiert, wurde aber nach Absenden des Registrierungsformulars ohne weiteren Kommentar oder Fehlermeldung auf die Startseite umgeleitet. Auch eine Bestätigungs-Mail ist nie eingetroffen. Dies lag daran, dass ich vergessen hatte den „Ich bin einverstanden“ auszuwählen. Es wird keine entsprechende Fehlermeldung ausgegeben, sondern der Nutzer wird dann nur auf die Startseite umgeleitet – auch das ist nicht sehr benutzerfreundlich. Einträge im Forum zeigen, dass dies nicht nur mir so passiert ist, die „Ich bin einverstanden“ Checkbox ist nicht sonderlich gut positioniert. Und es häufen sich auch die allgemeinen Beschwerden über die schlechte Benutzerführung.

Zudem konnte man bisher eine Unterzeichnung wiederrufen; da nur noch 100 Unterzeichner angezeigt werden und darunter nicht die neusten sind, findet man sich selbst aber nicht mehr in der Unterzeichnerliste und kann damit eine Unterzeichnung auch nicht rückgängig machen ...

Das obige Problem, dass das Petitionssystem behauptet der Nutzer hätte schon unterzeichnet obwohl dieser da anderer Ansicht ist, tritt auch bei weiteren Nutzern auf. Ob diese nur zweimal auf den Unterzeichnen-Button geklickt haben oder es tatsächlich ein Fehler ist kann ich aber nicht sagen. Ordentliche Software würde dies aber entsprechend abfangen ...

[Nachtrag 9. Februar, 15:32]

Heute reagiert die Petitions-Webseite wieder extrem langsam, manchmal treten auch Datenbank-Fehler auf (siehe Screenshot rechts). Der Zugriff auf eine Seite kann schon mal mehrere Minuten dauern, ganz abbrechen oder mit einer solchen Fehlermeldung enden.

Selbst das Laden eines statischen Bildes dauert schon mal mehrere Sekunden bis Minuten oder wird ganz abgebrochen. Dies deutet auf tiefergehende Probleme hin (Überlastung aufgrund sich gegenseitig blockierender Datenbankzugriffe und dadurch zu vieler Apache-Prozesse) – was ich gleich mal zum Anlass nehme, um in einem eigenen Artikel Tipps zum Umgehen dieser Probleme zu schreiben.

Bereits heute Vormittag wurde aufgrund der Probleme die Zeichnungsfrist für die Petition „Bedingungsloses Grundeinkommen“ um eine Woche verlängert. Das Forum wird aber morgen geschlossen – wahrscheinlich wird es den Moderatoren einfach zu viel Arbeit. Tja, mit einem selbstregulierenden System mittels eines flexiblen Bewertungssystems hätten sie kaum Arbeit, da die Nutzer die Trolle gleich selbst entsorgen könnten.

[Nachtrag 10. Februar, 16:10]

Die Probleme mit der Performance bestehen weiterhin: Lange Wartezeiten, teilweise kommt auch der gleiche Datenbankfehler wie im Screenshot eins weiter oben, und manchmal schlägt auch der Timeout vom Browser zu. Die große Frage ist, ob überhaupt Maßnahmen ergriffen werden, die Probleme zu beseitigen.

[11. Februar, 0:25]

Nun ist alles im „Wartungsmodus“ und außer Betrieb. Vielleicht wird nun alles auf besser ausgestattete Hardware umgezogen. Nach dem Motto: Versuchen wir mal unzureichende Software mit dickerer Hardware zu erschlagen.

Unteressanterweise änderte sich die Darstellung der Fehlermeldung innerhalb weniger Minuten, anfangs war der rote Text oben noch schwarz und nicht fett ...

[12. Februar]

Tatsächlich, die Last-Probleme scheinen zumindest vorerst behoben zu sein.

[17. Februar]

Der Server ist wieder zusammengebrochen, Datenbankfeher inklusive ...

[4. Mai]

Und bei der neuen Online-Petition gegen Internet-Sperren wird der Server wieder langsam ... Sehr langsam ...

Gesetzeswidrige Abfrage persönlicher Daten, komplizierte Benutzerführung und Software mit Sicherheitslücken kennzeichnen die neue Online-Petitions-Webseite, die die araneaNET GmbH für den Bundestag erstellt hat

Update, 16. November: Umfrage und Sicherheitsupdate beim Bundestag, Screenreader-MP3s und sonstige Neuigkeiten

Update, 7. Februar 2009: Petitions-System des Bundestages bricht zusammen

Die neue aber altbackene Online-Petitions-Webseite des Deutschen Bundestages führt den Nutzer zurück ins Web 1.0. Sie verdeutlicht ein Problem öffentlicher Ausschreibungen, das vermutlich nicht nur im IT-Bereich auftritt: die Ausschreibenden haben in der Regel wenig Ahnung von der Materie, müssen aber gleichzeitig fast immer das günstigste Angebot nehmen. Das Ergebnis im Fall der Petitionswebseite: Die zugrunde liegende Software hat kritische Sicherheitslücken, viele Anforderungen des Lastenheftes sind nicht eingehalten worden, die Datenschutzbestimmungen des Telemediengesetzes wurden ignoriert, die Webseite ist schwer bedienbar - und sieht einfach furchtbar altmodisch aus.

Denn anstatt einer speziell auf die Anforderungen von Online-Petitionen (e-Petitionen) samt dazugehörigem Diskussionsforum ausgerichteten Software mit komfortabler und moderner Benutzerführung gibt es ein altes, für den durchschnittlichen Internet-Nutzer schwer bedienbares PHP-Board, in das eine simple Unterschriften-Funktion hineingefrickelt wurde. Das Ganze wirkt eher wie ein privat betriebenes Forum, nicht jedoch wie eine der Würde des Parlaments angemessene, moderne Web-Applikation.

Aber der Reihe nach:

• Hintergrund der Ausschreibung
  Eine kurze Zusammenfassung der Hintergründe der Ausschreibung. [mehr ...]
• Die Umsetzung
  Beschreibung und Kritik der Implementation der Online-Petitions-Website: Sie hat eine schlechte Benutzerführung, altbackene Gestaltung, gesetzeswidrige Datenabfrage und ist nicht barrierefrei. [mehr ...]
• Das Simple Machines Forum
  Eine kurze technische Betrachtung der verwendeten Software, die mit einer ungewöhnlichen Lizenz, Sicherheitslücken und schwer wartbarem Spaghetti-Code glänzt. [mehr ...]
• Der Auftragnehmer: araneaNET GmbH
  Eine Kurzrecherche zu der Firma, die die Webseite für den Bundestag umgesetzt hat. [mehr ...]
• Fazit
  Zusammenfassung und Ausblick: Billig sollte nicht genug sein und welche sonstigen Lehren aus dem Projekt zu ziehen sind. [mehr ...]

Matthias schrieb den sehr empfehlenswerten Tipp:

Schreib deinen Code, als würde er auf's CPAN kommen

Dem kann ich mich nur anschließen. Auch wenn Code nur intern zum Einsatz kommt (was in der Praxis die Regel ist), sollte er stets nach den CPAN-Regeln und mit Hilfe der üblichen Tools erstellt werden. Dazu gehören beispielsweise Module::Starter (und Plugins, ich verwende zum Beispiel Module::Starter::PBP und Module::Starter::Smart; Module::Setup sieht aber auch interessant aus), Module::Build und die üblichen Test-Tools.

Zusätzlich sollte man aber auch immer die folgende Regel aus Damian Conways Perl Best Practices (siehe auch: Tipps für Perl-Bücher; Amazon-Direkt-Link zu PBP) beachten:

Codieren Sie immer so, als wäre der Typ, der den Code pflegen muss, ein gewaltbereiter Pshychopath, der weiß, wo Sie wohnen.

Und dem möchte ich noch hinzufügen: es handelt sich bei dem gewaltbereiten Psychopathen um den mit der Kettensäge ...

Um die Gefahr ein wenig zu reduzieren gibt es natürlich auch ein passendes Perl-Werkzeug: Perl::Critic und Test::Perl::Critic. Perl::Critic wacht dann im Rahmen der üblichen Test-Suite bei einem ./Build test darüber, dass der Code halbwegs sauber ist. Der Schwellwert (über den Parameter severity gesteuert) steht standardmäßig auf dem schwächsten Level 5, ich setze den auf jeden Fall auf 3 herab, so dass mehr Konstrukte angemeckert werden. Mit verbose=11 lassen sich ausführliche Meldungen erzwingen. Außerdem schalte ich ein paar Tests ab: RequirePodSections verlangt mir bei Kunden-Projekten zu viele bzw. die falschen POD-Sektionen, und RequirePodAtEnd verbietet POD direkt bei den Unterfunktionen, ich habe die Doku aber lieber da als am Ende vom Code.

Auf jeden Fall lassen sich so einige unsichere und gefährliche Konstrukte ausschließen. Perl::Critic meckert zum Beispiel auch, wenn einzelne Unterfunktionen zu komplex (und damit zu schwer verständlich) oder Blöcke zu tief verschachtelt sind. So kann man nicht nur die Kollegen sondern auch sich selbst ganz gut zwingen, weniger komplizierten Code zu schreiben: so ist dann zum Beispiel ab 20 if-Abfragen und ähnlichem pro Unterfunktion Schluss. Denn, man denke an den Psychopathen mit der Kettensäge ...

Bei vielen Projekten will man die Dokumentation, die in den eigenen Modulen und Skripten (hoffentlich!) haufenweise als POD vorhanden ist, nach HTML wandeln und sich so eine lokale Dokumentation erstellen.

Mit welchen Modulen / Werkzeugen erstellt Ihr Euer HTML (oder PDF oder ...)?

Ich habe gerne Pod::ProjectDocs verwendet, da das alles auf einen Rutsch erledigt. Nur das optionale Syntax Highlighting geht derzeit nicht, da Syntax::Highlight::Universal sich nicht compilieren lässt.

Nun ist mir Pod::Classdoc mit mkprojdocs aufgefallen, das zusätzlich auch noch Javadoc-ähnliche Formatierung erlaubt. Damit lassen sich dann relativ übersichtlich alle Ein/Ausgabeparameter auflisten. Bisher habe ich das gerne mit =item-Listen gemacht, aber dann wird der POD-Quelltext schnell unübersichtlich. Hierfür Javadoc zu nutzen erscheint also eine ganz brauchbare Lösung zu sein.

Es gibt ansonsten noch dutzende POD-Parser und -Konverter im CPAN; Pod::Simple mit Pod::Simple::HTMLBatch sieht evtl. auch brauchbar aus. Aber Pod::ProjectDocs bzw. Pod::Classdoc mit mkprojdocs scheint mir das einzige zu sein, dass ohne eigene Basteleien sofort funktioniert.

Update: Pod::POM::Web habe ich ganz vergessen zu erwähnen, mit dem man die Dokumentation zu allen lokal installierten Modulen im Browser nutzen kann. Eine sehr praktische Sache, aber auch nicht immer geeignet.