My Linguistic Profile

Your Linguistic Profile:

50% General American English 30% Yankee 10% Dixie 5% Upper Midwestern 0% Midwestern

What Kind of American English Do You Speak?

Buchtipp: Programming Collective Intelligence

Meine neueste Buchanschaffung und Buchtipp ist
"Programming Collective Intelligence" von Toby Segaran.

Was der Titel elegant verschweigt (vielleicht um potenzielle Käufer nicht abzuschrecken): Das Buch ist Machine-Learning angewendet auf moderne Web-Anwendungen. Das Inhaltsverzeichnis offenbart dies sehr deutlich. In dem Buch werden behandelt:

• Clustering (Item-based und Hierachisches)
• Künstliche Neurale Netzwerke
• Stochastische Optimierung (Hill-Climbing, Simulated Anneling, etc)
• Support Vector Machines
• Naive Bayesian Classifier
• Decision Tree Learning
• Genetic Programming
• Nicht-negative Matrix Faktorisierung

Dies ist schon eine ziemlich beeindruckende Liste von Verfahren. Viel mehr steht im "Mitchell" auch nicht.

Eine Besonderheit des Buches ist die absolute Abwesenheit von Pseudocode. Jeder Algorithmus wird in lauffähigen Python-Code dargestellt. Bei einigen komplexeren Ansätzen finde ich Pseudocode immer noch lesbarer, aber so sinkt die Hürde mit den Algorithmen direkt "zu spielen" ungemein.

Hinzu kommt, dass für jeden Ansatz auch immer praktische Beispiele für das Web angegeben werden. Es werden u.a. Empfehlungen auf Basis von del.icio.us-Daten gegeben, Personen auf Facebook gematcht und Preise auf eBay geschätzt. Alles extrem aktuelle Anwendungen inkl. Input (meist: HTTP-Request and Rest-Webservice und XML parsen) und Output z.B. ein Entscheidungsbaum als Image exportieren) der Ansätze, die in Python-Code dargestellt werden.

Ein weiteres Highlight des Buches z.B. im Vergleich zur Vorlesung "Maschinelles Lernen" ist in meinen Augen die Diskussion über die Auswahl und Parametrisierung der Ansätze. Es wird dargelegt, wann welcher Ansatz möglicherweise bessere Ergebnisse liefert, aber auch welche Auswirkungen Parameter haben und z.B. auch die tendenziellen Unterschiede zwischen Gini-Koeffizienten und Entropy beim Entscheidungsbaum-Lernen. In der Vorlesungen werden die Verfahren zwar skizziert, aber es gibt keine Beispiele realistischer Größe oder andere Hilfestellungen. Dies ist in der Form auch nicht unbedingt Aufgabe der Vorlesung. Ich sehe das Buch deshalb komplementär zur Vorlesung.

Diesen Zweck erfüllt das Buch meiner Meinung nach hervorragend und es macht Lust die Beispiele sofort zu nehmen, auszuführen und weiterzuentwickeln.

Allerdings sind einige Ansätze schon ziemlich abgefahren - Wird genetische Programmierung tatsächlich irgendwo eingesetzt? Auch habe ich teilweise das Gefühl, dass mehr Hintergründe/Theorie notwendig sind, um einige Ansätze auf neue Probleme anwenden zu können. Ob für Entwickler ohne Informatik-Background eine 2-seitige Einführung in Lineare Algebra ausreicht, um nicht-negative Matrixfaktorisierung auf andere Problemen anwenden zu können, bezweifele ich.

Artikel über Unittesting (in .NET)

Als ich noch vor zwei Wochen bei dem Wort "JUnit" angeguckt wurde wie ein Alien und nachdem etwas schief gegangen ist hämische Bemerkungen kamen, habe ich wieder bemerkt, dass Unittesting von den meisten Uni-Absolventen immer noch nicht wirklich wahrgenommen wird.

Da kommt es mir gerade gelegen, dass Karl Sequin diese Woche einen ausführlichen Artikel über die Unittesting veröffentlicht hat. Die von ihm vorgestellte Toolchain ist zwar auf .NET ausgerichtet, aber ersetze NUnit durch JUnit und RickoMock durch jMock und auch der Toolchain-Abschnitt ist weiterhin grundsätzlich gültig:

Sein Fazit ist:

But after my first project [using unit testing], I learnt a lot about what did and didn't work. One thing that immediately became clear was how much cleaner my code became. I quickly came to realize that if something was hard to test and I rewrote it to make it more testable, the entire code became more readable, better decoupled and overall easier to work with. The best advice I can give is to start small, experiment with a variety of techniques, don't be afraid to fail and learn from your mistakes. And of course, don't wait until your project is complete to unit test – write them as you go!

Der Artikel ist Teil der Serie "Foundations of Programming", die insgesamt sehr lesenswert ist.

Die Prüfungsordnung: Notenberechnung im Master

Für eine Bewerbung soll ich gerade meine Master-Endnote schätzen. Zeit einmal in die Prüfungsordnung die Notenberechnung nachzulesen. Im Gegensatz zur komplizierten Berechnung im Bachelor ist es erstaunlich einfach:

Die Note nach §19(2) setzt sich auf folgenden Elementen zusammen *:

• Modulnote "Softwaretechnik" (8 ECTS)
• Modulnote "Eingebettete Systeme und Systemsoftware" (8 ECTS)
• Modulnote "Modelle und Algorithmen" (8 ECTS)
• Modulnote "Mensch-Maschine-Wechselwirkung" (8 ECTS)
• Modulnote "Vertiefungsmodul" (8 ECTS)
• Modulnote "Projektgruppe" (8 ECTS)
• Modulnote "Nebenfach" (12 bzw. 10 ECTS bei Wiki)
• Note Abschlussprüfung (16 ECTS)
• Note Master-Arbeit (50 ECTS)

Wichtig ist die Beschränkung der Projektgruppe auf 8 ECTS-Punkte anstatt der 26 ECTS, die ihr nach der normalen auf der Zeit-basierenden Rechnung zustehen würden.
Die Master-Arbeit hat damit einen Anteil von 40% an der Gesamtnote. Die Abschlussnoten (Masterthesis, Abschlussprüfung) machen insgesamt mehr als 50% aus. Wenn ich damit zum Zweck meiner Recherche zurückkehre: Eine Schätzung der Gesamtnote ist nicht wirklich möglich. Aber immerhin ist die Note hier einfach zu berechnen.
* Ich gehe hier der Einfachheit wegen davon aus, dass die Projektgruppe in dem Vertiefungsgebiet absolviert wird. Wenn dies nicht der Fall ist, dann muss eines der Modulnoten durch das 3. Modul im Vertiefungsgebiet ausgetauscht werden.

Video: High-Performance Wordpress

This is a video about scaling the blogging site wordpress.com using techniques like WP-Cache and horizontal database partitioning using a "a plugin" called HyperDB.

The video is really interessing, but I woundered about the calculation of the maximal number of pages views possible with several configurations. The speaker claimed for example that the base wordpress installation can handle 8 requests per second and the can therefore handle 691.000 requests a day. But this is only true if the requests are uniformly distributed around the day.

When I plan to handle the requests even at the peak times (I mean day peak times not really extraordinary events like a Digg-attack), you can handle 8 requests per second at the peak, not on the average. Using the average over-the-day distribution of juli-blogs.de (based on the hours average) with peaks at 19h, I get a number that is smaller by more than a factor of 4. And even that is highly aggregated and not conservative calculation. Ok, even that number is clearly high enough for most wordpress sites (sure for dirkmeister.de ;-) )

Alte Erinnerungen

Vor vielen Jahren war ich während meiner Wehrdienstzeit u.a. als Rollenspieler ("darstellender Soldat") in der Ausbildung für Auslandseinsätze eingesetzt. Es war eine interessanter, aber auch harte Zeit.

Das Video "Wie die Bundeswehr auf Extremsituationen in Auslandseinsätzen vorbereitet" von zeit.de gibt einen kleinen Einblick in eine solche Ausbildungsarbeit (nicht meine!). Die Szenen mit dem Sozialwissenschaftler kann man dabei mal getrost ignorieren.

Die Prüfungsordnung: Vorlesungen auf Englisch

Es gibt doch immer wieder Kleinigkeiten in der Prüfungsordnung, die im Zweifelsfall extrem wichtig (um nicht zu sagen Studiums-verlängernd) sein können.

Heute: Englisch in der Master-Prüfungsordnung

§3(3): Alle Studierenden müssen Module und zugehörige Prüfungen im Hauptfach mit einem Umfang von mindestens 24 Leistungspunkten in englischer Sprache absolvieren.

Artikel §16(5) konkretisiert diese Anforderung weiter:

Module und zugehörige Prüfungen im Hauptfach mit einem Umfang von mindestens 24 Leistungspunkten müssen in englischer Sprache absolviert werden. Dies bedeutet im Rahmen dieser Ordnung, dass Vorlesungen bzw. Materialien in englischer Sprache gehalten werden bzw. vorliegen und die Prüfungen einen englischsprachigen Anteil von mindestens einem Drittel besitzen.

24 Leistungspunkte entsprechen 6 Master-Vorlesungen. Von den 10 normalen Vorlesungen, die man mit Hauptfach absolviert müssen also 6 auf Englisch sein. Das ist mal ordentlich. Bisher bin ich immer davon ausgegangen, dass ich relativ viele Vorlesungen auf Englisch gehört habe, aber so viele sind es dann auch wieder nicht - Woher auch nehmen, wenn nicht stehlen? So viele Vorlesungen werden ja auch nicht auf Englisch angeboten.
Und auch hier gilt mal wieder meine Aufforderung: Bitte weniger Einschränkungen im Studium. Ich möchte die Vorlesungen mit interessanten Themen belegen. Solche Regeln zwingen Studenten dazu Vorlesungen nach derartigen - ich nenne es mal so - willkürlichen Regeln auszuwählen anstatt nach Schwerpunkt.

Ahlblog: Der Wert kleiner Klassen

Eine Schande, dass ich das "Ahlblog" von Martin Ahlborg nicht schön früher erwähnt und verlinkt habe. Die kleinen Programmiertipps und seine Gebote für Programmierer sind schon lange eine Erwähnung wert gewesen.

Herausgepickt habe ich mir hier den Artikel "Klein aber Fein - Der Wert kleiner Klassen" vom 3. September. In diesem Artikel beschreibt der Autor die Daumenregel, dass Klassen nicht zu groß werden sollten.

Klassen können [...] zu groß werden, weil sie borgmäßig Aufgaben von anderen Klassen assimilieren. In vertikaler Richtung kann eine Klasse beispielsweise gleichermaßen Highlevel- und Lowlevel-Funktionen haben. Dieses Problem findet man oft bei Kommunikationsschnittstellen. Da gibt es dann eine Klasse, die sowohl die ganzen Lowlevel-Kommunikationsdetails kapselt als auch Funktionen, die eigentlich ins Datenmodell gehören. In horizontaler Richtung kann eine Klasse Funktionalität implementieren, die eigentlich auf mehrere Klassen aufgeteilt werden sollte. Man kann dies gut erkennen, wenn man einen Teil der Klasse entfernen kann, ohne den Rest kaputt zu machen.

