Sonntag, 4. März 2007

Wi(e)der ein dickes Fachbuch - Gedanken zu "Programmieren mit dem .NET CF"

Torsten Weber, der sich für .NET in und um Leipzig und darüber hinaus engagiert und den ich schon länger kenne und für seinen Enthusiasmus schätze, hatte mich anlässlich meines kritischen Postings über dicke Fachbücher gefragt, ob ich mir denn mal sein dickes Fachbuch zum Thema .NET CF anschauen und rezensieren könne. Das waren seine Worte:

"Nur um eines würde ich dich bitten: Sei ehrlich. Zerreiß es ruhig, wenn es nichts ist, in der Luft. Das ist mir für ein nächstes Buch zu wichtig, als „Honig ums Maul geschmiert zu bekommen“. Außerdem wäre eine positive / negative Rezension je nachdem eine Bestätigung deiner Vermutung über die Seitenanzahl oder das Zeugnis, dass einfach ein neuer Schreibstil her muss."

Solch Wunsch nach unverbrämtem Urteil hat mich dann doch motiviert, selbst ein dickes Fachbuch auch ohne Not und eigenes Sachinteresse mal näher anzuschauen. So habe ich mich denn rituell gereinigt, die Behaarung am ganzen Körper entfernt, mich mit feinsten Ölen eingerieben, in weiße Linnen gehüllt, Räucherstäbchen angezündet und drei Tage unter Absingen heiliger Journalistenlieder gefastet, um mich in den für Rezensenten angemessenen selbstlosen Zustand zu versetzen, der Voraussetzung für die vorurteilsfreie Betrachtung eines Buches ist. Kein Zorn, kein Eifer soll mich leiten, sondern nur der Wunsch, Torstens Titel gerecht zu werden. Ergebnisoffen möchte ich prüfen, ob er die Ausnahme zu meiner "Regel" ist, dass dicke Fachbücher inzwischen unzeitgemäß und kontraproduktiv seien.

So nehme ich denn die Betrachtung seines Buches auf...

Zur Form

Äußerlich kommt es (ge)wichtig daher mit 678 Seiten - die sich allerdings durch einen vergleichsweise kleinen Preis andienen. Für 39,90 EUR verspricht "Programmieren mit dem .NET Compact Framework - Anwendungsentwicklung für mobile Geräte" von Ruprecht Dröge, Peter Nowak und Torsten Weber "umfassendes Wissen zur Entwicklung von mobilen Anwendungen" und "viele[] praxisnahe[] Beispiele[]". Es zeigt "die nötigen Grundlagen, Techniken und besten Vorgehensweisen" für alle, die "mobile Anwendungen auf Basis der .NET-Plattform entwickeln möchten". Obendrein ist es auch noch empfohlen von mit einem Grußwort versehen von der OpenNETCF Consulting - werimmer das sein mag.

Das Buch verspricht also viel: Viel Wissen auf vielen Seiten, deren Gliederung allein 9 Seiten Inhaltsverzeichnis ausmachen. 10 Seiten Index sind dann schon nicht mehr so üppig, wenn man mal Arno Schmidts Forderung von 1 Seite Index pro 20 Seiten in Anschlag bringt, aber ich weiß selbst, wie nervig die Indizierung eines Buches ist. Wenn man alles endlich fertig geschrieben hat, dann fällt es schwer, nochmal alles ganz genau zu lesen und die wirklich wichtigen Worte herauszuziehen - allemal, da die Indizierung im Grunde nicht werkzeuggestützt ist. Alles mühselige Handarbeit. Allerdings: Bei .NET kompakt 3.0 sind Christian Weyer und ich immerhin auf 6 Seiten Index für knapp 200 Seiten gekommen. Aber ich schweife ab... Meine innere Reinigung war vielleicht doch nicht so synapsentief, wie angestrebt?

Äußerlich ist am Buch also erstmal nichts auszusetzen. Solide Buchdruckerkunst. Am Ende stellen sich die Autoren kurz vor und es wird doch auch angezeigt, wer welchen Teil des Buches zu verantworten hat. Diese Information hatte ich nämlich beim Blick auf die Kapitel vermisst. Ich finde eine klare Zurechenbarkeit zum Autor sehr wichtig.

15 Seiten Anhang geben dann noch über den Inhalt der CD-ROM Auskunft, 4 Seiten über sonstige nützliche Ressourcen. Die sind wie auch andere Hinweise mit einem ominösen LINKnnnn-Kürzel versehen, über dessen Funktion ich dann doch einen Moment rätseln muss. Ist LINK2202 nur als Platzhalter im Text gedacht, eben als Referenz in diesen Anhang? Nein, denn im Anhang stehen die Ressourcen nicht sortiert nach diesen Platzhaltern. Auch finden sich nicht alle Platzhalter im Anhang, wie z.B. LINK0002, der auf Seite 20 mit einer Aufforderung zu einer Rezension bei Amazon erwähnt ist. Erst auf Seite 35 und nach vielen solchen Platzhaltern wird die Auflösung verraten: Sie sollen als Label an die Domain www.nahtlos-mobil.de gehängt werden, z.B. www.nahtlos-mobil.de/gehezu/?link0002. Achso. Das ist natürlich eine nette Idee - aber warum kann man die nicht auf der ersten Seite vor Erwähnung des ersten LINKs erklären oder zumindest dort, wo im Anhang ein ganzer Haufen solcher Verweise gelistet ist?

