Wenn ich so programmieren würde wie Psychiater behandeln…

PsychiaterWenn ich Applikationen so programmieren würde wie die meisten Psychiater die Menschen behandeln, dann …

  • … hätte ich keine konkrete Ahnung, wie Computer tatsächlich funktionieren, nur vage Ideen an Hand der visualisierten Strömchen.
  • … würde ich eine fehlerhafte Applikation immer wieder denselben Fehler machen lassen und ihr dann mittels Powerpoint zeigen, wie es richtig gehen würde, bis sie verlernt den Fehler zu machen.
  • … würde ich die Applikation Zufallsausgaben machen lassen und sie ausgedehnt loben, wenn sie per Zufall die richtigen Zahlen ausspuckt.
  • … würde ich bei neuen Fehlern irgendwann mal die Compliance der Applikation anzweifeln.
  • … würde ich Termine ohne Uhrzeit vereinbaren: Vormittags (heisst „vor 16:00“) oder Nachmittags („am Morgen des nächsten Tages vielleicht“).
  • … würde ich von Montag bis Mittwoch von 10:00 bis 16:00 arbeiten (Morgen-, Mittag- und Nachmittagspause sind auch Arbeit) und 18 Wochen des Jahres mit Ferien und Kongressen verbringen.
  • … würde ich bei einer Fehlermeldung:
    • … die Fehlermeldung wegprogrammieren, nicht die Ursache des Problems.
    • … den Computer einen Vertrag unterzeichnen lassen, dass er die Fehlermeldung nicht mehr bringt.
  • … würde ich bei einer Programmiersitzung zuerst mal hinsitzen und schauen, was sich so während des Tages entwickelt.
  • … würde ich bei einem Bug das Aufstehen, Anziehen, Duschen, Kaffeetrinken, etc. des Programmierers nachstellen, um den Ursprung des Bugs zu ergründen.
  • … würde ich zuerst einen Monat ein Bisschen die eine Programmiersprache versuchen, dann einen Monat eine Andere, einen Monat später wieder die Erste, aber etwas intensiver, dann die Zweite mit einer Dritten kombinieren, …
  • … könnte ich nicht unterscheiden zwischen den verschiedenen Betriebssystemen und würde bei allen dasselbe ausprobieren.
  • … wäre ich überzeugt davon, dass jede noch so komplexe Applikation mit einer Stunde Programmieren pro Woche realisiert werden kann.
  • … würde ich bei schweren Bugs vorschlagen, mit dem Kunden zusammenzusitzen, um Wege zu finden wie er mit der verbuggten Applikation arbeiten kann statt diese zu beheben.
  • … würde es mir im Traum nicht einfallen den Debugger hervorzuholen, sondern ich würde immer wieder unterschiedliche Eingaben machen um die Ausgaben interpretieren zu können.
  • … würde ich die Ausgaben der Applikation nicht wirklich als deren Ausgabe sehen, sondern als Metapher für das, was sie ausgeben möchte, wenn sie denn funktionieren würde. Aus der Differenz würde ich schliessen, in welcher Projektphase Defizite vorhanden waren.

Neue Bücher von oncode.info: STFU und RTFM :)

RTFM – Read the (fine) manual

RTFM

In RTFM wird zuerst auf das Lesen eingegangen. Der Autor zeigt gekonnt, wie mit nur ca. 26 Symbolen ganz verschiedene Informationen codiert werden können. Ziemlich schnell erweitert er diesen Grundsymbolsatz auf die sogenannte Gross- und Kleinschreibung und die Satzzeichen. Geschickt beweist er, dass auch wenn eine dritte, vierte oder n’te Zeile aus denselben Buchstaben besteht, trotzdem noch neue Informationen in diesen vorhanden sein können und es darum nützlich sein kann, alles zu lesen. Etwas mühsam sind die Übungen, bei welchen die Leserin/der Leser lernt, dass Text auch ohne viele Bilder Sinn machen kann.

Fast in das Thema des untenstehenden Buches gehen die Konzentrationsübungen, in welchen eher autosuggestiv vermittelt werden soll wie man bei einem Problem nicht sofort herumschreit und wahllos Mails verschickt, sondern ruhig und gefasst nach weiteren Informationen sucht.

