Zustandsforschung

Hier ist wie jedes Jahr die Liste der Bücher, die ich im Verlauf des Jahres gelesen habe:

• Effective Java von Joshua Bloch:
  Quasi das Buch zur Java-Entwicklung überhaupt. Unbedingt empfehlenswert für jeden einigermaßen fortgeschrittenen Java-Entwickler.
• Der Wüstenplanet von Frank Herbert,
  Der Herr des Wüstenplaneten von Frank Herbert,
  Die Kinder des Wüstenplaneten von Frank Herbert,
  Der Gottkaiser des Wüstenplaneten von Frank Herbert,
  Die Ketzer des Wüstenplaneten von Frank Herbert,
  Die Ordensburg des Wüstenplaneten von Frank Herbert:
  Das war mein großes Leseprojekt dieses Jahr: Ich habe alle von Frank Herbert geschriebenen “Wüstenplanet”-Romane gelesen. Und obwohl es zusammen genommen ein sehr phantasievoll gestaltetes Science-Fiction-Epos ist, sticht doch der erste Roman was Qualität angeht, deutlich hervor. Für den gilt: absoluter Lesebefehl – auch wenn man nicht wirklich Science-Fiction-Fan ist. Den Rest muss man nicht unbedingt gelesen haben. Was mir aber insgesamt besonders gut gefallen hat, ist das Gefühl, das man vermittelt bekommt, dass nach den Ereignissen des ersten Buches das bewohnte Universum und vor allem eben der Wüstenplanet seine besten Zeiten hinter sich hat und nur noch ein verweichlichtes, verkommenes Abbild seiner selbst ist.
• Test-Driven Development By Example von Kent Beck:
  Wieder mal ein Fachbuch: Sehr anschauliche Einführung in das Prinzip “Test-Driven Development”.
• Walden; or, Life in the Woods von Henry David Thoreau:
  Henry David Thoreau zieht sich 1845 für zwei Jahre in eine Hütte zurück, um seine Vorstellung eines alternativen Lebensstils abseits der industrialisierten Konsumgesellschaft zu verwirklichen. Nach seiner Rückkehr hat er dieses Buch geschrieben, das seine Erlebnisse zusammenfasst. Mit seinem Fokus auf das Wesentliche ist er eine tolle Inspiration.
• Momo von Michael Ende:
  Ein Aufruf sich mehr Zeit zum Leben zu nehmen – verpackt in ein Kinderbuch.
• Jefta und seine Tochter von Lion Feuchtwanger:
  Aus ein paar Versen der Bibel hat Lion Feuchtwanger eine spannende Geschichte über die Gier nach Macht und die Beziehung eines Vaters zu seiner Tochter gemacht.
• Weisheit für Minimalisten von Peter Steiner:
  Eine Mischung aus Schwarzweißfotografien und kurzen Texten rund um das Thema “Minimalismus” (als Lebensstil). Sehr nett um immer mal wieder reinzuschauen und ein paar Seiten zu lesen.
• Effektive Softwarearchitekturen – ein praktischer Leitfaden von Gernot Starke:
  Eine Einführung in Softwarearchitektur entsprechend der unter arc42 frei verfügbaren Architekturvorlage. Das Buch liest sich recht leicht – den entsprechenden technischen Background mal vorausgesetzt und ich habe auch schon angefangen, die Architekturvorlage in meine Projekte einzubringen.
• Liebe und Abenteuer von Giacomo Casanova:
  Das Buch war ein Auszug aus den Memoiren von Casanova persönlich. Von den unterschiedlichsten Affären mal abgesehen, die Casanova für die damalige Zeit sehr deutlich beschreibt, hatte er auch ein sonst recht bewegtes Leben. Etwas verwirrend, da extrem viele Personen darin vorkommen, aber durchaus lesenswert.

In manchen Situationen kommt der Einsatz eines professionellen Profiling-Tools nicht in Frage. Das kann beispielsweise dann vorkommen, wenn es gilt, eine durch diverseste Firewalls geschützte Java-Applikation zu profilen und in der Firma, in der man arbeitet kein entsprechendes Tool eingesetzt werden kann oder darf (oder wenn der für das Tool zuständige “Experte” nicht greifbar oder nicht kooperativ ist).

Die JVM bringt aber auch ein eingebautes Profiling mit, das zwar nicht mit dem was eben die “richtigen” Profiler liefern vergleichbar ist, aber eben doch ganz brauchbar, wenn es darum geht herauszufinden, warum eine Applikation lahm ist. Die Funktion nennt sich hprof und viele kennen das vielleicht als Methode, um Heap-Dumps zu erzeugen. Aber das Ding kann noch mehr: um zu zeigen, wie man damit Performance-Probleme erkennen kann, verwende ich hier ein einfaches Beispiel, das Fibonacci-Zahlen rekursiv berechnet (der Source-Code für das Beispiel ist hier verlinkt).

