Author Archiv

Um unsere ASP.NET-MVC2-Kenntnisse mal wieder etwas aufzufrischen, haben ein paar von uns das zweitägige Webcamp von Microsoft in München/Unterschleißheim besucht, an dem man unter den Teilnehmern auch ein paar bekannte Gesichter wie Pete Sacchet, Christian Deger und Golo Roden angetroffen hat.

Am ersten Tag wurden die Grundlagen von MVC2, Entity Framework, JQuery und IIS vermittelt. Dabei wurde anhand einer Rich Web Application gezeigt, wie MVC2, das Entity Framework und JQuery zusammenspielen können. Am zweiten Tag mussten die am Vortag zusammengestellte Teams ein Projekt auf diesen Themengebieten basteln und vorstellen.

Moderiert wurde das Ganze von Jon Galloway und Christian Wenz, die am zweiten Tag bei Problemen mit Rat und Tat zur Seite standen.

Erhofft hatten wir uns von den zwei Tagen, einiges über MVC2 und JQuery zu erfahren. Enttäuscht wurden wir nicht, da uns noch unbekannte HtmlHelper, Validierungsmethoden sowie ein paar Tricks im Umgang mit Visual Studio gezeigt wurden. Das Entity Framework einmal im Einsatz zu sehen, war ganz nett, aber für uns nicht allzu interessant, da wir im Moment mit NHibernate arbeiten und damit ganz gut fahren.

Ja, zu essen gab es auch was. War lecker, wie man sieht. :P

Als Projekt am zweiten Tag haben wir uns für ein Buchungssystem von Ferienwohnungen entschieden. Wir waren leider nicht offiziell dabei, da uns diese Idee erst nach den Pitches eingefallen ist.
Das einzig Negative an der ganzen Veranstaltung war das Netz im Hotel Dolce Munich. 100 Leute, die gleichzeitig versuchen, über eine gefühlte DSL-Leitung zu saugen, saugt einfach. Der Proxy des Hotels setzte noch einen drauf und leitete Aufrufe auf localhost um, was den Start der Applikation in der Entwicklungsumgebung sehr schwer machte :>.

Nachdem man dann das WLAN deaktiviert hatte, konnte es dann auch losgehen.

Um uns möglichst nah an den Projekten in der Arbeit zu orientieren, haben wir erstmal Folgendes gemacht: SVN angelegt, Features, die wir aufnehmen wollten, erörtert, Architektur gezeichnet, Komponenten herausgearbeitet, Contracts erstellt, Komponenten angelegt, Komponenten implementiert. Und schwupps war die Zeit um. :> Wir sind leider nicht mit unserem Projekt fertig geworden, haben aber trotzdem in den zwei Tagen einiges gelernt.

Glückwunsch nochmal an die Gewinner des Wettbewerbs (Schiffe versenken).

kick it on dotnet-kicks.de

Share

Comments 2 Kommentare »

Endlich ist es geschafft. Ich habe das Buch “Clean Code” von Robert C. Martin a.k.a. Uncle Bob durchgelesen. Nach dem ersten Teil hier nun die versprochene Fortsetzung meiner Zusammenfassung:

10 Classes

Die erste Regel von Klassen lautet: Sie sollten klein sein.
Die zweite Regel von Klassen lautet: Sie sollten noch kleiner sein als das.

Klassen sollten eine hohe Kohäsion haben.
Kohäsion ist ein Maß dafür, wie stark die Methoden und Daten einer Klasse miteinander zu tun haben. Zur Verdeutlichung:
Eine Klasse, in der jede Membervariable von jeder Methode der Klasse verwendet wird, ist maximal kohäsiv.

Bei Klassen sollten folgende Prinzipien beachtet werden:

  • Das Single Responsibility Principle (SRP), welches besagt:
  • Eine Klasse oder ein Modul sollte nur einen Grund haben sich zu ändern. Eine Klasse sollte sich nur um EINE Sache kümmern.

  • Das Open Close Principle (OCP), welches besagt:
  • Klassen sollten offen für Erweiterungen sein, aber geschlossen für Modifikation.

  • Das Dependency Inversion Priniciple (DIP), welches besagt:
  • Klassen sollten von Abstraktionen abhängen und nicht von konkreten Klassen.