Und überhaupt: Wenn denn das Internet so mit in das Buch eingewoben ist - worauf mich Torsten schon vorbereitet hatte und was ich eigentlich sehr löblich finde -, warum ist dann noch eine Buch-CD nötig? Warum sind dann seitenlange Listen mit Referenzen nach irgendwohin im Buch? Immerhin knapp 20 Seiten oder 3% des Buches werden damit gefüllt, ohne rechten Nutzen zu bringen. Heute noch eine CD mit auszuliefern, ist anachronistisch. Ihr Inhalt veraltet quasi sofort nach der Pressung. Genauso die Liste der Ressourcen in Anhang B. Eine Bibliographie, die viele Verweise auf ohnehin nur offline verfügbare Texte enthält und genaue Quellenangaben an einem Ort im Buch bündelt, die sonst als Fußnoten darin verstreut wären, ja, so eine Bibliographie ist auch heute noch sinnvoll. Aber elektronische Ressourcen sind viel aktueller und leichter über ein ebensolches elektronisches Verzeichnis im Internet zu finden und zu nutzen. Insbesondere wenn Thorsten mir erklärt, dass das Buch sozusagen "work in progress" sei und Ressourcen ständig verändert/ergänzt würden... was soll dann eine Buch-CD und diese Platzverschwendung im Buch?

Es gibt eigentlich nur eine Antwort: Man hat einfach nach alter Väter Sitte gehandelt. ´s war schon immer so, dass man eine schöne Buch-CD beilegt. Wertet das Buch doch auf, oder? Das erwarten die Leser! Nun, ich zumindest erwarte keine CD. Eine CD veraltet unmittelbar, macht das Buch teurer, Bücher mit Softcover kann man dann nicht mehr bequem knicken und Einlegen macht mehr Umstände als eben mal zu einer URL surfen.

Aber genug davon. Ich glaub, ansonsten hab ich an den Äußerlichkeiten des Buches nichts auszusetzen. Ist halt ein solider MSPress Titel. Manche Abbildungen sehen zwar unnötig vergrößert aus, als ob die Seite sonst nicht voll geworden wäre, und andere vermitteln den Eindruck von etwas Bequemlichkeit, weil sie wie 1:1 von Microsoft übernommene Powerpoint-Folien aussehen, die im s/w-Druck aber ihren Charme verloren haben... doch sei´s drum. Das ist ok für ein Buch zu dem Preis.

Zum Inhalt

Jetzt endlich zum Inhalt. Meine Erwartungen sind hoch, denn die Ankündigung auf dem Einband verspricht viel und das Inhaltsverzeichnis scheint ihm Recht zu geben. Es scheint, als wäre zu jedem Stichwort, das mir im Zusammenhang mit .NET oder Mobile Computing einfallen könnte, auch etwas im Buch gesagt: Garbage Collection, Thread-Synchronisation, Unit Tests, Lokalisierung, ActiveSync, Business Intelligence, ImageList... you name it. Wow!

Aber was soll dieses Grußwort? Von einem Chris Tacke geschrieben, der dick bei OpenNETCF mit drin sitzt. Er kann sicherlich kein Deutsch und hat sicherlich das Manuskript des Buches nicht gelesen und nimmt darauf auch gar keinen Bezug. Er wünscht nicht mal viel Spaß beim Lesen. Was soll das also?

Dann nochmal 4 Seiten Vorwort der Autoren, Danksagung und Vorstellung der Autoren, die ich ja schon vom Ende des Buches kenne. Warum das? Wann geht es endlich los?

Es folgen 4 Seiten, die sich damit beschäftigen, was ich auf den folgenden noch knapp 650 lesen könnte, wenn ich alles lesen wollte. Warum das? Wann geht es endlich los?

Solche Art Meta-Aussagen finde ich schlicht überflüssig. Sie kommen dann auch noch am Anfang jedes Kapitels unter der Überschrift "Was sie in diesem Kapitel erfahren" vor. Das ist gut gemeint, langweilt den Leser aber. Irgendwann hat irgendwer mal (bei Microsoft?) die Idee gehabt, Vorträge und Bücher müssten mit solcherlei Vorspann ausgestattet sein. Das sei gut, um die Erwartungen der Zuhörer/Leser "einzuschwingen". Das halte ich jedoch für eine didaktisch/methodische Verirrung aus einem paternalistischen Geist heraus. Motto: "Jungchen, ich will dich mal nicht gleich unter dem Gewicht meines Wissens begraben, sondern führe dich ganz langsam ran. Erstmal ein Überblick, damit du dich nicht verschluckst. Ich weiß ja, du verträgst nicht soviel Neues. Die Dusche wäre zu kalt, wenn ich gleich anfangen würde." Der Überblick ist also so ehrlich wie das Lächeln einer amerikanischen Kellnerin. Und er ist kontraproduktiv, weil er langweilt, denn der Zuhörer/Leser merkt, dass er gegängelt wird. Nicht er muss sich aufwärmen, sondern eher der Referent/Autor. Aussagen über Aussagen, die man gleich machen wird, kann man quasi immer ersatzlos streichen. Der mündige Leser informiert sich anhand des Inhaltsverzeichnisses, wie der Gedankengang des Autors ist. Wenn ein Überblick nötig ist, dann aus der Sache heraus und nicht, weil es dir Form vorschreibt.

