Archiv

Archive for Januar 2010

Bemerkenswerte Links für den Januar 2010

31. Januar 2010 Kommentare aus

Auch im Januar fand ich wieder einige erwähnenswerte Links. Diesmal eher im Bereich der Medien und Zeitungen. Wünsche viel Spass beim lesen.

 

Ein Film, eine Meinung
Die WOZ beschreibt die Situation bei den Filmkritiken. Wer schon immer mal wissen wollte wieso die Kritiken so oft fast identisch sind, wird hier eine Erklärung finden. So wie im Filmjournalismus gespart wird, wird auch im Rest gespart. Sind die kopierten Filmkritiken eine Vorschau auf die restlichen Teile einer Zeitung?

Im Netz der Ignoranten – eine Replik zum Spiegel-Artikel “Im Netz der Giganten”
Auf Mediaclinique gibt es eine gute Replik auf den Artikel beim Spiegel. Schön das sich jemand die Zeit genommen hat um die Halbwahrheiten beim Spiegel darzulegen. Wer wie der Spiegel ständig von Qualitäts-Journalismus spricht und sich als Beispiel darstellt, sollte wesentlich bessere Qualität liefern.

German Publishers Go After Google; Apparently Very Confused About How The Internet Works
Bei Techdirt wird über das angekündigte Kartellverfahren gegen Google berichtet. Die Verleger rechnen mit falschen Zahlen und haben nun das Gefühl, Google würde seine Marktbeherrschende Stellung zu ihrem Nachteil nutzen. Techdirt geht dem nach und findet erstaunliche Ungereimtheiten.

“Höchst fragwürdig” – Ein Meinungsbeitrag zur Pressekonzentration
Hugo Triner von der NZZ äussert sich zur Pressekonzentration in der Schweiz. Wenn immer mehr zusammengelegt wird, verschwindet auch die Vielfalt. Die Kosten werden zwar gesenkt, doch ob es für den Konsumenten am Ende wirklich billiger wird? Monopole führen immer zu höheren Preisen und schlechterer Qualität. Der Beitrag wirft etliche Fragen auf, die hoffentlich auch aufgegriffen werden.

Aurora: Angriff mit IE-Exploit aus China auf Google und den Rest der Welt
ZDNet geht dem Angriff von China auf Google nach. Eine sehr spannende Erklärung wie sich nach derzeitigem Wissensstand der Angriff abgespielt hat. An der technischen Meisterleistung haben wohl ganze Teams über Monate hinweg gearbeitet. Am Ende hat man eine Lösung, die kaum mehr entdeckt werden kann.

Career Advice For Young Developers
Schon älter, aber noch immer sehr gut. Davy Brion listet einige Tipps für junge Entwickler auf, die bei der Planung der Kariere helfen können. Um eine gute Arbeit zu machen muss man diese gern machen. Wer weiss, meistens braucht man Tipps für die nächsten Schritte in seiner Laufbahn schneller als man glaubt. Einige Kommentare liefern zusätzliche Tipps, ich empfehle daher diese auch anzuschauen.

Buch-Rezension zu “Was man nicht messen kann…”

27. Januar 2010 1 Kommentar

Was man nicht messen kann… … kann man nicht kontrollieren” von Tom DeMarco ist die deutsche Übersetzung seines 1982 erschienenen Klassikers “Controlling Software Projects”. Die Führung von Projekten über Kennzahlen tönt nicht gerade interessant – doch sollte man sich zu keinem vorschnellen Urteil verleiten lassen.

 
Auch heute noch aktuell
Die Einleitung beschreibt sehr genau die Probleme, die in so manchem IT-Projekt herrschen. DeMarco schafft es, diese so zu benennen, dass es einem unverständlich dünkt, das man auf all dies nicht selber gekommen ist. Es ist doch alles so klar. Ich fand die Einleitung eine der treffendsten Beschreibungen der aktuellen Probleme, die ich seit langem gelesen habe. So war ich recht erstaunt, als ich das Erscheinungsjahr sah – 1982, mein Geburtsjahr. In der ganzen Zeit die ich auf der Welt bin hat sich somit an den Problemen nichts geändert. Dies ist doch eine rechte Enttäuschung.