Was bringen mir eigentlich kleine Klassen? Nun, hauptsächlich wird man flexibler. Programme lassen sich leichter erweitern, da sich Erweiterungen auf die Implementation neuer Klassen und hier und da ein paar kleinen Codeänderungen beschränken. Ebenso erhöht sich die Wiederverwendbarkeit des Codes. Dadurch kommen weniger Codewiederholungen vor, eine der Hauptursachen für so richtig fiese Bugs.

Kleine Klassen lassen sich auch besser testen. Große Klassen tendieren dazu, viel Funktionalität intern zu kapseln. Es gibt keine Möglichkeit diese Funktionen direkt zu testen. Nutzt diese Klasse jedoch andere Klassen, die jeweils einen Teilbereich der Funktionen implementieren, dann lässt sich dieses Konglomerat besser testen, weil ich damit quasi Testschnittstellen geschaffen habe. Ich kann jetzt interne Funktionen testen, ohne dass ich Raum und Zeit verbiegen muss.

Meiner Erfahrung nach, ist die Regel, dass eine Klasse nur reine Aufgabe haben sollte, die entscheidendere und passendere Daumenregel. Eine Folge dieser Regel sind dann meist kleinere Klassen. Deshalb störe ich mich auch etwas an dem Hinweis auf 400 Lines of Code (aber auch der Autor sieht es nur als ungefähren Wert). Dennoch ein gut geschriebener, lesenswerter Artikel wie (ich befürchte ich wiederhole mich) viele Artikel in dem Blog.
"Head First Design Pattern" nennt diese Regel "Eine Klasse sollte nur einen Grund haben sich zu ändern", aber im Endeffekt läuft es auf das Gleiche hinaus.

TR: A Pattern Language for Overlay Networks

Durch Zufall bin ich auf ein interessantes Paper zum Softwareentwurf von Peer-to-Peer-Systemen gestoßen: "A Pattern language for Overlay Networks - Design Patterns in Peer-to-Peer Systems " von Dominik Grolimund, ETH Zurück und heute Entwickler des P2P-Storagesystems Wua.la.

Durch eine Untersuchung des Quellcodes von zahlreichen Open-Source-P2P-Systemen aus dem praktischen und dem akademischem Umfeld (von LimeWire über Bamboo to FreePastry) hat der Autor des technisches Berichtes erfolgreich verwendete Lösungen für häufige Entwurfsprobleme (Pattern) extrahiert. Die Pattern gliedern sich in die Abschnitte "Application Interaction", "Messages", "Message Handling", "Routing", "Local Node", "Protocol", "Remote Node" und "Network Interaction".

Ich finde den Artikel schon deshalb interessant, weil er sich mit dem Softwaredesign von P2P beschäftigt. Normalerweise liegt der Fokus in dem Bereich quasi ausschließlich auf dem Systementwurf. Aber reale Systeme mit der hohen Komplexität brauchen auch ein angemessenes Softwaredesign.

Da Algorithmen für Sensornetzwerke aus der Softwaredesignperspektive eine hohe Ähnlichkeit mit Peer-to-Peer-Systemen (aus Systemdesignsicht ist dies so nicht der Fall, aber auch dort existieren Gemeinsamkeiten) ausweisen, wäre der technische Bericht auch in der Projektgruppe hilfreich gewesen. Wir müssen zwar nichts "real" implementieren (Pattern wie "Abstract Node Handle" sind dann nicht notwendig), aber viele der Pattern wären auch in den simulierten Algorithmen und den verwendeten Simulator sinnvoll einsetzbar gewesen. Zu spät.

P.S. In der Sidebar dieses Blogs werden nun auch neben meinen öffentlichen del.icio.us Bookmarks (RSS) auch die öffentlichen CiteULike-Bookmarks (RSS) aufgelistet. Die automatisch generierten del.icio.us-Artikel wird es nicht mehr geben.

dirkmeister.de up

May be you noticed it. dirkmeister.de is up again and I rescued some of the articles. Most of them through the unreleased Google Reader API and some other using archive.org and the Google Cache.

However, some of the articles are gone (I assume forever). Particularly most of the longer articles (e.g. the Java Concurrent Series) are lost.

HNF-Ausstellung: Fahren ohne Fahrer

Am Sonntag startet die neue HNF-Sonderaustellung "Fahren ohne Fahrer".

Es ist schon ein paar Jahre her, dass ich in dem Museum gewesen bin, obwohl ich quasi jeden Tag vor dessen Tür her gehe. Aber diese Austellung muß ich sehen!

Schon alleine wegen "Stanley", dem Gewinnerauto des "Grand Challenge"-Wettbewerbes. Auf der Webseite heisst es dazu:

Das Heinz Nixdorf MuseumsForum zeigt vom 9. Dezember bis 24. Januar zwei Modelle, die ohne Fahrer hinter dem Lenkrad auskommen. Der VW Touareg „Stanley" hat Technikgeschichte geschrieben und als erstes Auto vor zwei Jahren die „Grand Challenge" gewonnen. 23 Fahrzeuge waren für das Rennen zugelassen worden, weniger als ein Viertel erreichten nach 220 Kilometern durch die Mojave-Wüste das Ziel. Als zweites Auto präsentiert das HNF den Golf GTI 53+1, dessen Name auf den berühmten Filmkäfer verweist. Er ist in der Lage, einen Hütchenparcours ohne Fahrer schneller zu fahren als mit.

Zur Einstimmung nochmal das "Winning The DARPA Grand Challenge"-Video: Coole Fahrszenen und einige Skizzen der dahinter liegenden Machine Learning-Algorithmen.

Wer kommt mit?

How addicted to Apple are you?

The website justsayhi.com asks "How addicted to Apple are you"?

The result of me:

54%How Addicted to Apple Are You?

Someone already said: "as little?".

dirkmeister.de down

Due to a hard disk crash on the server dirkmeister.de is down. During the next days I will try to bring it back. I hope that I can rescue the old articles.

Vergleich von Generics in Java und C#

Jonathan Pryor vergleicht in dem Artikel "Comparing Java and C# Generics" die Umsetzung von Generics in Java und C#.
Er erklärt dabei die Gemeinsamkeiten und Unterschiede in Syntax und vor allem Semantik. Dabei geht er auch auf die weniger bekannten Funktionen wie die Möglichkeit weitere Typbedingungen zu definieren (in Java z.B. "T extends Number & Comparable<T>", in C# z.B. "where T : Comparable<T>") und Typwildcards ein.
Der größe Unterschied zwischen Java- und C#-Generics ist, dass Java-Generics ausschließlich zur Compile-Zeit verfügbar sind. Zur Laufzeit sind Genericinformationen nicht verfügbar.

Der Grund für dieses "type erasure " ist, dass man bei Java 5.0 Änderungen an dem Classfile-Format und der Java Virtual Machine absolut vermeiden wollte (eine Anforderung, die man am Ende doch nicht durchhalten konnte) und es außerdem eine einfache Zusammenarbeit von generifizierten Code und Legacy-Code erlaubt.
Dies klingt erst einmal harmlos, aber wie Jonathan begründet, muß man sich dieser Eigenschaft bewußt sein, wenn man generifizierten Code schreibt. Das zentrale Beispiel für einen der Fallstricke ist:

HashSet<String> set1 = new HashSet<String>();
HashSet<Integer> set2 = new HashSet<Integer>();
set1.equals(set2); // ist wahr
set1.getClass().equals(set2.getClass()); // ist auch wahr

Während man mit dem Ergebnis des 1. Vergleiches noch rechnen kann, überrascht das Ergebnis des 2. Vergleiches doch sehr. Es gibt in Java keine Möglichkeit zur Laufzeit Klassen auf Grund von generischen Typinformationen zu unterscheiden. Sobald die Typprüfungen des Compilers z.B. durch Reflektion umgangen werden, wird man bei falscher Verwendung wieder ClassCastExceptions erhalten genauso wie "früher". Bei C++ und C# bleiben die Typinformationen auch zur Laufzeit erhalten.

Sein Fazit gibt er schon in dem Untertitel bekannt. Er lautet "Whats Wrong With Java Generics":

The generics capabilities in Java and .NET differ significantly. Syntax wise, Java and C# generics initially look quite similar, and share similar concepts such as constraints. The semantics of generics is where they differ most, with .NET permitting full runtime introspection of generic types and generic type parameters in ways that are obvious in their utility (instance creation, array creation, performance benefits for value types due to lack of boxing) and completely lacking in Java.In short, all that Java generics permit is greater type safety with no new capabilities [...].Contrast this with C#/.NET, where the above code isn’t possible, as there are no raw types, and converting a List to a Listwould (1) require an explicit cast (as opposed to the complete lack of casts in the above Java code), and (2) generate an InvalidCastException at runtime from the explicit cast.Furthermore, C#/.NET convey additional performance benefits due to the lack of required casts (as the verifier ensures everything is kosher) and support for value types (Java generics don’t work with the builtin types like int), thus removing the overhead of boxing, and C# permits faster, more elegant, more understandable, and more maintainable code.

Ich sehe nur einen praktischen Vorteil der Java-Umsetzung. Dort hat man nicht die Mühe geschaut, die bestehende Bibliothek zu "generifizieren". Damit ist gemeint, dass bestehende Klassen die Möglichkeiten von Generics ab Java 5.0 intensiv nutzen. Die bekannteste Anwendung sind zweifelslos die Collections-API, aber auch das Comparable-Interface, ThreadLocal und (interessanterweise) die Klasse Class nutzen Generics intensiv.

Bei C# hat man keine bestehende Klasse angepasst. Die neuen Möglichkeiten werden den Framework-Bibliotheken auch deshalb wesentlich weniger verwendet. Schlimmer: Für die Collections-Klassen gibt es mehrere Versionen: Einmal die herkömmliche Version und einmal die generische Version. Wie es sich gehört, auch mit einigen Namensänderungen (z.B. Hashtable vs. Directory).

Normalerweise gilt die Regel, dass man eine API beim ersten Mal richtig machen muss, da es schwierig bis unmöglich ist, eine API für die Code exisiert zu ändern. Bei Generics gibt es aber vielleicht in Java 7 die Chance die generischen Typinformationen zur Laufzeit zu Erhalten ohne bestehenden Code zu brechen. Dies meint zumindest Neal Gafter in "Reified Generics for Java". Eine Übersicht über die Änderungen, die zu Java 7 kommen könnten(!), findet man im Blog "Pure Danger Tech".

Ich glaube, dass der Artikel gut die Ansätze vergleicht und den Vorteil der C#-Version herausarbeitet. Zum Teil geht er vielleicht etwas zu hart mit Java-Generics ins Gericht.

Bad News: Kein Java 6 in Leopard

Von Blue’s Blog gestiftete Leopard-Konsolenausgabe:

Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-237)
Java HotSpot(TM) Client VM (build 1.5.0_13-119, mixed mode, sharing)

Apple hat keine neue Java-Version zusammen mit Leopard veröffentlicht.

Naja, irgendwie war damit zu rechnen, weil Java 6 schon nicht in der 300 Einträe umfassenden Neuerungenliste von Leopard aufgetaucht war, aber enttäuschend ist es schon. Java 6 ist nun nicht brandneu (schon über ein Jahr) und bald werden wohl auch die ersten Projekt auftauchen, die Java 6 only sind (z.B. evtl. Glassfish 3).

Googlemail bekommt IMAP