Relativ umfangreich wird auf die einzelnen FMs eingegangen: Gedruckte Manuals, README Dateien, Onlinehilfen, Produktwebseiten, etc. Auch generische Informationsquellen kommen zum Zuge: Der Autor versucht dem Wissen „Google weiss alles“ etwas Pragmatik folgen zu lassen und zeigt auf, dass Google teilweise auch Praktisches beinhaltet.

Weniger gelungen sind die Kapitel über das Fragen, wenn keine FM da sind. Der Autor schlägt vor, sich Fragen aufzuschreiben und sie nicht einfach dem Nächstbesten, sondern jemandem ganz gezielt zu stellen. Dies ist wirklich harte Kost und hätte besser in ein Buch für Fortgeschrittene gepasst.

STFU And GBTW – Shut the fuck up and get back to work

STFU and GBTW

Obwohl dieses Buch auf den ersten Blick sehr technisch anmutet, will der Autor sehr viel Zwischenmenschliches vermitteln. Diese Aussagen sind zugleich eine Stärke und eine Schwäche des Buches. Die Thesen leuchten vielleicht auf den ersten Blick ein, jedoch bleibt der Schreiberling uns viele Beweise dafür schuldig.

Die Grundaussagen sind die Folgenden:

  • Wenn jemand ein Büro/Arbeitsraum betritt, muss er nicht alle und jeden persönlich begrüssen.
  • Wenn jemand ein Büro/Arbeitsraum betritt, muss er nicht über alles und jedes einen Kommentar abgeben.
  • Man muss trotz Twitter nicht jeden Gedanken ausformulieren und vor sich hinbrabbeln.
  • Man kann auch gewisse Dinge tun (Kaffee machen, Blätter kopieren, …) ohne dass man das Dafür und Dawider in einer spontanen Runde besprechen muss.
  • Spricht man mit jemandem, so darf man damit durchaus mal wieder aufhören. Es wäre sogar ok, nicht nur von sich zu sprechen und den Anderen auch mal zu Wort kommen zu lassen.

Etwas sehr elitär sind die Thesen, dass es machmal wichtiger sein kann zu arbeiten als der Beschreibung des vorletzten Furzes, den die 3. Tochter auf dem Wanderausflug am Wochenende von sich gegeben hat, zu lauschen! Ich sage nur: Beweisebeweisebeweise!

Gegen Schluss versteigt er sich sogar in der Aussage, dass es vielleicht sein könnte, dass gewisse Mitarbeiter nach getanem Tageswerk für ein paar Minuten alleine sein und nicht auf der ganzen Heimfahrt von der Arbeit sprechen möchten. Es könnte ein deutliches Zeichen sein, wenn sich diejenigen alleine irgendwo hinsetzen.

Es wird sich zeigen ob diese Vorschläge praktisch wirklich Sinn machen oder ob es sich um ein weiteres Getting Things Done handelt…

Impressum

Bücher geduckt mit dem oreillymaker.com.

Computer sind scheisse – Oder die Vorteile des Schafzüchtens