In den Jahren kamen (und gingen) unzählige Programmiersprachen, Vorgehensmodelle und Theorien. Und dennoch befinden wir uns immer noch am gleichen Punkt. DeMarcos Buch liefert Erklärungen, wieso dies so ist. Genau das was damals schon die Probleme verursachte, verschuldet diese auch heute noch. Eigentlich verständlich – wenn man Dinge immer gleich macht, wird auch immer das gleiche heraus kommen.

Die Vorschläge für dezidierte Mess-, Schätz und Testgruppen kosten viel Geld. Doch was kostet ein einziges fehlgeschlagenes Projekt? Das Buch geht dem nach und liefert Fakten. Was kosten Fehler? Wie kann man diese Verhindern? Und so wird aus einer ganzen Reihe von trockenen Kennzahlen plötzlich etwas sehr konkretes.

Es gibt aber auch einige wenige Punkte, bei denen man das Alter der Tipps merkt. Die Forderung den Code unkompiliert ans Testteam zu geben und das die Tester dann zum ersten Mal kompilieren erscheint heute wie aus einer anderen Welt. Gleiches gilt für das strikte Testverbot für Entwickler. In Zeiten von Unit Tests und TDD ist so ein Ansatz überholt.

 
Vom Chaos bis zur Qualität
DeMarco nimmt einem auf einen Rundgang durch die Führung von Projekten. Im Gegensatz zu “Der Termin” allerdings nicht in eine einzige Geschichte verpackt. Zahlreiche Formeln und Diagramme unterlegen seine Theorien. Somit ist es eher ein “Schulbuch” als ein Roman. Aber keine Angst! Die Formeln und Diagramme werden so erklärt, dass man deren Sinn und Zweck verstehen kann. Die 4 Teile des Buches gliedern sich so:

  1. Chaos und Ordnung im Software-Entwicklungsprozess
  2. Modelle und Kennzahlen eines Systems
  3. Kostenmodelle
  4. Softwarequalität

Der Rundgang beginnt beim feststellen der aktuellen Situation und zeigt, wie man unter Verwendung von Kennzahlen und einem strukturierten Vorgehen zum Ziel kommt. Von den zahlreichen Punkten sind mir die folgenden besonders aufgefallen.

 
Schätzen oder Messen?
Die Qualität einer Schätzung kann durch viele Einflüsse verschlechtert werden: Mangelnde Erfahrung, fehlende Fähigkeiten, Verwendung falscher Ausgangsdaten oder den Druck, genehme Schätzungen zu liefern. All dies führt nur dazu, dass die Schätzung mit der Realität nicht viel gemeinsam hat.
Dem Messen vertrauen wir deutlich mehr. Aber was wird gemessen? Was machen wir wenn das was wir messen wollen noch nicht vorliegt? Nichts machen kann da keine Lösung sein.

Es braucht somit die Kombination von Schätzen und Messen. Und vor allem eine Rückmeldung an den Schätzer, sobald die Messresultate vorliegen. Nur mit diesem Feedback kann sich der Schätzer verbessern. Und die Schätzer brauchen Erfahrung. DeMarco schlägt vor, innerhalb der Firma eine unabhängige Gruppe von Schätzern einzurichten, die sich nur um das Schätzen kümmern. Wenn die Schätzer vom zu schätzenden Objekt unabhängig sind und ihre Leistung nur an der Genauigkeit ihrer Schätzung gemessen wird, hat man eine Chance auf eine objektive Schätzung. Andernfalls gibt es einen Zielkonflikt, bei dem die Schätzung meistens unterliegt.

 
Der Entwurf zählt
Damit man etwas zu schätzen hat, braucht es eine Spezifikation (Was) und einen Entwurf (Wie). Nur diese Dokumente stehen am Anfang des Projekts zur Verfügung und können zur Schätzung von Aufwand und Kosten herangezogen werden. Die Schätzung auf Basis von Codezeilen fällt da flach – es gibt noch nichts dergleichen.

