build broken

Da es für einen Entwickler wichtig ist, sich ständig weiterzuentwickeln, sollte man sich durch Austausch mit anderen Entwicklern, aktives Programmieren oder eben Bücher weiterbilden. Das Buch, das ich gerade lese, heißt Clean Code von Robert C. Martin a.k.a. Uncle Bob. Ich bin momentan bei der Hälfte des Buches und muss sagen, dass ich von dem Buch ziemlich begeistert bin. Da ich denke, dass es vielen Entwicklern helfen würde, besseren Code zu schreiben, habe ich den Text ein wenig verkürzt und zusammengefasst – was natürlich nicht heißt, dass man dieses Buch nicht lesen muss. Meiner Meinung nach ist es absolute Pflichtlektüre für jeden Entwickler, der was auf sich hält.

Seit dem ich Code schreibe, steht für mich ein klarer und verständlicher Code an oberster Stelle. Ich hatte dann vor ca. eineinhalb Jahren Code Complete und The Pragmatic Programmer gelesen und dadurch die ersten Antworten bekommen, WIE man den Code unter Kontrolle hält. Anfang 2009 sind wir – ich und Stefan – durch den Podcast von Hanselman und Uncle Bob auf das Thema SOLID gestoßen – und darüber auch eine ausgiebige Diskussion geführt. Eins war uns klar: die Ideen, die dahinter stecken, könnten die Antwort auf unsere Suche sein.

Wir sind zu viert früh morgens in München aufgebrochen, um bei unserer ersten .NET Open Space-Veranstaltung teilzunehmen.

Da wir eine relativ lange Anfahrt hatten, waren fast alle schon da, als wir ankamen. Es waren um die 60 Leute.
Während der Vorstellungsrunde haben wir gemerkt, dass das Open Space nicht nur von Gurus besucht wird, sondern auch von Einsteigern. Wir hatten befürchtet, dass wir dort fehl am Platz sind, da wir relativ neu in der .NET-Community sind und noch relativ wenig Wissen weitergeben können. Aber wir wurden freundlich aufgenommen und können Jedem nur empfehlen, beim nächsten Mal dort hinzugehen. Einen schnelleren Weg, Wissen aufzubauen, gibt es nicht!

Angeregt durch die Diskussion auf dem Open-Spaces zum Thema schemalose Datenbanken, werden wir heute bereits die Vorabversion unserer StupidDB als open-source releasen.

Die StupidDB entstand bei uns aus der Notwendigkeit, immer wieder Objekte und Files schnell und einfach zu speichern, dies serverlos und trotzdem skalierbar und hochverfügbar vorzuhalten. Die StupidDB lässt sich am besten wie folgt beschreiben:

StupidDB ist ein einfaches Objektspeicherungs-Framework auf dem Filesystem. Vergleichbar mit dem WebCache kann man in der StupidDB jegliches Objekt ablegen, welches kosteneffizient auf dem Filesystem gespeichert wird. Geladen werden können Objekte und Binärdaten mit einem eindeutigen Key und einer Partition. Den echten Speicherort auf der Festplatte ermittelt StupidDB selbst. Durch Replikation des Filesystems z.B. per Windows-DFS ist zudem eine einfache Hochverfügbarkeit und Skalierbarkeit der Datenbasis herzustellen.

Es ist soweit, morgen geht es los: unsere erste Open Space Veranstaltung.

Wir fahren zu viert hin, alle sehr gespannt und erwartungsvoll, mit sehr viele Fragen in den Taschen.

Ich habe auch noch eine geheime Frage, worauf ich eine Antwort finden hoffe: warum sind außer mir keine Frauen dabei !!

Kommentare (Archiv)

1. Stefan Kölle

   Juli 11, 2009 um 10:10 pm

   Sehr informativer erster Tag!

2. TheYellowBrickCode » NOS Sued kommt: Ulm heißt heuer Karlsruhe

Vorbereitung

