Archiv

Archiv für die Kategorie ‘webRead’

Buch-Rezension zu “HTML5 and CSS3 (2nd edition)”

26. März 2014 2 Kommentare

HTML5 and CSS3HTML5 und CSS3 sind in aller Munde. Wo man auch hin sieht findet man schöne Beispiele die mit den neusten Browser-Versionen wunderbare Möglichkeiten bieten. Was aber macht man wenn die eigenen Seitenbesucher noch mit IE 8 unterwegs sind? Verzichtet man auf diese Möglichkeiten? Oder bastelt man eine Umgehungslösung?

Brian Hogan lieferte mit seinem Buch “HTML5 and CSS3” ein praxisbezogenes Handbuch um auch in solchen Situationen zu bestehen. Er beschreibt leicht verständlich den aktuellen Stand der HTML5 Spezifikation und wie man diesen in die eigene Webseite integriert. Dabei legt er sehr grossen Wert auf die Abwärtskompatibilität und erklärt eingehend wie man mittels Modernizr ein vergleichbares Verhalten auch für ältere Browser anbieten kann.

Seine Beispiele haben mir sehr geholfen um mich ins Thema HTML5 einzuarbeiten. Da diese nur genau das jeweils besprochene Feature behandeln musste ich nicht lange den Code nach den richtigen Anweisungen durchsuchen. Dies ist vor allem beim erweitern der eigenen Webanwendung sehr hilfreich. Da hat man meistens nicht Zeit um zahlreiche Beispiele nochmals nachzuvollziehen nur um die 2-3 Zeilen Code zu finden, die einem noch fehlen. Wer sich selber von den Beispielen überzeugen will findet diese bei PragProg.com.

Wer allerdings noch nie etwas mit HTML gemacht hat wird mit diesem Buch nicht glücklich. Dies ist definitiv kein Einsteigerbuch sondern richtet sich an Leute die über Erfahrung mit HTML 4 verfügen und möglichst auch schon jQuery verwendet haben. Erfüllt man diese Voraussetzungen führt aus meiner Sicht kein Weg an diesem Buch vorbei.

 

Fazit

Weder ist HTML5 nur unnötiger Schnickschnack noch braucht man zwingend den neusten Browser. Mit ein wenig Rücksichtnahme kann man sehr wohl die neuen Möglichkeiten von HTML5 und CSS3 auch für “richtige” Web-Anwendungen nutzen.

Das Buch von Brian Hogan liefert einem die nötigen Grundlagen um ohne grosses googeln loszulegen. Da seine Beispiele sehr praxisrelevant sind eignen sie sich auch gut um den eigenen Code darauf aufzubauen. So kann man schnell erste Ergebnisse erzielen und schrittweise die eigenen Anwendungen Richtung HTML5 weiterentwickeln.

 

Zum Buch

HTML5 and CSS3 (2nd edition)” von Brian P. Hogan, 2013 The Pragmatic Programmers, ISBN 978-1-9377-8559-8, 300 Seiten, Englisch

Schlagworte: , ,

Buch-Rezension zu “Code Complete 2nd Edition”

4. März 2014 Kommentare aus

Code Complete 2nd editionCode Complete – A Practical Handbook of Software Construction (2nd edition)” von Steve McConnell gilt als Standardwerk das man unbedingt gelesen haben muss. Es behandelt alle wichtigen Themen der Softwareentwicklung und gewann zahlreiche Preise.

Nach langem fand ich doch noch die Zeit um dieses Buch zu lesen. Allerdings fragte ich mich sehr bald ob die Empfehlungen auf Amazon vom gleichen “Code Complete” handeln. Entgegen der weit verbreiteten Meinung hatte ich kein praktisches Handbuch vor mir, sondern die ausführlichste Auflistungen von Studien die ich je gesehen habe. Nach zahlreichen weiteren Entdeckungen kann ich von diesem Buch nur abraten.

 

Solider 1. Eindruck