11 Systems

Separiere Konstruktion von Benutzung.
Realisiert werden kann das durch Dependency Injection.

Dependency Injection = Klassen bekommen ihre Abhängigkeiten von außen über den Konstruktor oder Setter übergeben. Dieses Pattern unterstützt das SRP, da sich die Klasse nicht mehr um das Instanzieren dieser Abhängigkeiten kümmern muss. Realisiert wird das ganze über Inversion of Control Container wie Windsor, Spring und wie sie alle heißen. Bei diesen Containern werden die Abhängigkeiten einmalig definiert, so dass man sich bei der Instanzierung nicht mehr darum kümmern muss.

Wenn Objekte zu einer bestimmten Zeit erstellt werden müssen, sollten Factories verwendet werden.

Systeme werden nicht von heute auf morgen gebaut. Sie werden nach und nach ausgebaut. Um sicherzustellen, dass dabei noch alles funktioniert, gibt es TDD, Refaktorisieren und Separation of Concerns.

12 Emergence

Viele Leute sagen, dass Kent Beck’s 4 “Rules of Simple Design” einem sehr helfen, gut designte Software zu erstellen.

Kent Beck sagt:
ein Design ist „simple“, wenn:

  • alle Tests durchlaufen
  • kein doppelter Code vorhanden ist
  • wenn es die Absicht des Programmierers ausdrückt
  • die Anzahl von Klassen und Methoden minimiert sind

in der Reihenfolge.

13 Concurrency

In Multithread-Anwendungen bekommt man schon bei minimaler Anforderung ein Problem mit der Komplexität. Da mit steigender Komplexität auch die Fehleranfälligkeit steigt, gibt es ein paar Prinzipien, die diese minimieren können:

Die Concurrency Defense Principles

  • Single Responsibility Principle
  • Trenne multithreaded Code von nicht-multithreaded Code

  • Limit the Scope of Data
  • Man sollte den Bereich, in dem multithreaded Code verwendet wird, möglichst klein halten.

  • Use Copies of Data
  • Verschiedene Threads sollten nicht mit demselben Objekt arbeiten. Wenn möglich sollte mit Kopien von diesem Objekt gearbeitet werden.

  • Independence
  • Threads sollten so unabhängig wie möglich sein

  • Library
  • Natürlich sollte man die Bibliothek, die man für Multithread-Anwendungen verwendet, sehr gut kennen.

14 Successive Refinement

Um Clean Code schreiben zu können, muss man erst Dirty Code schreiben und ihn dann bereinigen.

Einer der besten Wege, ein Programm zu ruinieren, ist, massive Änderungen an der Struktur vorzunehmen, um das Programm zu verbessern. Um das zu verhindern, nutzt man die Disziplinen von TDD. Eines der zentralen Doktrinen dieses Ansatzes ist es, das System zu jeder Zeit lauffähig zu halten. Mit TDD ist es also nicht erlaubt eine Veränderung am System vorzunehmen, die das System bricht.

15 JUnit Internals

JUnit Internals halt… (Kapitel überlesen)

16 Refactoring SerialDate

War mir eindeutig zu Java-lastig… (Kapitel überlesen)

17 Smells and Heuristics

In diesem Kapitel zeigt Uncle Bob eine Liste von Smells und wie man sie beseitigen kann. Er lobt das Buch “Refactoring” von Martin Fowler. Dieses Buch steht eh schon ganz oben auf meiner To-do-Liste. Das werde ich also demnächst angehen.

Zusammenfassung

