Programmer At Work

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."