Ebenfalls kontraproduktiv finde ich 2 Seiten voll mit dem, was man in dem Buch nicht (!) findet. Zur Profilierung und um allzuübliche Missverständnisse zu vermeiden, mag es gelegentlich angezeigt sein, auch zu sagen, worum es nicht geht. Aber gleich zwei Seiten? Und das bei einem Buch, das laut Einband "umfassendes Wissen" verspricht? Wie kann denn da soviel nicht behandelt sein?

Dieser Gedanke bringt mich nun unweigerlich zur zentralen Frage: Wer ist denn überhaupt die Zielgruppe? Was beabsichtigt das Buch genau? "Umfassendes Wissen" klingt zwar toll, aber macht mich auch hellhörig und skeptisch, wie - trotz aller Reinigung - nicht anders zu erwarten nach meinem Blogposting zur Unsitte dicker Fachbücher. Auf Seite 40 geht es endlich mit dem wirklichen Thema los.  Abgesehen vom Inhaltsverzeichnis kann ich also 30 Seiten überschlagen, um den Einstieg in das "umfassende Wissen" zu bekommen. Aber an wen richtet sich das dann? Seite 24 gibt eine genauso knappe wie simple Antwort: "Diese Buch besitzt keine scharf abgegrenzte Zielgruppe". So einfach ist das. Meine 6jährige Tochter zähle ich zwar nicht zu dieser großen Gruppe, aber alle, die sich wohl irgendwie mit der Softwareentwicklung für mobile Geräte im weitesten Sinne beschäftigen, gehören zu ihr. Egal, ob der Leser also Vorkenntnisse im Bereich .NET hat oder nicht, egal, ob er Vorkenntnisse im Bereich .NET CF hat oder nicht, egal, ob er Datenbankvorkenntnisse hat oder nicht, sich mit ASP.NET auskennt oder nicht, Multithreading beherrscht oder nicht... er gehört immer zur Zielgruppe.

Das (!) halte ich für den wesentlichen Fehler dieses wie vieler anderer dicker Bücher. Wer in die Zielgruppe so groß fasst, das er Schwierigkeiten hat, sie einzugrenzen, der hat keine und der weiß daher auch nicht, was ins Buch gehört und was nicht. Eine Zielgruppendefinition ist ein Maßstab, an dem man misst, ob Themenaspekte beschrieben werden sollten oder nicht. Er ist die Latte, auf der abgelesen werden kann, in wecher Art und welcher Tiefe Wissen vermittelt werden sollte. Ohne einen solchen Maßstab aber gilt: anything goes. Und das drückt sich im Inhalt aus und kann im Grunde schon aus dem Inhaltsverzeichnis. Es fehlt die thematische Kontur. Die aber ist nötig, denn der Buchtitel ist zu breit, als dass er angesichts dessen, was so ganz allgemein darunter fallen könnte, genügend Kontour böte.

Warum haben weder Autoren noch Verlag den Mut gehabt, eine Zielgruppe zu definieren? Sie hätten sich an erfahrene .NET-Programmierer wenden können, denen sie die Besonderheiten des .NET CF aufzeigen. Das Buch hätte sich dann auf die Beschreibung einer Differenz zwischen zwei sehr ähnlichen Plattformen konzentrieren können. Die Darstellungen hätten dann alle sehr tief gehen können, weil viel grundsätzliches Vorwissen in der Leserschaft einfach vorhanden gewesen wäre. Oder man hätte den Plattformeinsteiger adressieren können, den C/C++-Entwickler, der bisher schon im embedded/mobile Bereich gearbeitet hat und jetzt auf den .NET CF umsatteln will. Dann wäre klar gewesen, dass keine Differenz, sondern Grundlegendes vermittelt werden müsste. Tiefe wäre dann nicht nötig, sondern Überblick. Oder Autoren und Verlag hätten Entwickler angesprechen können, die schon Erfahrung mit dem .NET CF haben, um ihnen Best Practices aufzuzeigen. Grundlegendes und Differenzen wären dann unwichtig gewesen; stattdessen wäre es um Tiefe und Erfahrungswerte gegangen.

In der gegenwärtigen Form holt das Buch aber nicht wirklich die Leser ab. Aus Verlagssicht mag das noch einen gewissen Charme haben, denn für ein Buch, das sich an alle wendet, ist jeder vor dem Regal ein potenzieller Käufer. Wer beim Lesen jedoch hinter das Themensperrfeuer blickt, der kommt nicht umhin festzustellen: Wer alles für alle sein will, ist am Ende nichts für niemanden. Dafür ein paar Beispiele:

Wem nützt das Kapitel über "Die Geschichte von Mobile Computing"? Die Idee dahinter ist verständlich und es hätte ein interessanter Rückblick auf die embedded/mobile Softwareentwicklung dabei herauskommen können. Die Geschichte, also das Vergangene beschränkt sich jedoch auf knapp 4 Seite von 20 des Kapitels. Die Darstellung muss also notwendig oberflächlich sein. So ist denn auch nichts über seinerzeit hochgepriesene Technologien wie Auto-PC, den PC in der Uhr (SPOT Produkte) oder die ersten Tablet-PC Versuche Anfang der 1990er zu lesen. Auch vermisse ich in diesem Zusammenhang eine visualisierte Entwicklungsgeschichte der Microsoft Entwicklungsplattform für embedded/mobile Geräte zusammen mit ihren Betriebssystemgeschmacksrichtungen. Das alles hätte sinnvoll Platz gehabt in einem geschichtlichen Abriss. Stattdessen bietet die Geschichte auf 15 Seiten den Versuch einer Darstellung der Gegenwart einiger Windows Mobile Komponenten wie Internet Explorer oder ActiveSync. Und abschließend wird das Für und Wider mobiler Anwendungen vs. Web-Anwendungen diskutiert. Was hat das mit Geschichte zu tun? Das gehört in ein Architekturkapitel.