An dieser Stelle ein Dank an mein Entwicklerteam, dass ich das Buch so lange in Beschlag nehmen durfte :) (Teil 2 ging irgendwie zäher). Einen großen Dank auch an Peter Bucher und Rene Drescher-Hackel für ihre Ergänzungen bzw. Einwände. Man darf sicherlich nicht alles so ganz ernst nehmen und man kann es auch übertreiben (siehe Pyramiden etc.). Natürlich sollte man nicht blind durch die Welt laufen, sondern auch Dinge hinterfragen, aber man muss sagen, dass die Punkte von CCD (das ja auf diesem Buch beruht) durchaus plausibel sind. Ich denke schon, dass CCD unerfahrenen aber auch erfahrenen Entwicklern einen SOLIDen Weg zeigt, den man gehen kann und der sogar schon gepflastert ist. Man kann sich natürlich auch mit der Machete durch dichten Dschungel schlagen, was natürlich cool ist :) – aber halt wesentlich langsamer. Es sei denn man ist Chuck Norris.

kick it on dotnet-kicks.de

Share

Comments 1 Kommentar »

Clean Code

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.

Hier also meine kleine Zusammenfassung.

Kapitel 1 Clean Code

In diesem Kapitel wird beschrieben, was Clean Code ist und dass man „Clean Code“ schreiben muss, um sich selbst einen professionellen Softwareentwickler nennen zu dürfen. Was Clean Code ausmacht, hat Christina schon in ihrem Artikel „Clean Code Developer – The Yellow Brick Road of the Coder“ beschrieben. Außerdem wichtig sind :
LeBlanc’s Gesetz : Later equals never
und
die Boy Scout Rule : Leave the campground cleaner than you found it.

Kapitel 2 Meaningful Names

Benennung in einem Projekt ist sehr wichtig, sei es um das Gesuchte zu finden oder um den Sinn einer Variablen oder einer Methode ohne langes Überlegen zu erkennen. Man sollte bei der Vergabe von Namen so gründlich vorgehen, wie man es für seinen Erstgeborenen tun würde. In der heutigen Zeit ist die Ungarische Notation absoluter Quatsch. Die IDE kennt den Typ, warum sollte man das in den Variablennamen integrieren?

Kapitel 3 Funktionen

Die erste Regel von Funktionen lautet: Sie sollte klein sein.
Die zweite Regel von Funktionen lautet: Sie sollte noch kleiner sein als das.
Eine Funktion sollte nur eine Sache tun. Macht sie mehr als eine Sache, steigt die Komplexität. Und Komplexität ist schlecht.
Eine gute Benennung der Funktionen ist, wenn der Name beschreibt, was die Funktion macht. Dabei darf der Name ruhig lang sein, wenn es der Lesbarkeit des Codes dienlich ist.
Flagargumente sind verboten! Durch dieses Flag macht die Methode schon mehr als eine Sache und wir wären wieder bei der Sache mit der Komplexität. Böse.
Die ideale Anzahl von Parametern einer Funktion ist 0! Aber da nicht immer alles ideal laufen kann, sind 1, 2 auch okay. Aber mehr als 3 ist verboten. Okay?
Last but not least eine sehr wichtige Grundregel: Don’t Repeat Yourself!
Denn: Durch Verdopplung des Codes steigt der Wartungsaufwand proportional.

Kapitel 4 Kommentare

Kommentare sind schlecht, denn sie lügen! Ja, LÜGE! Code wird häufig verändert durch neue Anforderungen oder Refaktorisierungsmaßnahmen, der dazugehörige Kommentar aber meist nicht, wodurch schlechte bzw. in die Irre führende Kommentare entstehen. Es gilt also: Keine Kommentare sind besser als schlechte Kommentare. Man sollte die Zeit, die man für das Schreiben von Kommentaren aufbringen würde, lieber für die Refaktorierung der Methode verwenden. Denn Code sollte sich selbst erklären und ist außerdem die aktuellste Dokumentation. Nur schlechter Code muss kommentiert werden.
Auskommentieren des Codes ist verboten! Andere Programmierer, die den auskommentierten Code sehen, werden diesen nicht löschen, da sie denken, dass es einen Grund haben muss, dass er dort steht und dass er zu wichtig ist, um gelöscht zu werden. Somit bleibt dieser “Kommentar” auf ewig dort und müllt unseren “Clean Code” zu. Heutzutage muss man nichts mehr auskommentieren. Durch Versionskontrolle geht nichts mehr verloren.

