Von unproduktivem Arbeiten, schlechtem Code, Astronauten und Klebeband

In diesem Blog-Post will ich mich darüber auslassen…

• … warum unproduktives Arbeiten manchmal gut ist.
• … warum schlechter Code manchmal gut ist.
• … was Astronauten und Klebeband nicht gemeinsam haben.

weiter lesen »

Gefangen, nicht gefunden! #20

Informatik

• Kurzer Realitätsabgleich: In My life as a Code Economist erklärt Eric Sink, warum es sinnvoll sein kann, Bugs im System zu lassen.
• Einen sehr guten Vortrag über die Grundlagen von git gibts hier: http://blip.tv/scott-chacon/git-talk-4113729 Sehr schön ist hier insbesondere die grafische Repräsentation des Repositorys. Die ist wichtig zum Verständnis. Manchmal etwas schnell um dem inhaltlich zu folgen, aber dennoch gut verständlich.
• git for Computer Scientists. Sehr schön! Da wünscht man sich mehr von. Das hier sind ja nur die aller grundlegendsten Dinge.
• Where Did My Architecture Go? ist ein sehr interessanter Vortrag über Softwarearchitektur und wie man auf diese aufpasst.
• Es gibt wieder neue Folgen von Tatort Internet. Also nicht von diesem fragwürdigen Blödsinn auf RTL2 sondern von der Artikel-Serie auf Heise-Security (1 2) Sehr interessant.
• “A good coder writes code that looks like it was easy and straightforward to do” (via)
• Ein paar Lustige Bugs: OpenOffice kann dienstags nicht drucken, E-Mails nur im Umkreis von 500 Meilen (via)

Anderes

• Boa bin ich langsam. Das hier liegt schon seit Ewigkeiten hier um. Ein Punkt oben war noch “Die Delphi-Tage sind ausverkauft” (aus verständlichen Gründen hab ich das vor dem Posten wieder gelöscht; Anachronismen sind nicht sonderlich hilfreich) und WordPress zeigt den 16. August als Erstellungsdatum…

Warum manchmal unerklärliche Dinge geschehen

“Schon traurig, dass von mir als Informatiker manchmal als einziger Lösungsvorschlag ‘Stecker ziehen und wieder reinstecken’ kommt. — Und noch trauriger ist es, dass das auch noch hilft.”

Manchmal passieren Dinge, die uns unerklärlich, ja unglaublich erscheinen. In den letzten paar Tagen, durfte ich an ein paar WLANs rumbasteln und dabei sind diverse solcher Dinge passiert. Und das hat mich dann dazu gebracht, obiges zu meinem Cousin zu sagen. Das will ich mal zum Anlass nehmen und etwas darüber sagen, wie diese unerklärlichen Dinge geschehen.

Aber was ist denn nun passiert?

• Der neue WLAN-Router tut nicht so, wie er soll. Zuerst kommt er ins Internet, aber das WLAN geht nicht. Dann geht WLAN aber kein Internet mehr. Nach ein paar mal neu Booten und Stecker ziehen und wieder reinstecken, tut es wieder.
• Ein anderer WLAN-Router (gleiches Modell) hat laut LED eine Verbindung mit dem Internet. Das Kabel steckt aber nicht im WAN-Port. Netzstecker ziehen und wieder reinstecken und es geht.
• Der selbe WLAN-Router ist per Ping zu erreichen, zeigt bei Eingabe der IP in den Browser keine Konfigurationsoberfläche (Timeout). Ein Reset behebt das Problem.
• Bei selben Gerät ein Admin-Passwort eingerichtet (händisch in beide Edit-Felder eingetragen und gespeichert). Danach nimmt er das Passwort beim Anmelden aber nicht mehr an. Nach einem Reset nochmal versucht (diesmal langsam eingetippt). Selbes Problem. Dann Dummy-Passwort “abc” zum Probieren. Lustigerweise funktioniert das jetzt. Dann das Wunsch-Passwort nicht eingetippt, sondern per Copy’n'Paste jeweils eingefügt. Wieder “Benutzername oder Kennwort falsch”.
• Einen WLAN-AccessPoint als Repeater konfiguriert. Datendurchsatz ca. 40kbps (ja 40kbps bei 802.11n und ner Entfernung von 20cm). Neu Starten hilft diesmal nicht. Zum Testen als AP-Client konfiguriert: selbes Problem. Zum Testen mit anderem AccessPoint verbunden: Klappt problemlos. Wieder zurück zum eigentlich gewünschten AccessPoint: Wieder ewig lahm. Neu Starten hilft immer noch nicht. Einen Tag später nochmal versucht: Klappt auf Anhieb.
• Bei Verwendung des neues Repeaters friert der Rechner ein (Maus und Tastatur reagieren nicht mehr). Der Rechner war per Ethernet-Kabel mit dem Repeater verbunden. Selbst nach Abziehen des Kabels (also der Rechner ist mit dem Repeater nicht mehr verbunden. Beide stehen nur nebeneinander) besteht das Problem weiterhin. Ein bisschen WLAN lässt den Rechner einfrieren.
• Auch ein DSL-Router war mal per Ping zu erreichen und per Browser nicht. Wieder behob ein Steckerziehen das Problem.