GMail/Googlemail integiert (langsam) IMAP Zugriff auf die Mailpostfächer.

Bisher hat GMail nur POP3 Zugang unterstützt. Die zusätzliche IMAP-Funktion ist wirklich ein großer Schritt nach vorne, wenn es darum geht GMail mit Mail.app oder anderen E-Mail-Clients zu verwenden.
Statusänderungen wie Lesen und Löschen* werden automatisch mit dem Online-Postfach synchronisiert.

Die neue Funktion wird offensichtlich nur langsam unter den Benutzer ausgerollt. In meinen Einstellungen erscheint immer noch nur "POP3 Download". Aber die Supportdokumente sind online und so wird die Funktion wohl früher oder später jeden erreichen.

via Downloadsquard

* Leider nicht als Archivieren verstanden, sondern als Verschieben in einen Ordner "Deleted Items".

Meine Wintersemester-Planung

Es ist eine gute Tradition hier an dieser Stelle die Vorlesungsplanung für das nächste Semester vorzustellen.*

In diesem Jahr ist es unklarer als sonst, weil ich nicht mehr so viel Zeit (noch 2 Semester) habe die Vorlesungen zu hören.

Gesetzt:

• "Operating Systems" bei Prof. Rammig
• "Rechnernetze (Seminar)" bei Prof. Karl
• "Projektgruppe Orcos" bei Prof. Rammig

Noch unklar (1, 2 oder 3 werden überleben)

• Philosophie der Technik (Studium Generale)
• Leistungsbewertung und Simulation
• Maschinelles Lernen
• Web-Engineering
• Verteiltes Problemlösen

[*] Die ebenso gute Tradition der VKrit ist wegen technischer Probleme (iBook!) doch leicht in Verzug. Ich versuche aber die Texte über die Vorlesungen des letzten Semesters noch zu schreiben.

Wo bleibt .NET auf dirkmeister.de?

Es gab gestern eine "Beschwerde", dass ich an dieser Stelle zu viel über Java schreibe und kaum über .NET, auch wenn ich mit C#-Entwicklung (zumindest in den letzten zwei Jahren) einen nicht unerheblichen Teil meines Lebensunterhaltes bestritten habe.
Eine Kritik, die wohl nicht ganz unberechtigt ist.

Ich weiß nicht ob dies nach gestern noch zu ändern ist, aber ich kann ja damit beginnen die Webseiten und Blogs zum Thema C#/.NET zu nennen, die ich im Feedreader abonniert habe:

• Ganz vorne zu nennen wäre hier: CodeBetter.com. Ein Gemeinschaftsblog von 16 .NET Entwicklers, wovon 9 MVPs sind. Ein Focus ist dort im Moment ALT.NET mit alternativen .NET-Frameworks wie NHibernate, MonoRails, etc.
• Peter Bromberg’s UnBlog ist das .NET Blog von (offensichtlich) Peter Bromberg, ebenfalls ein MVP. Dort schreibt er über alle möglichen Themen aus dem .NET Umfeld und insbesondere neue Entwicklungen und Technologien.
• Quasi das Lokal-Blog: OutOfCoffeeException ist das Blog des UPB-Informatikstudenten und Microsoft Student Partner Matthias Raacke. Manchmal erscheint es mir etwas zu werbemäßig. Deshalb mit etwas Vorsicht zu geneißen.
• Die Blogs der Commerce Server Entwickler David Messner, Ryan R. Donovan und Vinayak Tadas haben mir bei der Entwicklung mit dem Microsoft Commerce Serer (2k3, 2k7) wirklich weitergeholfen. Die Dokumentation des Commerce Servers ist definitiv suboptimal. Tipps und Tricks über die MSDN-Doku hinaus, gibt es dort!
• Interessant finde ich auch den Ansatz von Adam Esterline nach C# Puzzlers (1, 2) ähnlich zu den Java Puzzlers zu suchen. Allerdings glaube ich nicht, dass die direkte Übersetzung von "Java Puzzler" in "C# Puzzler" erfolgversprechend ist. C# wird ganz eigene Cornercases haben.

Double != double

In Java existieren von je her für alle primitiven Typen wie int, double entsprechende Wrapperklassen. Für int ist dies die Klasse java.lang.Integer. double hat java.lang.Double als Gegenstück.

Die Verwendung von Wertdatentypen in Sammlungsklassen wie ArrayList oder HashMap war immer etwas beschwerlich. Die Collections-Klassen können nämlich nur mit echten Objekten umgehen. Wie man an dem nachfolgenden Beispiel sieht, muß man beim Einfügen und Herausholen eine manuelle Konvertierung - Boxing - vom primitiven Typ in das Wrapperobjekt durchführen:

int i = 99; //value to add
List list = new ArrayList();
list.add(Integer.valueOf(i));
[...]
int j = list.get(0).intValue();

Mit Java 1.5 wurde neben den Generics (oben schon gesehen) auch das so genannte Auto-Boxing eingeführt. Damit wird, wenn notwendig, automatisch eine Konvertierung zwischen primitiven Typen und den entsprechenden Wrapperklassen vorgenommen. Das gleiche Beispiel sieht unter Java 1.5 so aus:

int i = 99;
List list = new ArrayList();
list.add(i);
[...]
int j = list.get(0);

Der Code ist offensichtlich wesentlich aufgeräumter, aber Auto-Boxing ist primär "Syntactic Sugar", weil die notwendigen Methodenaufrufe (und Casts) immer noch ausgeführt werden.
Sie müssen nur nicht mehr explizit niedergeschrieben werden.

Auch in vielen anderen Fällen kann man mit den Objekten auf den ersten Blick so rechnen wie mit den Werten. Dies ermöglicht zum Beispiel diesen (realen) Code:

public final Double getDuration() {
if (duration == 0.0) {
duration = syncDuration + headerLength * secPerByte;
duration += enclosedPacket.getDuration();
}
return duration;
}

Konzeptionell sähe die Methode bei der Ausführung so aus:

public final Double getDuration() {
if (duration == 0.0) {
duration = syncDuration + headerLength * secPerByte;
duration += enclosedPacket.getDuration().doubleValue();
}
return Double.valueOf(duration);
}

Dieses Beispiel zeigt aber auch warum man stets zwischen Double und double unterscheiden sollte, auch wenn es so aussieht, als ob man den Unterschied weitgehend ignorieren könnte.

Performance

Ein Profiling der Anwendung, aus der dieses Codestück stammt, hat ergeben, dass die Anwendung 38% der Zeit in der Methode Double.valueOf verbringt und 14% der Zeit in Double.doubleValue.
Die Aufrufe sind nicht direkt erfolgt, sondern diese Methoden werden "unsichtbar" durch das Autoboxing erzeugt. [*]

Die Performance der Anwendung wurde halbiert auf Grund des Unterschiedes zwischen Double und double - Ein Buchstabe, Große Wirkung!

Nur weil man die Methodenaufrufe im Vergleich zu Java 1.4 nicht mehr sieht, sind sie trotzdem nicht weg. Der Unterschied zwischen Objektdatentyp und Werttyp ist nicht aufgehoben, sondern nur die Konvertierung ist einfacher. Die Methoden Double.valueOf und Double.doubleValue sind absolut triviale Methoden, aber es kann sich aufsummieren. In diesem Fall auf 50% der gesamtes Laufzeit. [**]

NullPointerExceptions

NullPointerExceptions (NPE) sind schon in normalen Fällen eine böse Sache, weil sie keinen wirklichen Hinweis darauf geben, was die wahre Ursache für den Fehler ist. Oftmals liegt der Fehler, der zu einer NullPointerException führt, an einer ganz anderen Stelle im Code als der Ursprung der Exception. Nicht umsonst liest man oft den Rat Nullen gar nicht erst in den Code zu lassen.

Noch schlimmer sind NullPointerExceptions, die durch Autoboxing entstehen.
Was passiert bei folgenden Code:

Integer obj;
[a lot of lines]
int i = obj * 10;

Richtig. Es wird eine NullPointerException geworfen, da obj nicht auf eine Referenz gesezt wurde. Wäre obj vom Typ int, so wäre es perfekt legaler Code bei dem i = 0 wäre.
Jeder Versuch ein auf null gesetztes Nummernobjekt automatisch zu konvertieren, endet in einer NPE.
Während es bei normalen NPE noch den Dereferenzierungsoperator "." als Hinweis gibt, sind Autoboxing-NPE quasi unsichtbar.

Mit Nummernobjekten ist es auch aufwändiger über die Korrektheit zu argumentieren. Der mögliche Zustandsraum ist um diesen elenden null-Fall größer als bei Werttypen. Man muß stets überlegen, ob das Objekt an der Codestelle null sein kann und wie darauf reagiert werden muß z.B. durch eine extra Prüfung auf != null oder eine inhaltlich sinnvolle Exception wie IllegalArgumentException.

Die Möglichkeit eine Variable auf null zu setzen fügt dem Zustandsraum eine zusätzliche Äquivalenzklasse hinzu, über die man extra nachdenken und die man i.d.R. mit eigenen Testfällen testen muß.

Beachtet man diesen wichtigen Unterschied nicht, so führt dies schnell zu ziemlich fragilen, unrobusten Programmen.

Vergleich zu C#

C# hat hier das Glück des Zweitgeborenen. Es konnte aus den Ungereimtheiten von Java lernen und dort wurde die Problematik gelöst, in dem int, long, etc. weitgehend normale Objekte sind und so auch in Collections eingefügt werden können. Der wichtigste Unterschied zu normalen Objekten ist, dass man die Wertobjekte nicht auf Null setzen kann. Mit .NET 2.0 wurde diese Möglichkeit durch eine Spracherweiterung (int?, double?, ...) nachgeliefert.

double ist dort nur ein Alias für den Frameworktyp System.Double. Vielleicht ist dies auch der Grund für den performance-hungrigen Code oben. Unter C# würde es dort kein Problem geben. Möglicherweise war der Entwickler eher in der C#-Welt zu Hause.

Fazit

Die Nummbernobjekte und Auto-Boxing sollten primär in Zusammenhang mit den Collections-Klassen oder ähnlichen Anwendungsfällen verwendet werden.
Im Zweifel kann man die Nummernobjekte auch verwendet, wenn man ausdrückten muß, dass ein Wert nicht gesetzt wurde (null).

Oftmals ist dies auch keine so gute Idee, aber es ist doch auf jeden Fall besser als Double.NaN und normalen Vergleichoperating für diesen Zweck einzusetzen (wie in der gleichen Anwendung an anderer Stelle gesehen).

Für alle anderen Fälle insbesondere in Berechnungen sollte man eher die Werttypen verwenden.
Die Dokumentationsseite der Java-API sagt dazu auch:

So when should you use autoboxing and unboxing? Use them only when there is an "impedance mismatch" between reference types and primitives, for example, when you have to put numerical values into a collection. It is not appropriate to use autoboxing and unboxing for scientific computing, or other performance-sensitive numerical code.

An Integer is not a substitute for an int; autoboxing and unboxing blur the distinction between primitive types and reference types, but they do not eliminate it.

1) Es gab noch ein paar Nummernobjekte in der Anwendung (, die bis auf eine Ausnahme alle besser Werte gewesen wären. 2) Ich bin der erste der zugeben würde, dass die Duration-Berechnung auch unabhängig von der Verwendung des Double-Objektes unglücklich entworfen und implementiert ist 3) Es ist nicht allein dieser Codestück für das Profilresultat verantwortlich, aber es war das zentrale Problem.