Liest man das Inhaltsverzeichnis durch sieht man dass alle wesentlichen Teile der Erstellung von Software in diesem Buch behandelt werden. Wie McConnell im Vorwort schreibt geht es ihm um eine ausgewogene Diskussion und nicht um Hype. Dies tönt vielversprechend und durchs ganze Buch hinweg untermauert er seine Aussagen mit Studien.

Die zahlreichen Diagramme helfen einem beim Verstehen der gerade vorgestellten Ideen und die Checklisten sind ein guter Ausgangspunkt um die gewonnenen Erkenntnisse im eigenen Code umzusetzen.

Versucht man allerdings mit dem Buch zu arbeiten bemerkt man schnell die ersten Probleme.

 

Genauer hingeschaut

Die objektive und ausgewogene Diskussion erreicht McConnell durch das Referenzieren von Studien. Über die ersten Kapitel hinweg erweckt dies einen sehr professionellen Eindruck. Bis man feststellt das McConnell einen Artikel eines gewissen “McConnell, S.” zitiert. Einen eigenen Artikel zu zitieren ist ja kein Problem, doch sollte man auf diesen Punkt hinweisen. Dies wäre besonders wichtig wenn es sich um ein eher kontroverses Thema handelt und der eigene Artikel der einzige Text ist der die eigene These stützt.

Richtig interessant wird es aber erst wenn die einzige Studie zu einem Thema unübersehbar falsch ist. Auf Seite 518 werden die Fehlerarten gemäss der Studie von Boris Beizer von 1990 aufgeführt. Es wurde dabei so genau gearbeitet dass die Prozentwerte auf 2 Nachkommastelen genau ausgewiesen werden. Dies obwohl die Studie nur die Resultate anderer Studien kombinierte und deren Werte mehr als 50% voneinander abweichen. Auf all diese Fehler weist McConnell explizit hin. Seine Schlussfolgerung daraus ist, die Werte mögen so nicht stimmen aber die Richtung ist in Ordnung. Er verwendet diese Werte danach um seinen Punkt zu beweisen – allerdings ohne die Nachkommastellen…

Wenn man so mit Studien arbeitet kann man auch gleich darauf verzichten. Dieses Beispiel ist das offensichtlichste, allerdings gibt es noch zahlreiche weitere Stellen wo die Resultate so lange verdreht werden bis der gewünschten Punkt „bewiesen“ ist.

 

Zu kurz

Obwohl das Buch rund 960 Seiten hat ist es viel zu kurz um die Fülle an Themen auch wirklich zu erklären. Lässt man das Vorwort, den Anhang, die einzelnen Verzeichnisse, die Checklisten und die Zusammenfassungen weg bleiben für jedes der 35 Kapitel nur noch 20 Seiten übrig. Das reicht in der Regel nur um das jeweilige Thema kurz anzuschneiden.

Besonders deutlich wird dies beim Kapitel “Refactoring“. Die Gründe für Refactoring werden von McConnell sehr gut dargelegt, gleiches gilt für mögliche Strategien. Wie man allerdings den eigenen Code umbauen soll bleibt unklar. Zu mehr als 2-3 Sätzen pro Refactoring-Technik reicht der Platz in diesem Kapitel nicht. Der Praxisnutzen ist dementsprechend gering und das Vorgehen für Refactorings erschliesst sich nur den Lesern, die den zu vermittelnden Inhalt bereits kennen. Da könnte man das Kapitel eigentlich gleich ganz weg lassen.

Leider ist dieser Platzmangel nicht auf ein Kapitel beschränkt sondern zieht sich durchs ganze Buch.

 

Wo es gefährlich wird

Der lockere Umgang mit Studien und der zu knappe Platz um ein Thema wirklich zu erklären birgt ein grosses Gefahrenpotential. Dies wird besonders bei den Kapiteln 25 und 26 deutlich, wo das Thema “Code-Tuning” behandelt wird.