Über Reflection kann man zur Laufzeit relativ einfach an alle Informationen eines Assembly herankommen. So ist es möglich, dass man von einem Assembly den Namen, Klassen, Methoden mit ihren Parametern, Eigenschaften und Rückgabewerte, usw. auslesen kann. Aber nicht nur das Auslesen ist möglich, sondern auch das Setzen.

Jetzt stellt sich für den einen oder anderen vielleicht die Frage, warum man zur Laufzeit auf diese Daten zugreifen kann. Jede Assembly verfügt über Module in denen sich die einzelnen Typen(Klassen) befinden. Für jedes Modul gibt es Metadaten, in denen die einzelnen Typen beschrieben werden. Die Assembly selbst verfügt noch über ein Manifest, in dem sich alle Informationen zum Assembly (z.B. Name, Version) befinden. Wenn man über Reflection auf Assemblies zugreift, dann werden diese Metadaten und das Manifest dafür herangezogen. Die Metadaten verfügen zwar noch über die Informationen, welche Modifizierer für Methoden, Properties, usw. verwendet wurden, aber der MSIL-Code (die Zwischensprache, die vom Endcompiler in die plattformspezifische Sprache übersetzt wird) nicht mehr. Die Modifizierer sind nur für den Compiler relevant und werden nach dem Kompilieren nicht mehr berücksichtigt. Somit ist es auch möglich über Reflection Properties, Methoden, usw. zu verwenden, die nicht öffentlich sind.

Seit einiger Zeit sind wir dabei, unser Portal zu refaktorisieren. Das entfernte Ziel ist, alles in .NET um zu bauen. Das betrifft zur Zeit über tausend Seiten aber wir möchten noch in diesem Leben fertig sein

Dazu kommt noch, dass wir – selbstverständlich – agiles Softwarentwicklung betreiben, was eine ständige und rhythmische Iteration vorsieht, keine Mega-Projekte mit ungewissem Ende. Also haben wir die verschiedenen Bereiche identifiziert und diese werden einer nach dem anderen neu gebaut.
Die neuen DLL-s in .NET werden mit Hilfe von verschiedenen Webservices angesprochen. Das führt allerdings unweigerlich dazu, 2 Technologien – ASP-Classic und .NET(C#) – miteinander sicher kommunizieren zu lassen. Das funktioniert so:

Anonyme Datentypen sind Klassen, die erst beim Kompilieren durch den Compiler definiert werden. Die Klassendefinition befindet sich also nicht im Quellcode. Die anonymen Datentypen leiten wie jedes andere Referenzobjekt von der Klasse object ab. Sie sind als reine Datenklassen gedacht und es können keine weiteren Methoden oder Events hinzugefügt werden. Obwohl der anonyme Datentyp auf Quellcodeebene noch nicht definiert ist, muss dank Visual Studio nicht auf die Intellisense verzichtet werden.

Ich bin gerade auf eine sehr interessante Seite mit einzelnen WebCasts zu .NET Themen aufmerksam geworden.

http://www.dimecasts.net/

Habe mir dort gleich mal “#106 – Learning the Adapter Pattern” angesehen, dort wird sehr schön in nur 9 Minuten erklärt wie man das AdapterPattern einsetzt.

Da wir kein geeignetes Plugin für Wordpress gefunden haben, um .NET-Code wie in Visual Studio darzustellen, habe ich ein wenig gegooglet und bin auf ein Addin namens “Copy Source As HTML” für Visual Studio 2008 gestoßen. Mit diesem Addin ist es möglich, seinen Sourcecode schön formatiert in HTML umzuwandeln.

Downloadlink und Anleitung findet man hier.

Nach der Installation steht im Kontextmenü neben Copy, Paste usw. auch der Punkt “Copy As HTML…” zur Verfügung. Bevor der umgewandelte Sourcecode in den Zwischenspeicher gespeichert wird, hat man die Möglichkeit, seine Konfiguration anzupassen.