Wem nützt das Kapitel "Die .NET-Plattform als Basis für Mobile Computing"? Hier könnte man eine Diskussion darüber erwarten, warum eine standardisierte Managed Code Plattform einen Vorteil für die Entwicklung mobiler Anwendungen hat. Warum nicht C++, warum aber auch nicht Java? Angesichts einer nicht definierten Zielgruppe ist es aber den Autoren natürlich schwer gefallen, ein klares Niveau der Darstellung zu finden. So schwankt man zwischen kurzer Abhandlung von grundlegend Konzeptionellem wie der Überwindung der DLL-Hölle durch .NET und mehrseitiger Erklärung für ein Implementatiosndetail wie Namensräume. Daran schließen sich dann 7 Seiten Schnelldurchlauf von allgemeinen Anwendungsarchitekturschlagworten wie "Präsentationsschicht" und "Verteilte Anwendungen" an, um von 7 Seiten Ausführungen zu "XML-Webdienste[n]" gefolgt zu werden. Da gibt es dann auch hübsche PDA-Emulatorscreenshots zu sehen und auch Code, sogar SQL-Skripte zur Einrichtung eines SOAP-Endpunktes im SQL Server 2005.  Ganz am Ende widmet sich das Kapitel dann noch auf 3 Seiten dem .NET Compact Framework mit einem Schaubild und einer Liste der Unterschiede zum .NET Framework. Aber was hat das nun alles in Bezug auf das Kapitelthema gebracht? Hat ein in Sachen .NET unbedarfter Leser etwas über den .NET Framework erfahren können? Nein. Dafür hätte die Darstellung der .NET-Grundlagen breiter sein müssen. Ein Unbedarfter hätte nach einer so kurzen Einführung dann aber auch mit den folgenden Ausführungen nichts mehr anfangen können; sie wären zu speziell gewesen. Hat sich das Kapitel also an den erfahrenen .NET-Entwickler gewandt? Warum dann ein Ausflug in die Grundlagen? Und warum das Thema Architektur? Hat es speziell etwas mit Mobile Computing zu tun? Kann man die Grundbegriffe nicht ohnehin voraussetzen, unabhängig davon, ob der Leser schon Erfahrung mit dem .NET Framework hat oder nicht? Selbst ein VB6- oder Java-Entwickler wird nicht umhin gekommen sein, vom Schichtenmodell gehört zu haben. Und mehr als eine ganz flüchtige Einführung hat das Kapitel hierzu auch nicht gegeben. Sie ist daher überflüssig. Die originären Vorteile von .NET für das mobile Computing hingegen sind nicht wirklich herausgearbeitet worden. Von knapp 30 Seiten des Kapitels beschäftigen sich nur 3 wirklich mit ihm.

Wem nützt das Kapitel "Vorbereitung auf die Entwicklung für mobile Geräte"? Das wird mit dem "Aufbau von .NET Compact Framework" begonnen - ein Thema, das ich im vorhergehenden Kapitel erwartet hätte -, um nach einem Dutzendschaubild im Vorbeigehen AppDomains auf 1 Seite einzuführen und dann 3 Seiten lang die Garbage Collection zu thematisieren. Anschließend eine halbe Seite zur Sicherheit - und das war´s.  Jetzt soll der Leser wissen, wie der .NET CF aufgebaut ist. Denn es folgen als "Neuerungen im .NET Framework 2.0" nur Generics - was ist mit all den anderen Neuerungen? - und dann in einer Tabelle "Neues im .NET Compact Framework 2.0". An wen hat sich dieser Abschnitt gewandt? Anfänger haben nichts über den .NET Framework oder CG gelernt. Fortgeschrittene .NET Entwickler ohne Erfahrung mit dem .NET CF auch nicht. Weiter gehts mit einer Vorstellung von VS2005: 1 Seite Informationen wie aus einer Marketingbroschüre, dann die Information "Das Visual Studio ist eine IDE [...]". Dann 5 Seiten mit Neuerungen in VS2005 - die zumindest z.B. für unbedarfte C++ embedded Software Entwickler mit Umstiegswille, die ja auch zur Zielgruppe gehören, nichts bringen. Warum sollte auch ein Buch zum Thema .NET CF auch nur ein Wort über das Refactoring oder CodeSnippets in VS2005 verlieren? Aber jetzt... es ist kaum zu glauben, auf 3 Seiten geht es wirklich um spezifische Aspekte des mobile Computing rund um mobile Device Emulatoren. Wie sich die Arbeit mit einem Emulator aber gestaltet... davon ist hier nicht die Rede. Aber vielleicht kommt das ja im nächsten Kapitel. Hier sollen ja auch nur Vorbereitungen behandelt werden. Zu denen gehört sicherlich auch ganz dringend Lutz Roeders Reflector und NUnit. Und das war´s. Fertig mit der Vorbereitung. Aber was habe ich gelernt? Nichts. Ich fühle mich nicht auf die "Entwicklung für mobile Geräte" vorbereitet. Weder kenne ich jetzt den .NET CF, wenn ich ihn vorher noch nicht kannte. Noch habe ich eine Ahnung, wie ich ein Programm für ein mobiles Gerät in VS2005 schreibe und im Emulator ausprobieren kann. Dier Prozess - so einfach er sein mag - ist nicht mit einem Beispiel demonstriert worden.

