Programmer At Work

Nachdem wir letztes Silvester in München verbracht haben, zog es uns dieses Jahr für vier Tage nach Budapest. Eine wirklich schöne Stadt, deren Erkundung mir wohl auch aufgrund eigenartiger Servicekräfte und dem schweinekalten Wetter noch länger in Erinnerung bleiben wird.

Tipp an andere Netbook-Reisende: Das Cafe Angelika bietet freundliche Bedienung bei angenehmen Ambiente, leckere Kuchen und freien WLAN Zugang.

Funny Fact: Wie man uns an der Rezeption unseres Hostels mitteilte, ist es in Ungarn im Gegensatz zu den meisten anderen europäischen Städten, nicht üblich das neue Jahr mit einem großen Feuerwerk willkommen zu heißen. Mit einem solchen Feuerwerk feiern die Ungarn lieber ihren Nationalfeiertag am 23. Oktober. Wie man anhand des Beweisfotos hier (vom Burgpalast aus) sieht, sehen das nicht alle Ungarn so.

Tipp: Wer in Budapest ist, sollte unbedingt auch einen Tag für einen Besuch im größten Bad Europas, dem Széchenyi-Heilbad, einplanen!

Die Frustration beim Debuggen einer Webapplikation in der Umlaute trotz vermeintlich korrekter Konfiguration vermurkst wurden, trieb mich unlängst in die Innereien von Jetty einem leichtgewichtigen Java Servlet Container und Webserver. In der aktuellen Release-Version, immerhin bereits Version 6.1.11 (!), lies mich der folgende Code erleichtert aufatmen.