Ein Entwurf. Das ist zu häufig eines der ersten Dinge die man einspart um “agil” zu sein. Braucht es nicht, ist eh zu teuer und schliesslich und endlich hat man ja den Programmierer, der dies festlegt. Ist dies wirklich so?
Ein Entwurf der klar zeigt welche Dinge wo gemacht werden müssen und wie die einzelnen Module zusammenarbeiten, wäre äusserst hilfreich. Sowohl für die Entwickler, die deutlich weniger vermuten müssten. Auch für die Tester würde ein guter Entwurf viel bringen. Wenn klar ist was welcher Teil wie machen müsste, kann man auch genau dies testen. Und man hat klare Vorgaben, mit denen man den Erfolg des Projekts am Ende messen kann.

Wie es DeMarco auch schreibt darf der Entwurf natürlich nicht am Anfang einmal gemacht werden und dann in einer Schublade verschwinden. Neue Anforderungen müssen dort genauso aufgenommen werden wie in der Spezifikation. DeMarco formuliert dies auch recht direkt:

Es gibt keinen Ersatz für das Prinzip, dass man zuerst denken und dann handeln sollte.

Der Entwurf soll daher als Bauplan dienen. Dabei ist es wichtig, dass dieser auch mit den Kunden besprochen werden kann – und zwar ohne vorher wieder eine “Konvertierung” durchzuführen.

 
Ein Fehler kommt selten allein
Entgegen der Vermutung sind Fehler nicht gleichmässig über den ganzen Code verteilt. Hat man Module bei denen schon etliche Fehler gefunden wurden, ist die Wahrscheinlichkeit gross, dass dort noch mehr Fehler versteckt sind.
Eine Erklärung dafür liegt in der Art wie die Module erstellt werden. In der Regel kümmert sich ein Teil der Entwickler um Modul A, eine andere Gruppe um Modul B usw. Es gibt Leute die mehr Fehler machen als andere. Arbeiten diese vor allem an Modul A werden dort häufiger Fehler auftreten.

DeMarco liefert einige Beispiele wie durch einen anderen Einsatz der Leute die Fehler reduziert und die Qualität gesteigert werden kann. Die dahinter liegende Idee ist wiederum einfach: Das verhindern von Fehlern ist billiger als deren Behebung. Um zu wissen welche Leute besser für die Fehlersuche als für die Entwicklung geeignet sind, braucht es aber Messdaten. Und damit schliesst sich der Kreis wieder bei der Messbarkeit.

 
Fazit
Ein aufschlussreiches Buch das an Aktualität fast nichts eingebüsst hat. Heute würde man zur Modellierung UML verwenden und so liesse sich einiges an Erklärung für die Darstellungsart von DeMarco einsparen. Messen kostet, genauso Qualität. Aber erst recht teuer werden fehlgeschlagene Projekte oder ein nachträgliches anheben der Qualität. In 28 Jahren wird dieses Buch hoffentlich nicht mehr aktuell sein.

Wie bei allem darf man es natürlich auch beim Messen nicht übertreiben. Wenn man nur noch am messen ist, fehlt die Zeit um zu arbeiten. Auch hier benötigt es ein Gleichgewicht.

 
Zum Buch
Was man nicht messen kann… …kann man nicht kontrollieren” von Tom DeMarco, Mitp-Verlag, 2. überarbeitete Auflage 2008, ISBN 978-3-8266-1488-0, 450 Seiten

Schlagworte: ,

Katana – wie ein Kunstwerk entsteht

21. Januar 2010 1 Kommentar

(C) Rama, licensed: Creative Commons Attribution-Share Alike 2.0 France
3Sat zeigte in der Reihe “Im Fokus: Japan” die Dokumentation “Das Schwert der Samurai”. Darin wird gezeigt wie ein japanisches Langschwert, das Katana, erstellt wird.

 
 