Wem nützt das Kapitel "Einführung in die Entwicklung für mobile Geräte"? Ah, da kommen jetzt mal die Projektvorlagen für Geräteanwendungen vor.  Aber nach noch nicht einmal 2 Seiten geht es um Details des WinForms-Designers wie den Gebrauch von partiellen Klassen gleich neben der Abbildung der Eigenschaften eines Buttons. Wen will man damit erreichen? Wer nichts über partielle Klassen weiß, lernt hier nichts. Eine Entschädigung könnten eventuell allerdings die 1,5 Seiten darstellen, die dem Deploymentprozess eines Hello-World-Programms in einen Emulator hinein gewidmet sind. Aber dann hat es sich auch mit dieser Besonderheit der .NET-CF-Programmierung. Es folgen knapp 20 Seiten mit der Vorstellung von Benutzersteuerelementen wie Label, TextBox, TreeView usw. Ein Nutzen ist dabei leider nicht zu erkennen. Weder findet hier eine Gegenüberstellung der Eigenschaften dieser Steuerelemte mit ihren Pendants beim .NET Framework statt, noch wird wirklich erklärt, wie die Steuerlemente zu nutzen sind. Den Abschluss des Kapitels bilden 6 Seiten eines vielversprechenden Themas: "Hybride Anwendungen". Es ist der Frage gewidmet, ob und wie Anwendungen möglich sind, die sowohl auf dem .NET Framework, d.h. Desktop Rechnern, wie auch auf dem .NET CF, d.h. mobilen Geräten, laufen. Das (!) ist nun wirklich mal ein Thema, das zum Titel des Buches passt und auch jeden Leser interessieren sollte. Leider empfinde ich die Behandlung als oberflächlich und unvollständig. Einziges Thema sind WinForms-Benutzeroberflächen. Was ist aber mit ASP.NET-Seiten, die sowohl hüben wie drüben angezeigt werden sollen? Oder welche Teile des .NET Framework sollte man nicht einsetzen, um portabel zu sein? Wie wäre es mit einem Hinweis zur Architektur von hybriden Anwendungen? Nicht nur, dass das Thema besser ans Ende des Buches gepasst hätte, weil es eigentlich die Kenntnis beider Plattformen voraussetzt, die Autoren schweigen auch zu diesen selbst für mich als .NET-CF-Laie auf der Hand liegenden Fragen. Fühle ich mich am Ende des Kapitels nun eingeführt in die Entwicklung für mobile Geräte? Nein. Die Spezifika von mobilen Geräten wurden nur im Vorbeigehen behandelt und die Darstellung hat sich auf Oberflächliches im doppelten Sinn beschränkt: Allereinfachstes wurde für WinForms-GUIs besprochen.

Wem nützt nun das Kapitel "Erweiterte Möglichkeiten bei der Entwicklung für mobile Geräte"? Schon der Titel lässt vermuten, dass es hier, hm, sehr allgemein zugehen wird. Von "Möglichkeiten" ist immer die Rede, wenn ein konkreterer Begriff grad fehlt. Und unter "erweiterte Möglichkeiten" passt dann wirklich alles, was irgendwie noch nicht gesagt wurde. Doch dann die Überraschung: Laut Inhaltsverzeichnis, das jeweils auch noch auf "Kapiteltitelblatt" aufgeführt ist, behandelt das Kapitel nur ADO.NET. Warum hat man es dann nicht "Datenbankprogrammierung mit dem .NET CF" genannt oder "ADO.NET für .NET CF"? Weil das nächste Kapitel schon so ähnlich heißt? Vielleicht. Vielleicht aber auch, weil man noch viel mehr für dieses Kapitel vorhatte, dann aber die Zeit nicht mehr reichte? Ich weiß es nicht. In jedem Fall beschränken sich die "Erweiterte[n] Möglichkeiten" auf ADO.NET. Auf 20 Seiten wird eine Einführung in den Datenbankzugriff mit ADO.NET versucht von der Connection bis zum Databinding. Eine Erklärung, was es früher mit COM auf sich hatte, gibt es als Bonus noch dazu - ohne das ich wüsste, was das nun hier soll. (Interessanterweise taucht diese "Definition" im Index auch gar nicht auf.) Darüber hinaus ist es immer schlecht, wenn eine Definition des Definierten (hier: COM) folgt. Das ist hier aber der Fall. Auf COM wurde schon mehrfach angespielt (z.B. im Zusammenhang mit der DLL-Hölle). Aber weiter mit ADO.NET. Was soll diese Darstellung? Wer ADO.NET noch nicht kannte, kann durch sie nicht wirklich lernen, was das Besondere an ADO.NET ist. Und wer es schon kannte... der konnte nichts dazu lernen. Ein schlicht überflüssiges Kapitel.

Wem nützt das Kapitel "Programmierung von Datenbanken für mobile Anwendungen"? Es mutet zunächst an wie eine Marketingbroschüre für den SQL Server 2005. Da ist von Enterprise Data Management und Business Intelligence die Rede. Da steht ein Dialog zum Aufbau einer Verbindung mit dem SQL Server nur 2 Seiten entfernt von einer SQL CLR Funktion. Dann 6 Seiten zum Thema OLAP, die nichts mit mobile Computing zu tun haben. Und jetzt... 35 (!) Seiten zum Thema "Eine mobile Datenbank-Anwendung". Wow! Da geht es richtig zur Sache mit Synchronisationsmechanismen. Das (!) ist relevant für mobile Computing. Die Anwendung, um die es laut Überschrift aber gehen soll, findet sich kaum beschrieben. Es geht im Grunde nur um Infrastruktur, der Rest ist auf der Buch-CD zu finden. Das finde ich schwach. Es überlässt dem Leser den Aufbau eines Kontextes, in dem die ganzen Infrastruktureinrichtungen erst Sinn ergeben. Didaktisch schlecht. Hier wäre ein Motivation am Anfang mit einem Überblick angezeigt gewesen nach dem Motto "Was wir machen wollen und was wir dafür benötigen und wie wir dann vorgehen werden".

