Richard Stallmann
Letztes Wochenende war "Free and Open Source Developers' Europe Meeting" in Bressel. Wenn man je mal tausende Geeks und Nerds sehen will, dann ist das ein guter Termin fuer Europaeer. Viele, viele seltsame Gestalten reden ueber seltsame Dinge. Bei allem Erstaunen muss man sich aber bewusst machen, dass diese Leute die Sachen programmieren, die wir alle benutzen (von MS Windows mal abgesehen). Schonmal von Linux gehoert? FreeBSD? KDE? Jabber? Alles Programme, die von Millionen benutzt werden, direkt oder indirekt. Und trotzdem findet die Konferenz auf einem Unigelaende statt ohne Hochglanz. Die Einrichtungen sind genauso unrasiert, wie die Teilnehmer. Das bestaerkt wieder mal meine These, dass hinter jeder Innovation, hinter jedem Gadget, das die Massen im Alltag verwenden, ein Technofreak sitzt, der das Ding zum Laufen gebracht hat, ohne den Ruhm zu ernten. Den Ruhm und die Hochglanzkonferenzen bekommen die Vertriebler und die Anwender. Wir brauchen das nicht. Wir sind schon froh, dass jemand unsere Werke benutzt. Das bringt uns zum Copyright. Richard Stallmann (GNU) ist traditionell einer der Hauptredner der Veranstaltung. Er propagiert einen 10-jahres Copyright Schutz fuer viele Werke, aber absolute Freiheit ohne zeitlichen Schutz fuer funktionale Werke inclusive Software. Die Vorstellung sieht so aus: ein typischer Linux-Admin mit Rauschebart und laaangen Haaren steht in Struempfen auf der Buehne eines Hoersaals und filosofiert ohne Folien. Alle finden das OK. Content ist King.
2. März 2005
FOSDEM 2005
8. Februar 2005
Ich will User
Ich habe ein tolles Stueck Software programmiert. Und praktisch it es auch noch. Das finde nicht nur ich sondern hunderte von Testern. Wenn 80% aller zufaelligen Testuser die Software toll finden, kann das nicht so falsch sein. Komischerweise gibt es aber nur wenige richtige User. Sogar die begeisterten Testuser wundern sich, dass es nur wenige User gibt. Eigentlich sollte man meinen, dass es sich per Mund-zu-Mund Propaganda rumspricht und schnell viele User bekommt. So ist es aber nicht. Nur ab und zu kommt jemand zufaellig auf der Homepage vorbei, macht den Download, installiert, probiert und findet es gut. Und dann ... nichts weiter. Keine Mund-zu-Mund Propaganda, keine Massen von Usern. Es geht natuerlich um LLuna. Was ist falsch?
Ideen bitte an wolf@bluehands.de.
Trotzdem: ich gebe nicht auf. Moralische Unterstuetzung bitte an wolf@bluehands.de.
_happy_coding_
Labels: Virtuelle Präsenz, Zahlentheorie, Zeitgeist
4. Februar 2005
1 Mio mal fast nichts
Moderne Prozessoren sind rasend schnell. Sie machen eine Milliarde Operationen pro Sekunde. Manche auch 2, 4 oder 10, aber das ist so die Groessenordnung. Deshalb meinen manche Leute sie koennen dem Prozessor auch viel zumuten. Falsch! Prozessorzeit ist ein kostbares Gut. Sie muss gehegt und gepflegt werden weil sie sonst viel zu schnell aus ist. Jede Instruktion will bedacht sein. Nicht jede Prozessorinstruktion, aber jede Codezeile. Natuerlich nicht immer, aber immer in Schleifen, die 1 Mio mal durchlaufen werden. Und das ist das Thema hier: Wenn du etwas 1 Mio mal tust, dann tue FAST nichts.
Obwohl Prozessoren rasend schnell sind, ist einfach nicht mehr drin. 1 Mio mal in Speicher schreiben, um ein Array zu initialisieren ist OK. 1 Mio mal addieren ist auch OK, wenn man nicht erwartet, dass es nur eine Mikrosekunde dauert, aber lege NIE 1 Mio Objekte an. Das bedeutet 1 Mio mal Memory Management. Als Faustregel gilt, Memory Management ist 1000 mal so teuer, wie Memory schreiben. Also kosten 100 malloc oder new dann 1e9 Zyklen. Das dauert eine ganze Sekunde. Das ist nicht schnell. Und wenn die Applikation fertig ist, dann wird es noch schlimmer. Dann kommt jemand auf die Idee das ganze als Serveranwendung mit 100 Usern zu betreiben. Wenn das alle User machen, dauert es 100 Sekunden.
Deshalb: Wenn man etwas sehr oft tut, dann besser fast nichts. Auch im Zeitalter der Gigaherzen.
_happy_coding_
Labels: Code, Coding Rule, Hardware, Zahlentheorie
3. Februar 2005
Entspannung
13. Januar 2005
Tue Gutes und logge es
Kürzlich im aktuellen Projekt: Der Projektleiter mahnt nochmals alle Beteiligten, ausführliches Logging zu betreiben. Und zwar nicht nur Fehlerlogging, sondern auch informatives, bzw. gesprächiges (verbose) Logging, dass man im Zweifelsfall zuschalten kann. Begründung: wie soll man einen Fehlerfall debuggen, der beim Kunden ab und zu auftritt. Man will sich ja nicht dahinter setzen bis der Fehler passiert und dann im Debugger durchsteppen. Was man eigentlich will, ist verbose Logging einschalten und sich das Logfile zuschicken lassen, wenn es wieder passiert ist.
Und was passiert knapp 2 Wochen später? Kunde ruft an, hat ein "komisches" Verhalten. Was tut der Projektleiter? Loglevel hochsetzen und wieder darauf warten. Schade, wenn sich nicht alle Entwickler an die Bitte des Projektleiters gehalten haben und genau die fraglichen Teile im Logfile nicht enthalten sind. Das ist teuer. Das kostet Zeit und Reputation. Also: immer fleißig loggen. Gigabytes an Logdaten sind unsere einzige Waffe gegen "komisches Verhalten" von Anwendungen. Von strukturiertem Programmieren, Code Review, Software Patterns, Xtreme Programming einmal abgesehen.
_happy_coding_
Labels: Code, Coding Rule
2. Januar 2005
SAX sucks
Eine Kritik am SAX Interface
Neulich auf der Jabber Developer Liste: Ein Noob-Developer beschwert sich, dass er das Jabber Protokoll nicht verarbeiten kann, weil das letzte Tag nicht kommt. (Zur Erklärung ein paar Vokabeln: Noob = Newbie (engl.) = Neuling, Jabber = XML-basiertes Instant Mesage Protokoll, das letzte Tag = das schliessende XML-Tag eines XML-Dokuments). Neben den üblichen mailinglistentypischen dümmlichen Antworten, erhält er die wertvolle Empfehlung, einen SAX Parser statt dem DOM Parser zu verwenden. Das ist richtig, denn im Jabber Protokoll wird ein XML-Strom verarbeitet. Der gesamte Strom ist ein einziges Dokument und da dieses nie fertig ist, geht es nicht mit einem DOM Parser. Danach war einen Tag Ruhe, dann kam die nächste Frage etwa so: "Der SAX Parser meldet zu viel und das falsche. Der SAX Parser ist nicht brauchbar. Was nun?"
Da hat er leider Recht. Der SAX Parser meldet nämlich Öffnen und Schliessen jedes XML-Tags und jedes Fitzelchen Daten zwischen den Tags, selbst wenn das nur ein Zeilenumbruch ist. Damit kann der Applikationsentwickler aber leider nichts anfangen. Eine Jabber Message sieht als XML so aus:
<message from='cs@bluehands.de' to='hw@bluehands.de'>
<body>Hallo Welt!</body>
</message>
Der SAX Parser liefert dafür eine Serie von Callbacks:
startElement "message"
characterData "\n "
startElement "body"
characterData "Hallo Welt!"
endElement "body"
characterData "\n"
endElement "message"
Was soll man jetzt damit anfangen? Klar, der Anwendungsprogrammierer muss alle Teilinformationen sammeln bis das Ende der Message signalisiert wird. Dann kann er die gesamte Message auswerten. Anders ausgedrückt: XML hat eine hierarchische Struktur. SAX serialisiert und unterdrückt die Struktur. Der Anwendungsprogrammierer muss die Struktur wieder rekonstruieren. Eine Aufgabe, die in eine Bibliothek gehört. Leider ist sie bei SAX Parsern nicht enthalten. Nu ist an SAX Parsern nichts falsch, denn SAX heisst "Simple API for XML". Man wundert sich nur, warum es nach vielen Jahren XML immer noch keine besseren Schnittstellen für XML-Streaming gibt.
Was man eigentlich will ist eine Mischung aus DOM und SAX. Für die Verarbeitung von XML-basierten Protokollen braucht man einen Parser, der wie eine SAX Parser XML-Fragmente verarbeitet, der dann aber jedes komplette XML-Tag als Struktur liefert, so dass man nicht selbst die Struktur rekonstruieren muss. Also eine Art "Fragment API for XML". Wenn jemand fragt, wie man das Jabber Protokoll verarbeitet, heisst die richtige Antwort: nimm einen FAX Parser, z.B. meinen.
_happy_coding_
25. Dezember 2004
o2 Mobil Portal Stichproben
23.12.2004: Schlagzeile: "Putin vereidigt Yukos Übernahme". 5 mal die gleiche Information + 2 Bilder von Putin. Und wieder 2 zusätzliche Sätze auf der dritten Seite.
25.12.2004: Schlagzeile: "Weihnachtsbotschaft des Papstes von Sorge geprägt". 5 mal die gleiche Information + 2 Bilder vom Papst. Und wieder 2 zusätzliche Sätze auf der dritten Seite.
Wir wollen nicht vorschnell urteilen, aber eine gewisse Regelmässigkeit ist zu erkennen.
Labels: Mobile