Das hier ist die Java-Klasse, mit der wir die entsprechenden Daten erzeugen:

package example;
 
public class Fib {
 
	public long calculate(long n) {
		if(n == 0) {
			return 0;
		}
		if(n == 1) {
			return 1;
		}
		return calculate(n-1) + calculate(n-2);
	}
 
	public static void main(String[] args) {
		Fib fib = new Fib();
		System.out.println(fib.calculate(Long.valueOf(args[0])));
	}
 
}

Ruft man nun diese Klasse mit folgenden Parametern auf, erhält man eine Datei java.hprof.txt, die jede Menge Stack-Traces und am Ende eine Tabelle mit Profiling-Informationen enthält:

java -agentlib:hprof=cpu=times,depth=100 example.Fib 20

Den vollständigen Satz an möglichen Optionen erhält man mit java -agentlib:hprof=help oder im Artikel HPROF: A Heap/CPU Profiling Tool in J2SE 5.0.

Die Tabelle am Ende der Datei sieht ungefähr so aus:

CPU TIME (ms) BEGIN (total = 96) Wed Dec 07 16:53:53 2011
rank   self  accum   count trace method
   1 15.63% 15.63%    5020 301386 example.Fib.calculate
   2  9.38% 25.00%    4760 301385 example.Fib.calculate
   3  8.33% 33.33%    3632 301387 example.Fib.calculate
   4  7.29% 40.62%    2942 301384 example.Fib.calculate
   5  6.25% 46.87%    2026 301388 example.Fib.calculate
   6  5.21% 52.08%    1024 301389 example.Fib.calculate
   7  5.21% 57.29%     512 301390 example.Fib.calculate
   8  2.08% 59.38%     174 300332 java.lang.StringBuffer.append
   9  2.08% 61.46%    1152 301383 example.Fib.calculate
  10  1.04% 62.50%     256 301375 java.lang.Long.<init>
  11  1.04% 63.54%     256 301374 java.lang.Number.</init><init>
  12  1.04% 64.58%       1 301231 java.util.Hashtable.get
  13  1.04% 65.63%       5 301162 java.lang.StringBuilder.toString
  14  1.04% 66.67%       1 301111 java.io.FilePermissionCollection.<clinit>
  15  1.04% 67.71%       1 301031 java.io.Win32FileSystem.normalize
  16  1.04% 68.75%       1 300988 sun.net.www.protocol.file.FileURLConnection.getPermission
  17  1.04% 69.79%       1 300986 java.io.FilePermission.init
  18  1.04% 70.83%       1 300982 java.io.FilePermission$1.run
  19  1.04% 71.88%      44 300950 java.lang.StringBuffer.append
  20  1.04% 72.92%       1 300886 sun.net.www.protocol.file.Handler.createFileURLConnection
...

Hier kann man schon sehen, dass unsere Methode calculate() wohl nicht die schnellste ist. Außerdem sieht man noch, dass die langen Laufzeiten in dieser Methode in unterschiedlichen Threads immer mal wieder vorkommen.

Jetzt kann man in der gleichen Datei nach der Nummer, die in der Spalte trace steht suchen und findet dazu für die erste Zeile folgenden Thread

TRACE 301386:
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.main(Fib.java:Unknown line)

Hier kann man dann ablesen, dass es sich wohl um den rekursiven Aufruf handelt, der hier das meiste der Performance auffrisst. Wenn man Glück hat, dann stehen da auch noch die Zeilennummern dabei – warum das hier nicht der Fall ist, weiß ich ehrlich gesagt nicht.

Weil diese java.hprof.txt-Files gerne mal ziemlich riesig werden können und die Sucherei in den Files nicht wirklich Spass macht, habe ich ein kleines Python-Skript geschrieben, das die Files in eine HTML-Seite umwandelt, in der man per Klick von der Liste zu den Threads springen kann und wo man auch bestimmte Klassen ausfiltern kann, von denen man schon weiß, dass die nix mit dem Problem zu tun haben. Das Skript habe ich hprof2html getauft und es kann hier heruntergeladen werden: https://github.com/zustandsforschung/hprof2html