* Dieses Beispiel ist in meinen Augen auch ein Musterbeispiel für den Optimierungsgrundregel, dass man - wenn möglich - auf Basis von Messungen optimieren sollte. Diese kleine unscheinbare Methode war das absolute Performancebottleneck. Nur durch "scharfes Hinsehen" hätte man dies niemals herausfinden können.

Entire Berkeley Lectures on YouTube, More to Come

[Why I write English articles once in a while] The famous "University of California, Berkeley" makes some of its entire lectures freely available on YouTube.

The press release states that

UC Berkeley is the first university to make videos of full courses available through YouTube. Visitors to the site at youtube.com/ucberkeley can view more than 300 hours of videotaped courses and events. Topics range from bioengineering, to peace and conflict studies, to "Physics for Future Presidents," the title of a popular campus course. Building on its initial offerings, UC Berkeley will continue to expand the catalog of videos available on YouTube.

Unfortunately, up to now there aren't any Computer Science courses are available on YouTube. But the old webcast site of Berkeley doesn't seem to be dead. There you can stream videos of lectures using the RealPlayer (since 2001!). It would be great if Berkeley would replace the streaming with YouTube since the RealPlayer streaming is very unrelyable even with 4k DSL. Even better than YouTube would be a "real" video podcast, but I assume that would cause to much traffic.

One of the lecures the university is offering on the old webcast site is "Operating systems and system programming", the Berkeley analog to "Konzepte und Methoden von Systemsoftware". It is nice to see how Paderborn (or better Prof. Karl) performs in a (more or less) direct comparision to John Kubiatowcz, one of the fathers of the P2P systems OceanStore and Tapestry.

Since I haven'€™t it done before, it is also worth to mention the iTunesU program where a lot of american universites post recordings of some of their lectures.

[via Jendrik Bertram]

Microsoft veröffentlicht Quellcode des .NET-Framework

Einer der größten Hindernisse beim Entwickeln mit dem .NET-Framework war stets, dass der Quellcode nicht verfügbar gewesen ist. Das hat .NET stets von Java oder auch der MFC unterschieden.

In 99,9% der Zeit reichen die Interfacebeschreibungen und die Dokumentation in der MSDN durchaus aus, aber die Doku ist nicht wirklich überall gleich gut (um nicht zu sagen, an einigen Stellen kaum vorhanden). In diesen restlichen 0,1% der Zeit wird .NET dann einfach zu einer riesigen Blackbox.
Dieses Hindernis wird aber nun aus dem Weg geräumt.

Der Microsoft-Mitarbeiter Schott Guthrie hat in seinem Blog angekündigt, dass der Quellcode wichtiger .Net-Bibliotheken veröffentlicht wird.
Mit .NET 3.5, dass noch in diesem Jahr erscheint, wird der Quellcode (inkl. Kommentaren) von vielen Basisklassen, ASP.NET, Windows Forms, ADO.NET, XML und WPF verfügbar gemacht.

Man wird den Quellcode entweder seperat oder über eine Integration mit Visual Studio 2008 herunterladen können .

Die Lizenz des Codes wird nur nur ein Lesen des Quellcodes erlauben. Änderungen und Weitergabe sind untersagt. Aber schon das Lesen und die Möglichkeit zum Debuggen wird eine große Hilfe sein.

[via CodeBetter.com]

Buchtipp: Java Puzzlers

In "Java Puzzlers - Traps, Pitfalls, and Corner Cases" stellen Joshua Bloch und Neal Gafter, zwei herausragende Personen der Java-Welt, 95 "Java Puzzle" vor. Dies sind kleine Codestücke, bei denen der Leser herausfinden soll, was der Code macht. In der Regel tut er nicht, das was von ihm erwartet wird.

Anschließend stellen die Autoren stets vor, was der Code wirklich macht und gibt Tipps, wie man die Probleme vermeiden kann. Die Puzzle drehen sich um verschiedene Bereiche von Java u.a. die Probleme von automatischen Casts, Generics, Autoboxing (beliebte Quelle für NullPointerExceptions), Klasseninitialisierung und Exceptionhandling. Aber auch die Java-Bibliothken werden angesprochen.

Die Puzzle und die Auslösungen sind wirklich extrem verzwickt und wären ideal für einen sadistischen GP1-Tutor. Das Lesen hat einfach Spaß gemacht.

In einem zwei Monate altem Artikel von mir habe ich vermutet, dass der Gebrauchswert von "Java Puzzler" geringer ist als der des Buches "Effective Java".
Dem ist wohl auch so, aber "Java Puzzlers" ist nicht nur nett zu lesen, sondern kann tatsächlich eine hilfreiche Lektüre sein.

In einem aktuellen Universitätsprojekt ist man gleich in mehreren Fällen auf die im Buch präsentierten Fallstricke "reingefallen",z.B. auf Puzzle 1 (Oddity), Puzzle 29 (Bride of Looper), Puzzle 57 (What’s in a Name?) und Puzzle 58 (Making a Hash of It).

Als Fazit kann man sagen, dass es nicht den gleichen praktischen Wert hat wie "Effective Java", aber mit dem Tipps und dem Wissen aus dem Buch wird man nicht so leicht über die Randbereiche von Java stolpern bzw. man wird eher erkennen, wo die Randbereiche liegen. Nun kann man leicht sagen, dass in gut geschriebener Software die aller meisten Probleme aus den Puzzles nicht auftauchen. Die meisten Puzzles sind schon ziemlich obskur, so dass die meisten Entwickler den Code sowieso umschreiben würden. Aber die Hinweise sind auch in der Realität wichtig (siehe oben) auch weil nicht jeder Code perfekt geschrieben ist. Wenn man Code vorgesetzt bekommt, der nicht gut geschrieben ist und weitgehend ungetestet, dann können die Hinweise Gold wert sein.

Die gute Nachricht ist, dass viele der Randfälle aus dem Buch auch durch das statische Analysetool FindBugs (eigentlich mal einen eigenen Artikel wert) gefunden werden. Um ehrlich zu sein, habe ich die oben erwähnten Bugs nicht durch Java Puzzlers sondern durch FindBugs entdeckt.

Wer in Java Puzzler hineinlesen möchte, kann die Probekapitel auf javapuzzlers.com lesen. So interessant wie das Buch sind auch die jährlichen Puzzlevorträe auf der JavaOne-Konferenz, die online ansehen gewerden können. Bei Sun gibt es die Talks als Audiopräsentation mit Transskript und den Slides (2007, 2006) , den 2007-Vorträ gibt es auch bei Google-Video (Joshua Block zusammen mit FindBugs-Autor Bill Pugh)

Fazit: Kein Muss-Lesestoff, aber durchaus interessant, lehrreich und gleichzeitig Fun. Zumindest wenn man nicht absolut allergisch auf die Bezeichnung "Geek" reagiert.

Null-Parameter und Rückgabe von null in Java

Ein guter Artikel über "null" als akzeptierter Methodenparameter und den Rückgabewert "null" in Java:

I am not a fan of methods that accept null and I can find very few reasons for ever wanting to return null. Once a null gets into your code it can cause havoc, which is best discovered as soon as possible during development as it either indicates a serious problem or a buggy method returning null under certain circumstances (usually instead of an empty Collection).

How many times have you had to rewrite a simple equals call to allow for a null?

Etwas arg philosopisch und in der Praxis nicht einzuhalten, aber trotzdem ein guter Rat. Auch sollte man das Null-Muster (ps) in diesem Zusammenhang nicht vergessen.

Ich hab immer die Regel des Eclipseprojektes gemocht. "Null" ist dort - wenn ich mich richtig erinnere - als Eingabeparameter ungültig, es sei denn der Fall wurde in den Javadoc-Kommentaren explizit erlaubt.

Java Exception Handling Antipattern

Der Artikel "Exception-Handling Antipattern" auf java.net erklärt wie Exceptions in Java verwendet und nicht verwendet werden sollten.

Der Artikel ist für jeden Java-Entwickler lesenswert. Die in dem Artikel genannten Antimuster sind:

• Log and Throw
• Throwing Exception
• Throwing the Kitchen Sink
• Catching Exception
• Destrutice Wrapping
• Log and Return Null
• Catch and Ignore
• Throw from within Finally
• Multi-Line Log Messages
• Unsupported Operating Returning Null
• Ignoring InterruptedException
• Relying on getCause()

Die Regeln sollten eigentlich (weitgehend) Common Sense sein, aber (nach leidvoller Erfahrung der letzten Monate) bin ich der Meinung, dass man kann selbst Common Sense nicht oft genug wiederholen.

Ich würde noch drei Empfehlungen hinzufügen, die vielleicht zu offensichtlich sind, aber dennoch irgendwie in die Liste passen. Java-Pros werden wahrscheinlich (zumindest für Empfehlung 1) Gegenbeispiele finden, aber grundsätzliche sind dies gute Ratschläe.

1. Niemals Exceptionen von Error und Untertypen werfen.
   "Error" ist in der Regel einzig und allein der Virtuell Maschine und dem SDK vorbehalten sein und sollte so nur in Ausnahmefällen von Benutzercode gefangen werden. Schon gar nicht sollte Benutzercode Error-Exceptions werfen.
   In der Dokumentation zu Error heisst es:

   <blockquote>
     <p>An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions.</p>
   </blockquote>
   
   <p>In der Regel verwendet man eine Error-Klasse für einen ganz anderen Zweck als in der Dokumentation angegeben, nur weil der Name passend klingt z.B. VerifyError für die Verifikation von Benutzereingaben. Eigene Exceptions oder RuntimeExceptions für problematische Zustände sind die oft die bessere Wahl.</p>
   

2. System.exit() sollte nicht in catch aufgerufen werden.
   Ich gestehe zu, dass es von dieser Regel Ausnahmen geben kann, aber das Anliegen von Exceptionhandling ist, dass sich der Code um die Fehlerbehandlung kümmert, der weiß ein Fehler behandelt werden soll. Nur niemand eine Exception behandeln kann, soll das Programm beendet werden.

   <p>Wenn man System.exit() in catch aufruft, dann nehme ich Methoden weiter oben im Stack die Möglichkeit den Fehler zu behandeln. In der Regel ist dies nicht sinnvoll.</p>
   
   <p>System.exit() sollte in der Regel sowieso gemeiden werden, da z.B. alle Cleanup-Operationen nicht durchgeführt werden und der Code mit System.exit() mit einem Schlag quasi-untestbar wird.</p>
   

3. Eine NullPointerException sollte nicht manuell geworfen werden.
   Eine NullPointerException ist eine wirklich meise Art von Exception, weil sie oft auf Fehler hinweisen, die an ganz anderen Stellen im Code verursacht wurden. Zum Beispiel sind NullPointerExceptions tief aus dem Code eines J2EE-Containers ist so das schlimmestem was passieren kann. Es ist nur schwer möglich den Grund für den Fehler zu suchen.

   <p>Wenn man den Gedanken hat durch "throw new NullPointerExcecption()" manuell eine NPE zu werfen, sollte man besser davon Abstand nehmen und eine Exceptionklasse wählen, die besser den wirklichen Fehler beschreibt z.B. IllegalArgumentException("xy is null").</p>
   