Kapitel 5 Formatting

Eine perfekte Formatierung gibt es nicht, vielleicht für jeden Einzelnen, aber nicht für ein Team. Jeder hat seine Vorlieben. Letzendlich ist nur wichtig, dass sich das Team auf EINE Formatierung einigt. Jeder in diesem Team muss sich daran halten, auch wenn es für einen selbst nicht die optimale Lösung ist. Der Nutzen einer gemeinsamen „Sprache“ ist einfach zu groß, denn Kommunikation ist das A und O.

Kapitel 6 Objects and Data Structures

Es wird grundsätzlich zwischen Objekten und Data Structures unterschieden.
Objekte enthalten Businesslogik und sollten ihre interne Struktur nach außen hin verbergen, also keine Properties, welche die Member-Variablen des Objekts zurückgeben oder verändern lassen. Nur das Objekt selbst sollte seinen internen Status ändern können, wobei bei Objekten auf das Gesetz von Demeter zu achten ist:
Es besagt, dass Objekte nur mit Objekten in ihrer unmittelbaren Umgebung kommunizieren sollen.
Also:
Methode m der Klasse k sollte nur Methoden nutzen von:

  • k
  • Ein Objekt, dass von m erstellt wurde
  • Ein Übergabeparameter an m
  • Ein Memberobjekt von k

Data Structures sind zum Beispiel Data Transfer Objects, kurz DTOs. Das sind Klassen ohne Methoden, also reine Datenträger. Eine spezielle Form von DTOs sind Active Records. Diese Objekte haben Methoden wie Save() und Find(), enthalten jedoch keine Businesslogik.

Kapitel 7 Error Handling

Moderne Programmiersprachen haben ein Feature namens Exceptions. Das sollte man auch nutzen. Fehlercodes oder ähnliches sind veraltet. Eine gute Exception sollte allerdings so viel Information liefern, dass man auch ohne Debuggen den Fehler identifizieren kann, sonst kann man sich die ganze Mühe auch sparen.
Außerdem noch 2 wichtige Grundregeln:
Don’t Return null – somit wird es unnötig auf null zu prüfen
und
Don’t Pass null – null an eine Methode zu übergeben ist noch schlimmer als null zu returnen

Kapitel 8 Boundaries

Man sollte unbedingt das Adapterpattern anwenden, wenn man 3rd party Code verwendet. 3rd party code sollte an so wenig stellen wie möglich verwendet werden, um Abhängigkeiten zu vermeiden.

Kapitel 9 Unit Tests

Die 3 Gesetze von TDD:

  1. Man darf keinen produktiven Code schreiben, solange man keinen fehlgeschlagenen Unit Test geschrieben hat.
  2. Man darf nicht mehr als nötig schreiben, um einen Unit Test fehlschlagen zu lassen, und Fehler beim Kompilieren bedeutet einen fehlgeschlagenen Test.
  3. Man darf nicht mehr produktiven Code als nötig schreiben, um einen fehlgeschlagenen Test zu reparieren.

Außerdem gilt: Tests sollten genauso “Clean Code” sein wie produktiver Code. Tests sollten genauso evolvierbar sein. Denn wenn sich der Code verändert, muss sich der Test auch verändern.
Ein Test sollte nur ein Szenario abdecken – wieder das Thema Komplexität.

Clean Tests folgen noch 5 anderen Regeln:
Fast
Independent
Repeatable
Self Validating
Timely

Teil 2 gibt es hier

kick it on dotnet-kicks.de

Share

Comments 5 Kommentare »

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!

Falls sich jemand nicht mehr an uns erinnert, hier ein Bild von uns :)


(von links nach rechts: Andreas Seebauer, Stefan Kölle, Thomas Christian, Christina Hirth)