Nicht nur in der IT-Branche kommt es immer mal wieder vor, dass mehr Arbeit da ist als der normale Arbeitstag lang ist. Die übliche Reaktion der meisten Unternehmen ist es, zu versuchen diese zusätzlich benötigte Zeit durch Überstunden wieder reinzuholen.

Gleichzeitig ist das aber auch eine Reaktion, die sich früher oder später sowohl für den Mitarbeiter als auch für die Firma wieder rächt.

Die Konsequenzen für den Mitarbeiter selbst, der die Überstunden ableistet, muss ich glaube ich nicht wirklich detailliert betrachten – ich nehme mal an, das kennen die meisten selbst. Viel interessanter ist, warum es sich auch für die Firma selbst dann nicht lohnt, wenn die Überstunden “bereits mit dem Gehalt abgegolten” sind, wie es in Arbeitsverträgen oft formuliert wird.

Ich möchte hier zwei Aspekte aufgreifen, die ich für relevant halte.

Qualitätsverlust

Das hier nenne ich das “Eger’sche Überstundentheorem” :

Code, der nach 18 Uhr entsteht ist schlechter als Code, der vor 18 Uhr entsteht.

Meine eigene Erfahrung nicht nur an meiner Person, sondern auch was ich an meinen Kollegen beobachte, zeigt dass je später der Abend desto mehr lässt die Konzentration nach und wenn die Konzentration nachlässt werden die Arbeitsergebnisse meist nicht unbedingt besser. Ich wage auch zu behaupten, dass das nicht nur für Softwareentwickler gilt, sondern auch für andere Berufsfelder. Das gilt übrigens um so mehr, je länger die Periode, in der Überstunden geleistet werden andauert.

Schlechterer Code bedeutet mehr Fehler oder zweifelhafte Designentscheidungen, die es zwar kurzfristig erlauben, einen Termin zu halten, im späteren Verlauf des Projektes aber oft mehr Zeit kosten als hätte man es ausgeruht gleich richtig gemacht.

Know-How-Verlust

Wenn über einen längeren Zeitraum Überstunden zu leisten sind, dann ist es oft so, dass sich bei den Mitarbeitern eine gewisse Unzufriedenheit einstellt. Das kann unterschiedliche Gründe haben wie zum Beispiel

• Unzufriedenheit mit der wenigen Freizeit und weil das Privatleben darunter leidet oder
• Unzufriedenheit durch die weiter oben genannten Schwierigkeiten, gute Qualität abzuliefern oder
• Unzufriedenheit mit der Planung, die dazu geführt hat, dass die Überstunden überhaupt notwendig wurden.

Das Problem für den Arbeitgeber entsteht nun dadurch, dass unzufriedene Mitarbeiter sich auch gerne mal nach einem anderen Job umschauen. Besonders für die richtig guten Mitarbeiter ist es oft auch kein Problem einen anderen Job zu finden. Und mit jedem Mitarbeiter, der das Unternehmen verlässt, geht gleichzeitig auch ein gewisses Maß an Know-How für das Unternehmen verloren.

Ich verstehe natürlich, dass es notwendig sein kann mal über den Zeitraum von ein paar  Wochen länger zu arbeiten, weil irgendwelche unvorhergesehene Dinge passiert sind oder eine Deadline droht. Wenn allerdings über einen längeren Zeitraum kontinuierlich immer wieder Überstunden geleistet werden müssen, dann macht die Firma was falsch.

Wer gerne noch mehr wissen möchte:

• The Problem with Working Overtime
• Teamicide Revisited
• “Overtime is part of the job” true but a bad attitude?

Ein Detail, das mich an meiner ansonsten ziemlich perfekten Mythbox noch gestört hat, war dass das Herunterladen der Fanart (Hintergrundbilder für den “Watch Recordings”-Screen) nur für Serien funktioniert hat. Für Filme hat es leider nicht funktioniert und in diesem Artikel geht es nun darum, wie ich es geschafft habe, verschiedene Skripte meiner MythTV-0.23-Installation so zu patchen, dass es doch funktioniert.

Den Rest dieses Eintrages lesen »

Seit mittlerweile ungefähr eineinhalb Jahren ist bei mir ein selbstgebastelter MythTV HTPC im Einsatz. In diesem Artikel werde ich ein bisschen von meinen Erfahrungen berichten.

Ich glaube, dass MythTV die Art, wie wir – also meine Frau und ich – Fernsehen schauen grundlegend verändert hat. Wir hatten vorher auch schon einen Festplattenrecorder, aber MythTV bringt einfach so viele nette Features mit, dass wir mittlerweile eigentlich gar nicht mehr anders Fernsehen.

Den Rest dieses Eintrages lesen »