Studienfond OWL: Bewerben oder nicht?

Viele Studenten an der Universität Paderborn werden schon den Flyer vom "Studienfond OWL" in der Mensa gesehen haben. Aber was dahinter steckt, ob es für einen selbst relevant ist, bleibt unklar. Grundsätzlich ist es die Chance auf ein Stipendium von 1000 Euro pro Jahr (und andere Vorteile). Es ist nicht, wie einige Studenten glauben, ein Angebot für einen Studienkredit, der zurückgezahlt werden muss. Ein Stipendium ist ein Stipendium.

Der Studienfond OWL ist ein Verein, der von den fünf Hochschulen in OWL gegründet wurde und an Studenten an diesen Hochschulen Stipendien vergibt. Das besondere an dem Studienfond ist, dass er sich grundsätzlich aus Spenden von Privatpersonen und Firmen (besonders aus der Region) finanziert. Gegründet wurde der Studienfond (auch wenn er selbst diesen Zusammenhang gerne verneint, um nicht Teil der politischen Debatte zu werden) im Zuge der Einführung von Studienbeiträen. Nicht aus Zufall wurde die Förderung zunächst einmal auf 1.000 Euro für ein einjähriges Stipendium festgesetzt. Es sollten zumindest die Studienbeiträe ersetzt werden. Im Grunde ist es ein Kompromiss zwischen einer höheren Förderung und der Unterstützung von mehr Studenten.

Aber es soll dort nicht nur um Geld gehen. Zusätzlich will der Studienfond auch immateriell fördern. Dies geschieht durch ein Angebot von "Networking"-Veranstaltungen wie Firmenbesichtigungen, Vorträen und Unternehmergesprächen. Ebenso wurden zum Beispiel Freikarten für die Hannover Messe von Unternehmen zur Verfügung gestellt. Auch bei der Vermittlung von Praktika und "studienförderlichen Jobs" - scheinbar das neue Modewort der Universitätsleitung - soll geholfen werden.

Der Studienfond OWL will zwei Gruppen von Studenten fördern:
1) Akademisch erfolgreiche Studenten: Die Homepage spricht davon, dass die Studenten unter den besten 10% sein sollten. Zusätzlich ist auch ein Empfehlungsschreiben von einem Hochschulprofessor notwendig.
2) Studenten in finanzieller Notlage, die trotz Bedürftigkeit kein BaföG erhalten. Es sollen finanzielle Notlagen ausgeglichen werden, die die Weiterführung des Studiums gefährden würden.
Dabei sind die Bedingungen sollten eher als grobe Richtlinien zusehen. Es kommt auch immer darauf an, wie viele Studenten sich beworben haben und wie viele Spenden zu verteilen sind.

Womit wir zu der wichtigsten Frage kommen: Wie stehen die Chancen?
Ich glaube, dass alle Studenten, welche die Bedingungen mehr oder weniger erfüllen, ziemlich gute Chancen haben. Noch bewerben sich wenige Studenten. Gleichzeitig scheint die Sammlung von Spenden ganz gut zu klappen. Die Chancen sind heute so gut wie nie zuvor und sie werden vielleicht auch nie wieder so gut werden, wie sie jetzt sind.

Ist alles Gold, was glänzt: Nein, natürlich nicht. Noch sind die Stipendien verhältnismäßig gering (auf der Höhe von Büchergeld bei anderen Organisationen wie der Friedrich-Naumann-Stiftung). Der (auf der Homepage angekündige, aber wohl nicht 100% "durchgehaltene") Ausschluß von Bafög-Empfängern erscheint mir ziemlich unsinnig und es könnten auch insgesamt mehr Stipendien sein. Im Moment sind es 12 an der Uni Paderborn. Insgesamt ist das Ganze ist ein Prozess der sich gerade am Anfang befindet.

Ich bin der Überzeugung, dass eine Fundamental- und Schmähkritik, wie sie von der Asta Bielefeld vorgebracht wurde, nicht angebracht ist. Die Autoren scheinen den Studienfond als reines Täuschungsmanöver zu sehen und gehen dabei auch noch kreativ mit Fakten um. Ich glaube hingegen, man ist ehrlich bemüht, zu unterstützen. Auch die Qualität und Quantität der Förderung wird wohl (irgendwann) ausgebaut. Und man sieht und (oder vielleicht auch: man will nicht sehen) das nie alles von Beginn an perfekt klappt. Es ist wie oben schon gesagt ein Prozess.

Sollte man sich bewerben? Ja, wenn man glaubt die Bedingungen mehr oder weniger zu erfüllen, denn man hat wenig zu verlieren und ein Stipendium zu gewinnen. Weitere Infos gibt es auf der Webseite des Studienfonds OWL. Die Bewerbungsformulare sind auch nicht viel länger als die Formulare zur Anmeldung zu Prüfungen.

Dieser Artikel wurde (in geringfügig anderer Form) in der "Matik 59″, dem Magazin der Fachschaft für Informatik und Mathematik an der Universität Paderborn veröffentlicht. Veröffentlichung an dieser Stelle mit Genehmigung der Fachschaft.

Vector vs. Collections.synchronizedList

Every Java developer knows (or should know), that concurrent access to a list has to be synchronized.

In Java there are two build in ways to synchronize lists directly:

1. java.util.Vector: The original implementation of an dynamic array from the old days of Java 1.0 - Java Stone Age.
2. the factory method Collections.synchronizedList which produces a synchonized wrapper around a list (e.g. ArrayList or LinkedList).

There is also the list implementation CopyOnWriteArrayList from the package java.util.concurrent, which I will ignore here most of the time.

When I have to synchronize the access to a list in new code, which variant should be used

Depending from the concrete usage it could be an ultimate advance of the factory method, that the implementation of the underlying list can be chosen. If Vector is used, it is obviously a bad idea to delete elements from the middle of a list on a regular basis. The O calculus strikes back.

Furthermore the performance comparison shows surprising clear differences.

At the artificial task to insert 2^17 elements sequentially into the list, Vector needs 8 percent less time than the synchronized ArrayList. The advance is caused by the fact that Vector doubles the capacity of its internal data structure every time a threshold is reached. The ArrayList increases its internal array only about 50%. As a result the ArrayList copies its data more often into new arrays.

The iteration over 2^17 elements the vector needs six times longer then the synchronized variant of the ArrayList. This huge difference is caused by the locking behavior of the classes. Vector locks every single access to next(). The synchronizedList-Implementation doesn’t lock the access over an iterator as described in the javadoc. This breaks the rule that the client should never be responsible for thread safety of a class, but it allows coarse-grained locking around the whole loop. This avoids the possibility of ConcurrentModificationExceptions. The difference between one entry and release of an critical region against the 2^17 entrances and releases, causes the surprisingly high time difference.

Of course it is also possible to lock very single access to next, e.g. when the execution of the loop body takes a longer time. With this fine-grained locking the performance would be the same as of the Vector implementation.

Another reason against vector is the ballast the class carries from the Java 1.0 time. Vector implements the List interface and offers the methods add(), remove() and so, but it also has old methods like elementAt (old get), elements (old iterator which returns an Enumeration) and insertElementAt (old add). This makes the usage not very handy.

A more subtle reason for synchronizedList is that a lot of developers use Vector all the time, even if no synchronization is needed. It is often not clear, if Vector is used with purpose or since a lack of experience or knowledge. A lot of tutorials and books don’t mention the collections api. Furthermore there are universities haven’t discovery the collections api yet.

synchronizedList documents the purpose of the code in a better way: Yes, I want synchronization. Yes, I know what I do. In very case the intention should be documented. In the javadoc and (in the ideal case) also with the Annotations from "Java Concurrency in Practice".

In my opinion Vector should be declared obsolete at least after the introduction of generics. When no synchronization is needed, a "new" list implementation should be used. In the case of multi threading a synchronized wrapper or (when the reading accesses outnumbers the write accesses) the CopyOnWriteArrayList implementation should be used. Let Vector die, its time is over.

A bit more correct: Vector locks every single access to get(), which is called by next().
[Update May, 5th, 2008: In the Javaposse Googlegroup is currently an active and interessing discussion about ArrayList vs. Vector with further details, options and surprisingly different results]

Artikel über Swarm Bahavior

In National Geographic Juli 2007 steht ein interessanter Artikel zur Swarm Intelligenz:

Swarm Theory: A single ant or bee isn’t smart, but their colonies are. The study of swarm intelligence is providing insights that can help humans manage complex systems, from truck routing to military robots.

Obwohl der Artikel sich weitgehend mit der Biologie beschäftigt, geht er auch auf die Umsetzung von Swarm Intelligenz in der Informatik ein.

By demonstrating the power of self-organizing models to mimic swarm behavior, Reynolds [a Computer Science Researcher] was also blazing the trail for robotics engineers. A team of robots that could coordinate its actions like a flock of birds could offer significant advantages over a solitary robot. Spread out over a large area, a group could function as a powerful mobile sensor net, gathering information about what’s out there. If the group encountered something unexpected, it could adjust and respond quickly, even if the robots in the group weren’t very sophisticated, just as ants are able to come up with various options by trial and error. If one member of the group were to break down, others could take its place. And, most important, control of the group could be decentralized, not dependent on a leader.

"In biology, if you look at groups with large numbers, there are very few examples where you have a central agent," says Vijay Kumar, a professor of mechanical engineering at the University of Pennsylvania. "Everything is very distributed: They don’t all talk to each other. They act on local information. And they’re all anonymous. I don’t care who moves the chair, as long as somebody moves the chair. To go from one robot to multiple robots, you need all three of those ideas."

Interessant zu lesen!

Wieder Wahlen an der Uni: FUMI

Es ist schon wieder Wahl an der Universität. Wie in keinem Jahr zuvor, war das Jahr geprät von Streit in der Uni-Landschaft. Die Abschaffung und Wiedereinführung des Sommerfestivals ist nur ein Beispiel.

Vor einem Jahr habe ich die Liste Naturwissenschaften gewählt. Zeit für eine Neubewertung.
Ich wähle: FUMI - FachschaftsUmfeld Mathematik und Informatik.

Während sich die anderen Alternativen fast nur um sich selbst drehen (Asta-Reform hier, Stellungnahme zu politischen Themen da) will da jemand mal ganz konkret meine Studiensituation verbessern. Dafür ist der ganze Haufen doch (auch) da, oder?

- Grillen auf dem Campus:
Zwar nicht das wichtigste aller Themen, aber schon gut.

- Studiengebührentransparenz:
Absolut, ich will wissen, wo mein Geld hinfließt. Meine kleine private Verschwörungstheorie ist ja, dass die Zahlen im Asta detailiert vorliegen, aber absichtlich zurückgehalten werden. Sonst müsste man noch zugeben, dass das für Tutorenstellen für überlaufende Veranstaltungen geschaffen wurden, usw. Und es darf ja nicht sein, was nicht sein soll.

- Uni-Linie um 13:50:
Die Uni-Linie ist ein wichtiges Thema. Eine Fahrt mehr wäre ein echter Vorteil für alle Studenten, die oft zwischen FÜ und Uni wechseln müssen.

- mehr Campusleben:
Allgemeinplatz, der von jedem gefordert wird. Weg dahin bleibt unklar.