Ein gewaltiger Aufwand
Der Aufwand um ein Katana zu erstellen ist enorm. Es gibt kein “schnell, schnell” und mal eben ein Schwert “machen”. Bei der Auswahl des Tamahagane, dem Rohmaterial, beginnt ein Prozess, der in jedem einzelnen Schritt Perfektion verlangt. Um nur schon den Stahl zu gewinnen, braucht man 3 Tage – am Stück, ohne Unterbruch.
Erst dann kann man mit dem Schmieden beginnen. Allerdings nicht mit dem Schmieden des Schwertes, sondern mit dem Falten des Stahls. Das Falten dient der gleichmässigen Verteilung des Kohlenstoffgehalts. Ohne diesem Vorgang könnte bei der Belastung das Schwert sonst brechen. Danach erst wird der Stahl in die Form des eines Schwertes gebracht. Damit ist die Arbeit aber noch lange nicht fertig. Es folgt noch das Härten und das Gravieren, bevor der Meisterpolierer sich dem Schwert annimmt.

 
Perfektion: Ein Muss und keine Option
Mich faszinierte die Präzision, mit der gearbeitet wird. Jeder Arbeitsschritt muss perfekt ausgeführt sein, immer die richtige Aktion im richtigen Moment. Zu spät und die ganze Arbeit ist für nichts. Zu früh und es bricht beim nächsten Schritt. Alles muss zusammen passen. Eine Unachtsamkeit und man produziert teuren Abfall. Alles ist darauf ausgerichtet das Schwert perfekt zu machen. Ein Ziel, eine Richtung, ein Kunstwerk.

Nur die Erfahrung dient als Wegweiser. Die Färbung des Stahls und des Feuers zeigen an wann der richtige Zeitpunkt gekommen ist. Jedes Schwert wird ein Unikat. Und so ist auch der Weg dorthin immer ein wenig anders. Ein stures festhalten am letzten Durchgang und man kann es wegwerfen. Man muss sich immer mit dem Schwert auseinander setzen.
Hunderte Jahre an Erfahrung wurden von Meister zu Meister weitergegeben, ergänzt und verbessert. Flexibilität und der auf Erfahrung gegründete Prozess müssen sich unterstützen und ergeben nur gemeinsam ein Produkt auf diesem hohen Niveau.

Erst wenn jeder daran beteiligte sein Bestes gibt, wird aus einem Stück Stahl nicht nur ein Schwert, sondern ein Mythos. Hat aber auch nur einer das Gefühl, er könne eine schlampige Arbeit abliefern, wird aus dem Kunstwerk im besten Fall noch ein übergrosses Brotmesser.

Schlagworte:

Buch-Rezension zu “Pragmatic Thinking & Learning”

19. Januar 2010 Kommentare aus

Pragmatic Thinking & Learning – Refactor Your Wetware” von Andy Hunt erschien im September 2008 bei The Pragmatic Programmers. Andy Hunt geht der Frage nach, wie unser Gehirn arbeitet und was dies für Auswirkungen auf unser Denken und Lernen hat. Obwohl das Buch von einem Programmierer geschrieben wurde, ist es nicht nur etwas für Programmierer.

Der wichtigste Grundsatz des Buches ist der L-Mode und der R-Mode des Gehirns. Die rechte Gehirnhälfte kümmert sich demnach um Intuition, Bilder, Emotionen und die Kreativität, während die linke Hälfte für die Logik und das rationale und analytisches Denken da ist. Um effizient mit unserem Gehirn zu arbeiten, brauchen wir beide Seiten.

Eine andere Grundthesen des Buches bezieht sich auf das Dreyfus-Modell mit den 5 Ebenen des Erwerbs und der Entwicklung von Fähigkeiten. (Das Modell wurde unter anderem auch in der Krankenpflege angewandt). Die 5 Stufen gliedern sich so:

  1. Anfänger
  2. Fortgeschrittener Anfänger
  3. Fachliche Kompetenz
  4. Erfahrung
  5. Experte

Je nach Stufe lernt man anders. Daher ist es wichtig, dass man sich im klaren ist, auf welcher Stufe man sich befindet.

Das Buch hat 48 Tipps rund ums lernen und arbeiten. Einige sind sehr allgemein, andere spezifisch wie die Verwendung zweier Monitore für die Arbeit am PC. Mir selber haben vor allem die 4 folgenden Ideen gefallen.

 
Morning Pages
Morning Pages sind eine Technik, die von den Schriftsteller kommt. Man schreibt jeden Morgen als erstes mindestens 3 Seiten über das, was einem einfällt. Wichtig ist, das man einfach drauflos schreibt, ohne die Gedanken zu filtern. Wichtig ist, das man es wirklich als erstes am Morgen macht. In der Regel ist man da noch nicht ganz wach und das Unterbewusstsein hat es einfacher, einem Ideen zu liefern. So entsteht quasi ein Brain Dump.