Aber wie kann das alles sein? Und was hat das mit Software-Entwicklung zu tun? Ich wage mich mal an eine Erklärung des Unerklärlichen. weiter lesen »

Enbugging — Wie wir Fehler machen und wie wir sie vermeiden

Wie im letzten Jahr, hab ich auch dieses Mal wieder einen Vortrag auf den Delphi-Tagen gehalten. Diesmal gings ums Fehler vermeiden. Man könnte auch sagen, um konstruktive QA-Maßnahmen. Egal. Jedenfalls gings um Bugs.

Abstract

“Wenn Debugging der Vorgang ist, Fehler aus einem Programm zu entfernen, dann ist Programmierung der Vorgang, Fehler in ein Programm einzubauen.” So liest man zuweilen im Netz und manchmal ist es nur zu wahr. Stunden verbringen wir damit, umständlich einen Fehler zu suchen, den wir zuvor noch ganz mühelos einbauen konnten. Wäre es da nicht praktischer, statt uns mit Debugging aufzuhalten, das Enbugging, das Einfügen von Fehlern gar nicht erst zu betreiben? Letztendlich sind wir ja eigentlich selbst schuld: Bugs entstehen nicht aus dem Nichts. Vielmehr erzeugen wir — meist unabsichtlich — Bedingungen, unter denen diese kleinen Krabbelviecher so prächtig gedeihen. Dieser Vortrag soll zeigen, wie Bugs entstehen und was wir dagegen tun können. Eine vollständige Betrachtung des Themas kann dabei natürlich nicht erfolgen. Stattdessen wird ein Überblick gegeben, um danach einzelne Aspekte zu vertiefen.

Folien

Wie versprochen gibts hier die Vortragsfolien: Download: Enbugging (Größe: 1.14 MB; bisher 354 mal heruntergeladen)

Ich hab wieder eine Gratwanderung zwischen vortragsunterstützenden Folien und Infos für alle, die den Vortrag nicht gesehen haben, versucht. Ob mir das gelungen ist, darf jeder selbst beurteilen (und mir am besten auch noch ein bisschen Feedback geben).

Hinweise

• Eigentlich wollte ich noch erwähnen, dass Tony Hoare (der übrigens auch den QuickSort erfunden hat) auch dran schuld ist, dass in Pascal die geschweiften Klammern Kommentare sind. Hoare hat Vorbedingungen und Nachbedingungen in geschweiften Klammern vor bzw. hinter Code geschrieben (“Hoare-Tripel“) und damit formale Verifikation gemacht. Niklaus Wirth gefiel das Ganze so gut, dass er die geschweiften Klammern zu Kommentarzeichen machte.
• Um die Beispiele zu verstehen, sollte man sich genau angucken, wie die Bezeichner (insbesondere die Klassen) heißen. Man sollte daraus erraten können, worum es geht. Meine Beispiele waren meist allgemein bekannte Datenstrukturen (List, Map, Set) oder standen in losem Zusammenhang mit Feedreadern, HTML-Parsern u.ä.
• “Meine Fehlerliste” enthält viel zu wenige Daten, um hieraus schon etwas Sinnvolles ableiten zu können. Da muss ich noch mehr sammeln. Das hab ich beim Vortrag zwar schon dazu gesagt, aber es steht so explizit nicht in den Folien.
• Was ich auch im Vortrag erwähnt hab, aber nicht auf den Folien steht: Bidirektionale Assoziationen sind starke Kopplungen. Also wenn sich zwei Module gegenseitig kennen, anstatt dass nur ein Modul das andere kennt, aber nicht umgekehrt. Man sollte deshalb zusehen, dass man möglichst nur einseitige Beziehungen hat.
• Der Anhang enthält noch weitere Beispiele und Hinweise auf weiterführende Themen, die nicht angesprochen werden konnten.

