Heute ein paar Links für den geneigten Webentwickler:

• Ajax in 30 Sekunden. Gnadenlos mal wieder der Unterschied zwischen dem Hype und zugrunde liegenden Technologie. Es ist ein Knüller, wie einfach es funktioniert. Umso bizarrer das ganze Tohuwabohu das derzeit stattfindet. Leute, es ist zwar nett, aber bleibt mal auf dem Teppich.
• Abgefahrenes Javascript, um Bilder auf einer Website darzustellen. Ich gebe zu, daß ich JavaScript lange unterschätzt habe, aber man kann schöne Sachen damit machen.
  Das Ganze sieht dann z.B. so aus (yo, klick das Bild an):
  (Im Firefox ist es allerdings noch besser).

Es hat mir keine Ruhe gelassen, drum gibt es jetzt die Sterne in beliebiger Farbe (gd sei Dank). Außerdem ist man jetzt nicht mehr auf 5 Sterne bzw. 10 Punkte beschränkt.

Der alte Aufruf funktioniert wie gehabt, der neue geht so:

Stern(punkte,gesamtpunkte,rot,grün,blau). Also

Stern(13,20,200,150,50) ergibt (13 von 20 irgendwie komisch braunen Sternen (pfui!))
oder
Stern(3,6,50,250,100) ergibt (3 von 6 ziemlich grünen)

Die erzeugten Files werden gecacht, es ist also kein großes Performance-Problem.

Mein obskures Wertungssystem schmeiß ich über Bord. Ab jetzt gibt es Sterne! Und zwar
goldene:
rote:
blaue:
graue:
Aha. Dafür habe ich ein kleines WordPress Plugin zusammengehackt. Ziemlich billig, aber recht praktisch, da ich im laufenden Text nur noch z.B. " S t e r n ( 8 , g ) " tippen muss und schon habe ich z.B. 4 (von 5) goldenen Sternen am Start. Meine Skala geht also von 0-10. Man könnte natürlich noch weitere Sternfarben hinzufügen. Oder noch alberner, die Farbe der Sterne mit gd zur Laufzeit erst einstellen. Dann könnte man loslegen mit S t e r n (8 , 255 , 0, 0) für 4 von 5 roten Sternen. Aber so reicht das erstmal. Was bedeuten die Sternfarben?
- Gold: Standardfarbe, das beurteilte Objekt ist was für die breite Masse
- Blau: interessant für Leute mit speziellem Interesse, Geheimtip
- Grau: eher unbedeutend. Wäre früher das große "C" gewesen. Es kann sich also zwar um etwas Solides handeln, aber wen interessierts?
- Rot: Diese Farbe wird man nur ganz selten sehen. Und wenn, dann handelt es sich das Objekt der Begierde um einen echten Knaller. Begierde, halt ;-)

Es gibt so eine Art Qualitätskurve, auf der man Software ansiedeln kann. Am einen Ende findet man Werkzeuge für den Einmalgebrauch, schnell zusammengeschustert ohne Rücksicht auf Stil und Speicherlecks, Hauptsache, die Aufgabe läuft irgendwie durch. Danach kommen eigene Tools für den Hausgebrauch, dann vielleicht Software für Einzelkunden oder Unternehmenssoftware, später sog. "Shrinkwrap", also massentauglicher Kram der im Mediamarkt in den Regalen steht und ganz am Ende Firmware und Konsolenspiele. Wenn man für das jeweilige Produkt einen festen Zeitaufwand zugrunde legt wird man feststellen, daß sich die Aufgabenanteile für unterschiedliche Tätigkeiten wie Konzeption, Implementierung und Test auch entlang dieser Kurve verschieben.

Das fiel mir neulich bei einem Gespräch mit einem Kollegen auf, bei dem es darum ging, daß wir nicht sicher wissen, welche Teile des Codes überhaupt verwendet werden bzw. welche Teile der Anwendung der Kunde überhaupt nutzt. Wenn wir jetzt Computerspiele entwickeln würden, hätten wir da ein großes Problem. Tun wir aber nicht. Und das beste: Wir haben nicht einmal Zeit, es herauszufinden. Tests auf dem Niveau von Shrinkwrap würden bei uns Bugs und Inkonsistenzen in enormer Anzahl zutage fördern. Aber es gibt keinen Vorteil, wenn viel Zeit verbraucht wird und der betreffende Bereich der Anwendung nie vom Kunden ausgeführt wird. Ein anderes Beispiel ist das Refakturieren. Damit bezeichnet man das Umschreiben von größeren Programmteilen mit dem Ziel, eine Vereinfachung, Verbesserung und in vielen Fällen auch quantitative Verringerung des Programmcodes herbeizuführen. Die Vorteile bleiben zwar, dennoch bringt eine Refakturierung in unserem Bereich mehrere Nachteile mit sich:

• Der refakturierte Code muß erneut getestet werden
• Es ist schwer sicherzustellen, daß durch die Änderungen keine unerwarteten Nebenwirkungen auftreten
• Die Änderungen müssen an die Kollegen kommuniziert werden
• Durch die enorme Menge vorhandenen Codes sind i.d.R. fast immer größere Änderungen erforderlich. Der dafür benötigte Zeitaufwand kann nicht immer fakturiert werden. Falsch. Kann eigentlich nie fakturiert werden.

Ein guter Freund von mir ist ein regelrechter Code-Ästhet. Nichts soll redundant sein, alles effektiv und glatt gebügelt. Er hätte mit dem Kram hier nicht viel Freude.
Worauf ich hinaus will: Man kann zwar denselben Beruf haben, aber seinen Tag trotzdem fast komplett mit andere Dingen verbringen.