In meinen letzten Ferien habe ich dies versucht und war vom Ergebnis erstaunt. Ich blieb zwar unter den 3 Seiten, aber es half doch enorm, meine Gedanken zu sortieren. Ideen die ich hatte sind nun aufgeschrieben und gehen nicht verloren. Umgesetzt ist damit natürlich noch nichts. Aber ich kann darauf aufbauen und muss nicht immer wieder von vorne beginnen. Es half mir auch beim loslassen. Einige Gedanken die mir vorher immer wieder kamen und über die ich recht lange nachdachte, haben sich seit dem aufschreiben quasi “erledigt”.

Derzeit bin ich noch auf der Suche nach einem für mich passenden Ansatz, um die Morning Pages auch während der Arbeitswoche zu schreiben.

 
Smarte Ziele
Bei einer schier unlimitierten Anzahl an Möglichkeiten muss man seine Ziele klug auswählen. SMART kann einem dabei sehr helfen. Die Abkürzung steht für Specific, Measurable, Achievable, Relevant und Time-Boxed. Man will innerhalb einer bestimmten Zeit eine bestimmte Sache erreichen. Dieses Ziel muss erreichbar, relevant und vor allem auch messbar sein.

 
Mind Maps für die Entwicklung
Mind Maps sind nichts neues. In den letzten 15 Jahren waren Mind Maps immer wieder ein Thema. Sei dies an der Schule, während der Lehre oder auch am Tech – immer wieder wurden Mind Maps als Lösung für alles Mögliche angepriesen. Bisher hat mich das jeweils nicht wirklich überzeugt. Nun also schon wieder Mind Maps. Hunt beschreibt nicht nur die Methodik, sondern auch die Anwendung. Er bringt einige gute (und für mich neue) Ansätze, wie man Mind Maps anwenden kann.

Ich gab Mind Maps nochmals eine Chance, als ich für die Entwicklung eines Tools die Anforderungen aus der Spezifikation zusammensuchen musste. Ich war erstaunt wie dies meine Arbeit erleichterte. Es hat sicherlich noch Verbesserungspotential. Aber für den Anfang war das deutlich besser, als was ich bisher machte. Ich werde dies fürs erste weiterverfolgen.

 
Das persönliche Wiki
Der Vorteil von einem Wiki besteht in der Verknüpfung von Informationen. Damit ist es ein ideales Tool um Informationen und Wissen zu speichern. Was im grossen bei Wikipedia funktioniert, kann man auch im kleinen nutzen. Ein persönliches Wiki dient dabei zum ablegen von all den Ideen, Gedanken und Fakten, die man für “speichernswert” hält.

Ich startete mein persönliches Wiki im Mai 2005. Mich sprach damals DokuWiki am meisten an und so ist es auch heute noch. Das Wiki ist sehr einfach zu bedienen, bietet alles was ich brauche und lässt sich mit unzähligen Templates seinem Geschmack anpassen.

 
Fazit
Das Buch bietet eine gute Zusammenstellung von Ideen für ein optimaleres lernen. Einige sind besser, einige nutzten mir nichts. Auf zahlreiche Ideen bin ich selber gekommen und habe ich erfolgreich umgesetzt. Zu Beginn meines Studiums hätte ich dieses Buch sehr gut gebrauchen können. Jetzt war es eher eine Bestätigung meiner Erfahrungen.

Die Grafiken erwecken oft den Eindruck von einem Entwurf. In einem fertigen Buch bin ich mir bessere Grafiken gewohnt und fand die teils schwer entzifferbaren Texte der Bilder mühsam. Die durch den grauen Hintergrund unübersehbaren “Seitentexte” störten meinen Lesefluss. Mehr Tiefe im Hauptteil und weniger Seitentexte würden das Buch auch für Einsteiger attraktiver machen.

 
Zum Buch
Pragmatic Thinking & Learning – Refactor Your Wetware” von Andy Hunt, 2008 The Pragmatic Programmers, ISBN 978-1-934356-05-0, 288 Seiten