Errata

• Auf Folie 60 fehlt ein not. Es müsste also heißen if not FInnerList.Contains(item) then.

Bitte um Feedback

Das Feedback, das ich bisher bekommen hab, war durchweg positiv. Das freut mich. Ich will hier aber trotzdem nochmal nach Feedback und explizit auch Kritik fragen. Nur, wenn ich weiß, was ich besser machen kann, kann ich in Zukunft etwas weniger schlimme Vorträge machen… *g*

Insbesondere würde mich folgendes interessieren:

• Hab ich verständlich geredet? War ich vielleicht zu schnell?
• Waren die Beispiele verständlich? Nachvollziehbar? Praxistauglich?
• Wie versteht man die Folien, wenn man sich den Vortrag nicht angehört hat?
• Waren Thema und Inhalt angemessen? Zu theoretisch? Zu einfach? Zu schwer? Zu trivial?
• Kann ich sonst etwas verbessern?

Enbugging — Was ich auf den Delphi-Tagen erzählen will

“Wenn Debugging der Vorgang ist, Fehler aus einem Programm zu entfernen, dann ist Programmierung der Vorgang, Fehler in ein Programm einzubauen.” Und ich fürchte das stimmt. Debugging ist manchmal nervig, auf jeden Fall aber zeitaufwändig. Und dabei sind wir doch eigentlich selbst schuld: Mühelos bauen wir Fehler in unseren Code ein, damit wir diese dann wieder mit viel Mühe erkennen, lokalisieren und beheben können.

Schön wäre es doch, wenn wir die Fehler gar nicht erst einbauen würden. Wir tun das nicht bewusst. Man könnte das jetzt einfach als Nachlässigkeit oder “Versehen” abtun, aber meistens ist es mehr: Wir erzeugen Bedingungen unter denen Bugs leicht entstehen. Wir tricksen und quasi selbst aus, indem wir unsere Programme so entwerfen, dass wir fast unausweichlich Bugs machen müssen, wenn wir nicht höllisch aufpassen. Uns ist das nicht immer bewusst, aber es ist so. Einige solche Bugschleudern hab ich selbst schon fabriziert.

Um dem zu begegnen gibt es IMHO drei Dinge, die wir tun können:

1. Verstehen wie Code funktioniert, welche Probleme und Fallstricke existieren und welche Fehler man machen kann.
2. Verstehen welche Fehler man persönlich macht.
3. Bedingungen erzeugen, unter denen Bugs nicht so leicht entstehen oder zumindest schneller erkannt werden.

Das ist mehr oder weniger das, was ich auf den diesjährigen Delphi-Tagen in Köln erzählen will. Einen Vorgeschmack gibts schonmal hier: Download: Enbugging-preview (Größe: 383.76 kB; bisher 155 mal heruntergeladen)

Ich hab viel zu erzählen und weiß noch nicht ganz, ob ich davon noch etwas kürzen oder verändern muss. Deshalb erstmal nur das Kapitel zur Einführung. Den Rest gibts dann als finale Version nach oder kurz vor den Delphi-Tagen. Das, was ich hier zeige, ist zwar mit Abstand das langweiligste Kapitel, aber zumindest ist ein Inhaltsverzeichnis dabei, sodass man schonmal nen Eindruck gewinnen sollte, ob es sich lohnt, mir zu zu hören.

