Your Guide to Modern, Pragmatic Project Management

Es ist schon fast einen Monat her, seit ich dieses Buch gelesen habe. Nun habe ich mich endlich dazu aufraffen können, auch darüber zu bloggen. Das liegt aber nicht daran, dass das Buch schlecht ist, nur fällt es mir viel schwerer, etwas über ein Management-Buch zu schreiben als beispielsweise über eine Programmiersprache. Das könnte daran liegen, dass Projekt-Management nicht so ganz “meine Welt” ist, ich weiss es nicht.

Das Buch richtet sich, wie könnte es anderst sein, eigentlich an Projektmanager, welche ein paar nützliche Ratschläge von einer erfolgreichen und erfahrenen Projektmanagerin erhalten möchten. Ich dachte, vielleicht kann ich mich eher mit dem Thema anfreunden, wenn ich mal ein Buch der Pragmatic Programmer darüber lese, wer weiss, vielleicht will ich auch mal richtig Geld verdienen

Das Buch führt einem durch verschiedenste PM-Aktivitäten, angefangen bei der Projektplanung, dem Scheduling, Aufwandsschätzung (dazu lese ich übrigens passenderweise gerade “Thy Mythical Man-Month”), über das Zusammenbringen eines Projekt-Teams, Meetings und so weiter. Besonders gefallen hat mir das Kapitel “Recognizing and Avoiding Schedule Games”, in dem verschiedenste “Spielchen” der (höheren) Manager und Geldgeber kategorisiert und diskutiert werden. Beispiel: Queen of Denial, mit dem wohl prägenden Satz: “It’ll be ok, you’ll make the deadline”, auch wenn man soeben das Gegenteil darzulegen versuchte. Oder das Schedule Chicken, bei dem kein Team mehr innerhalb der geplanten Zeit ist, es aber alle behaupten und darauf warten, dass ein anderer zuerst “einbricht”.

Ich glaube, das Buch ist auch für Nicht-Projektmanager durchaus interessant, auch wenn es vielleicht nicht jedermanns Hauptbeschäftigung ist, etwas zu managen gibt es doch immer, und man ist schnell in der Lage, dass man Verwantwortung für etwas (wenn vielleicht auch kleines) übernehmen muss.

Ich möchte noch unseren Studien- und Diplomarbeitern gratulieren (etwas verspätet zwar.. Feiertagsstress), die ihre Arbeit am IFS abgeschlossen haben. Folgendes ist dabei entstanden:

• JavaScript-Refactoring (Diplomarbeit) für JSDT von Matthias Balmer und Roman Kühni.
• Groovy-Refactoring (Studienarbeit) für Groovy-Eclipse von Martin Kempf, Reto Kleeb und Michael Klenk. (apropos Groovy: Juhui!)
• Python-Refactoring und Type Inference (Studienarbeit) für PyDev von Reto Schüttel und Robin Stocker.

Etwas verzögert wegen personellen Problemen ist das PHP-Refactoring Plug-in für PDT, erste Ergebnisse sind aber schon sehr vielversprechend.

Auch nicht zu vergessen ist das COAST Project, welches Peter Sommerlad’s C++-Applikationsframework wieder auf die Beine bringt.

Sehr erfreulich ist natürlich auch, dass die meisten Teams ihre Arbeit in Form einer Bachelorarbeit fortführen. Ich freue mich schon auf die Zusammenarbeit!

Was vor wenigen Jahren undenkbar erschien, ist längst zur Tatsache geworden. Der Arbeitsmarkt für sehr gut ausgebildete Fachspezialisten ist in diversen Bereichen völlig ausgetrocknet.

So beginnt tatsächlich ein Brief, den ich heute erhalten habe. Hab ich da was verpasst? Ist es nicht genau umgekehrt? Interessanterweise sieht er auch nicht einfach wie beliebige Massenwerbung aus, wurde er doch von zwei Personen handschriftlich unterschrieben. Tja, in den Müll muss er trotzdem

Im News and Noteworthy des Eclipse 3.4M4 habe ich heute morgen etwas ziemlich komisches gesehen, und zwar gibts es einen neuen Quickfix:

Was durch folgenden Code ersetzt wird:

Ok, was fällt auf? StringBuffer! Dabei sollte man grundsätzlich immer StringBuilder verwenden, welcher im Gegensatz zum StringBuffer nicht synchronisiert ist. Um Thomas, unseren Parall- und Netzwerkprogrammierexperten, zu zitieren, ist der StringBuffer “unglaublich schweinisch sauteuer”.