Schlagworte: ,

Silverlight 4 Hands-On Lab

17. Januar 2010 3 Kommentare

Am 15. Januar besuchte ich das Hands-On Lab zu Silverlight 4 bei Microsoft in Wallisellen. Bisher habe ich nur ein wenig mit den Beispielen zu Silverlight experimentiert. Hier mal ein wenig mit den Komponenten gespielt, da ein wenig Code angepasst. Meine Erfahrungen mit Silverlight waren somit bisher vor allem theoretischer Art. Das Hands-On Lab war daher eine gute Gelegenheit, endlich mehr zu machen als nur ein wenig zu Spielen.

 
Was ist ein Hands-On Lab?
Bei einem Hands-On Lab nimmt man sein eigenes Laptop mit und kann selber die vorgegebenen Beispiele ausführen. Beim Lab zu Silverlight war die Einführung sehr kurz, dafür die Aufgabe umso grösser. Auf 104 Seiten wurde ausführlich beschrieben, wie man eine Silverlight Applikation mit WCF RIA Services baut. Die Applikation nutzt die Nordwind Demo-DB und zeigt die Bestellungen an. Ein Sub-Report ermöglicht die Bearbeitung von Details der ausgewählten Bestellung. Neben dieser Grundfunktionalität gibt es einige kleine Helfer wie die Validierung der Eingabe, einen Busy Indikator beim Laden der Daten, eine Autocomplete-Box für die Suche nach Städten und die Druckfunktion.

Kurzum: Die Applikation des Hands-On Lab ermöglicht einem komprimiert und in sich stimmig die wohl am häufigsten benötigte Funktionalität auszuprobieren.

 
Derzeit noch alles Beta
Sowohl Silverlight 4 wie auch Visual Studio 2010 sind erst in Betaversionen erhältlich. Die finalen Versionen sollten wohl in 3-6 Monaten erscheinen. Mich erstaunte die Geschwindigkeit von Visual Studio. Von 2008 ist man sich einen langsamen Start gewöhnt. 2010 dagegen startet sehr schnell.
In der Beta muss man noch bei fast jeder Aktion im Server-Teil ein rebuild all durchführen. Das lässt sich zwar einfach von Hand machen, doch wenn man dies vergisst, bekommt man nur noch Fehlermeldungen zu Gesicht. Ein automatisches nachziehen der generierten Proxy-Klassen wird die Entwicklung nochmals deutlich angenehmer machen. Zudem stürzt Visual Studio 2010 in der Beta 2 zu häufig ab. 1 Absturz pro 45 Minuten ist auch bei dem schnellen Start einfach noch zu viel. Für eine Beta-Version ist der Gesamteindruck aber schon sehr gut.

 
Fazit
Ich fand das Lab eine gute Erfahrung. Man kann selber im eigenen Tempo arbeiten und stösst man auf Probleme, hat man sehr kompetente Personen im Raum, die einem helfen können. Bei Silverlight gefiel mir wie einfach und vor allem schnell man ein Grid anzeigen konnte. Kein herumschlagen mit Requests, Postbacks oder Session – einfach nur hineinziehen, verbinden und es lief.

Auch die einfache Verwendung von RIA Services hat mich positiv erstaunt. Die Objekte werden zum DB-Schema passend angelegt und man kann damit loslegen. Kein Aufbau von Sessions und keine Proxy-Errors. Werden die Daten im Subreport geändert, wird erst validiert und dann gespeichert. Hat man es dann gespeichert, bleibt es dies auch. Und vor allem wird nicht schon gespeichert, wenn der Benutzer nur etwas im Formular ändert. Somit fällt auch viel von dem Overhead weg, der mich derzeit bei der WebForms-Entwicklung stört.

Silverlight ist definitiv eine sehr interessante Technologie. Und mit Version 4 gibt es einen grossen Schritt nach vorne.

Schlagworte: ,
Follow

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 254 Followern an