Es gab zwar keine vorher festgelegten Themen, aber diese wurden vor Ort vorgeschlagen und danach demokratisch bestimmt. Es wurden sehr interessante Bereiche besprochen, aber leider konnte man nicht in jeden Open Space gleichzeitig. :)

Für uns am interessantesten waren:
MVC, DDD, IoC und DI (danke an Albert, Markus, Thomas, Peter, Stefan und Sergey)

Das Themenboard :

Am Sonntag hat uns besonders die Clean-Code-Development-Runde gefallen. Wir sind dabei, dies in unserem Team umzusetzen. Für alle, die es nicht kennen, gibt es hier alle Informationen.

Die Organisation war einwandfrei. Das Essen war lecker und Getränke waren massenhaft vorhanden. Danke an Thomas und Alex.

Raum 5 war auch das absolute Highlight. Es war immer sehr entspannend da oben.
Leider haben wir die Party verpasst, da wir nicht dort übernachtet haben. Wir hätten zu gerne Alberts Bauchtanz gesehen. :)

Beim Gewinnspiel hat natürlich Stefan den Hauptpreis (eine Telerik-Lizenz) gewonnen. :)

Auch einen Tag nach dem .NET Open Space Süd sind wir immer noch voller Begeisterung und müssen das Erlernte erst einmal verarbeiten. Für uns ist jetzt schon klar, dass wir unbedingt beim nächsten Mal wieder dabei sein wollen.

Wir raten wirklich jedem Programmierer, der besser werden möchte, das nächste Open Space zu besuchen. Man trifft dort freundliche und teilweise sehr erfahrene Entwickler, die ihr Wissen gerne weitergeben.

Bis zum nächsten Mal.

Share

Comments Keine Kommentare »

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.

Definiert und intstanziert werden sie mit new und einem Objektinitialisierer:

    var mitarbeiter = new { Name = "Müller", Abteilung = "IT" };

var ist der implizite Typ und nicht der anonyme Datentyp. Er fungiert hier lediglich als container für die Instanz des anonymen Datentyps, die mit new {} erzeugt wird.

Gibt man keinen Namen für die Properties an, werden die Namen der Properties verwendet, mit denen initialisiert wird.

    var abteilung = new { Abteilungsname = "IT" };
    var mitarbeiter = new { Name = "Müller", abteilung.Abteilungsname };
    Console.WriteLine(mitarbeiter.Abteilungsname);

Wenn man mit Werten initialisiert, muss ein Name angegeben werden.

Anonyme Datentypen bieten sich an, wenn man Abfragen mit Linq ausführt und entweder nur eine Teilmenge des ursprünglichen Objekts braucht, oder wenn man ein Objekt erweitern will, ohne extra eine neue Klasse zu definieren.

Hier ein Beispiel aus einem Castle Monorail Projekt, in dem eine erweiterte Liste an eine vm gegeben wird, ohne eine neue Klasse definieren zu müssen. Es soll dabei eine Liste erstellt werden, in der die Mitarbeiter mit ihrem Horoskop verknüpft werden :

    public void Action() {
        IList<Mitarbeiter> mitarbeiterListe = m_service.GetMitarbeiter();
        var mitarbeiterMitHoroskopListe = (from mitarbeiter in mitarbeiterListe
            select new { Mitarbeiter = mitarbeiter,
                         Horoskop = GetHoroskop(mitarbeiter.Geburtsdatum) });
        PropertyBag["mitarbeiterMitHoroskopListe"] = mitarbeiterMitHoroskopListe;
    }
Share

Comments Keine Kommentare »

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.

Hierfür habe ich folgende Konfiguration verwendet:

Config

Nach der Bestätigung der Konfiguration sieht das Ergebnis folgendermaßen aus :

 

   12     /// <summary>
   13     /// Summary
   14     /// </summary>
   15     class Program {
   16         static void Main() {
   17             // Kommentar
   18             Console.WriteLine("Hello World");
   19         }
   20     }

Share

Comments 3 Kommentare »