Bücher

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

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.

C Traps and Pitfalls, Andrew Koenig, 1988, awprofessional.com, ISBN: 0-201-17928-8.

"This book belongs on your shelf if you are using C at all seriously, even if you are an expert: many of the professional C programmers who saw early drafts said things like that bug bit me just last week!"

Andrew Koenig ist in der C und C++ Welt kein Unbekannter. Er zählt zu den anerkanntesten C++ Experten weltweit und hat bis vor wenigen Jahren, wie auch Bjarne Stroustrup, in einer Forschungsabteilung von AT&T/Bell Labs (Brutstätte von C, C++, UNIX, ...) gearbeitet. Seine Rolle als Verfechter von ISO/ANSI Standards unterstützte er mit seiner Arbeit im ISO/ANSI Standardisierungsgremium für C++.

1985 hat Koenig begonnen Fallen in die C Programmierer sich immer wieder verlieren zu sammeln. Drei Jahre später wurde diese 147 Seiten umfassende Sammlung von Addison-Wesley erstmals im Taschenbuch-Format veröffentlicht. Mir liegt der neunzehnte Druck vor, wobei am Inhalt des Buches seit November 1988 nichts mehr verändert wurde. C hingegen hat sich seit den Achtzigern sehr wohl weiterentwickelt: 1989 wurde ANSI C (ANSI X3.159-1989 "Programming Language C." respektive ein Jahr später ISO/IEC 9899:1990) verabschiedet und seit 1999 (ISO/IEC 9899:1999) gibt es mit C99 wiederum einen neuen Nachfolger-Standard.

Und dennoch: Fast zwanzig Jahre nach Erscheinen dieses Buches lohnt es sich immer noch, Zeit in die Lektüre dieser Sammlung zu stecken. Nicht nur für low-level C-Programmierer. Dem Engagement Koenigs hinsichtlich Standardkonformität ist es zu verdanken, dass seine Sammlung auch wenn sie vor der Verabschiedung von ANSI C entstand, sich dennoch bereits an diesem orientiert.

Der Inhalt

Das Buch ist in 10 Abschnitte geteilt:

0 Introduction
1 Lexical pitfalls
2 Syntactic pitfalls
3 Semantic pitfalls
4 Linkage
5 Library functions
6 The preprocessor
7 Portability pitfalls
8 Advice and answers
Appendix: printf, varargs, and stdarg

"I wrote my first C program in 1977. Of course it didn't work."

In den Kapitel 1 - 3 bespricht Koenig Grundlagen, die man so auch in ähnlichen Büchern findet:

Klassiker wie das ungewollte Vertauschen von = mit == (bzw. &, | mit &&, ||), Greedy / Maximal Munch-Strategie (warum a---b zu a -- - b und nicht zu a - -- b wird), Probleme von verschachtelten Kommentarstrukturen, Zeichenketten vs. Zeichen. Warum man sich vor Ausdrücken wie (*(void(*)())0)(); (declare it the way you use it) nicht fürchten muss; richtige Reihenfolge bei der Operatoren-Auswertung, Dangling-Else, Pointer vs. Arrays und wie man richtig zählt und sich mit asymmetrischen Grenzen viel Ärger (off-by-one errors) ersparen kann. Express a range by the first element of the range and the first element beyond it. [...] Use inclusive lower bounds and exclusive upper bounds.

In Kapitel 4 geht es um die Rolle des Linkers und welche Probleme beim Verlinken von Objekt Modulen auftreten können. Weitere Punkte: Die Unterschiede zwischen einer Deklaration und einer Definition, Bezeichner Konflikte und deren Auflösung (static-Modifier), und was schiefgehen kann, wenn Funktionsargumente, -parameter, Rückgabewerte und external Typinformationen durcheinander gebracht werden.

Es folgt ein kurzes Kapitel über wichtige Funktionen aus der Standard Library mit überraschenden Eigenschaften. Wie etwa: getchar() liefert einen int und keinen char zurück oder der richtige Umgang mit errno. In den nächsten beiden Kapitel dreht sich alles um Macros und auf welche Problemstellen geachtet werden muss, wenn man Software schreiben möchte, die portabel auf mehreren Architekturen unter verschiedenen Umgebungen verwendet werden soll.

"[...] For this reason, it is a good idea in a macro definition to enclose each parameter in parentheses. It is also important to parenthesize the entire result expression to defend against using the macro in a larger expression."