Alles in Allem werde ich nichts bahnbrechend Neues vorstellen. Das ist teilweise Erstsemester-Stoff [1], aber ich werde versuchen, aufzuzeigen, warum das wirklich praxisrelevant ist. Relevanter als ich das im ersten Semester erkannt hab. Es wird ne Menge Beispiele geben, die auch mit Abstand die meiste Arbeit gemacht haben und hoffentlich den ein oder anderen Aha-Effekt erzeugen. Mal sehen, ob mir das gelingt. Zumindest ist das mein Ziel.

Vorab kann ich schonmal sagen, dass ich den Titel geklaut hab. Und zwar von diesem sehr lesenswerten Artikel: The Art of Enbugging von Andy Hunt und Dave Thomas.

[1] OK, wirklich nur teilweise

Gefangen, nicht gefunden! #18

Informatik und Anderes

• Böser Bug. Böser Bug. *Sehr* böser Bug! Aber sehr lehrreich. Einmal, weil man hier deutlich sieht, wie wichtig das Testen ist und wie schnell man einen fatalen Fehler übersieht. Und zum zweiten zeigt das Beispiel recht schön, warum Haftungsfragen auch bei eigentlich nicht sicherheitskritischer Software eine Rolle spielen können. Ich bin ganz froh darüber, dass ich gerade eine passende Vorlesung zu dem Thema höre. Die Rechtsprechung ist hier teilweise *sehr* merkwürdig, was Software anbelangt. (via).
• “The great thing about TCP jokes is that you always get them.” Zugegeben: Es hat ein bisschen gedauert, bis ich den verstanden hab (Das Problem bei TCP-Witzen ist ja auch, dass es ziemlich lang dauern kann, bis man anfängt, sie zu verstehen. ). Aber ich find den richtig gut. Und es gibt noch mehr von der Sorte. Die sind wohl irgendwie in Twitter entstanden. Noch ein paar gute:
  • @eigenrick: The problem with TCP jokes is that people keep retelling them slower until you get them. #protolol
  • @reconbot: WHO HAS ANY ARP JOKES? #protolol
  • @OhMeadhbh: the SYN flood attack #protolol: “knock knock. who’s there? knock knock. who’s there? knock knock. who’s there? …”
  • @yoz: order best is tell that The you thing can about jokes BitTorrent them in any. #protolol
  • @peter_tonoli: Chuck Norris has only one OSI level – Physical

  (via)

• Per Zufall bin ich auf eine sehr interessante Seite gestoßen: ioexception.de. Das ist ein Blog von ein paar Informatik-Studenten der Uni Ulm. Und da gibts so einige interessante Inhalte zu entdecken:
• Zustandsautomaten, State Pattern und Java Enums. Hinlänglich bekannt, aber nochmal schön zusammengefasst. Außerdem vielleicht ganz interessant für meine SEP-Studenten, die gerade einen Bot für ein Netzwerkkartenspiel schreiben dürfen. Und hier bietet sich eben das StatePattern und die genannte Umsetzung an. Das ist nicht die einzige Möglichkeit, Automaten in Code zu gießen. Bei Gelegenheit schreib ich da mal was dazu…
• Eine interessante Idee: git als Update-Mechanismus verwenden.
• Auch die anderen Posts lohnen sich. Einfach mal reingucken…
• Martin Fowler hat einen sehr interessanten Artikel über Flags in Methoden. Dem kann ich eigentlich kaum noch etwas hinzufügen. Außer vielleicht, dass Methoden-Flags i.d.R. Kontrollkopplungen sind, also den Kontrollfluss der Methode beeinflussen, statt ein Datum darzustellen. Und Kontrollkopplungen sind starke Kopplungen, d.h. man sollte sie vermeiden.
• Mein Vortrag auf den Delphi-Tagen ist wohl gesetzt. Zumindest verschickt Embarcadero schon Rundmails, in denen ich als Speaker genannt werde. Man darf sich also jetzt schon auf eine Stunde rund um Bugs und deren Vermeidung freuen oder sich wahlweise davor fürchten. Ich hab viel zu erzählen.
• Per Zufall bin ich hierüber gestolpert: Wie man ein guter Java-Programmierer wird. Ich fürchte, da ist was Wahres dran. Gilt natürlich auch für andere Sprachen und Bereiche. Nun, was soll ich sagen? Ich bin 23 und hab vor knapp 10 Jahren angefangen zu programmieren. Und B.Sc. bin ich auch schon. Also weiter gehts…
• Die aktuelle Liste der Top 25 Sicherheitslücken. Erschreckend, dass SQL-Injection immer noch ganz vorne ist.
• In C# kann man Interfaces auf zwei Arten implementieren. Entweder implizit oder explizit, d.h. entweder man implementiert einfach passende Methoden oder man spezifiziert genau, dass die Implementierung ausschließlich für dieses Interface gedacht ist. Das bedeutet, es ist möglich, dass eine Methode von einem bestimmten Interface aus zugänglich ist, von der eigentlichen Klassenreferenz aber nicht. Das klingt erstmal sehr merkwürdig, hat aber seine Vorteile. Es bietet nämlich die Möglichkeit, Methoden, die nur für ein bestimmtes Interface relevant sind, vor anderen Benutzern zu verbergen. Das ist dann quasi eine weitere Möglichkeit der Kapselung. Nick Hodges zeigt in einem Blog-Post, dass das auch in Delphi möglich ist. Bei Delphi kommt noch ein weiterer Punkt dazu: Wenn man in Delphi Interfaces verwendet, sollte man diese nicht mit echten Objektreferenzen mischen (außer man weiß sehr genau, was man tut). Das hängt damit zusammen, dass Interface-Referenzen im Gegensatz zu normalen Referenzzählung implementieren. Mit diesem Ansatz kann man also quasi sicher stellen, dass man die Klassenreferenz nicht benutzt (auf der anderen Seite sollte man hier eh überlegen, ob man nicht lieber ne Factory-Methode einsetzt). Die Diskussion in den Kommentaren ist übrigens auch interessant. Darüber wie und ob man dieses Feature verwenden sollte, sind die Meinungen gespalten. Auf jeden Fall, sollte man sowas gut dokumentieren.