Nehmen wir an, es würde anstelle des Buffers ein Builder verwendet, dann wäre der QuickFix trotzdem ziemlich unsinnig, denn der Compiler (zumindest Sun’s) ersetzt manuelle String-Konkatenationen sowieso durch StringBuilder-Aufrufe. Aus:
int offset = 3, line = 5;
String s = "Offset " + offset + " is at line " + line;entsteht also folgender ByteCode:

0  iconst_3
1  istore_1 [offset]
2  iconst_5
3  istore_2 [line]
4  new java.lang.StringBuilder [16]
7  dup
8  ldc  [18]
10  invokespecial java.lang.StringBuilder(java.lang.String) [20]
13  iload_1 [offset]
14  invokevirtual java.lang.StringBuilder.append(int) : java.lang.StringBuilder [23]
17  ldc  [27]
19  invokevirtual java.lang.StringBuilder.append(java.lang.String) : java.lang.StringBuilder [29]
22  iload_2 [line]
23  invokevirtual java.lang.StringBuilder.append(int) : java.lang.StringBuilder [23]
26  invokevirtual java.lang.StringBuilder.toString() : java.lang.String [32]
29  astore_3 [s]
30  return

Interessanterweise wurde der QuickFix auch schon an anderer Stelle kritisiert, allerdings nicht das Kernproblem:

I know using StringBuffers is better for performance.

Tsts…

Ich überlege mir, einen Patch einzureichen, der den QuickFix wieder löscht

So, ich habe meinen Beamer wieder, und er funktioniert auch wieder tadellos. Allerdings ist mir noch etwas “lustiges” passiert: Der Drachen Die Dame am Postschalter hatte noch ein anderes Paket für mich (eine Amazon-Bestellung), für welches ich auch nie eine Abholungseinladung erhalten hatte. Dann behauptete sie noch, dass dies das einzige Paket für mich sei. Glücklicherweise hatte ich den Beamer aber gesehen (es stand auch gross STOCKER drauf) und konnte Sie darauf hinweisen. Zum Schluss wurde mir noch vorgeworfen, dass ich die Abholeinladung verloren hätte.

Was mir etwas Angst macht: Ich erwarte schon seit längerem noch drei andere Pakete…

Zwei Jahre alt ist dieses Blog nun schon, und da mein altes Theme nicht mit Wordpress 2.3 kompatibel war, habe ich die Gelegenheit genutzt und ein anderes Theme angepasst, bis es mir gefallen hat. Ich hoffe euch auch

Eventuell werde ich noch Kleinigkeiten anpassen, es ist auch noch nicht ganz alles übernommen. Ich hoffe auch, dass alle Links noch funktionieren.

Ich überlege mir gerade ernsthaft, ob es nicht sinnvoll wäre, den Erstsemestrigen, also den Programmieren 1 Besuchern, den Einsatz einer IDE zu verbieten. “Du Unmensch”, höre ich euch schon rufen, “es ist doch Java!”. Ich weiss, aber was soll ich sagen, wenn Studenten (so wie ich das heute in der Pause mitanhören musste) keine Ahnung von Packages haben, aber sich darauf verlassen, dass Eclipse ein rotes Kreuzchen macht, das man nur anklicken muss und alles korrigiert wird. Ähnliche Probleme gibt es beim Unterschied zwischen Instanz- und Klassenmethoden, sowie deren Sichtbarkeit.

Die Gefahr ist halt gross, dass man einfach mal etwas “drauf los programmiert” und danach das Gehirn einschaltet und die rot unterkringelten Statements noch mal genauer anschaut. Das ist vielleicht auch ein Grund dafür, dass, um den neumodischen Begriff zu verwenden, “dynamische Programmiersprachen” von vielen verschmäht werden, da man nicht die (trügerische) “Sicherheit” einer IDE hat.

Um wieder zurück zur Schule zu kommen: Sich auf die IDE zu verlassen ist auch in Hinsicht auf die bevorstehenden Prüfungen vielleicht nicht die beste Idee.

Obwohl, eigentlich müsste der Titel unterdessen eher “Argh, die Post!” oder ähnlich lauten. Nachdem Rico seinen Beamer ja seit gestern wieder hat und ich immer noch am warten bin, habe ich beim Reparateur mal nach dem Stand, bzw. der Trackingnummer gefragt. Und tatsächlich, das Paket ist seit Montag abholbereit, nur einen gelben Zettel habe ich nie erhalten Ich frage mich, was passiert wäre, wenn ich einfach weiter gewartet hätte. Nach einer gewissen Zeit wäre das Paket wohl einfach wieder zurück gegangen, oder?

Backups sind ein eher unbeliebtes Thema, genau so wie das bezahlen von Krankenkassenprämien und Versicherungen: Im Moment hat man nichts davon (ausser dass man vielleicht ruhiger schlafen kann), aber wenn mans mal braucht dann ist man ungemein froh darüber.