Natürlich schlagen oder beißen so manche der beschriebenen Fallen heutzutage nicht mehr (zu). Konnte a =- 1 von frühen C Compilern noch als a = a - 1 statt a = -1 missverstanden werden, so hat sich zum einen C gewandelt, (heute: a -= 1) und zum anderen haben sich die Compiler-Implementierungen gebessert. So sind viele der beschriebenen Compiler-Macken wie etwa a >> = 1 als legales Konstrukt oder 0195 als oktale Zahl durchgehen zu lassen, in modernen Compilern wohl kaum noch anzutreffen.
ähnliches gilt für andere Beispiele, wie etwa: "A function called before it is defined or declared is assumed to return int."
Das stimmt für C90 kompatiblen Code, hat sich allerdings mit C99 geändert. Dennoch finde ich solche Hinweise nützlich, denn abgesehen davon, dass man etwas über die Geschichte von C erfährt, schwirrt da draußen noch sehr viel alter Code rum der gewartet werden muss.

Am Ende eines jeden Kapitels bringt Koenig Übungsbeispiele, die einerseits die besprochenen Inhalte vertiefen und anderseits zur weiteren Beschäftigung einladen sollen. Kapitel 8 enthält ausführliche Lösungen zu diesen Aufgaben, sowie allgemeine Ratschläge zur Fehlervermeidung und Tipps aus dem Alltag.

Exercise 2-1. C permits an extra comma in an initializer list:

    int days[] = { 31, 28, 31, 30, 31, 30,

                   31, 31, 30, 31, 30, 31, };

Why is this useful?


Exercise 5-1. When a program terminates abnormally, the last few lines of its output are often lost. Why? What can be done about it?

Abschließend folgt auf 13 Seiten die wohl beste und ausführlichste Behandlung über die printf-Familie, die mir je in einer nicht C-Referenz untergekommen ist und eine kurze Einführung in variable Argumentenlisten mit varargs / stdargs.

"Perhaps the most important avoidance technique is to know what you're doing."

Fazit

Wer bereits über langjährige C Erfahrungen verfügt, wird in diesem Buch nur wenig Neues erfahren. Anderseits sollte man die erste bessere C Einführung und einige praktische Erfahrungen doch schon hinter sich gelassen haben, um die Inhalte auch wirklich nachvollziehen zu können.

Seit etwa zwei Jahren gebe ich sporadisch einigen HTL Schülern C/C++ Nachhilfe. Das Ganze macht großen Spass, und ist sehr lehrreich. Ich erfahre, welche Konzepte (oft ganz unerwartet) Verständnisschwierigkeiten bereiten (z.B. Funktionsparameter) und kann zusammen mit etwas Computerarchitektur-Hintergrundwissen vermitteln, warum etwas so ist, wie es ist. An diesen Schülern habe ich eine Reihe von Beispielen aus dem Buch erproben und mit Erfolg testen können.

Koenig hat mit diesem Buch aber vor allem eines geschafft: Er hat mich wieder neugierig werden lassen. Wie reagieren und implementieren die C Umgebungen mit denen ich zu tun habe (gcc > 3 mit glibc, dietlibc sowie bedingt die libc von FreeBSD/Apple) tatsächlich? Und das ist weit mehr als ich erwarten durfte.

Müsste ich mich zwischen diesem Buch und "Expert C Programming" von Peter van der Linden entscheiden, dann würde ich letzteres wählen. Dazu jedoch etwas später mehr.

My current book stack

• State of War
• POSTWAR
• Das Königsspiel
• To Kill a Mockingbird
• High Fidelity
• why europa will run the 21st century
• The World is Flat
• Europa
• THE 7 HABITS OF HIGHLY EFFECTIVE PEOPLE
• OUT OF THEIR MINDS: The Lives and Discoveries of 15 Great Computer Scientists
• NATURWISSENSCHAFT: Alles, was man wissen muss
• Die Nervenprobe: Schauplatz Kuba

Currently reading

• MY JOB WENT TO INDIA
• Wirtschaft und Finanzen
• Der Schwarm

Der dtv-Atlas Weltgeschichte kommt in zwei Bänden; der erste Band behandelt die Zeitspanne von den "Anfängen" bis hin zur französischen Revolution. Der zweite, mir vorliegende, Band handelt von der französischen Revolution bis zur Gegenwart. (2004) Mich interessiert allgemein die Epoche der Neuzeit und insbesondere die Zeitgeschichte. Dennoch bei Gelegenheit werde ich mir den ersten Band auch noch besorgen.