Egal wie man zu Computern steht, den Meisten ist das breite Gefühlsspektrum wohlbekannt das Computer erzeugen können; von freudiger Erregung die leicht in Entzücken ausartet bis hin zu abgrundtiefem Hass und Verachtung. Doch ein Gefühl ist mir neu: Ekel. Mich schauderts, aber nicht ob den Brosamen in der Tastatur die alsbald von selbst ihren Kaffeetümpel verlassen werden, auch nicht ob den gruftigen Staubfetzen die munter aus dem Ventilatorschacht tentakeln. Ebenfalls sind die täglichen Abstürze (nananah, Ruhe dahinten, auch Unix/Linux hängt ab und zu!), vermurkste Backups, spezifikationsfremdes Verhalten und andere Widrigkeiten nicht genug, meine eiserne Ruhe gegenüber dem Möchtegernehirn zu brechen. Nein, es ist das Ding das wir aus dem Computer gemacht haben, der Computer an sich von A wie Aufstarten bis hin zu Z wie Zentraleinheit (oder „Zieh mal da, tut sich jetzt was?“).
Lasst uns bei der Hardware beginnen. Vorbei die Tage als man noch wusste was schnell und gut ist: Intel sagt Megaherz, Apple sagt FLOPS. AMD sagt Quantispeed, Intel sagt SSE, die Büroklammer meint Arbeitsspeicher, Via meint Systembus. Hans meint SCSI, Fritz sagt Dell, und mein Bauch sagt „guter Support“. Aus sind die Zeiten wo man mit stoltzgeschwellter Brust seinen Computer tätschelnd leise in den Diskettenschlitz flüstern konnte, wie schnell er doch sei und wie stolz man auf ihn ist. Erstens weiss man nicht, ob er denn wirklich schnell ist, zweitens ist noch vor dem Auspacken ein schnelleres Modell auf dem Markt und drittens haben einige Computer gar keinen Floppyschlitz mehr.
Die Prozessoren haben Fehler, die PCI-Steckplätze sind wählerisch, die RAMs tun eitel wenn es um die Zusammenarbeit geht und die Settings im BIOS kann sowieso niemand mehr überblicken. Gehen wir der Einfachheisthalber davon aus, dass wir einen lauffähigen Computer vor uns haben, einen zugeschraubten, mit Garantiesiegel versehenen, der immerhin noch ein kleines, neidisches „Dasundas wäre aber besser gewesen“ bei den Kollegen hervorruft. Und gehen wir davon aus, dass nichts kaputt geht, denn kostenpflichtige Preisauskünfte, Pauschalpreise und Servicenummern die an Informationsgehalt nicht viel mehr absondern als andere Nummern mit derselben Vorwahl, die aber erst nach Mitternacht beworben werden dürfen, reichen normalerweise völlig aus um einen wohlgesonnenen Menschen nach Neuseeland zu treiben (wo er sich dann mit Schafezüchten beschäftigen wird).
Wir dürfen dann ein Betriebssystem auswählen (auch dieses Privileg muss man sich erkämpfen). Das eine Betriebssystem weiss alles besser. Es weiss wo ich meine Dateien hinschreiben und womit ich im Internet suchen will, was für Musik ich hören möchte und welche Programme ich nicht brauche. Es weiss sogar, wann ich genügend gearbeitet habe, denn dann verabschiedet es sich und simuliert Nacht auf dem Monitor. Ich kann nichts mehr ändern am System, denn es weiss es besser und stellt es bei Gelegenheit wieder zurück. Bäh. Sowas ist nicht nett. Wenn dieses Betriebssystem ein Mensch wäre, würde ich ihn meiden, ganz bestimmt.
Das zweite Betriebssystem weiss nicht soviel. Es lässt mich alles selber konfigurieren. Stundenlang, tagelang, wochenendelang, feierabendlang. Ist es so wie es gefällt, ist alles veraltet und eine neue Version der Programme ist angesagt. Repeat. Wenn dieses System ein Mensch wäre, würde ich ihn nicht verstehen, obwohl ich in sein innerstes kucken kann.
Es gibt auch noch andere, zugegeben, aber wieviele Betriebssysteme erträgt ein Mensch? Man sollte alle zu der armen Seele nach Neuseeland schicken.
Egal ob Betriebssystem oder Applikation, der Umgangston ist schlimmer als unter Schafszüchtern: „Do you want to reboot now?“. Nein, natürlich nicht, aber was bleibt mir anderes übrig. „Sind sie sicher?“, wenn mir diese Frage alle 3 Minuten gestellt wird, verwundert es denn, wenn mein Selbstbewusstsein zum Teufel geht?
Programmieren habe ich immer als etwas elegantes empfunden. Algorithmik: suche einen guten Weg, formuliere eine Lösung. Das funktioniert ideal im Labor, doch versagt bei richtigen Programmen. Es ist allgemein anerkannt und sogar respektiert wenn mit wichtigem Blick gesagt wird „Alle Programme haben Fehler“. Wie wird die Zeit abgeschätzt die ein Informatikprojekt braucht? Nein, kein Publikumsjoker, ich sage es: Schätzung des kompetenten Mitarbeiters mal zwei plus zehn Prozent. Ist DAS eine erwachsene Wissenschaft. Oder – lachen verkneifen – gar eine exakte Wissenschaft? Ist es da noch eine Freude zu programmieren? Fragen sie jemanden nach einer kurzen Erklärung für COM. Lesen Sie die Einführung eines beliebigen Buches zu COM in dem ein Überblick gegeben wird. Und, häh? Das treibt uns nicht nur nach Neuseeland, sondern reicht sogar um die Schafe dort zum Weinen zu bringen.
Objektorientiertheit, objektorientiertheit, höre ich die Studenten singen. Sehen Sie sich 80% der Objekte eines Projektes an und stellen Sie sich diese als reale Dinge vor. Huh, ein IPCallBack läuft durch die Wohnung. Bitte steh nicht auf mein DirValidator. Ja, das vereinfacht den Durchblick ganz extrem. Klar wie Schafssch… nee?
Und mit was programmieren wir denn? En Vogue ist es im Moment, Ausgaben in einem Programm über das Netzwerk anzusehen von einem Programm welches ein Script interpretierte, das einen Interpreter benötigt, der mit einer Sprache geschrieben wurde die einen Compiler benötigte, welcher sich selbst und das Betriebssystem braucht, welches ein Programm im ROM (und den Compiler) benötigt das wiederum Kleinstcode im Prozessor benötigt. Cool man, es sind doch nur Nullen und Einen! Kein Mensch kann heute mehr ein richtiges Programmierprojekt von Anfang bis Ende überblicken. Kein Mensch kann sich mit mehr als einem 13Mikrometer grossen Teilgebiet der Informatik beschäftigen. Niemand hat den Über- und den Durchblick. Alle wursteln.
Und diejenigen die auf alles eine Antwort haben, sollte man zuletzt fragen, noch nachdem man seine Schafe konsultiert hat.
Installiert man ein „fertiges“ Programm, gilt es sich durch die EULA oder Lizenzvereinbarungen zu kämpfen. Buchstaben aneinandergereiht, Zeile für Zeile Juristengeschwätz. Nicht fundiert und bewiesenermassen voller Lügen. Wir lesen das ja immer SORGFÄLTIGST und STIMMEN ZU. Was ist, wenn ganz unten ganz klein gestanden hat „Der Verwender verpflichtet sich, ab jetzt bei jedem Vollmond mit irrem Grinsen um sein Haus zu tanzen“? Lacht nicht, es gibt schlimmeres das da steht.
Haben Sie gewusst dass Ihnen ein Programm nicht gehört dass Sie gekauft haben? Denn dann dürften Sie es Kopieren und zerstören oder was Ihnen sonst so einfällt. Doch das ist verbotener als verboten.
Kein Gemotze ohne Verteidigung der Privatsphäre: Viele Leute können ohne grosse Mühe herausfinden was ich wo einkaufe, wann ich meinen Computer ein und ausschalte, mit wem ich Kontakt pflege, was und wie und für wieviel ich arbeite, etc. SO IST ES klingeling DAS IST KEINE ZUKUNFTSMUSIK. ’nuff said.