Nach einem Hinweis über die Wichtigkeit von Messungen zu Beginn der Optimierung (Baseline) beginnt eine kaum enden wollende Reihe von Mikro-Optimierungen. Ist es schneller eine Schlaufe zum zuweisen der Array-Werte zu verwenden oder sollte man diese einzeln aufschreiben? Soll man bei verschachtelten Schlaufen zuerst über die innere oder über die äussere Schlaufe iterieren?
Zu all diesen Fragestellungen gibt es einen Codeschnipsel und eine Tabelle. Je nach Sprache und Problem variiert die Grösse der Einsparmöglichkeiten oder ist sogar negativ. Es fehlt einzig ein Hinweis wie diese Werte zustande kommen.

Erst nach gut 50 Seiten dieser Mikro-Optimierungen erklärt McConnell wie er diese Werte berechnet hat:

[For the first edition] I ran most of the tests in this chapter 10‘000 to 50‘000 times to get meaningful, measurable results. For this edition I had to run most tests 1 million to 100 million times. When you have to run a test 100 million times to get measurable results, you have to ask whether anyone will ever notice the impact in a real program.

Diese Fragestellung hätte McConnell zu Beginn des Kapitels aufwerfen müssen. So allerdings erklärt man den Lesern erst ausführlich wie gross die Unterschiede zwischen den einzelnen Varianten sind obwohl diese in der Realität keine Bedeutung haben.
In der Folge davon darf man in unzähligen Projekten grosse Diskussionen über die Reihenfolge von Schlaufen führen. Denn schliesslich hat McConnell ja gezeigt das dieser Ansatz 73% schneller ist…

 

Alternativen

Wer seine Lesezeit sinnvoller verwenden will sollte sich diese 3 Bücher anschauen:

Lässt man die Anhänge weg sind diese Bücher zusammen auch rund 960 Seiten lang. Allerdings werden hier die jeweiligen Themen praxisnah und verständlich beschrieben.

 

Fazit

Auf den ersten Blick ist “Code Complete” ein sehr gutes Buch mit zahlreichen interessanten Ideen. Betrachtet man es genauer sieht man sehr bald die vielen Unstimmigkeiten. Aus einer objektiven Darstellung wird so ein zurechtrücken von Studien und durch die vielen angeschnittenen Themen fehlt der Platz um einen wirklichen Praxisnutzen zu vermitteln.

Für Einsteiger ist dieses Buch dadurch nicht geeignet und durch die realitätsfremden Mikro-Optimierungen sogar gefährlich. Und wer sich mit der Thematik bereits auskennt wird kaum etwas Neues finden. Statt “Code Complete” liest man besser die 3 alternativen Bücher, da hat man am Ende auch etwas mit Praxisbezug gelernt.

 

Zum Buch

Code Complete – A Practical Handbook of Software Construction (2nd edition)” von Steve McConnell, 2004 Microsoft Press, ISBN 978-0-7356-1967-8, 960 Seiten, Englisch

 

Schlagworte: , ,

5 Bücher die jeder Software-Entwickler kennen sollte (Ausgabe 2014)

7. Januar 2014 2 Kommentare

Vor gut 1.5 Jahren habe ich bereits einmal eine Top 5 Liste mit Büchern veröffentlicht. Seither habe ich viel gelesen und es ist daher höchste Zeit die Leseempfehlungen zu aktualisieren.

Ich versuchte wiederum eine möglichst technologieneutrale Liste zusammenzustellen. Frameworks kommen und gehen und sind stellenweise in erschreckend kurzer Zeit wieder obsolet. Die hier vorgestellten Bücher behandeln Themen die schon länger aktuell sind und es allem Anschein nach noch einige Jahre bleiben werden.

 

Practical Object-Oriented Design in Ruby

POODR Obwohl sehr viel über OO-Design geschrieben wird ist es sehr schwer ein gutes Buch für den Einstieg zu finden. Sandi Metz hat einen guten Mittelweg zwischen Theorie und Praxis gefunden und es gelingt ihr dieses Thema in verständlichen Schritten zu erklären. Auch wer sich mit Ruby nicht auskennt kann hier viel über OO-Design lernen.

Da die Beispiele recht kurz sind kann man sich auf genau den behandelten Teilaspekt konzentrieren. Dies hilft nicht nur Einsteigern sondern ist auch sehr gut als Auffrischung für erfahrene Programmierer geeignet.
(ISBN: 978-0-3217-2133-4 | detaillierte Rezension)

 