Nach 233 Seiten bzw. knapp einem Drittel des Buches erlaube ich mir, seine Analyse nun abzuschließen. Für den Rest schaue ich nocheinmal ins Inhaltsverzeichnis:

Der Umgang mit dem Dateisystem wird auf knapp 20 Seiten beschrieben inkl. der Behandlung von kommaseparierten Dateien. Das grundlegende Stream-Konzept findet hier allerdings keine Erwähnung. Das finde ich verwunderlich. Welchen Eindruck soll ein Neuling von den Fundamenten des .NET Framework da bekommen?

Für die Entwicklung von "Multithreading-Anwendungen" stehen knapp 40 Seiten zur Verfügung. Ein sicherlich wichtiges Thema, das ich allerdings nicht so konkret im Zusammenhang mit mobilen Anwendungen sehe. Sicher können und sollen dort auch mehrere Threads zum Einsatz kommen. Aber muss dem Thema im Vergleich zu anderen, die eine größere Zahl von Entwicklern betreffen, soviel Raum gegeben werden?

"Zugriff auf Netzwerke" umfasst knapp 40 Seiten und behandelt von GPRS über MSMQ und AJAX bis zu Bluetooth scheinbar alles, was irgendwie mit Kommunikation zu tun hat. Außer Webservices, die ja schon viel früher einmal dran waren und auch bei XML nochmal einen Kurzauftritt hatten. Überprüfung des Headsets und XML-Dateninseln scheinen auch irgendwie mit Kommunikation zu tun zu haben, denn darum geht es auch in diesem Kapitel. Eine eigenwillige Mischung.

Emulatoren und Unit Tests sind auf 30 Seiten zusammengefasst. Einen groben Zusammenhang kann ich da erkennen, aber für wirklich geglückt halte ich die gemeinsame Abhandlung nicht. Ohne Emulatoren geht es nicht. Aber Unit Tests sind "lediglich" eine Best Practice.

Auf 40 Seiten kommt dann doch auch noch endlich das Thema Deployment zur Sprache. Warum es aber nicht am Ende des Buches steht, sondern danach noch Multimedia-Techniken folgen... das verstehe ich nicht.

Fazit

Ich habe das Buch nicht Seite für Seite gelesen. Ich möchte ihm, den Autoren und dem Verlag auch kein Unrecht tun. Dennoch glaube ich, dass die ausführlicheren Kapitelschilderungen - pars pro toto - die Qualität des Buches treffend beschreiben. Es ist gut gemeint, hat grundsätzlich bestimmt einen Markt - mobile Computing ist gefragt und wird immer gefragter -, aber es leidet unter Konzeptlosigkeit. Das Konzept, allen etwas zu bieten, ist kein tragfähiges Konzept. Allemal nicht, wenn dieser Anspruch dann so unsystematisch umgesetzt wird wie hier. Es fehlt das Gefühl, was wichtig und was unwichtig ist. Auf der einen Seite werden weitgehend irrelevante Schlagworte abgehandelt, auf der anderen Seite offensichtlich Relevantes nicht behandelt. Insbesondere die fehlende Definition von Voraussetzungen - was auf Seite 27 gelistet wird, ist wenig hilfreich - zeigt sich immer wieder. Sie führt zur Behandlung von Themen, die entweder nicht behandelt werden müssten oder die zu flach behandelt werden. So verpufft der Aufwand und bläht das Buch nur unnötig auf.

Mein Gefühl ist, dass hier drei Autoren mit sehr gutem Willen ein wichtiges Thema angegangen haben - aber in der Durchführung am Mangel einer klaren Vision wie auch an einer zu wenig koordinierten Verschiedenheit ihrer Interessen gescheitert sind. Das Buch sagt sicherlich auch Gutes und Richtiges, doch das ist versteckt im Rauschen des Überflüssigen. Schade.

Letztlich fühle ich mich aber dadurch in meiner These bestätigt. Das ist zwar nicht wirklich mein Ziel gewesen, aber trotz aller Reinigung komme ich nun doch nicht drumherum. Das Buch ist zu dick. Auf das wirklich Wichtige gekürzt und mit in einigen Bereichen verbesserter Darstellung könnte es mit vielleicht 350 Seiten gut sein - vorausgesetzt, eine Zielgruppe wird klar definiert.

Sorry, Torsten.

PS: Mein Urteil mach sich nun besonders schlimm anhören, weil ich hier ein Buch herausgegriffen habe. Zur "Milderung der Umstände" sei aber gesagt, dass viele Fachbücher in der Softwareentwicklung unter denselben Symptomen leiden: interessantes Thema, gute Idee - aber schlechtes Konzept und mangelnde Struktur/didaktische Schwäche. Es ist eben schwer, ein Buch zu schreiben. Und je dicker, desto schwerer. Aus das ein Grund, warum ich gegen dicke Fachbücher sind. Sie gehen soviel leichter daneben.