Ich ekle mich vor dem Computer. Er macht aus mir ein Monster das Scheusslichkeiten wie „gerebootet“, „Task“ und „synchronisieren“ im aktiven Wortschatz hat. Es lässt mich Abends erkennen, dass ich nicht weiss welchen Tag in welchem Monat wir haben und was für Wetter draussen war. Er lässt mich an der Kasse warten. Er lässt mich sauer werden auf Leute, welche länger als 42 Sekunden am EC Bankomaten brauchen. Er lässt mich ständig an mir selber zweifeln und mein Wissen vergehen. Schauder.

Was sind die letzten Worte eines Informatikers: „Ich bleibe hier bis es funktioniert“. Wäre er doch besser nach Neuseeland Schafe züchten gegangen.

Bug ist nicht gleich Bug

Per Zufall bin ich wirklich faszinierende Bugnamen gestossen… Wenn jemand noch mehr kennt, wäre ich Dankbar für eine Mitteilung:

Der Heisenbug
Verändert sich wenn er beobachtet wird. Tritt zum Beispiel auf, wenn sich die Kompilieroptionen für Release und Debug unterscheiden und der Bug nur im Release auftritt.
Der Bohrbug
Ist ein unter allen Umständen und leicht zu reproduzierender Fehler.
Der Mandelbug
Der Mandelbug ist ein Bug, dessen Ursachen so komplex sind, dass er chaotisch erscheint.
Der Schroedinbug
Beim Schroedinbug (oder Shroedinbug) handelt es sich um einen Bug – also einen Fehler in einem Programm – der jedoch noch nicht bekannt ist, weil noch niemand die entsprechende Funktion bzw. die entsprechende Kombinationen von Funktionen ausprobiert hat.
Der Zeilinbug
Die Herkunft der Benennung ist hier nicht bekannt. Zeilinbug bezeichnet einen Fehler, der sich im Code herumbeamt, ohne das man genau weiss warum. Schuld daran können fehlerhaftes Kopieren und Einfügen oder wirre Codegeneratoren sein. Manchmal auch ein konzeptionelles Fehlwissen der Entwickler.
Der Nelsonbug (benannt nach Ted Nelson)
Ein Bug, der entsteht, weil ein Teil der Implementierung auf später verschoben wurde und dieser dann vergessen gegangen ist. Er kann auch auftreten wenn generell nur Stubs vorhanden sind. Ist mit dem Schroedinbug verwandt.
EBCAK
Error Between Chair And Keyboard, Nuff said :)…
ID10T (Ai-Di-Ten-Ti)
Tja, das ist nun nur für 1337.
JASE
Just another System Bug.