jetty-6.1.11/modules/util/src/main/java/org/mortbay/util/UrlEncoded.java:
 405 / -------------------------------------------------------------- /
 406 /** Decoded parameters to Map.
 407   @param in the stream containing the encoded parameters
 408  */
 409 public static void decodeTo(InputStream in, MultiMap map, String charset, int maxLength)
 410   throws IOException
 411 {
 412   if (charset==null || StringUtil.__UTF8.equalsIgnoreCase(charset) || StringUtil.__ISO_8859_1.equalsIgnoreCase(charset))
 413   {
 414     decodeUtf8To(in,map,maxLength);
 415     return;
 416   }
 417 
 418   if (StringUtil.__UTF16.equalsIgnoreCase(charset)) // Should be all 2 byte encodings
 419   {
 420     decodeUtf16To(in,map,maxLength);
 421     return;
 422   }

Danke, keine weiteren Fragen Eurer Ehren! Zum Vergleich die korrigierte Version von decodeTo in der aktuellen SVN HEAD Revision:

  / -------------------------------------------------------------- /
  /** Decoded parameters to Map.
    @param in the stream containing the encoded parameters
   */
   public static void decodeTo(InputStream in, MultiMap map, String charset, int maxLength)
   throws IOException
   {
   if (charset==null || StringUtil.__ISO_8859_1.equals(charset))
   {
     decode88591To(in,map,maxLength);
     return;
   }
   if (StringUtil.__UTF8.equalsIgnoreCase(charset))
   {
     decodeUtf8To(in,map,maxLength);
     return;
   }
   if (StringUtil.__UTF16.equalsIgnoreCase(charset)) // Should be all 2 byte encodings
   {
     decodeUtf16To(in,map,maxLength);
     return;
   }

ppk on JavaScript - Modern, accessible, unobtrusive JavaScript explained by means of eight real-world example scripts, Peter-Paul Koch, 2007, 500 Seiten, newriders.com, ISBN: 0-321-42330-5.

Peter-Paul Koch (ppk), kannte ich vor allem aufgrund seiner tollen W3C DOM Kombatibilitätstests. Als Leser hat er mich allerdings durch die online verfügbare Einführung seines Buches geködert, dort heißt es:

Obviously, I cannot teach you to use a tool that I myself don't understand. Therefore this book only treats those language features I work with. Object-oriented JavaScript, for instance, is conspicuously absent because I've never seen the need to use it.

Äh, wie jetzt? Ein JavaScript Guru der nichts von OO hält? Ähm? Pff, interesting. JavaScript Bücher sprießen zur Zeit (wieder) wie Pilze aus dem Boden, der Konkurrenz hält ppk seine Erfahrungen an "richtigen" Projekten entgegen:

Where other books teach JavaScript using sample scripts that have little value in professional practice, ppk on JavaScript takes you inside eight real-world scripts created for actual, paying clients.

Auch das hört sich zunächst recht gut an. Auf die Beispielskripte sollte man vorher unbedingt einen Blick werfen, denn als Ganzes sieht man diese im Buch leider nie wieder.

Wer wie ich Besitzer eines frühen Erstdrucks ist, der darf sich über eine Sammelausgabe freuen oder besser gesagt, wird sich über eine solche ärgern. Denn aufgrund eines Druckfehlers wurde aus dem geplanten "blue book of JavaScript" ein graues - wodurch mitunter die Lesbarkeit der Code-Beispiele leidet.

Inhalt: (detailliert)

1. Purpose
2. Context
3. Browsers
4. Preparation
5. Core
6. BOM
7. Events
8. DOM
9. CSS modification
10. Data retrieval

Auf den Leser warten 500 Seiten in denen ppk weitgehend ohne JavaScript Vodoo (ala Crockford, Edwards oder Resig) anhand seiner Projekte (modernes) JavaScript vorstellt. Es beginnt mit einer Liebeserklärung an JavaScript, CSS, Webstandards, Browser - sprich das Web samt Anhang - und einem historischen Abriss über jene Entwicklungen die uns zum Status quo geführt haben. Diese ersten Kapitel enthalten zwar wenig Neues, zählen für mich dennoch zu den Besten, denn ppk schafft es seine Begeisterung glaubhaft rüberzubringen. Die restlichen Kapitel bieten eine solide JavaScript Einführung mit zahlreichen Tipps, in denen sich ppk vornehmlich auf die "eight real-world scripts created for actual, paying clients" stützt. Wenn ppk die split() Methode vorstellen möchte, dann sieht das in der Praxis (Kapitel 5F, Seite 183) z.B. so aus:

[Form Validation, lines 80-98, condensed heavily]

  // els[i] is the form field currently being investigated
  var req = els[i].getAttribute('validation');
  var reqs = req.split(' ');
  for (var j=0;j<reqs.length;j++) {
	// run check
  }

Für mich bieten solche Beispiele keinen essentiellen Mehrwert zu:

  var text = "Hier steht eine Zeichenkette.";
  var splitted_string_array = text.split(' ');

Im Gegenteil - erzwingen sie doch oft unnötige Kontextswitches für den Leser. Die Beispielskripte selbst werden nicht mit ihrem Kontext als Ganzes besprochen, sondern dienen vielmehr als praktische Veranschauung für gerade behandelte Eigenschaften, Methoden oder Konzepte. Ein Beispiel zu appendChild() aus Kapitel 8D auf Seite 368:

I use appendChild() many times in the example scripts. Take, for instance, this function from Sandwich Picker:

[Sandwich Picker, lines 184-186]

  function addExtraButton() {
      document.getElementById('extraButtonTarget').appendChild(extraButton);
  }

Bedingt durch diese Vorgehensweise wirkt auch der Aufbau der Inhalte nicht sehr durchdacht. Die Beispiele in den ersten Kapitel machen reichlich Gebrauch von Methoden oder Konzepten, die erst viel später erklärt werden. Mich störte auch die Art der informellen Einführung von neuen Inhalten; anstelle von Methoden-Signaturen findet man konkrete Anwendungsfälle und oft langatmige Erklärungen, ein Beispiel dazu (aus Kapitel 9A, Seite 424):

W3C's solution is the window.getComputedStyle() method, which works similarly but with a more complicated syntax:

  var x = document.getElementById('test');
  alert(window.getComputedStyle(x, null).color);

[...]

Wofür das zweite Argument von getComputedStyle() steht, warum es null ist, bleibt unbeantwortet. Als Entwickler erwarte ich vollständige Signaturen. Letztendlich musste ich im Laufe meiner Leseerfahrung mit dem Buch immer wieder mit mir ringen, überhaupt noch weiter zu lesen. Zu den Stärken hingegen zählen die vielen Hinweise zu Browser-Inkompatibilitäten und Neulinge werden die ausführlichen Erklärungen (recht toll ist z. B. das Kaptel 7 über Events) zu schätzen wissen.

Zum Thema Exceptions noch ein Gustostückerl:

I am not a big fan of try/catch statements, since I don't like executing code that may cause an error.

Wien wartet auf Dich! - Der Faktor Mensch im DV-Management, Tom DeMarco und Timothy Lister, 1999 (2. Auflage), 267 Seiten, hanser.de, ISBN: 3-446-21277-9.


Was sich übersetzer und Verlag bei der Wahl des Titels gedacht haben? Ich weiß es nicht. Vienna von Billy Joel ist zweifelsohne ein toller Song, aber auch mit dem Hintergrund dass man das Buch kennt, nur wenig passend für einen Ratgeber zur Projekt- und Teamführung.

1987 erschien die erste Auflage des in der Zwischenzeit zum Standardwerk für IT-Projekte aufgestiegenen Management-Bestellers von DeMarco und Lister: "Peopleware - Productive Projects and Teams". Zwölf Jahre später folgte die zweite Auflage mit acht zusätzlichen Kapitel und einigen wenigen Korrekturen. Die meisten der genannten Studien und Beispiele stammen deshalb aus den 80igern; COBOL ist noch in aller Munde und das Umfeld in vielen amerikanischen Arbeitsstätten von Entwicklern gleicht einem Dilbertschen Albtraum.

Seit dem hat sich einiges getan, doch das Wichtigste bei Software Projekten hat sich nicht verändert: Es kommt immer noch auf die Personen an. Im Mittelpunkt des Buches steht deshalb die Rolle des Managers: Wie ermöglicht man es den Mitarbeitern ihre Arbeit zu machen und nicht, wie man Mitarbeiter dazu bringt zu arbeiten.

Die größten Probleme bei unserer Arbeit sind keine technologischen Probleme, sondern soziologische Probleme.

Zum Inhalt:

• Teil I: Menschen führen
• Teil II: Die Büroumgebung
• Teil III: Die richtigen Personen
• Teil IV: Produktive Teams formen
• Teil V: Die Arbeit hier soll Spaß machen
• Teil VI: Wien wartet noch immer

In Peopleware geht es darum, wie man eine Umgebung schafft, in der Entwickler überhaupt erst produktiv arbeiten können. DeMarco und Lister sprechen über Bürogestaltung, Teamführung, Vertrauen, Bildung motivierter eingeschworener Teams, Wege um höhere Produktivitäts- und niedrigere Fluktuationsraten zu erreichen, wie man die richtigen Personen findet und den Spaß an der Sache nicht verliert.

Es gibt Tausende von Möglichkeiten, einen Arbeitstag zu verlieren, aber keine einzige, um einen Tag zurückzubekommen.

Auf den Leser warten insgesamt 34 kurze Kapitel in denen die Autoren in einem lockeren, unterhaltsamen Stil viele Anekdoten und Erfahrungen aus ihrem Consulting-Alltag mit praktischen Ratschlägen gepaart zum Besten geben. Schwächen in der Übersetzung sind vorhanden, halten sich jedoch im Rahmen.

Ich musste während des Lesens immer wieder zustimmend nicken; aus Sicht eines Entwicklers klingt vieles Selbstverständlich und einleuchtend. Doch einige Manager bzw. Unternehmen sehen ihre Mitarbeiter scheinbar eher als Zuchthühner die zu funktionieren haben. Als lästige Notwendigkeiten, deren Aufgaben darin bestehen ihren Vorgesetzten in endlosen Meetings untertänig Tribut zu zollen und sich irgendwie (wozu gibt es schließlich Wochenenden?) an die vorgegebenen Deadlines zu halten. Solche (zugegebenermaßen überzeichneten) Unternehmen verbrennen ihre Arbeitskräfte förmlich.

Die Wichtigkeit der Rolle des Managers bei Software Projekten wird jedoch auch von uns Entwicklern oft übersehen. Am besten überlegt man sich noch vor Annahme eines Angebotes, ob der Manager smart genug ist, um von ihm noch etwas zu lernen und die nötige Unterstützung zu erhalten. Wenn er Peopleware gelesen hat, ist das schon mal ein gutes Zeichen.

Die schwerste Sünde, die ein Manager begehen kann, ist es, die Zeit seiner Mitarbeiter zu verschwenden.

Bulletproof Ajax, Jeremy Keith, 2007, newriders.com, ISBN: 0-321-47266-7.

There are plenty of books out there aimed at server-side programmers who want to learn about Ajax. This isn't one of them.

Nach dem gelungenen Erstlingswerk (DOM Scripting) von Jeremy Keith habe ich mir auch den Nachfolger, Bulletproof Ajax, angesehen.

Als Fortsetzung zu DOM Scripting angelegt, wartet auf den Leser neben Neuem auch Altbekanntes. Kapitel 2 etwa, über "JavaScript and the Document Object Model" ist eine solche Wiederholung. Da bleibt bei 207 Seiten, großen Schriften (angenehm empfand ich die farbliche Gestaltung) und großen Randbereichen für fortgeschrittenen Tiefgang wenig Platz. Dass darf man sich auch nicht erwarten, denn diese überaus gelungene Einführung in Ajax richtet primär an "Front-end Web Designer".

Nachdem geklärt wurde was man sich unter Ajax vorstellen darf, der Kurzfassung von DOM Scripting, geht es in den Kapitel 3 und 4 mit der Vorstellung von XMLHttpRequest und XML, JSON und HTML ans Eingefleischte.

In the buzzword-filled world of Web design, it was almost inevitable that the name Ajax would show up sooner or later.

Die folgenden Blöcke drehen sich um Hijax, Jeremys Begriff für Ajax-Webapplikationen die nicht auf Progressive Enhancement und Unobtrusive JavaScript vergessen, Herausforderungen im Ajax-Zeitalter, und Accessibility.

In Kapitel 8 wird das bisher Besprochene zu einem großen Ganzen, einem Webshop, zusammengefügt. Anhand dessen Online-Demonstration kann man sich recht gut ein Bild vom Umfang der besprochen Inhalte machen.

Zum Schluss erwähnt Jeremy noch kurz die üblichen Verdächtigen unter den JavaScript Libraries und gibt Tipps zur Wahl einer solchen.

Ajax is a cool technology, but that's not a good reason to use it. Ajax can improve usability: that's a much better reason to use it.

Web Standards Solutions - The Markup and Style Handbook, Dan Cederholm, 2004, friendsofed.com, ISBN: 1-59059-381-2.

Dan Cederholms Markup and Style Handbook zeigt Lesern, die über grundlegende XHTML und CSS Kenntnisse verfügen sollten, wie sich alltägliche Web Design Probleme schnell und einfach mit Web Standards lösen lassen.

Der Inhalt des 253 Seiten starken Buches verteilt sich in zwei Teilen auf 16 Kapitel (Markup-Teil: Lists; Headings; Tables Are Evil?; Quotations; Forms; <strong>, <em>, and Other Phrase Elements; Anchors; More Lists; Minimizing Markup, CSS-Teil: Applying CSS; Print Styles; CSS Layouts; Styling Text; Image Replacement; Styling <body>; Next Steps) in denen ein breites Spektrum an Alltäglichen und Nützlichen behandelt wird. Cederholms lockerer Stil gefällt mir ebenso, wie der Aufbau des Buches.

Kapitel beginnen mit der Vorstellung eines konkreten Problems, anschließend werden jeweils mehrere Lösungsvarianten vorgestellt und deren Vor- bzw. Nachteile besprochen. Es folgt eine Zusammenfassung und ein Extra Credit Abschnitt, in dem das Besprochene ein wenig vertieft wird. Die Beispiele sind einfach und nachvollziehbar, die Sprache ist klar und die Bebilderung unterstützt Cederholms Vorstellung von sauberem Markup und richtiger Semantik optimal.

Dem CSS Veteran bietet das Buch nichts Neues, aber für weniger Webstandards versierte Leser oder "Old-School Tabellen-Junkies" ist es ein wahrer Augenöffner der noch nichts von seiner Aktualität eingebüßt hat.

P.S.: Von Dan Cederholm gibt es auch ein aktuelleres, ähnliches Buch: "Bulletproof Web Design", mehr dazu später.

Test-Driven Development - By Example, Kent Beck, 2003, awprofessional.com, ISBN: 0-321-14653-0.

"Code that isn't tested doesn't work."

Mit Extreme Programming, und Test-Driven Development (TDD) im Besonderen, sorgte Kent Beck für Begeisterung und Kopfschütteln gleichermaßen unter Entwicklern.

Die Grundidee ist simpel: Write a test. Make it run. Make it right. Befolgt man dieses Rezept, so erhält man zum Dank dafür "realiable bug-free code no matter what it's level of complexity": Software die tut was sie soll, deren Design glänzt und eine umfassende und aktualisierte Testssuite obendrein. Oder so.

PART I: The Money Example
PART II: The xUnit Example
PART III: Patterns for Test-Driven Development

In den ersten beiden Teilen zeigt Beck anhand zweier kleiner Beispiele wie TDD in der Praxis aussehen kann. zunächst entsteht ein Währungsrechner in Java: Er wird getestet, entwickelt, verbessert und irgendwann ist er da. Beck stellt sich seine Leser jedoch ein wenig sonderbar vor: Einerseits sollten diese von TDD noch nicht viel gehört haben, anderseits aber mit JUnit vertraut sein, denn eine Einführung in das Testing Framework gibt es nicht. Dieses Detail der praktischen Umsetzung bleibt den Lesern überlassen. Erst später, im Laufe des zweiten - hier entsteht ein xUnit Framework in Python - und dritten Teiles, fallen einige wenige (allgemeine) Worte dazu.

Die Beispiele illustrieren vor allem (auch) den Entwicklungsprozess hinter testgetriebener Entwicklung; wobei die Schritte vielerorts imho doch ein wenig zu atomar ausfallen.

"Clean code that works is out of the reach of even the best programmers some of the time, and out of the reach of most programmers (like me) most of the time."

Der Dritte Teil ist für mich der Grund, warum das Buch gerade noch so die Kurve kratzt. Hier bietet Beck einen bunten Eintopf aus Patterns, Tipps und Erfahrungen zu TDD.

Doch diese interessante Einblicke alleine reichen mir nicht für eine klare Empfehlung, auch weil ich Becks Stil mit den vielen gekünstelten Schmäheinlagen und Kommentaren zu Gott und die Welt eher lästig als unterhaltsam fand.

"Failure is progress."

In meiner Bibliothek tummeln sich ein paar Hundert Bücher, hauptsächlich FachBücher rund um Software-Entwicklung/Informatik. Heute kam aus dem Nachlass der aufgelösten Universitätsbuchhandlung MEX das Buch "Grundlagen der technischen Informatik" von Dirk. W. Hoffmann aus dem HANSER-Verlag dazu.

Ohne zum Inhalt konkret etwas sagen zu können, hat mich HANSER insofern schon mal positiv überrascht, als dem Buch eine kostenlose eBook-Version beiliegt. Seit Jahren ärgere ich mich darüber, dass das nicht eine völlige Selbstverständlichkeit unter den Verlagen ist. Immerhin kosten deren qualitativ durchwachsenen Bücher (übliche Preisspanne: 30,- bis 80,- EUR) eine Menge und werden oft schon nach wenigen Wochen durch eine Neuauflage obsolet. Doch die haben scheinbar anderes zu tun. Wie etwa über den Absatz von DRM kaputtisierten eBooks zu jammern, die gerade mal lächerliche 5,- bis 10,- EUR weniger als die jeweiligen Printausgaben kosten. Mich wundert es jedenfalls nicht, wenn sich "alternative eBook-Ausgaben" der Bücher im Netz verbreiten. Irgendwie scheinen Medienanbieter allgemein ein wenig lange zu brauchen um zu begreifen, dass Kundenverarsche auf Dauer einfach nicht funktioniert.

Abzüge in der A-Note gibts allerdings ganz klar für den Zwang sich Adobe Digital Editions zur Nutzung antun zu müssen, aber ein Schritt in die richtige Richtung ist die Beigabe allemal.

Wo wir schon mal dabei sind: Wenn ein Buch wie beispielsweise »UNIX Filesystems« bei Amazon.com für 29.70,- USD (~ 19.55,- EUR) zu haben ist, während Amazon.de hierzulande 54.99,- EUR für selbiges veranschlagt, dann fühle ich als Kunde mich durchaus "irritiert".

für einen Bericht mache ich mich in den nächsten Wochen, kurz vor dem Release von Firefox 3, noch auf die Suche nach den nützlichsten Firefox 2 Extensions. Auswahl gibt es genug, addons.mozilla.org listet knapp 2000 Extensions; dafür fehlen mir noch konkrete Zielgruppen Vorstellungen. Jedenfalls will ich mit knappen Notizen hier nützliche und weniger nützliche Begegnungen festhalten, beginnend mit Erweiterungen die ich selbst einsetze.

Vorrangig für UNIX Geeks interessant, die ohnehin in ihrem Editor (Vim, Emacs, ...) leben und gerade für längere Text- oder Codeeingaben auch im Web den Komfort ihres Editors nicht missen mögen, ist It's All Text. Diese Erweiterung blendet bei Aktivierung eines <textarea>-Elements, also eines mehrzeiligen Texteingabefeldes, einen kleinen edit-Button ein, welcher einen vorkonfigurierten Editor öffnet. Nach Verlassen des Editors wird der Text automatisch in das Textarea-Feld übernommen.

Bei Mika gesehen:

94 Wörter

Du hast 391 Punkte erreicht, damit befindest du dich auf Platz 2270 von 102164

Du schreibst 517 Zeichen pro Minute
Du hast 94 korrekt geschriebene Wörter und
Du hast 2 falsch geschriebene Wörter

Und das beim zweiten Versuch auf einer 8 Jahre alten, total abgenutzen, klebrig-klapprigen, urlauten, Tasten verschluckenden und sehr schwerfälligen Tastatur von Microsoft: Das Natural Keyboard Pro, dessen Nachfolger mich seit Jahren entäuschen, so dass ich immer noch auf dem Ding rumhämmere.

XUL - Entwicklung von Rich Clients mit der Mozilla XML User Interface Language, Jonathan Protzenko, 2007, opensourcepress.de, ISBN: 978-3-937514-23-9.

XUL ist eine auf XML basierende Sprache zur strukturellen Beschreibung von grafischen Interface-Elementen. Diese werden von Gecko (der Layout-Engine des Mozilla Projekts) gerendert, was die Entwicklung von Rich Clients die innerhalb des Browsers oder als eigenständige Applikationen laufen (XULRunner) möglich macht. Anhand einer praktischen Fallstudie soll der Leser in das Mozilla Application Framework eingeführt werden und selbst damit Anwendungen entwickeln können.

Das gewählte Beispiel, ein Forum auf XUL Basis, finde ich zwar wenig interessant, doch Protzenko nutzt es für einen zweckdienlichen Streifzug in eine Reihe von zusammenspielenden Technologien wie CSS, DOM, DTD, JavaScript. LDAP, PHP, RDF, SOAP, SOAP, WSDL XBL, XML, XMLHttpRequest, XPCOM, XPI, XUL, ... Klingt nicht nur abschreckend, ist auch so. Protzenko übernimmt sich zudem bei dem Versuch es allen Lesern recht zu machen. [1]

Ebensowenig überzeugen mich Aufbau und Struktur seines Rundumschlags. Die Mängel die sich durch inhaltliche Lücken, zu viele Sprünge und anderseits unpassend wirkende Einschübe auftun, lassen die Vermutung hoch keimen, dass es sich hier ursprünglich um ein Uni-Projekt handelte aus dem schnell ein Einführungsbuch zu recht gepflastert werden sollte. Ein wenig stört mich auch der Versuch Protzenkos XUL als Konkurrent (!) von AJAX positionieren zu wollen.

Das 351 Seiten umfassende Buch gleicht einer Achterbahnfahrt. Auf gute Abschnitte folgt immer wieder ein Tief. So zählt Kapitel 6 ("Verbesserte Darstellung mit CSS") zu den Besseren, das darauffolgende Kapitel, eine Einführung in JavaScript ("Erste Animationen mit JavaScript"), hingegen enttäuscht wiederum wieder und glänzt eher mit Falschaussagen. [2] Statt nachlässige Einführungen in Grundlagen wie JavaScript, CSS, DOM und Co. zu riskieren, sollte sich ein Buch über XUL / Firefox Extensions da doch lieber Verweise in die entsprechende Fachliteratur erlauben und sich auf eine bessere Darstellung der Kernkonzepte konzentrieren. Auch der Code und seine Präsentation schließen sich an. Inkonsistenzen, stilistische Fragwürdigkeiten, nervige Patzer und lehrreiche Offenbarungen reihen sich aneinander. Das Bemühen dem Leser ein großes Gesamtbild zu zeichnen, kann man höchstens als unterentwickelt bezeichnen. Das Buch weist allgemein eine größere Affinität zur alten Mozilla Suite bzw. SeaMonkey auf, geht aber auch Firefox ein. Als sehr erfreulich und lehrreich empfand ich die zahlreichen Verweise auf hervorragende Online Quellen zur Vertiefung.

Bei diesem von Open Source Press verlegten Erstlingswerk von Jonathan Protzenko handelt es sich um eine Übersetzung der bereits 2005 erschienenen französischen Originalausgabe »XUL - Mozilla XPFE, XBL, XPI, CSS, JavaScript, XML, RDF, DOM, PHP 5« (ISBN: 2-212-11675-6). Das ist mir zunächst gar nicht aufgefallen, denn die Einführungskapitel überspielen beides noch: Erst später als es richtig zur Sache geht wunderte ich mich, wie ein 2007 erschienenes Buch, derart veraltet sein kann. Aufklärung brachte ein Blick in das Impressum. "Ahh, Übersetzung. 2005. Seufz.".

Die Übersetzung an sich ist durchwegs gelungen, doch mit dem Alter der Vorlage hat sich der Verlag keinen Gefallen getan. Vorallem mit Firefox 1.5 hat sich gerade hinsichtlich der Extension-Entwicklung einiges geändert. So haben beispielsweise die einfacher aufgebauten Manifest-Dateien (chrome.manifest) die vormaligen RDF-Dateien (contents.rdf) zur Registrierung einer Erweiterung im Wirtssystem abgelöst. Erst im Anhang wird auf diese Transition eingegangen; wodurch sich weite Teile des vierten Kapitels ("Eine echte Mozilla-Erweitung") zumindestens für FF Nutzer als überflüssig erweisen. Immer wieder quält man sich als Leser durch veraltete Darstellungen und ärgert sich darüber, dass hier bei der Nachbearbeitung und Übertragung nicht konsequenter eingegriffen wurde.

Die fünf Anhänge betreiben Schadensbegrenzung und gehören wiederum zu den besseren Attributen des Buches:

• Firefox 1.5 und danach
• Firefox 2.0 und Änderungen an der Entwicklungsarbeit mit XUL (von Sebastian Schürmann)
• Liste der verwendeten XPCOM-Komponenten
• CSS: Syntax, Selektoren, Eigenschaften
• Referenz der grafischen XUL-Elemente

Auch wenn sich die XUL Referenz im Anhang nur auf das Nötigste beschränken möchte, Screenshots von den jeweiligen UI Elementen wären doch allemal sinnvoll gewesen. Die Online Referenzen von developer.mozilla.org oder xulplanet.com bieten hier deutlich mehr. Der abschließende Index mit seinen fünf Seiten ist leider auch ein wenig zu mager ausgefallen.

Eine deutschsprachige Errata, Codebeispiele zum Runterladen oder Weiterführendes sucht man auf der Seite des Verlages vergeblich; xulforum.org selbst bietet die Orginalquellen und weiteres Material - allerdings in Französisch.

Mein Fazit: Muss nicht sein! Zum Einen existieren hervorragende Online-Ressourcen, zum Anderen stürzen sich wieder mehr Verlage auf das Thema und bringen aktuellere Werke auf den Markt. Im April diesen Jahres erschien beispielsweise Programming Firefox im O'Reilly Verlag und im Oktober bringt entwickler.press mit Rich Clients mit Mozilla XUL einen deutschsprachigen Titel; weitere Bücher werden folgen.

[1] Das Buch richtet sich an professionelle Programmierer, Webentwickler, Designer und Anfänger. Siehe Abschnitt: "An wen wendet sich dieses Buch?", S. 16.
[2] "Nach jeder Anweisung in JavaScript steht ein Semikolon - ebenso wie in C oder Java", S. 129

DOM Scripting - Web Design with Java Script and the Document Object Model, Jeremy Keith, 2005, friendsofed.com, ISBN: 1-59059-533-5.

"You don't need to be a programmer to understand DOM Scripting. In fact, this book is aimed specifically at web designers."

Jeremy Keith engagiert sich seit Jahren im Web Standards Project innerhalb der DOM Scripting Task Force für zugängliche und auf Webstandards basierende Webseiten. In DOM Scripting richtet er sich primär an Webdesigner, an Personen die über keine oder wenige Programmiererfahrungen verfügen, die wissen möchten, wie sie mit JavaScript und DOM Skripting ihre Seiten sinnvoll um dynamische Elemente erweitern können.

Das 341 Seiten umfassende Buch beginnt mit einer kurzen pragmatischen JavaScript Einführung und widmet sich dann ausführlich der Erklärung des Document Object Models. Was ist das DOM und wozu das Ganze? Was kann man damit machen und wie kann man es machen? In den folgenden Kapitel soll der Leser anhand einer Reihe von ausführlich erklärten Praxisbeispielen ein Verständnis für die wichtigsten DOM Methoden und Eigenschaften erlangen. Schrittweise werden kleine Teilprojekte entwickelt (Bildergalerie, Elemente animieren, Inhalte mit JavaScript on the fly generieren oder verändern, Aussehen und Verhalten einer Seite dynamisch erweitern) die am Ende schließlich zu einem großen Ganzen, zu der Seite der fiktiven Band Jay Skript and the DOMSTERS, zusammengeführt werden.

Dem letzten Kapitel über die Zukunft von DOM Scripting, Webapplikationen und einer Einführung in Ajax folgt eine 16 seitige Referenz mit den wichtigsten Methoden und Eigenschaften des DOM. Den Schluss bildet ein 11 seitiger Index der zwar ganz brauchbar ist, aber dennoch eine Spur ausführlicher hätte ausfallen können. Die Referenz gibt es übrigens auch als Podbook zum Downloaden.

Jeremy achtet sehr auf den praktischen Real-World-Nutzwert seiner Beispiele. Er bemüht sich alle Anweisungen und Konzepte im Code zu erklären und auf mögliche Fragen des Lesers einzugehen. Seine ausführliche Art Code zu besprechen, tendiert ein wenig zu Wiederholungen, hat jedoch auch den Vorteil, dass der Code auch ohne Rechner nachvollziehbar bleibt.

Die einzelnen Kapitelinhalte bauen aufeinander auf und zeichnen sich zudem durch ihre Struktur aus:

• What this chapter covers
• Inhalt
• (Summary)
• What's next?

Das Buch hat mich aufgrund seiner sauberen und soliden Einführung überrascht. Wer bereits über DOM / JavaScript Erfahrungen verfügt, wird zwar wenig Neues aus dem Buch erfahren, kann aber trotzdem von den Beispielen profitieren. Keith bemüht sich seine Beispiele ständig weiter zu entwicklen (progressive enhancement) und predigt vor allem den sinnvollen Einsatz von DOM Scripting:

• Graceful degradation: ensuring that your web pages still work without JavaScript.
• Unobtrusive JavaScript: separating structure from behavior.
• Backwards compatibility: ensuring that older browsers don't choke on your scripts.

Man merkt dem Buch durchaus an, dass es von einem Autor geschrieben wurde, der nicht aus einem Informatik Umfeld kommt. Jeremy präsentiert seine Inhalte weniger formal strikt, als pragmatisch locker. Layout und Papier laden angenehm zu Randnotizen ein. Weniger toll hingegen ist, dass es zwar eine Webseite zum Buch gibt, aber der Code zum Buch nur auf der Seite des Verlages zu finden ist.

• Webseite zum Buch
• Errata
• Code-Beispiele

My Job Went to India - 52 Ways To Save Your Job, Chad Fowler, 2005, pragmaticprogrammer.com, ISBN: 0-9766940-1-8.

"It is true India has the advantage in software and China in hardware. If India and China cooperate in the IT industry, we will be able to lead the world...and it will signify the coming of the Asian century of the IT industry." -- Wen Jiabao

Vor einigen Jahren hatte ich für eine Vorlesung ein Paper zum Thema "Veränderung der Arbeitsstrukturen im Informationszeitalter durch Globalisierung" zu schreiben. Bei der Recherche habe ich mich mit den sozialen Auswirkungen zunehmender Automatisierung, Offshoring, und speziell den aufstrebenden IT-Sektoren Indiens und Chinas für die westliche Welt beschäftigt.

Software-Entwicklung ist ein komplexer und aufwändiger Prozess der all zu oft anders verläuft als ursprünglich geplant und Ressourcen überbeanspruchen kann. Das Auslagern von Arbeiten im IT-Sektor in Billiglohnländer wirkt daher attraktiv - zu Malen die Fürsprecher die selbe Leistung zu einem Bruchteil der Kosten versprechen.

"You might not know it, but you've already lost your job."

Werden unsere Straßen also tatsächlich bald von Softwareentwicklern überschwemmt werden, die mit "Will Code For Food" Schildern darauf hinweisen, dass sie nicht nur ihren Konkurrenzkampf verloren haben? Welche Gefahren und welche Möglichkeiten bietet Offshoring wirklich? Und gibt es bereits Kurse die arbeitslose Softwareentwickler auffangen und zu einer neuen aussichtsreicheren Karriere als Profi Mini-Golfspieler verhelfen?

Diese Fragen lässt das Buch unbeantwortet. Fowler hat zwar eineinhalb Jahre in Bangalore als Leiter eines indischen Offshore-Teams verbracht, doch das Buch dreht sich nicht um seine Erfahrungen vor Ort, sondern bedient sich dieser lediglich hin und wieder zur Illustration seiner Empfehlungen.

Der eigentliche Inhalt dreht sich - frei nach dem Untertitel "52 Ways To Save Your Job" - ganz um die Frage: Was kann man tun, um ein noch besserer Entwickler zu werden?

"Feeling irreplaceable is a bad sign, especially as a software developer. If you can't be replaced, it probably means you perform tasks in such a way that others can't also do them."

Chad Fowler legt uns hier einen 185 Seiten umfassenden zeitlosen Ratgeber vor, der in 52 kurzen Kapiteln - nicht nur für Software-Entwickler - zeigt, was man tun kann um noch besser in seinem Job zu werden und ihn letztendlich, in dieser globalisierten hektischen Welt trotz großem Konkurrenzdruck und ständig wechselnden Anforderungen, zu behalten. Eine Sammlung von Ratschlägen, Anekdoten und Weißheiten die gepaart mit gesundem Menschenverstand zu einem Karriere-Handbuch für Softwareentwickler - und solche die es bleiben wollen - wird.

Kurzum: Ein schnelles, aber lohneswertes Leseabenteuer, dass man sich am Besten alle zwei, drei Jahre immer wiedermal gönnen sollte. Freilich, ganz ohne Schwächen ist es nicht: Manche Passagen wirken banal und offensichtlich - doch auch diese haben ihren Sinn, schließlich ist es doch oft das Selbstverständliche dessen Nichtbeachten uns in unnötige Schwierigkeiten bringt.

"Too many of us seem to believe that specializing in something simply means not knowing about other things."

Die 52 Episoden des Buches sind sechs Abschnitten zugeteilt:

1. Choosing Your Market
2. Investing in Your Product
3. Executing
4. Marketing...Not Just for Suits
5. Maintaining Your Edge
6. If You Can't Beat'Em

Mich hat ursprünglich der Titel zu diesem Buch gebracht, da ich mehr über Indien, die Situation von indischen Softwareentwicklern, Offshoring und das Zusammenspiel mit westlichen Technologie-Firmen lernen wollte. Doch wie Dave Thomas in einem Postings erklärt, ist diese etwas unglückliche Titelwahl für ein Buch dieser Art wohl schuld daran, dass es sich schlechter verkauft als erwartet.

"Be the worst guy in every band you're in."

Viele haben schlicht Angst vor den Veränderungen in dieser Welt, vor dem Fremden und vor einem Buch, welches lediglich das Mantra ("die da drüben machen alles besser und günstiger obendrein!") der üblichen medialen Panikmache wiedergibt. Fowlers Buch hingegen hat damit nichts zu tun. Er sieht und präsentiert Chancen für jeden Entwickler dieser Welt sich weiterzuentwickeln, zu einem unentbehrlichen Teammitglied zu werden und seine Marktchancen zu steigern. Jobs verschwinden nicht. Sie verändern sich. Leben wir damit.

"You may be a great coder, but if you can't express yourself in words, you won't be very effective on a distributed team."

Am Ende vieler Kapitel fordert Fowler in so genannten "Act on it!" Abschnitten seine Leser auf, Besprochenes für sich selbst umzusetzen und in den Alltag zu integrieren.

Act on it!

1. Carve out weekly time to investigate the bleeding edge. Make room for at least two hours each week to research new technologies and to start to develop skills in them. Do hands-on work with these new technologies. Build simple applications. Prototype new-tech versions of the hard bits of your current-tech projects to understand what the differences are and what the new technologies enable. Put this time on your schedule. Don't let yourself miss it.

Mit dem für mich wichtigsten Ratschlag Fowlers und einer klaren Leseempfehlung beende ich diese Rezension:

"Love It or Leave It"

Links:

• Perlcast Audio-Interview über das Buch mit Chad Fowler (Januar 2006, 35min, 25 MB)
• Webseite zum Buch (Inhaltsverzeichnisse, Ausschnitte)

After the Gold Rush - Creating a True Profession of Software Engineering, Steve McConnell, 1999, mspress.microsoft.com, ISBN: 0-7356-0877-6.

"Software engineers shall commit themselves to making the analysis, specification, design, development, testing, and maintenance of a software beneficial and respected profession. In accordance with their commitment to the health, safety, and welfare of the public, software engineers shall adhere to the following eight principles: [...]" -- The Software Engineering Code of Ethics and Professional Practice

Steve McConnell zählt seit ich die erste Ausgabe von Code Complete gelesen habe, zu meinen favorisierten Autoren. In After the Gold Rush geht es für McConnell um eine Herzensangelegenheit: Um die Notwendigkeit des Erwachsen werdens der Softwareentwicklungsbranche. Der Titel bezieht sich weniger auf die Goldgräber-Stimmung die 1999 in vielen Softwarebudden herrschte, sondern auf eine Geschichte aus dem Buch. In der Hoffnung auf schnellen Reichtum hat der kalifornische Goldrausch Mitte des 19. Jahrhunderts Tausende von Menschen angelockt, die mit einfachsten Mitteln (wie Pfannen) ihr Glück suchten. Der größte Teil dieser Goldsucher scheiterte und verstarb in armen Verhältnissen, doch der Mythos des schnellen Reichtums liess weiterhin immer mehr Menschen nach Kalifornien strömen. Das meiste einfache Gold in Flüssen war jedoch längst gefunden, so dass andere aufwändigere Methoden nötig wurden, um an Gold zu kommen. für einzelne Goldgräber wurde die Situation aussichtslos; stattdessen übernahmen Unternehmen die einen systematischen und professionellen Abbau forcierten, die Führung.

"The success of a software project depends on not writing source code too early in the project."

McConnell sagt uns in After the Gold Rush, dass auch in der Softwareentwicklung die Zeit der amateurhaften Goldsucherei vergangen ist. Es ist an der Zeit systematisch organisiert und professionell vorzugehen. In dieser 156 Seiten umfassenden Sammlung von Essays schildert er die aktuellen Zustände der SW-Industrie und zeigt mögliche Auswege aus der Misere von nicht-enden wollenden fehlgeschlagenen Projekten.

"A Standish Group survey of more than 8,000 business systems projects found that the average project overran its planned budget by more than 100 percent."

McConnell schreibt üblicherweise Bücher mit einer langen Bookshelf-Haltezeit, so auch hier. Die Krankheiten die McConnell 1999 der Software-Branche diagnostiziert, treffen auch 2007 noch zu.

Die Essays sind drei Teile geteilt:

• The Tar Pit


1. Software Dinosaurs
2. Fool's Gold
3. Orphans Preferred
4. Software Engineering Is Not Computer Science


• Prospecting


1. After the Gold Rush
2. Engineering a Profession
3. Ptolemaic Reasoning
4. Body of Knowledge
5. Novum Organum


• Through the Pillars


1. Stinking Badges
2. Architects and Carpenters
3. Hard Knocks
4. The Professional's Code
5. Alchemy

"The commitment software developers' have to their projects as compared to their commitment to their companies is unusual. [...] Once a programmer has visualized the software to be built, bringing the vision to life becomes paramount and the programmer feels tremendously unsettled until that can be done."

Im ersten Teil des Buches zeichnet McConnell einerseits ein Bild der SW-Branche - ein Code-and-Fix (Trial-and-Error) Entwicklungsmodell, welches zu Projekten führt, die entweder komplett failen oder hoffnungslos veranschlagte Ressourcen (Zeit, Budget) überstrapazieren und obendrein eine extrem hohe Fehlerrate aufweisen - und anderseits ein Bild der Psyche von Menschen die in der Softwareentwicklung arbeiten.

Auf die Frage ob Software-Entwicklung Kunst oder Wissenschaft ist, antwortet McConnell, dass Software-Entwicklung vieles ist, aber vorrangig doch Engineering sein sollte. Er argumentiert weiters, dass die Ausbildung von professionellen Softwareentwicklern im Rahmen eines Software-Engineering Studiums erfolgen sollte, und man nicht weiter auf Computer Science (Informatik) Abgänger zurückgreifen dürfe.

"Individual heroics can contribute to project success, but teamwork generally contributes more than individual accomplishment does."

Im darauffolgenden Teil geht es darum, warum Softwareentwicklung verantwortungsbewusster betrieben werden muss, warum die aktuellen Vorgehensweisen schlecht sind und welche Folgen aus ihnen resultieren. Welche Massnahmen sollten ergriffen werden, damit man bereits bei der Ausbildung zukünftiger Software-Engineers sicherstellen kann, dass sich zwischen den Praktiken der Besten und jenen des Durchschnitts nicht weiter eine klaffende Kluft ergibt.

"The gap between the best software engineering practice and the average practice is very wide - perhaps wider than in any other engineering discipline." -- Fred Brooks

McConnell argumentiert, dass die Ausbildung an Universitäten besser werden muss und man Standards braucht um sicherzustellen, dass Absolventen über gewisse Grundlagen in der professionellen Softwareentwicklung verfügen. Er bespricht wie mögliche Software-Engineering Studiengänge aussehen könnten, welche Themen sie behandeln sollten und welche Entwicklungen sich aktuell in verschiedenen Ländern abzeichnen.

"Keeping up to date in software engineering can be time-consuming, and many software developers don't even try. One publisher reported that the average software developer reads less than one professional book each year and subscribes to no professional magazines."

Im letzten Teil geht es schließlich um die Frage, ob professionelle Softwareentwickler nicht aufgrund ihrer Verantwortung gegenüber der Allgemeinheit (und ihren Kunden) eine Zertifizierung/Lizenzierung durchlaufen müssen sollten. Nur eine solche würde seiner Meinung nach, ein Mindestmass an fachlicher Ausbildung und Erfahrungen garantieren können und dies sei schließlich auch der Grund, warum sich andere Berufsgruppen wie Mediziner oder Ingenieure solchen Qualitätssicherungsmassnahmen unterwerfen müssten.

Ein Fehler in einem mechanischen Teil eines Boilers hatte 1937 in einer texanischen Schule zur Folge, dass dieser explodierte und mehr als 300 Schüler sterben mussten. In Texas reagierte man daraufhin, indem Ingenieure von nun an ein Lizenzierungsverfahren durchlaufen mussten, um ihren Beruf ausüben zu können. Die Steuerungs-Aufgabe dieses ehemals mechanischen Teiles wird heute oft von Software übernommen.

McConnell stellt die Frage: Warum gelten für andere Ingenieurs-Bereiche oder Berufe wie Mediziner wesentlich strengere Kriterien als für Softwareentwickler?

"An attempt to trade quality for cost or schedule actually results in increased cost and a longer schedule."

Noch müssen Software-Entwickler kein Berufsausübungsverbot fürchten, falls ein Fehler in einem Software-System Menschenleben fordert. Aktuell werden nicht einzelne Personen sondern Prozesse bzw. konkrete Softwaresysteme zertifiziert. In der Luftfahrt etwa, ist eine Erlaubnis der EASA oder FAA nötig, wenn man ein Flugzeug entwickeln und damit Passagiere befördern möchte. Um diese Zertifizierung zu durchlaufen, müssen bei der Entwicklung strenge Standards (siehe DO-178B) eingehalten werden.

"Conway's Law: the structure of a computer program reflects the structure of the organization that build it."

Es sind streitbare Ziele und Wege die McConnell vorschlägt, mit denen er zwar keinen Konsens, aber immerhin doch eine Diskussion unter den Betroffen erreicht.

Update: Die zweite Edition (2004) erschien unter dem Titel: Professional Software Development - Shorter Schedules, Better Projects, Superior Products, Enhanced Careers.

Practical Debugging in C++ von Ann R. Ford und Toby J. Teorey, 2002, prenhall.com, ISBN: 0-13-065394-2.

Ein verlockender Titel und Schmetterlinge am Cover - was will man mehr? Idealerweise den dazu passenden interessanten Inhalt - und genau hier hakt es bei diesem 104 Seiten umfassenden Heftchen leider deutlich.

Aus dem Vorwort:

This book is a tutorial on debugging techniques for both the beginning and intermediate programmer.

Diese Einschätzung ist in meinen Augen noch übertrieben. Denn bereits geringe C++- oder Programmiererfahrungen machen große Teile des Inhalts irrelevant.

Ich habe versucht mich in die Rolle eines Lesers zu versetzen, der gerade anfängt seine ersten Programmiererfahrungen zu sammeln. Doch selbst unter diesen Umständen kann ich mit dem Buch nicht glücklich werden; dazu sind die dargebotenen Inhalte schlicht viel zu trivial.

Der Inhalt

Chapter 1 Introduction
Chapter 2 Common Syntax and Semantic Errors
Chapter 3 Tracing Techniques for Debugging
Chapter 4 Trace Debugging for More Advanced C++ Constructs
Chapter 5 Using an Interactive Debugger
Appendix A The 32 Most Common Bugs in First Programs
Appendix B Checklist for Error Detection and Prevention

In Kapitel 2 werden geläufige Syntax- und Semantik-Fehler besprochen. Wie/Wo treten sie auf? Wie korrigiert man sie? Beispiele: fehlendes Semikolon am Ende einer Anweisung, Return-Anweisung(en) vergessen, = statt ==, nicht beachtete Operatoren-Reihenfolge, Off-By-One Error, Zugriff auf nicht gültige Array Indizes, ...

Tracing using extra print statements probably is the single most important method for debugging computer programs.

Kapitel 3 und 4 bilden zusammen den Haupt- und zugleich schlechtesten Teil des Buches. Anhand einer Reihe von unnötig unübersichtlichen Beispielen zeigen Ford und Teorey hier auf 46 Seiten verteilt, dass man tatsächlich std::cout nutzen kann, um Variablen-Inhalte auszugeben! Äh, Vista-WOW!

Wenigstens das Puffer-Konzept von Ausgabe-Streams hätte man hier besprechen können. Wenn Text zur Ausgabe (am Bildschirm) in einen Ausgabe-Stream geschickt wird, dann wird aus Performance Gründen nicht sofort jedes Zeichen direkt ausgegeben. Stattdessen werden die Zeichen in einem Zwischenpuffer (streambuf) gesammelt, welcher erst dann geleert wird (d.h. der Text wird in das eigentliche Ziel geschrieben), wenn bestimmte Ereignisse eintreten. Wie etwa: Es sind ausreichend viele Zeichen im Puffer, das Programmende wurde erreicht, Input von einem Eingabe-Stream soll gelesen werden, Stream wird geschlossen oder wenn ein Entleeren durch den Benutzer erzwungen wird (std::flush, std::cout.flush())

Die Bespiele іm Buch verwenden allesamt std::cout (gepuffert) zur Fehlerdiagnose; rufen allerdings auch std::endl auf und veranlassen somit neben der Ausgabe von '\n' ein std::flush().

Das fünfte Kapitel bietet eine kurze Einführung in die integrierten Debugger von Metrowerks CodeWarrior Professional Release 5 und Microsoft Visual C++ 6. Das gewählte Beispiel und die Erläuterungen sind zweckdienlich, doch die Screenshots des Microsoft Debuggers sind von einer äußerst geringen Qualität und kaum unleserlich.

Im Anhang folgt eine Liste von 32 häufigen (Anfänger-)Fehler und eine Liste mit allgemeinen Tipps zur Fehlervermeidung/-suche. überrascht hat mich schließlich die einseitige Bibliographie am Ende des Buches, denn hier finden sich durchwegs Referenzen zu einigen empfehlenswerten Büchern.