Refactoring

Trotz seines Alters ist Refactoring nach wie vor das Standardwerk zur Restrukturierung von Code. Der ausführliche Katalog mit Strategien zur Verbesserung der Codebasis ist aus meinem täglichen Entwicklerleben nicht wegzudenken.

Dies bedeutet keinesfalls dass ich alle darin vorgestellten Methoden auswendig kenne. Aber Refactorings wie das Umbenennen von Variablen oder das Extrahieren von Methoden sind Dinge die jeder beherrschen sollte. Diese sind sehr einfachen und verbessern den Code doch enorm.
(ISBN: 978-0-201-48567-7 | detaillierte Rezension)

 
 

The Art of Unit Testing (Second Edition)

The Art of UnitTesting 2nd editionRoy Osherove liefert das aus meiner Sicht bisher beste Buch über Unit Testing. Es gibt viele Bücher die gut sind, seine Erklärung von komplexeren Themen wie dem Mocken von Abhängigkeiten ist aber immer noch unerreicht. Und mit der 2. Ausgabe wurden die Praxisbeispiele und Tipps nochmals besser.

Gerade diese Praxisbeispiele helfen einem dabei auch die komplexeren Bereiche mittels Unit Tests abzudecken. Nur wenn man diese Herausforderungen meistern kann wird man Unit Tests in die eigenen Projekte integrieren.
(ISBN: 978-1-6172-9089-3 | detaillierte Rezension)

 
 

Clean Code

Unit Tests und Refactoring sind Techniken die den Code sauberer machen. Wenn einem diese Richtung gefällt ist Clean Code von Robert C. Martin der nächste Schritt.

Sein Buch geht den Weg weiter und verbindet verschiedenste Erkenntnisse in der Software-Entwicklung der letzten Jahre zu einem Ganzen.
Bei Clean Code ist es aus meiner Sicht aber besonders wichtig das man das Ziel bei all den Regeln nicht aus den Augen verliert. Verständlicher Code sollte immer vor einer in Stein gemeisselten maximalen Anzahl Zeilen für eine Methode gehen.
(ISBN: 978-0-13-235088-4 | detaillierte Rezension)

 
 

Patterns of Enterprise Application Architecture

Patterns of Enterprise Application ArchitectureDas 2. Buch von Martin Fowler in meiner Liste behandelt die Patterns rund um Geschäftsanwendungen. Die Problemstellungen in diesem Bereich sind so grundlegend dass die meisten Entwickler in ihren Projekten damit zu tun haben – ganz egal ob ihre Projekte den Stempel „Enterprise“ tragen oder nicht.

Fowler beschränkt sich nicht nur darauf die einzelnen Patterns aufzulisten, sondern erklärt auch die jeweiligen Vor- und Nachteile. Diese Gegenüberstellung macht für mich den Wert dieses Buches aus, da man nur so eine fundierte Entscheidung treffen kann.
(ISBN: 978-0-3211-2742-6 | detaillierte Rezension)

 
 

Soweit meine aktualisierte Liste von Büchern die ich als “Must-Read” bezeichne. Ich würde mich freuen zu erfahren was andere Entwickler als unverzichtbare Bücher auflisten.

 

Schlagworte: , , ,

Buch-Rezension zu “The Art of Unit Testing (2nd Edition)”

27. November 2013 2 Kommentare

The Art of UnitTesting 2nd editionSeit Ende letzter Woche gibt es mit “The Art of Unit Testing, Second Edition” eine neue Ausgabe meines favorisierten TDD-Buches. Die erste Ausgabe erschien 2009 und beeinflusste mein Verständnis von Test-Driven Development nachhaltig.

Ich war einerseits gespannt auf die neue Ausgabe und andererseits auch ein wenig unentschlossen ob es wirklich eine neue Ausgabe benötigt. Konnte die neue Ausgabe die kleineren Mankos der 1. Ausgabe wirklich beheben? Oder gibt es am Ende ein ganz anderes Buch das nur den gleichen Namen trägt?

 

Aufbau beibehalten, Inhalt überarbeitet