Quellen: Wikipedia, Bullhost und A1 Weblog.

Nachtrag (16.03.2008): Die englische Wikipedia hat auch eine Seite für Bugs!

Sich ändernde Mailsignaturen mit fortune

Wir Gothen sind ja bekannt dafür, besonders lustige Zeitgenossen zu sein. Um dies auch im virtuellen Raum zum Ausdruck bringen zu können, kann man zum Beispiel jeder Mail ein zufälliges Zitat anhängen.

Um bei Linux Bordmitteln und mehr als 30 Jahre bewährte Technologie zu verwenden, empfiehlt sich das Kommandozeilenprogramm fortune. Es liest aus einer Textdatei einen zufälligen Eintrag und gibt ihn aus… Also genau das was wir wollen…

  1. Zuerst muss man sich eine „Datenbank“ mit Sprüchen anlegen. Dies ist eine Textdatei in welcher die Sprüche hineingeschrieben werden, getrennt durch ein Prozentzeichen alleine (!) auf einer Zeile. Als Beispiel kann meine DB dienen: Sprüche für Mailsignaturen
  2. Fortune muss eine Indexdatei für die DB haben. Diese erstellt man mittels strfile sig_filename, in demselben Verzeichnis wie die Sprüchedatei.
  3. Nun ein kleines Skript erstellen, das den gewünschten Text ausgibt (pfortune.sh):
    #! /bin/bash
    echo "  Yours,"
    echo "     Linill"
    echo "-=-=-=-=-=-=-=-="
    /usr/games/fortune ~/sig_filename

    Dieses Skript muss ausführbar sein: chmod u+x pfortune.sh

  4. In KMail wird die Signatur bei „Identitäten“ konfiguriert. Hier als Programm den kompletten Pfad zu pfortune.sh eingeben.

Will man zusätzlich noch seine Tuffheit demonstrieren, so kann man sich eine Datei mit Tuffheitsbeweisen anlegen und das Skript erweitern:

#! /bin/bash
TOUGH=`fortune ~/svn/oncode.info/signatures/trunk/toughmen/toughmen`
echo "  Mit freundlichen Grüssen,"
echo "     Skaldrom Y. Sarg ($TOUGH)"
echo "-=-=-=-=-=-=-=-="
fortune ~/svn/oncode.info/signatures/trunk/shorties/shorties

Die Weiber werden einem nur noch so zufliegen….