- Cafete schon ab 7:15 Uhr:
Kaffee! Längere Öffungszeiten des Palmengartens in der FÜ wären ebenfalls sinnvoll. Früher öffnen (15 Minuten früher würde schon über die erste Vorlesung helfen), später schließen (15:30 ist doch etwas früh).

- Arbeitsplätze in D und E, mehr Arbeitsplätze in der Bibo:
Wie lange bin ich schon durch die Uni geirrt, um Arbeitsplätze zu finden. Volle Zustimmung.

- Wasserspender in der Bibo:
Auch eine gute Idee

- Weltfrieden:
Will ich auch! Im Ernst: Sehe ich als Seitenhieb auf die Mitbewerber, die alles versprechen. Insbesondere Dinge, die nicht in der Macht der Asta liegen ("Wir wollen uns dafür einsetzen, dass das Netz der DB ausgeweitet wird" und einige mehr) und Dinge, die mit der Aufgabe der Asta meiner Meinung nach wenig zu tun haben ("gezielten Aktionismus")*. Sie können sich ja gerne gesellschaftlich einsetzen wofür sie wollen, aber sie sollen es nicht unbedingt mit meinem Zwangsbeiträen machen. Die sollten meiner Meinung nach nur für die Vertretung an der Uni, Dienstleitungen, Aktive und ernsthafte Hochschulpolitik genutzt werden.

Meine Vermutung ist zwar, dass in der Fachschaft politisch relativ weit links steht, aber sie wollen offensichtlich durch kleine aber wichtige Schritte die Studiersituation verbessern. Dafür meine Stimme!

* Ich weiß, dass für beides bessere Beispiele existieren, aber die beiden Zitate musste ich einfach in diesem Text unterbringen.

Studium Generale und die 16 Punkte Kulanz

Es gab in den letzten Tagen einige Diskussion bezüglich Studium Generale-Veranstaltungen für den Masterabschluss im Rahmen der 16-ECTS-Punkte-Kulanzregelung. Man merkt, dass so langsam viele Studenten an der Grenze von Bachelor zu Master stehen.

Bachelorstudenten, die einige Bedingungen erfüllen, dürfen bis zu 16-ECTS-Punkte für den Masterabschluss vorziehen, so steht es in den Übergangsregelungen. Dort heist es genau:

Vor Abschluss des Bachelorstudiums dürfen Veranstaltungen des Masterstudiengangs im Haupt- und Nebenfach im Umfang von maximal 16 ECTS-Punkten absolviert werden, sobald die Bachelorarbeit angemeldet ist und bereits zwei Bachelor-Module des 2. Studienabschnitts absolviert wurden.

Diese Regelung wurde von einigen Studenten so interpretiert, dass es nicht möglich wäre Veranstaltungen im Studium Generale vorzuziehen. Eine Interpretation, die ich ja nachvollziehen kann; Genau das steht da. Die Regelung ist nur nicht sinnvoll. Warum sollte man Haupt- und Nebenfach vorziehen dürfen und Studium Generale nicht? Meine Vermutung ist viel mehr, dass das Studium Generale einfach vergessen wurde.

Aber bevor es in einem Jahr Stress gibt, habe ich mal bei Prof. Szwillus nachgefragt. Er sieht da gar keine Probleme. Es sah so für mich aus, als wäre er überrascht, dass es diese Diskussion gibt. Er meinte auch, dass es so oder so nicht kontrollierbar wäre, da es für das Studium Generale keine zentrale Anmeldung geben würde.

Disclaimer: Bitte fragt im Zweifelsfall selbst bei Prof. Szwillus nach. Wenn es doch Probleme geben sollte, dann gebt bitte nicht mir die Schuld. Alle Angaben ohne Gewähr.

Prüfungsanmeldung noch weiter verschärft

Letztes Jahr war das erste Jahr in dem sich die Informatikstudenten für Prüfungen zentralisiert beim Prüfungssekretariat anmelden mussten. Vorher wurde dies recht unkompiziert und (oft) unbürokratisch direkt über den Veranstalter möglich.

Es gab viel Stress mit den neuen Regelungen z.B. durch Vorlesungen mit Sonderbedingungen oder Vorlesungen, die dem PrüfSek nicht bekannt waren. Deshalb habe ich gehofft, dass die Universität aus ihren Fehlern lernt und wieder zur Anmeldung beim Veranstalter zurück kehrt.

Sie hat es nicht:
Im Gegenteil: Früher war die Regel, dass man sich bei mündlichen Prüfungen bis zwei Wochen vor dem Termin anmelden konnte. Nur schriftliche Prüfungen müssten in der Anmeldephase (dieses Jahr bis zum 29.6) genehmigt werden.
Wie auf den Seiten des PrüfSek nachzulesen ist, ist die Neuerung in diesem Jahr, dass auch mündliche Prüfungen (im Hauptfach) in der Phase angemeldet werden müssen, selbst wenn noch kein Termin bekannt ist. Der Termin wird nun durch die Professoren online nachgetragen.
Eine weitere Verschärfung. Noch mehr Bürokratie.

Irgendwie passt dazu, dass ich vor ein paar Monaten mit dem Rektor geredet habe (im Rahmen des Studienfond) und in einem Nebensatz die Universität als "Behörde" bezeichnet habe. Dies hat ihn sichtlich verärgert Wenn die Universität keine Behörde sein will, kein Ausführungsorgan eines Ministeriums sein will, wieso benimmt sie sich immer so?

ACM Studie: Universität Paderborn in Software Engineering weltweit auf Platz 16

Pressemitteilung der Universität:

Die Universität Paderborn ist die Nummer 1 der Software-Institute in Deutschland und nimmt auch international eine Spitzenposition ein", so Prorektor Prof. Dr. Wilhelm Schäfer vom Institut für Informatik. Dies belege ein aktuelles Forschungs-Ranking, das gerade von der renommierten Association for Computing Machinery (ACM) veröffentlicht wurde.

In der aktuellen Ausgabe der Zeitschrift Communications of the ACM (Juni 2007) werden die Top 50 Institute im Bereich Software Engineering weltweit bewertet. Die Universität Paderborn belegt dabei einen hervorragenden 16. Platz und ist so mit Abstand das beste deutsche Institut. Lediglich die Universität Karlsruhe (Platz 29) und das Fraunhofer-Institut für experimentelles Software-Engineering (IESE) in Kaiserslautern (Platz 32) finden sich als weitere deutsche Einrichtungen in den Top 50. Im internationalen Vergleich liegt Paderborn z.B. noch vor der Stanford University. Auch in Europa zählt Paderborn zu den besten vier Instituten neben der Polytechnischen Universität Mailand und den beiden Londoner Universitäten Imperial College und University College.

Eine schöne Nachricht für die Universität.
Auch gerade jetzt kurz vor der Entscheidung über die Exzellenz-Cluster.
Bei aller Freude sollte man aber anmerken, dass der Artikel der ACM nicht (primär) ein Ranking ist, sondern eine Vorstellung einer neuen automatischen Methode zum Ranking. Ohne den Spaß verderben zu wollen, aber das ist ein Unterschied.

Unabhängig von diesem Makel ist es natürlich schön zu sehen, wenn die eigene Universität in der Forschung international mitspielen kann (oder zumindest so bewertet wird). Es liest sich schon beeindruckend:

1 Massachusetts Institute of Technology
2 Carnegie Mellon University
3 Georgia Institute of Technology
4 University of Maryland, College Park
5 Oregon State University
[...]
16 University of Paderborn
[...]
18 Stanford University
[...]
32 Fraunhofer-IESE, Germany

2. Auflage von "Effective Java" in Arbeit

Bei den regelmäßigen Lesern dieses Blogs sollte ich herumgesprochen haben, dass ""Effective Java" von Joshua Bloch eines meiner Lieblingsbücher ist.

Leider ist die aktuelle Version schon von 2001 und damit aus IT-Sicht uralt. Hinweise wie der Tipp für typsichere Enums sind von der Sprachspezifikation überholt worden; Nebenläufigkeit ist heute wichtiger als vor 6 Jahren und natürlich werden auch generische Typen nicht besprochen.

Dennoch hat es auch heute noch einen Mehrwert. Deshalb fand ich es schade, dass "Effective Java" nicht mehr verkauft wird. Aber die gute Nachricht ist dieses Interview mit Bloch auf der letzten JavaOne:

Q: You are currently busy revising Effective Java. Can you give us some hints about what will be in the second edition?

A: I’m trying very hard to preserve the tone of the first edition. I’m revising all the existing items in light of the J2SE 5.0 language changes and everything I’ve learned since 2001. I’m adding a few more items here and there, plus an entire chapter on generics. Also, I’m slanting the threads chapter toward java.util.concurrent.

Für die Übergangszeit gibt es noch "Java Puzzlers", auch wenn ich vermute, dass der "Gebrauchswert" von "Puzzler" deutlich geringer sein wird.

Singletons: Bitte nicht als Ersatz für globalen Variablen

Vor 1 1/2 Jahren habe ich schon mal etwas über das Singleton-Pattern geschrieben. Damals ging es um die Implementierung in Java. Auch damals hatte ich schon geschreiben

Merke: Wenn Singleton (meist ist dies keine so gute Idee), dann doch bitte nur mit private-Konstruktor.

Einen Vorteil hat das Singleton-Pattern gegenüber den anderen GoF-Pattern. Es ist absolut einfach zu verstehen. Das Klassendiagramm enthält nur eine einzige Klasse und das Singleton hat nichtmal einen Clienten. Es ist in vielen Kursen (zum Beispiel auch in Modellbasierte Softwareentwicklung) eines der ersten oder das erste Pattern, dass vorgestellt wird.

Dies führt dazu, dass es zu jedem nur denkbaren Zeitpunkt eingesetzt wird. Nachdem ich mich im Moment in ein Open Source Projekt einarbeite in dem Klassen mit Singleton-Eigenschaft nicht die Ausnahme sondern die Regel sind, ist es Zeit etwas auszuführen, warum das Singleton-Pattern meist keine so gute Idee ist.

Nicht, dass es für das Singleton-Pattern keine sinnvolle Verwendung gibt, aber meine Schätzung ist, dass es in 90% der Fällen als Ersatz für globale Objekte verwendet wird anstatt für den eigentlichen Zweck. Singleton ist eine Erzeugungsmuster. Es dient dazu sicherzustellen, dass niemals mehr als eine Instanz einer Klasse existieren.

(more...)

Mac-OS Tiger: Endlich installiert

Mal ein kleiner Rückblick in die Geschichte dieses Blogs:
12. April 2005:

Was könnte ein besserer 1. Beitrag für dirkmeister.de sein als die Nachricht, dass Mac OSX 10.4 Codename "Tiger" endlich erscheint.
Die integrierte "Suchfunktion" Spotlight und Dashboard sind echt schon zwei Schmankerl und Microsoft um mehrere Jahre voraus. *grin*
Von dem Geld, das ich mir in den Semesterferien verdient habe, kaufe ich mir vielleicht "Tiger".

Irgendwie ist da nie etwas raus geworden. Die Investition habe ich immer gescheut.
Aber gestern war es soweit: Am Vorabend der Leopard-Veröffentlichung habe ich Tiger gekauft und installiert.

Der Grund: Spotlight, Dashboard? Nein
Es ist dieser kleine Text:

    $ java -version
   java version "1.5.0_07"
   Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164)
   Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode)