PPS: Ich habe übrigens grad neulich ein Buchprojekt wieder abgesagt, das ich angeleiert hatte. Der Grund: Ich war mir der Struktur und Didaktik nicht mehr so sicher wie zum Zeitpunkt der Idee. Das Thema ist weiterhin wichtig und ich schreibe auch darüber. Aber angesichts unerwarteter Hürden in der Technologie, konnte ich die Struktur noch nicht genügend gut festlegen, weil ich die Puzzleteile noch nicht alle im Blick habe. Also schreibe ich lieber (erstmal) kein Buch, als eines, bei dem ich mich so durchs Thema laviere.

 

Technorati tags:

7 Kommentare:

Anonym hat gesagt…

Hi Ralf!

Wieso "Sorry Torsten"? Mir ist ungeschminktes Feedback um Längen lieber, als anders herum. Kann man sich nicht nur so verbessern? Be the fly on the wall.

Daher also: Vielen Dank Ralf für das wertvolle Feedback. Gerade die ersten Kapitel sind tatsächlich nicht ganz glücklich geschrieben geworden. "Erweiterte Möglichkeiten" sollte tatsächlich kein ADO.NET-Kapitel sein, ist es aber geworden. Das "Sicherheit"-Kapitel ist zu kurz geraden und zu wenig fokussiert. An einigen Stellen, da hast du völlig Recht, sind wir nicht zu fokussiert bzw. der konzeptionelle Aufbau passt nicht ganz. Viele Beispiele rein, passt auch nicht immer. Auch finden sich ein paar Schönheitsfehler – wie z. B. „blau abgebildet“ in einem Schwarz-Weis gedrucktem Buch, die erstaunlicherweise durchs Fach-/Lektorat gegangen sind.

Vielen Dank für das wertvolle Feedback an vielen Stellen, es fließt in eine weitere mögliche Auflage und zwei weitere Bücher ein.

Viele Grüße!

Torsten

Ralf Westphal - One Man Think Tank hat gesagt…

@Torsten: Freut mich, dass du auch nach meinem Verriss noch guter Dinge bist.

Wenn die ersten 7 Kapitel anders sind als die weiteren und ich dem Buch damit Unrecht getan haben sollte, täte mir das leid. Aber ich hab einfach nicht mehr gekonnt. Und nach einem Drittel des Buches sollte ich auch annehmen können, dass das Gelesene schon repräsentativ für das Ganze ist. Besser wäre aber vielleicht doch noch gewesen, statt 7 Kapitel vom Anfang her zu nehmen, vielleicht nur 4 in der Reihenfolge zu betrachten, so wie es ein Leser tun würde, und dann 3 zufällig und aus der Reihe anzuschauen.

Aber einerlei. Ich denke nicht, dass sich mein Urteil wesentlich ändern würde, hätte ich mir das Sicherheitskapitel näher angesehen, das du selbst für zu kurz und zu unfokussiert hälst, oder Kapitel 15 über Emulatoren & Co, in dem nicht mal nebeneinandergestellte Abbildungen der verschiedenen Emulatoren zu finden sind, geschweige denn eine Tabelle mit den unterschiedlichen Displaygrößen z.B. bei PDA oder SmartPhone.

Unterm Strich muss ich leider sagen: Das Buch hätte nicht veröffentlicht werden sollen. Die Qualitätssicherung des Verlages hätte schon früh im Produktionsprozess, d.h. während der Manuskripterarbeitung, Stopp rufen müssen, weil klar sein musste, dass hier keine Einheitlichkeit und kein Fokus entstehen würde.

Nicht nur die Schönheitsfehler bei den Abbildungen, sondern vor allem strukturelle/didaktische Schwächen sind es immer wieder, die von den Verlagen nicht erkannt werden. Dabei wäre das (!) ihre vornehmste Aufgabe: Expertenwissen so an die Hand zu nehmen, dass etwas wirklich Lesbares und Nützliches herauskommt. Bücher drucken kann jeder. Aber die "Hebammenkunst des Wissens", die Arbeit mit und an den Autoren zu hoher inhaltlicher Qualität... die ist zumindest in unserer Branche Mangelware. Schade.

Aber wahrscheinlich müssen wir uns hier alle nur an die eigene Nase fassen. Verlage sind auch nur "Lebewesen" und lavieren sich durchs Leben. Sie tun das, was passt, was sie überleben lässt, nicht das, was "gut" ist. Und wenn es halt passend genug für den Markt, die Leserschaft, also uns ist, was sie da so produzieren... dann geben wir ihnen nicht genug Feedback.

Verlage befragen Leser ja nicht, ob ihnen ein Buch gefällt. Sie machen keine "Testscreenings". Oder wenn, dann so spät, dass sie eh nichts mehr großartig ändern lässt.

Ihr einziges Feedback ist der Umsatz. Auch du hast mir ja gesagt, euer Buch sei bald ausverkauft und hast damit signalisieren wollen: Das ist Buch ist gut. Denn was fast ausverkauft ist, kann doch nicht schlecht sein, oder?

Nun, es gibt viele Gründe, warum sich ein Buch häufig verkauft. Das kann schlicht an seiner Qualität liegen. Sorry to say, aber das glaube ich bei eurem Buch nun leider nicht mehr. Es kann am Titel liegen, der bei euch sicherlich viele anspricht. Es kann an der mangelnden Konkurrenz liegen. Könnte bei euch auch der Fall sein. Es kann an seinem gewichtigen Auftreten liegen (Universalanspruch). Ist bei euch auch so. Es kann am Buchhandel und Verlagsvertrieb liegen, die einen Titel anders platzieren als andere zum gleichen Thema.