Im Gegensatz zur Krankenkassenversicherung wird man von niemanden dazu gezwungen, ein Backup auch zu machen. Bitte alle aufstehen, die irgendwo ein System haben, das nicht gebackupd wird. Und jetzt auch noch alle, die zwar ein Backup haben, aber noch nie einen Restore davon ausprobiert haben? Alle die jetzt stehen sollten den folgenden Beitrag lesen, und ich bin mir sicher, dass es einige sind

Ein Backup zu erstellen ist nicht besonders schwer, und man braucht auch bestimmt nicht selbst irgendwelche Skripts zu schreiben.

Ich nutze eigentlich auf allen System Dirvish. Es ist ziemlich einfach zu konfigurieren, und vor allem ist es sehr einfach nachzuvollziehen, was passiert, bzw. was gebackupd wird. Dirvish nutzt Hardlinks für die verschiedenen Versionen des Backups, gleiche Dateien belegen also nicht mehrfach Platz. Vielleicht noch zwei Begriffe: Dirvish legt die verschiedenen Backup-Ziele (sogenannte “Vaults”) in einem “Bank”-Verzeichnis ab.

Zuerst müssen wir Dirvish jedoch noch installieren:

sudo aptitude install dirvish ; sudo emerge dirvish

Wie gesagt, Dirvish braucht eine “Bank” für die Backups, sowie einen Vault pro Backupziel. Unsere Bank erstellen wir in /mnt und nennen sie “backup”. Ein Vault ist nichts anderes als ein Ordner mit einem Unterordner namens “dirvish”, nennen wir ihn “root”.

sudo mkdir -p /mnt/backup/root/dirvish

Danach editieren wir die Datei /etc/dirvish/master.conf, in der die globalen Einstellungen gemacht werden. So könnte es Beispielsweise aussehen:

bank:
        /mnt/backup

# Veranlässt Dirvish, beim Backup auf dem
# aktuellen Filesystem zu bleiben.
xdev: true

# Ein paar nützliche excludes:
exclude:
        lost+found/
        /proc
        /mnt
        /dev
        /sys
        /var/cache/apt/archives/*.deb

# Alle Backups werden grundsätzlich
# nur 30 Tage lang aufbewahrt
expire-default: +30 days

# bis auf das erste jedes Monats,
# das behalten wir ein ganzes Jahr lang:
expire-rule:
# MIN HR DOM MON DOW STRFTIME_FMT
   *   *  1   *   *   +1 year

# Welche Backups/Vaults standardmässig
# gesichert werden:
Runall:
        root

Diese Einstellungen sind für alle Vaults gültig. Danach brauchen wir nur noch eine Konfiguration für das Backup (/mnt/backup/root/dirvish/default.conf):

# Der lokale Name des Rechners
client: Debian-40-etch-64-LAMP

# Und den Pfad, ab dem wir sichern wollen
tree: /

Mehr brauchen wir nicht zu konfigurieren. Tatsächlich sind wir schon fast fertig, wir müssen nur noch den Vault initialisieren und abwarten, während das erste Backup gemacht wird.
dirvish --vault root --init

Per cronjob (/etc/cron.d/dirvish) wird das ganze nun jeden Abend angekickt. Das wars schon!

Nachdem ist bereits das erste Buch der Serie ziemlich genial fand, musste der zweite Teil natürlich auch sofort her. Wieder gibt es über ein dutzend Kapitel von (mehr und weniger) bekannten Autoren, welche jeweils über ein Thema schreiben. Sehr gefallen haben mir:

• Learning to Love JavaScript
• The Case for Groovy
• Give It a REST
• Web Testing with Selenium
• Capistrano: Application Deployment and More

Auch immer interessant ist das letzte Kapitel, in dem alle Autoren ihre “Favorite Books” und “Favorite Technical Tool” vorstellen, meine Leseliste wird immer länger… etwas verwirrend fand ich, dass in der Bibliographie das Buch “The Productive Programmer” von Neal Ford und David Bock erwähnt wird. Verwirrend deshalb, da es das Buch gar nicht gibt (oder ich zu blöde bin es zu finden).

Etwas entäuscht war ich vom Beitrag “Pragmatic Tips, Tricks and Techniques: Eclipse”, ich wage zu behaupten, dass dazu das Lesen meines Blogs mehr nützt Ein guter Tipp war zwar dabei: unter Preferences -> Java -> Appearance -> Type Filters kann man Packages von der Code Completion ausschliessen (z.B. java.awt).

Nachtrag:
Har gerade eine Antwort von Neal Ford erhalten, anscheinend gibt es das Buch doch

I’m just finishing it up now. All the writing is done, it’s just shuffling the content now.

Na dann ist ja gut.