Ich brauche jetzt endgültig Java 5.0.

Mündliche Prüfungen im Bachelorstudiengang: Nicht verpflichtend

Es gibt eine weitere kleine Richtlinie in der Bachelorprüfungsordnung über deren Auswirkungen wohl niemand richtig so nachgedacht hat. §5 der BScPO sagt:

Die Prüfungen werden [...] im zweiten Abschnitt in der Regel in Form mündlicher Prüfungen durchgeführt. Mindestens drei dieser Prüfungen müssen in Form einer mündlichen Prüfung abgelegt werden.

Dies war auch dringend geboten, denn wie die Fachschaft schon richtig sagt: Einige Studenten müssten warten

bis wieder eine mündliche Prüfung in einem Bereich stattfindet in dem sie noch keine Prüfung absolviert haben, oder sie müssen Vorlesungen belegen, die nicht ihren Interessen entsprechen aus dem einzigen Grund eine mündliche Prüfung zu absolvieren.

Also eine weitere Regel die Studenten dazu bringt nicht gute Vorlesungen oder Vorlesungen aus Ihrem Interesse heraus zu belegen, sondern sie zwingt nicht so gute oder passende Veranstaltungen zu "absolvieren" nur um ziemlich willkürliche Regeln zu befolgen.

Aber in diesem Fall (es gibt noch mehr Regeln dieser Sorte) wurde diese Regelung nach einem Mitteilung der Fachschaft entschärft:

Eine Rücksprache mit Herrn Szwillus (Vorsitzender PA Informatik) hat ergeben, dass diese Regelung nicht als Verpflichtung für Studierende zu sehen ist, sondern als Verpflichtung für das Institut so viele Möglichkeiten zur mündlichen Prüfung anzubieten, dass im Schnitt jeder Studierende mindestens drei mündliche Prüfungen im Hauptstudium absolviert.

Das steht leider so aber nicht in der Prüfungsordnung. Dort steht "müssen". Deshalb: Streicht diese Regelung bei der nächsten Revision ganz raus.

Wenn man schon dabei ist, streicht jede ähnliche Regelung gleich mit. Diese Regelungen benachteiligen alle Studenten, denen es nicht egal ist, welche Vorlesungen sie belegen. Auch braucht man sich mit solchen Regelungen nicht mehr über eine lange durchschnittliche Studiendauer wundern.
Mehr Lernfreiheit würde den Prüfungsordnungen gut tun.

Nur als Randbemerkung:
In Prüfungsordnungen gilt wie in der Politik: Nicht alles was wünschenswert ist, sollte reglementiert vorgeschrieben werden. Man sieht hier welche negativen Auswirkungen es haben kann, wenn man das Individuum und die individuelle Situation ignoriert.

Bloggen vom Linuxtag

Wer wissen möchte, wie relativ untechnische, ungeekige, Medizin- und Philosophiestudentinnen den Linuxtag wahrnehmen, dem sei Evas Artikel "Bloggen vom Linuxtag" (und noch nachfolgende Artikel) ans Herz gelegt.
Erste Impression:

Mehr Maenner als auf dem Deutschlandtag der Jungen Union.

Zweite Impression:

Die Tastaturbelegung dieses Rechners kann nicht herausgefunden werden von den Herren Informatikern um mich herum, weswegen ich auf gut Glueck und ohne Umlaute und unter Verzicht auf die meisten Satzzeichen schreiben muss. So ist das bei freien Softwareprojekten. Das sei wie Katzen hueten, habe ich heute schon gelernt.

Eclipse-Emma-Plugin: EclEmma

Emma ist ein Werkzeug zur Überdeckungsanalyse für Javacode. Man kann damit Basisanalysen erstellen wie gut JUnit-Tests die verschiedenen Zweige im Code überprüfen.

Doch der Einsatz der Emma-Bibliothek alleine ist ziemlich aufwendig. Man muss manuell den Code instrumentalisieren und Berichte aus den gesammelten Informationen erstellen. Mit einem guten ant-Skript ist dies kein Ding, aber für den einzelnen Entwickler/Unittester doch zu viel Aufwand.

Mit EclEmma (momentan Version 1.2.0) gibt es ein sehr gutes Eclipse-Plugin, das den ganzen Prozess extrem abkürzt. Die Coverageprüfung integriert sich als zusätzlichen Lunchmode (neben Debug und Run). Damit wird das Durchführen einer Coverageprüfung ein Kinderspiel. Der Code wird automatisch instrumentalisiert und die Resultate werden automatisch ermittelt und dargestellt.

Apropo Ergebnisse:
Bei der Anzeige der Ergebnisse zeigt sich der wahre Vorteil des Plugins. Ähnlich wie bei der Edition für Tester von Visual Studio 2005 werden die Überdeckungsinformationen direkt im Codeeditor angezeigt. Extrem übersichtlich. Man sieht direkt, wo die Tests noch nicht ausreichen.

Ich kann das Plugin nur empfehlen. Man erhält ohne großen Aufwand einen echten Mehrwert bei der Überdeckungsanalyse. Es ist nicht einmal notwendig die Projekteinstellungen zu verändern.

"USA Erklärt" für Grimme-Preis nominiert

Das Blog "USA Erklärt", welches ich im Februar empfohlen habe, wurde jetzt für den Grimme-Preis nominiert.

Viel Glück von meiner Seite.
Ich fände es gut, wenn eine Seite gewinnt ,die durch ihren Inhalt besticht (wie USA Erklärt) und nicht nur durch schickes Design (wie IMHO einige der Mitbewerber)

Nachtrag zu Jabber

In dem Artikel "Fazit vom 1. Webmontag" habe ich geschrieben, dass mir der Jabber-Vortrag überzeugt hat und ich nochmal versuche werde von ICQ nach Jabber zu wechseln.

Naja, nach einigen Beschwerden ich sei ja nie online oder würde auf Nachrichten nicht antworten, bin ich heute zumindest zu 50% zurückgewechselt: Das ICQ-Gateway vom Jabberserver nutze ich nicht mehr.

Ich konnte zwar ICQ-Kontakte sehen und selbst auch Konversationen beginnen. Für mich sah also alles gut aus. Aber mein Online-Status wurde nicht gesehen und eingehende Konversationen wurde nicht weitergeleitet. Von der anderen Seite sah es also gar nicht gut aus.

Fazit:

1. Es hat nicht so gut funktioniert wie gehofft, aber ich werde Jabber weiterhin als Zweit-Account nutzen.
2. Die Idee und auch die Umsetzung von Jabber finde ich super. Aber die Massenträheit, ...
3. Wenn einige Leser sich gewundert haben, dass ich nie online war und nie geantwortet habe. Ich bin nicht schuld, die Technik ist schuld ;-)

"Writing Better (Java) Code: A Conversation with Brian Goetz

In dem Interview mit dem unhandlichen Titel "Writing Better Code: A Converstion With Sun Microsystems Technology Evangelist Brian Goetz" im Sun Developer Network verbringt sich ein sehr interessanter Artikel über Javaprogrammierung und insbesondere zur Fragen der Performance.

Insbesondere will Goetz, der Hauptautor von "Java Concurrency in Practice"(amazon.de,ub.upb.de), mit einigen Performancemythen aufräumen.
So stellt er der Befürchung, threadsichere-Programmierung sei nur mit einem Verlust an Performance möglich, entgegen, dies sei vor 10 Jahren wahr gewesen aber heute nicht mehr:

Every major JDK release has reduced the overhead of synchronization over the previous version. Yes, there’s still overhead, but people worry too much about that and not enough about writing clean, correct code.

Interessant ist auch die Antwort auf die Frage wie Entwickler am besten schnellen Javacode schreiben:

The answer may seem counterintuitive. Often, the way to write fast code in Java applications is to write dumb code — code that is straightforward, clean, and follows the most obvious object-oriented principles. This has to do with the nature of dynamic compilers, which are big pattern-matching engines. Because compilers are written by humans who have schedules and time budgets, the compiler developers focus their efforts on the most common code patterns, because that’s where they get the most leverage. So if you write code using straightforward object-oriented principles, you’ll get better compiler optimization than if you write gnarly, hacked-up, bit-banging code that looks really clever but that the compiler can’t optimize effectively.
[...]
My advice is this: Write simple straightforward code and then, if the performance is still not "good enough", optimize. But implicit in the concept of "good enough" is that you need to have clear performance metrics. Without them, you’ll never know when you’re done optimizing. You’ll also need a realistic, repeatable, testing program in place to determine if you’re meeting your metrics. Once you can test the performance of your program under actual operating conditions, then it’s OK to start tweaking, because you’ll know if your tweaks are helping or not. But assuming "Oh, gee, I think if I change this, it will go faster" is usually counterproductive in Java programming.

Wie man OOP nicht lehren sollte

Einer der wichtigen Regeln zur Vererbung ist, dass eine Klasse b nur von einer Klasse a ableiten sollte, "wenn jedes b auch ein a ist" zum Beispiel jeder "Button" ist ein "Control", aber nicht jedes "Prisma" ist ein "Dreieck":

Hier ist eine alte Klausuraufgabe, die ich (nicht an der Universität) vor langer langer Zeit "lösen" musste (Schon mal ein großes [sic!] an dieser Stelle, Rechtschreibfehler nicht von mir):

Definieren Sie Java-Klasse (Dreieck), die ein gleichwinkeliges Dreieck beschreibt. Hierfür benutzen Sie den geeigneten Datentyp für die Klassenvariable (Seitenlänge). Anschließen schreiben Sie eine Klasse, die ein main()-Methode beinhaltet, um die Flächen und den Umfang von zwei Dreieck-Objekten mit Seitenhängen 40.3 und 30.5 zu erstellen, die Flächen und den Umfang zu berechnen und die Seitenlängen und die berechneten Daten auszugeben.
[...]
Erweitern Sie die Dreieck-Klasse so, daß sie einem Prisma beschreibt, dessen Oberfläche und Volumen später benötigt werden. Achten Sie darauf, daß dem Benutzer der Klasse Prisma die Dareieckfläche verdeckt bleibt.

Ja, da kommen Erinnerungen wieder hoch. ;-)

P.S. Nein, ich gebe nicht die Quelle an. ;-)
Darum geht es in diesem Artikel auch gar nicht.

Stöckchen von Fredo gefangen

Ich habe mein erstes englisches Stöckchen von Frederick gefangen. Aber ich wechsele trotzdem mal wieder die Sprache. Nicht dass ich etwas gegen Englisch hätte, aber in einem Blog nur einen Stöckchenartikel auf Englisch zu schreiben, ist wenig sinnvoll.

Das Stöckchen geht an einen Vertreter des Chaos-Blogs, wenn die solche Sachen mitmachen.

Bücher:
Derzeit lese ich das Buch "Versuchungen der Unfreiheit" von Ralf Dahrendorf, in dem er sich damit beschäftigt, warum einige öffentliche Intellektuelle in Zeiten der Prüfungen nicht den Versuchungen der Unfreiheit (Faschismus, Kommunismus) erlegen sind.

Insgeheim warte ich auf die 2.0-Version eines meiner (früheren) Lieblingsbücher: "Mikrosklaven" von Douglas Coupland. Das Originalbuch ist spielt vor mittlerweile 14 Jahren und ist nicht mehr zeitgemäß. Zeit für "Mikrosklaven 2.0″. Zu Schreiben gäbe es genug.