Die Kapitelstruktur der 2. Ausgabe unterscheidet sich nur minimal von der 1. Ausgabe. Der ehemalige Anhang A “Design and testability” ist nun ein “richtiges” Kapitel und Mock-Frameworks werden in einem zusätzlichen Kapitel noch eingehender angeschaut. Die übrigen Kapitel blieben alle erhalten und wer sich nur am Inhaltsverzeichnis orientiert wird diese 2. Ausgabe wohl schnell wieder weglegen.

Die grossen Neuerungen finden sich in den Kapitel selber. Diese wurden komplett überarbeitet und liefern nun eine noch bessere Erklärung wieso man seine Unit Tests auf diese Art organisieren und strukturieren soll. Die Beispiele sind nun so gut dass man dieses Buch auch problemlos einem Anfänger geben kann. Roy Osherove führte zwischen den 2 Büchern zahlreiche TDD-Kurse durch und hat seine dabei gewonnenen Erkenntnisse in die 2. Ausgabe einfliessen lassen. Dadurch wurde auch hinsichtlich der Praxistauglichkeit nochmal ein Schritt nach vorne gemacht, was sich vor allem an den viel klareren Namensregeln zeigt.

Wenn man die erste Ausgabe kennt und täglich mit Unit Tests arbeitet wird man fast nur bei den Mock-Frameworks neue Erkenntnisse bekommen. Die aktuelle Liste lieferte einem eine gute Übersicht und kann einem auch helfen sich gegen ein bestimmtes Framework zu entscheiden:

MSFakes might be free and included with Visual Studio, but it will cost you a lot of money down the line in developer hours, fixing and trying to understand your tests.

Wer seine erste Ausgabe nicht nur als Staubfänger nutzt sollte sich die 2. Ausgabe zulegen. Ob man das Buch als Nachschlagewerk, zum Auffrischen seiner Unit Testing Kenntnisse oder für neue Teammitglieder braucht – die überarbeiteten Kapitel sind einfacher zu verstehen und näher an der Praxis.

 

Fazit

Mit der 2. Ausgabe konnte Roy Osherove die hohen Erwartungen übertreffen und ein noch besseres Buch über Unit Testing liefern. Die darin beschriebenen Vorgehensweisen helfen in der Praxis die Unit Tests im Griff zu behalten und eine Struktur hinein zu bringen. Wenn man die erste Ausgabe besitzt und damit noch arbeitet lohnt sich auch der Kauf der 2. Ausgabe.

 

Zum Buch

The Art of Unit Testing, Second Edition” von Roy Osherove, November 2013 Manning, ISBN 978-1-6172-9089-3, 296 Seiten, Englisch

 

Schlagworte: , , ,

Buch-Rezension zu “Kanban and Scrum”

3. Oktober 2013 Kommentare aus

Kanban and ScrumKanban and Scrum – making the most of both” von Henrik Kniberg und Mattias Skarin erschien Ende 2009 bei InfoQ. Kanban und Scrum sind 2 Begriffe die im Zusammenhang mit agiler Softwareentwicklung immer häufiger fallen. Aber was ist nun Kanban? Und wie verhält sich dies zu Scrum? Auf diese und noch viele weitere Fragen liefert das Buch auf rund 100 Seiten eine Antwort.

Bei dieser Seitenanzahl darf es einem nicht verwundern wenn man keine umfassende Erklärung in alle Details rund um Kanban und Scrum bekommt. Den Autoren gelingt es aber dennoch alles Wesentliche auf den Punkt zu bringen. Man kann so in kurzer Zeit abschätzen ob Kanban oder Scrum etwas ist was man vertiefter anschauen will.

 

Teil 1: Vergleich von Scrum und Kanban

Im ersten Teil macht Henrik Kniberg einen Vergleich zwischen diesen beiden Ansätzen. Er zeigt objektiv auf was die beiden Modelle für Gemeinsamkeiten haben und wo die Unterschiede liegen. Man merkt schnell das Scrum mehr Regeln mitbringt als Kanban und so viel mehr Einfluss auf den Arbeitsablauf ausübt. Kanban erlaubt einem aber durchaus die Teile von Scrum zu übernehmen die einem dort besonders gefallen.