Ab der 2. oder 3. Auflage mögen die Verkaufszahlen tatsächlich mit der Qualität korrelieren. Vorher jedoch halte ich sie für wenig aussagekräftig. Das bedeutet: Bei einer Erstauflage bekommen weder Verlag noch Autoren in den meisten Fällen mit, ob ein Buch gut ist oder nicht. Und das bedeutet wiederum: Weder Verlag noch Autoren können lernen, es besser zu machen.

Sehr schade. Denn das kostet viele Leser jedes Jahr viel Geld. Hm... vielleicht sollten wir alle deshalb öfter ausführlicher Bücher rezensieren. Das gäbe mehr Feedback. Insbesondere negative Rezensionen - wo nötig - wären dann wertvoll. Denn die sparen potenziellen Lesern Geld und geben konkrete Hinweise, wo noch Verbesserungsbedarf ist. Rezensionen, die einfach nur "durchwinken", sind dagegen langweilig ;-)

Na, mal schauen... Vielleicht mache ich mir die Mühe der öffentlichen Rezension ja in Zukunft öfter. Eine Buchhandelskette hatte mich darum schon länger gebeten. Aber die wollten wahrscheinlich auch eher Empfehlungen von mir hören ;-)

-Ralf

Anonym hat gesagt…

Hi Ralf.

"Ihr einziges Feedback ist der Umsatz. Auch du hast mir ja gesagt, euer Buch sei bald ausverkauft und hast damit signalisieren wollen: Das ist Buch ist gut. Denn was fast ausverkauft ist, kann doch nicht schlecht sein, oder?"

Nein, dass wollte ich nicht signalisieren, sondern nur, dass es vom Markt gut aufgenommen wird. Da habe ich mich sicherlich verkehrt ausgedrückt. Zitat: "Ich weiß nicht genau ob es daran liegt, dass es ein Leitfaden, sozusagen eine Anlaufstelle für weiterführende Informationen zu Mobile Computing ist, oder an etwas anderem, dass es sich sehr gut verkauft."

Genau deswegen möchte ich soviel wie möglich ungeschminktes Feedback und Ideen. Du hattest eine, die ich immer bei meinen Artikeln praktiziere, die wohl vom Feedback / Rezension her exzellent sind. Den "Hausfrauen"-Test. Lass es lange vor Abgabe nicht von Domänenexperten, sondern vom Zielpublikum lesen. Beim Buch hatte ich großartige Unterstützung (Danke erneut an Alexander Groß), aber den "Hausfrauen"-Test habe ich hier tatsächlich nicht durchgeführt.

Wie gesagt, Danke für das Feedback, die nächste Auflage und Bücher (in der ersten Auflage ;) ), werden auch daran ausgerichtet.

Viele Grüße!

Torsten

Anonym hat gesagt…

Kurzer Detailhinweis: Leser ohne DSL-Flatrate (und die gibt es auch unter Entwicklern) wissen eine CD in einem Buch sehr wohl zu schätzen.

Ralf Westphal - One Man Think Tank hat gesagt…

@Volkmar: Hier wie auch sonst ist, so denke ich, eine Abwägung durchzuführen. Wieviele Entwickler haben eine Flatrate und wieviele nicht?

Und ich würde sagen: Die große Mehrheit hat eine Flatrate. Da ist es dann schlicht eine Kostenfrage für den Verlag, ob er die wenigen, die keine haben, mit einer CD beglücken muss.

Die Welt dreht sich. Und wer heute als Entwickler keine Flatrate hat, der hat sich schlicht von der Informationsquelle Nr. 1 abgeschnitten. Sorry to say. Ich wäre im Zweifel, ob ich mit ihm als Dienstleister arbeiten wollte.

-Ralf

Ralf Westphal - One Man Think Tank hat gesagt…

@Volkmar: Mein Zögern, ob ich mit einem nicht per Flatrate erreichbaren Entwickler arbeiten möchte, bezieht sich natürlich nicht auf seine Qualifikation.

Qualifikation ist aber nicht alles. Zur modernen SW-Entwicklung gehört daneben auch Kommunikativität. Und die ist ohne Flatrate in jeder Hinsicht heute begrenzt.

Weder kann sich ein Entwickler ohne Flatrate und schnelle Internetverbindung gescheit im Internet informieren - ich müsste also auch an der Aktualität seines Wissens zweifeln -, noch kann ich mit ihm zwanglos online konferieren (IP-Telefonie, shared Desktop).

Das halte ich heute aber für Vorbedingungen, um produktiv zu sein.

Aber... das ist natürlich nur meine unmaßgebliche Meinung als "digitaler Nomade", der gerade in einem Zug unterwegs und per UMTS online ist.

-Ralf

Anonym hat gesagt…

...also das technologische Aus für alle tausende Entwickler, die in einem Nicht-DSL-Gebiet wohnen?!
Sorry, Diskussionen und Entwicklungen kann (okay, konnte: seit 2007 DSL) ich auch per Modem verfolgen, über ersparte Downloads freu(t)e ich mich doch - und noch funktionieren Telefone auch per Kabel ;-)

Hmm, kein "digitaler Nomade" - also "digitaler Bauer"? Und wenn: ist das nun schlecht?

Kommentar veröffentlichen

Hinweis: Nur ein Mitglied dieses Blogs kann Kommentare posten.