Zeitungen:
Ich lese nur selten (meist auf langen Zugfahren) Zeitungen. Mir fehlt einfach die Zeit dafür. Wenn ich eine Zeitung aufschlage, dann meine Lokalzeitung "Die Glocke", Welt (kompakt) oder "Die Zeit".
Ersatz für die Tageszeitungen sind meine abonnierten RSS-Feeds, aber bei diesem Stöckchen geht es ja explizit um "gedrucktes" Lesbares.

Technische Bücher:
Im Moment liegt das "Dragonbook" über Compilerbau und "Effektiv C++ programmieren " von Scott Meyer auf meinem Nachttisch.
Ich warte auf die Lieferung von "Building Scalable Web Sites" von Cal Henderson.

Studium:
Nachdem ich den ganzen "Code Quality" und "Effektiv Java programmieren"-Sachen vom SmartTeams-Vortrag beiseite geräumt habe, sind einige Paper zum Thema "Data Dissemination in Large-Scale Sensor Networks" wieder aufgetaucht: PG-Vortrag steht an.

Tipps zur Softwareentwicklung für "SmartTeams"

Ich habe eben für die Projektgruppe "SmartTeams" einen Vortrag mit Tipps zur Softwareentwicklung gehalten.
Ziel war es die wichtigsten Themen zur Programmierung mit Java, zu den Möglichkeiten von Java 1.5 und zur Wartbarkeit von Code in eine Präsentation zu packen.

Als 45 Minuten Präsentation geplannt, wurden aber schon viele Folien bewusst ausgelassen und es fehlen immer noch Themen, die auf jeden Fall hätten enthalten sein müssen wie zum Beispiel Serialisierung, Cloneable und die Vorteile von Unveränderbarkeit. Behandelt wurden aber immerhin:

• Schnittstellen als Typen anstatt Klassen
• Vererbung und Komposition
• Performance
• Java Collections API
• Java 1.5
• Vertrag von equals() und hashCode()
• Ausnahmebehandlung
• Kommentare

Folien: (pdf, 2MB)

Weiterführende Links:

• "Effektiv Java programmieren" von Joshua Bloch (amazon.de, ub.upb.de)
• "Code Quality" von Diomidis Spinellis (amazon.de, ub.upb.de)
• "Head First Design Pattern" von Eric Freemann et. al. (amazon.de, ub.upb.de)
• "How do a Good API and why it Matters", Google TechTalk von Joshua Bloch (video.google.com, Slides)
• Apache Jakarta Commons (jakarta.apache.org)
• Java SE 5.0 API Dokumentation (java.sun.com)

Kommentare und weitere Fragen bitte in den Kommentaren zu diesem Artikel

Pflichtenheft der Bachelorarbeit online [Update]

Zusätzlich zu der Bachelorarbeit habe ich auch das Pflichtenheft (64 Seiten) der Bachelorarbeit online gestellt.

Vielleicht hilft das Pflichtenheft anderen Studenten bei der Erstellung von Pflichtenheften für Studienarbeiten.

In Kürze wird auch die entwickelte Anwendung live gehen.

[Update: Link zum Pflichtenheft wurde korrigiert]

Schöne Panoramabilder meiner Uni

Schöne Panoramabilder meiner Uni gibt es bei Olaf zu sehen.

Schön grün und eine ganz nette Atmosphäre.
Interessent wäre es zum Vergleich Bilder der gleichen Orte im Winter zu haben.
Dann ist die Uni Paderborn grau und ziemlich hässlich.

Präsentation zur Architektur von LiveJournal

LiveJournal ist ein bekannter amerikanischer Bloghoster, der seine Serversoftware auch als Open Source verfügbar macht.

Dessen Gründer Brad Fitzpatrick (2005 würde LiveJournal an Six Apart verkauft) berichtet in diesem Video über deren Softwarearchitektur, deren Ansatz zu skalieren und die dafür eingesetzte meist-selbstentwickelte und als Open-Source veröffentlichte Software.

Der Foliensatz der Präsentation sind auch separat verfügbar.

[via Tech Presentations]

Skalierbarkeit und "Ruby on Rails"

Twitter ist eine stark wachsende Web 2.0-Anwendung, die mit Rails entwickelt wurde.

Ich möchte mich hier gar nicht mit dem Sinn und Unsinn von Twitter beschäftigen, sondern ich möchte mich auf ein aufschlussreiches Interview mit dem Twitter-Entwickler Alex Payne verweisen in dem es auch um die Skalierbarkeit von Rails geht.
In dem Interview heisst es:

Twitter is the biggest Rails site on the net right now. Running on Rails has forced us to deal with scaling issues - issues that any growing site eventually contends with - far sooner than I think we would on another framework.

The common wisdom in the Rails community at this time is that scaling Rails is a matter of cost: just throw more CPUs at it. The problem is that more instances of Rails (running as part of a Mongrel cluster, in our case) means more requests to your database. At this point in time there’s no facility in Rails to talk to more than one database at a time.

The solutions to this are caching the hell out of everything and setting up multiple read-only slave databases, neither of which are quick fixes to implement. So it’s not just cost, it’s time, and time is that much more precious when people can[’t] reach your site.

None of these scaling approaches are as fun and easy as developing for Rails. All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise. Once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both.

Dies hat mit der (Grundsatz-)Entscheidung des Ruby Entwicklers David Heinemeier zu tun, sich um Skalierbarkeit und Performance wenig Gedanken zu machen. Er gibt Entwicklern den Rat "Don’t scale".

Ein (in der extremen Form wie ihn David Heinemeier gibt) riskanter Rat wie Greg Linden in diesem Posting von 2005 argumentiert.

Sopra oder Swtpra

Gestern war die 1. Präsentation der von mir betreuten Gruppe im Softwaretechnikpraktikum und sie hat auf ihren Folien das Wort "Sopra" als Abkürzung verwendet und neben viel berechtigter Kritik und einigen Dingen über die man streiten kann, kam auch die Meta-Kritik bekommen die gültige Abkürzung für das Softwaretechnikpraktikum wäre "SWTPRA" und nicht "SOPRA". "SOPRA" wäre die Abkürzung für das Softwarepraktikum der Wirtschaftsinformatik und das sei etwas ganz anderes und die Gruppe sollte in Zukunft besser SWTPRA verwenden.

Mal ne kleine Umfrage unter den Lesern: Wie nennt ihr die Veranstaltung SWTPRA oder SOPRA?
Also ich habe noch nie gesagt, ich mache jetzt SWTPRA oder ich bin dieses Semster wieder SWTPRA-Tutor. Ich verwende immer SOPRA.

Aber lassen wir einfach Google entscheiden. Auf den Webseiten der Informatik findet Google für "sopra" 179 Einträe und für "swtpra" 70 Einträe.

Offizielle Unterlagen bestätigen den Google-Vergleich da: Im Modulhandbuch heisst es:

Softwaretechnikpraktikum (SOPRA):
Das Softwaretechnikpraktikum ist ein 6-stündiges Praktikum inklusive einer Vorlesung über Projektmanagement. Eine komplexe Softwareentwicklungsaufgabe wird im Team von ca. 10 Studierenden unter Verwendung von UML und Java bearbeitet. Schwerpunkte des Praktikums liegen in der Erfahrung einer teamorientierten Softwareentwicklung unter Benutzung marktüblicher Werkzeuge und Methoden (Rational Rose, Configuration and Version Management (CVS). Zu Beginn des Praktikums arbeiten sich die Studierenden anhand eines bereits in Teilen vorliegenden Quelltexts, der im Praktikum zu erweitern ist, in die Aufgabe ein und müssen diesen re-dokumentieren. Die Erstellung von Meilensteinplänen, ein teilweise durch die Studierenden zu übernehmendes Projektmanagement sowie die Anfertigung von Kostenschätzungen und die Protokollierung des Aufwandes durch Stundenzettel sind wesentliche Bestandteile, um die Praxisnähe des Projekts sicherzustellen.

Also ich kann es weiterhin "SOPRA" nennen. SWTPRA klingt einfach auch blöd.

Die Prüfungsordnung - Das unbekannte Wesen: Seminare und Proseminare

Die Prüfungsordnung ist die rechtliche Grundlage für das Studium und regelt die Rechte und Pflichten der Studenten und der Dozenten. Doch die meisten Studenten kennen die PO nur sehr wenig. In den meisten Fällen wird das Wissen nur über Mund-zu-Mund-Propaganda weitergegeben.
Schon der Vergangenheit bin ich in einigen Beiträen auf die Prüfungsordnung eingegangen. Diesmal möchte ich mir mit den Vorschriften für Seminare und Proseminare beschäftigen.
Seminare sind eine sinnvolle Art wissenschaftliches Arbeiten zu erlernen und die wissenschaftlichen Methoden zu vertiefen. Deshalb sind Seminare elementare Bestandteile des Informatikstudiums an der Uni Paderobrn.
Doch wieviele Seminar muß man im Informatik-Studium belegen? Wieviele darf man belegen?

Bachelor-Prüfungsordnung:
Ganz einfache Regelung: Es gibt keine.
Seminare oder Proseminare werden in der Prüfungsordnung gar nicht erwähnt.

Master-Prüfungsordnung:
Im Master ist dies sehr eindeutig in Artikel 16, Abschnitt 5 regelt:

Neben dem obligatorischen Seminar im Rahmen der Projektgruppe muss in einem Modul des Vertiefungsgebietet eine der Wahlpflichtveranstaltungen ein Seminar sein. In höchsten einem Wahlpflichtmodel [...] kann eine weitere Wahlpflichtveranstaltung ein Seminar sein.

"Die Silicon Valley Story" am 20. April auf Arte

Der geniale Verfilmung des Aufstieges der Firmen Apple und Microsoft - "Die Silicon Valley Story" (Orig: Pirates of Silicon Valley) wird am 20. April auf Arte ausgestrahlt.

Arte schreibt zu dem Film:

Der Fernsehfilm spielt in den Jahren, als zunehmend Computer für private Nutzungen entwickelt wurden. Die großen Rivalen waren damals Apple-Computer-Chef Steve Jobs und Microsoft-Gründer Bill Gates. Apple hatte gerade den Macintosh-Computer herausgebracht, der weitgehend auf den Forschungsergebnissen des Palo Alto Research Center von Xerox basierte. Microsoft vermarktete das Betriebssystem MS-DOS, Büro-Software wie Multiplan und zahlreiche Implementierungen der Programmiersprache BASIC. Der weltweite Erfolg von Apple II hatte die Firma Apple reich gemacht. Für eine erfolgreiche Vermarktung benötigte ihr neuer Mac die Programme von Microsoft. Daher stellte Apple der Firma Microsoft einen Prototyp ihres Computers zur Verfügung, da Microsoft zugesichert hatte, die Software weder zu untersuchen noch zu kopieren. Doch Microsoft suchte für sein Betriebssystem MS-DOS eine grafische Benutzeroberfläche mit Fenstern und Maus. Es kam zur Konfrontation zwischen den führenden Männern der beiden Unternehmen.

Ein Muß, zumal ich ihn noch nicht auf Deutsch gesehen habe. Leider ist die RC2-DVD von dem Film noch nicht veröffentlicht worden.