Dieses Fallweise übernehmen von Vorgaben und Empfehlungen bietet einem eine sehr flexible Lösung. Wem Scrum zu fix ist sollte einen Blick auf Kanban werfen. Und wem Kanban zu wenig konkret ist kann sich bei Scrum umschauen.

 

Teil 2: Detailliertes Fallbeispiel

Mattias Skarin beschreibt im zweiten Teil was für Erfahrungen er machte bei der Einführung von Kanban in einer skandinavischen Firma. Die Entwickler die nach Scrum arbeiten treffen auf den technischen Betrieb, der sowohl die Entwickler unterstützen wie auch den Betrieb aufrecht erhalten soll. Ein sofortiges lösen von Betriebsproblemen lässt sich nur schwer mit den Iterationen von Scrum in Einklang bringen. Kanban dagegen ist flexibel genug um auch solche Dinge zu ermöglichen.

Wo fängt man aber mit Kanban an und wie integriert man es mit Scrum? Skarin beschreibt dies meiner Meinung nach sehr gut: Egal wo wir anfangen, wir werden es ändern müssen. Also beginnen wir einfach und machen Änderungen sobald diese nötig werden.

Ein tägliches Stand-up Meeting, eine Retrospektive am Iterationsende und das Führen eines Impediment Backlog sind Aktivitäten mit denen Kanban in diesem Fallbeispiel angereichert wurde.

 

WIP Limits für schnelles Angehen eines Problems

Unter dem Titel „One day in Kanban-land“ gibt es ein sehr gutes Beispiel zum Wert von WIP Limits (also einer maximal erlaubten Menge von Arbeit die in einem Verarbeitungsschritt gleichzeitig in Bearbeitung sein darf).

Kanban-Board mit WIP

Für die Tätigkeit Entwicklung wurde ein WIP Limit von 2 vorgegeben. Diese Grenze gilt dabei sowohl für das was gerade entwickelt wird wie auch für die Pakete die aufs testen warten. Gibt es im Test (wo das WIP Limit 1 ist) ein Problem staut sich die Arbeit in der Entwicklung. In kurzer Zeit erreichen die Entwickler ihre Grenze und können keine neue Arbeit beginnen. Die so vorhandene Kapazität kann man nun nutzen um die Probleme im Test anzugehen.

Kanban-Board: WIP erreicht

Wird in der Entwicklung nicht die geforderte Qualität erreicht merkt man dies in diesem Beispiel nach dem 3. Arbeitspaket. Man kann so mit einer Verbesserung in der Entwicklung starten wenn der Schaden noch klein ist. Dies ist deutlich billiger und schneller als wenn man dies erst am Ende beim Abnahmetest bemerkt…

 

Download

Das Buch gibt es sowohl als Paperback wie auch als E-Book zum kostenlosen Download. Vom E-Book gibt es mittlerweile zahlreiche Übersetzungen, die leider nicht alle an die Qualität des Originals heran kommen.

 

Fazit

Wer einen Einblick in Kanban haben möchte oder wissen will wo die Unterschiede zu Scrum sind ist mit diesem kleinen Buch sehr gut bedient. Man bekommt in sehr kurzer Zeit alles Wesentliche mit und hat eine gute Grundlage um sich vertieft mit Kanban oder Scrum zu beschäftigen.

 

Zum Buch

Kanban and Scrum – making the most of both“ von Henrik Kniberg und Mattias Skarin, 2009 InfoQ, ISBN: 978-0-557-13832-6, 120 Seiten, Englisch

 

Kanban Serie

Falls dieser Beitrag ihr Interesse geweckt hat sollten Sie einen Blick auf die übrigen Folgen dieser Kanban Serie werfen:

  1. Durchstarten mit Kanban
  2. Buch-Rezension zu “Kanban”
  3. Werkzeuge für Kanban
  4. Buch-Rezension zu “Kanban and Scrum”
  5. Erfahrungen mit Kanban

 

Follow

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 245 Followern an