I really like the idea of Don Park's identicons.
His aim is largely to use it as a way to recognize commenters in blog posts by evaluating their IP address. Since the human eye or rather, the human brain is faster at telling images apart than it is at finding differences in written IP addresses, this makes commenter validation much easier. Alas, since I don't have many commenters I went for a different application. I implemented a .NET class that creates bitmaps from an integer input value, very much like Don described it here. The create method takes an integer and a size value and returns an Image.Bitmap which can be saved or used within the application. I didn't take a look at the source code provided since I don't understand like Java very much. I started from scratch using GDI+. There is a handy object available called GraphicsPath. It is a container for shapes like lines, polygons and so on. These objects can be manipulated through a transformation matrix. Just the right thing for the shapes that make up the identicon. The implementation is probably very ineffective in terms of runtime performance . I have tried to keep it as simple as possible in order to understand what's happening even later on! :-)

Here you can download the class. Feel free to use it. Feedback is appreciated.

.NET 2.0 is required but only for the generic lists that hold the shapes, it should be easy to port it back to .NET 1.1.

Wieder mal ein Stück teuer erworbenes, aber fast nutzloses Wissen: In .NET spielen dll's unterschiedlicher Versionen normalerweise prima zusammen, man kann z.B. ein Executable mit der Version 1.9.1.0 mit einer älteren Library 1.8.0.0 zusammen laufen lassen. Aha! Aber es gibt eine Ausnahme.. ist die Anwendung ein Windows Service, so stürzt sie beim Start mit einer älteren Libraryversion mit dem nicht gerade sehr hilfreichen Fehler ab:
"Error 1053: The service did not respond to the start or control request in a timely fashion"
Wie bitte, timely fashion? Die Meldung erscheint nach etwa 3-4 Sekunden! Da mußte was faul sein, aber es hat wirklich gedauert bis ich drauf gekommen bin :-\

Dieses Wochenende hatte ich ein paar Stunden Zeit, so daß ich endlich mal den SRTM Viewer debuggen konnte, der hier schon so lange rumlag, daß sich bereits ein leicht unangenehmer Geruch breitmachte ;)
Hier gibt es dazu noch ein paar Bilder.

Meine Schwiegermutter ist ganz begeistert von Patchwork. Neulich erzählte sie was von einer neuen Decke und wir kritzelten dann verschiedene Muster auf ein Karopapier. Naja, warum einfach wenn es auch kompliziert geht? Darum gibt es jetzt die Patchworkvorschau, da kann man sich das Ganze besser vorstellen. Eigentlich aber nur wieder ein autodidaktisches Projekt, um etwas besser JavaScript zu beherrschen.

Eine Shell unter Windows? Bisher nur mit äußerster Skepsis zu genießen. Von mir bislang unbemerkt gibt es endlich eine neue Shell für Windows, kräftigerweise gleich PowerShell genannt (früher hieß es mal "Monad"). Zusammen mit einer passenden Console, die mehrere Shells gleichzeitig in Tabs darstellen kann ergeben sich fast schon UNIX-artige Zustände! Ich bin entzückt.
Mit Eingabeumleitung und ähnliche Spezereien aus der Unixwelt reichlich ausgestattet. Aber das interessanteste ist die Verbindung mit .NET. Eine Variable nimmt immer implizit den Typ des entsprechenden .NET Datentyps an, mit der Folge, daß alle dazu gehörenden Methoden verfügbar sind.
Beispiel:

PS>$a = "bla di blub di"
PS>$a.Split(" ")
bla
di
blub
di
PS>

Abgefahren. Ich kratze hier ja nur an der äußersten Spitze des Eisbergs. Alle wichtigen Keywords sind ebenfalls vorhanden, so daß man in der Shell jetzt eigentlich richtige .NET Programme ausführen können müßte. Die Integration mit .NET (2.0!) ist gleichzeitig auch ein gewisser Nachteil, es dauert eine ganze Weile, bis das Teil gestartet ist und auch der von .NET her bekannte Ressourcenhunger ist vorhanden. So, jetzt muß ich noch ein bißchen weiterspielen..
Cheat Sheet

Diesmal ein eher technischer Eintrag, dessen Zweck eher eigene Gedankenstütze als öffentliche Erheiterung ist. Hoffe ich zumindest.

Im .NET Framework 2.0 gibt es zusätzlich zum bekannten DataGrid Steuerelement das neue DataGridView. Dessen Fähigkeiten wurden gegenüber dem Vorgänger stark erweitert, so daß es inzwischen nur noch Sekunden dauert, um eine Datenquelle über ADO oder eine eigene Implementierung an die Tabelle anzuschließen. Das Ding bringt bereits nette Fähigkeiten mit, z.B. die Spalten umzuordnen. Die Spalten allerdings (durch einen Klick auf den Spaltenkopf) automatisch umzusortieren ist leider nicht so einfach, wie es zunächst aussieht. Das Sortieren der Datenquelle funktioniert nur dann problemlos, wenn ein Datagrid bzw. ein Dataview angebunden ist. Kommen die Daten direkt aus der Datenbank ist das auch kein Problem. Hat man jedoch die anzuzeigenden Objekte woanders her, z.B. aus einer Liste, funktioniert das leider nicht mehr. Die Liste weiß nicht, nach welchen Kriterien sie sortieren soll. Die Lösung besteht darin, eine eigene Listenimplementierung einzuführen, die von der ursprünglichen Liste erbt und zusätzlich IBindingList implementiert.

public void ApplySort(PropertyDescriptor property, ListSortDirection direction)
{
Trace.WriteLine(string.Format("sorting column {0}",property.DisplayName));
PropertyDescriptorCollection properties = TypeDescriptor.GetProperties(typeof(AISShip));
this.sortProperty = properties.Find(property.DisplayName, true);
this.Sort(this.Comparison);
this.OnListChanged(resetEvent);
}

Diese Methode ist ein Teil der Implementierung von IBindingList. Sie wird beim Sortieren der Liste implizit (vom DataGridView durch ein callback) aufgerufen. Das spaltenrelevante Sortieren habe ich so gelöst, daß die entsprechende Spalte lokal gespeichert wird und die Suchfunktion mit einem Vergleichs-Delegaten aufgerufen wird. Das wirkt etwas ungewöhnlich, es ist auch eine Neuerung in .NET 2.0.
Die eigentliche Vergleichsfunktion sieht etwas lahmarschig aus, man hätte hier sicher noch eleganter mit Reflection arbeiten können (wenn auch weniger performant):

protected int Comparison(AISShip a, AISShip b)
{
if (this.sortProperty.Name.Equals("Timestamp"))
return a.Timestamp.CompareTo(b.Timestamp);
if (this.sortProperty.Name.Equals("Name"))
return a.Name.CompareTo(b.Name);
if (this.sortProperty.Name.Equals("Callsign"))
return a.Callsign.CompareTo(b.Callsign);
if (this.sortProperty.Name.Equals("IMO"))
return a.IMO.CompareTo(b.IMO);
// usw.
return 0;
}

Eine weitere Verbesserung kann man noch einbauen, wenn man sich beim Suchen außerdem die letzte Sortierrichtung merkt und diese dann umdreht, falls sich die Spalte nicht geändert hat. Damit erreicht man dann das typische Verhalten, daß der Benutzer aus dem Windows Explorer her kennt.