Schon beim ersten Durchblättern beeindruckte mich dieses kleine Taschenbuch, vorallem durch sein umfassendes Kartenmaterial. Auf 138 Farbabbildungen helfen Karten, Schautafeln und Diagramme rasch einen überblick über verschiedenste globale Entwicklungen zu erhalten. Darauf gestoßen bin ich durch Helmut - er schwärmte ziemlich davon. Allerdings tun das Historiker bekannterweise recht schnell...

In Zeiten von Wikipedia haben es Werke wie dieses natürlich schwer, insbesondere unter Nicht-Historikern. Doch gerade diesen kann der dtv-Atlas einiges bieten, wo Wikipedia nicht mithalten kann. Der Atlas punktet klar durch übersichtlichkeit, Kompaktheit und einer konzentrierten chronologischen Abfolge auf der einen Seite und das wirklich tolle Kartenmaterial auf der anderen Seite.

Durch den Versuch ein umfassendes überblickswissen über Entwicklungen in der ganzen Welt, nicht nur einzelner Regionen, aufzubieten, fehlt es natürlich an Tiefe. Dies ist jedoch kein Nachteil. für Nicht-Historiker sind viele Details - in ihren komplexen Verzweigungen - ohnedies zweitrangig. Bei Interesse liest man einfach die jeweiligen Auslegung in den entsprechenden Monographien nach. Nicht missverstehen: es handelt sich hier keineswegs um eine reine Sammlung von Jahreszahlen. Abgerundet wird das Ganze durch ein erfreulicherweise ausführliches Register.

Vor etwa einem Jahr hatte ich mir Der Prophet von Khail Gibran gekauft. Ich weiß nicht mehr so recht, wie ich auf dieses Büchlein kam, doch damals schien irgendwie jeder davon begeistert zu sein. Die Kundenrezensionen von Amazon.com sprechen mit 5 Sternen bei 203 Bewertungen hier auch eine eindeutige Sprache. Gibran's Prophet spricht zu den Einwohner der Stadt Orfalis über abendländische und nahöstliche Philosophien und von einer besseren Welt .

Meine Ausgabe im kleinen Taschenbuchformat fasst zwar nur 95 Seiten, dennoch hatte ich nach der Hälfte erstmal die Lust daran verloren. Angeregt durch die - bei allem Verständnis - unverhältnismäßigen Ausschreitungen im Zusammenhang mit dem sogenannten Karikaturen-"Streit" habe ich nun wieder zur zweiten Hälfte gefunden.

Die Rezensionen bei Amazon.de sind ausgeglichener als beim amerikanischen Pendant, sie spalten sich einmal mehr in zwei Lager: die einen finden das Buch super toll, die anderen würden es nicht mal als besseren Bierdeckel nutzen wollen.

Ich finde mich da irgendwo dazwischen wieder. Zum einen schöne Wort in einer nahbaren Sprache, mit Sinnbildern die zum Nachdenken anregen. Zum anderen finde ich es zu blumig und das es sich zu einfach macht. Binsenweisheiten die - zumindestens aus meinem Kulturverständnis heraus, eher Selbstverständlich als besonders aufregend erscheinen - glänzen hier durch eine sprachlich anregende Verpackung. Allerdings muss man dem Buch zu Gute halten, dass es einer bald Hundert Jahre alten Mentalität entstammt und sein Erfolg und Bekanntheitsgrad in der westlichen Welt erscheint mir durchaus nachvollziehbar. Khalil Gibran's Prophet ist im Netz vorallem für seine Zitate bekannt, und auch ich habe mir einige Stellen vorgemerkt...

Den Inhalt beschreibt das Buch in seiner Einleitung selbst wohl am besten:

Eine Stadt im Orient: Der Prophet al-Mustafa erwartet das Schiff, das ihn in seine Heimat zurückbringen soll. Bevor er sie verlässt, bitten ihn die Einwohner von Orfalis, ein letztes Mal zu ihnen zu sprechen: von Liebe, Schmerz, Schönheit, Freude und allem anderen, was die Menschen bewegt. Die Antworten des Propheten sind voller Lebensweisheiten und mystischer Tiefe und zählen zum Faszinierendsten, was die spirituelle Literatur hervorgebracht hat. Khalil Gibran gelang mit diesem Werk der Brückenschlag zwischen der Alten und Neuen Welt, zwischen Orient und Okzident, Islam und Christentum. 1923 erschienen, erlebte 'Der Prophet' einen beispiellosen Triumphzug im Westen und avancierte zu einem Kultbuch, das Generationen überdauert.