Gefangen, nicht gefunden! #8

Informatik

• MPICH2 (zumindest die Windows-Version) ist wohl eines der wenigen Programme das seine Versionsnummer verheimlichen will. Readme – schweigt sich aus, Changelog – gibts (in der Installation) nicht, --version-Parameter – gibts nicht, Ordnername mit Versionsnummer – auch nicht. Letztendlich hab ich den Wert nur in der Systemsteuerung gefunden (da wo man das deinstallieren kann; früher hieß das mal “Software” jetzt glaub ich “Programme und Funktionen”).
• Deadlocks sind unlustig. Insbesondere, wenn man sie sich mit MPI baut. Naturgemäß lassen sich die Dinger nur schwer debuggen. Da braucht man ne ganze Zeit, bis man die Fehlerquelle überhaupt lokalisiert hat…
• Hat schonmal jemand seine Bugs protokolliert? Ich hab das mal gemacht und es ist ganz interessant zu sehen, welche Fehler man so macht. Vllt. blogge ich mal ne Statistik.

Anderes

• Letztens hatte ich mal die Gelegenheit die Menüführung von dem “Bordcomputer” vom Mercedes Sprinter zu bewundern. Schlecht! Mit Useability scheinen es die Auto-Bauer nicht so zu haben. Normalerweise ist sowas ja nicht schwer zu realisieren. 4 Knöpfe reichen da: Menü/OK, Hoch/+, Runter/- und Exit. Das System sollte hinlänglich bekannt sein und ist bei den meisten Monitoren für die Farbeinstellungen, etc. genau so implementiert. Die Entwickler hatten die Lösung also wohl direkt vor der Nase. Was aber ist denen eingefallen: Es gibt 6 Knöpfe: MenüHoch, MenüRunter, Hoch, Runter, + und -. Kein OK, kein Exit, aber dafür Hoch-Runter drei mal. Äh… Was haben die sich dabei gedacht? Vielleicht unterschiedliche Hoch/Runter-Knöpfe für unterschiedliche Hierarchieebenen? Das wär ja schon bescheuert, aber noch nicht mal das stimmt so recht. Sry, aber ne Useability-Schulung täte den Ingenieuren gut.
• Noch ein Useability-Unfall beim Sprinter: Scheibenwischer und Blinker sitzen hier auf einem Hebel. Zum Wischen muss man da jetzt die Hand vom Lenkrad nehmen und drehen… Da wollten sie wohl den Regensensor verkaufen…