Darauf habe ich die letzten 2 Monate sehnsüchtig gewartet, ein Resharper das die neuen .NET 3.5 Spach-Features unterstützt. Seit dem 15.2 gibt es die ersten „ReSharper 4.0 Nightly Builds“. Die Installation und Benutzung ist soweit reibungslos, bei Stefan Lieser ebenfalls. Viel Spass damit :-)

Folgender Aufruf zeigt, dass es voran geht und wir von schnöder Entwicklungstätigkeit langsam zu den wesentlichen Dingen der Welt vordringen. Hoffentlich ist und hat die Methode keinen Bug :-)

Untiges Bild zeigt deutlich, dass Eclipse Benutzer mehr Hilfe durch Google in Anspruch nehmen müssen und einen höheren Informationsbedarf haben als die Visual Studio Anwendergemeinde. Die Recherche belegt dies imposant. Eclipse Entwickler sind offensichtlich auch beeinflusst von astronomischen Ereignissen. Ihr Hilfebedarf wächst mit Mond und Sonnenfinsternissen maßlos. Die Frage für IT-Entscheider muss also lauten, ob Sie sich im harten Projektalltag auf Entwicklerteams verlassen möchten, die derartig Bedingungsfühlig sind.

Eines der größten Themen wenn es um Unit-Testing geht, ist das Mocken von Objekten. Die Grundidee beim Mocken ist fein granuliertes Testen zu ermöglichen, in dem Stellvertreter Objekte erzeugt werden, die die Bedürfnisse des Testfalls befriedigen. Hierfür gibt es in der .NET Welt eine Reihe von Frameworks die dies ermöglichen. Die bekanntesten sind wohl NMock, RhinoMocks und das Mächtige TypeMock.NET. Seit mehreren Jahren bin ich nun Test Infected, was mein Entwicklerleben deutlich einfacher macht. Im Schnitt liegt mein Test-Coverage für die Businessschicht bei über 80%. Trotz dessen sind Mocking Frameworks noch nicht wirklich in meinem Toolset gelandet. Stattdessen arbeite ich mit Setup Erzeuger Klassen, die die Businessschicht verwenden um einen definierten Zustand zu erzeugen: Ein Nebenprodukt dieser Erzeuger Klassen ist, dass sie bei der Entwicklung verwendet werden können um Testdaten zu erzeugen, wieder und wieder. Ein weiterer Pluspunkt ist, dass die API von Businessobjekten durch vermehrte Verwendung „Benutzerfreundlicher“ wird. Natürlich hat dieser Ansatz Grenzen. Testfälle müssen schnell sein, sonst werden sie nicht regelmäßig aufgerufen. (Nicht nur) Entwickler warten nicht gerne. Die Verwendung von externen Ressourcen für Testfälle fällt also flach. (Es sei denn die Unit-Test Umgebung soll auch für Integrationstest herhalten). Da externe Resourcen sowieso mit einem Proxy versehen gehören, ist das Erzeugen von Mocks (auch wieder ohne MockFramework) leicht. Hier sind IoC Container großartige Helfer. Der Gebrauch von Datenbanken sollte für das Erzeugen eines definierten Zustands unbedenklich sein. Eine Entwicklerdatenbank sollte mehr als 1000 CRUD Operation in der Sekunde verdauen können, was auch das Erstellen von komplizierten Testfällen nicht behindern sollte. Und wenn die Laufzeit der Test auf über 3sec ansteigt, kann man diese auch gruppieren und nur eine Teilmenge der Tests ausführen. Was aber frühestens bei 100 Tests, eher deutlich später eintreffen sollte.

Wow das ging schnell. Wir haben uns am Montag für "Microsoft Empower for ISV" Program angemeldet. Das Programm ermöglicht es Unternehmen 1 Jahr, 5x MSDN Premium Subscriptions für €320 (ohne MwSt) zu erhalten und kann optional um ein Jahr verlängert werden. Vorhin kam unser UPS Mann vorbei und brachte ein 4.5 Kilo Paket. Inhalt: u.a 2 dicke MSDN Ordner mit allem was glücklich macht. Wie bei jeder anderen Subscription gibt es auch die MSDN-Subscriber Downloads. Wenn ich mich erinnere, wie ich vor 5 Jahren noch an Linux Servern gefrickelt und eifriger PHP Verfechter war und zum Thema Microsoft kein gutes Wort gefallen ist (Kann wohl an dem etwas ungewollten Abstecher in classic ASP mit VB-Script gelegen haben) und vergleiche: Heute weiß ich in welchen Haus auf dem Microsoft Campus das Büro von Scott Gutherie ist (No 42 ;) und dank Don Box weiß ich auch wie es von Innen aussieht (hier das Video).. Wie sich die Zeiten ändern :-) Microsoft liefert wunderbare Entwicklertools und macht mit IIS 7.0  und Windows 2008 Server wohl einen Quantensprung. Die OSS Community gedeiht und seit der SVN-Bridge macht auch Codeplex mehr Spass. Und jetzt fällt mir eigentlich nur noch Steve Balmer ein: ("Developers, Developers, Developers!", scheint ganz gut zu funktionieren :-)

Zurzeit entwickeln wir eine Ausschreibungsplattform ähnlich zu MyHammer, für die Vermittlung von Druckaufträgen. Eine Ausschreibung nennen wir ein wenig unpräzise Auktion. Die derzeitige Herausforderung ist das Abbilden und der Test verschiedener Zustände sowohl für die UnitTests als auch für das Frontend. Hier ein (vereinfachtes) Zustandsdiagramm, das die Situation ein wenig verdeutlicht: Wir haben also 5 Zustände und 8 Übergange (Transitions). Es fehlen noch einige Bedingungen (Guards) und in Real sind noch ein par mehr Übergänge möglich. Da die Anforderungen sich während der Entwicklung mit sehr hoher Wahrscheinlichkeit ändern werden, ist das Diagramm für also absolut ausreichend. Nun die Fragen: Wie lässt sich das schnell und einfach implementieren? Wie lässt sich das Ergebnis schnellst möglich im User Frontend testen, um eine Gefühl dafür zu bekommen was sinnvoll ist und was nicht. Der erste Schrit ist die Implementierung, hier ein erster Ansatz: Ganz klassisch bekommt jeder Zustand eine Klasse. Die Möglichen Übergänge werden dessen Methoden. Fangen wir jedoch erstmal klein an bauen ein Enum für jeden Zustand. public enum RequestState{ Active, ExpiredWithBids, ExpiredNoBids, Awarded, ClosedSuccessful, ClosedUnsuccessful } Es steht in Frage ob das Enum bis zum Ende der Implementierung überleben wird, aber wir gesagt, wir fangen klein an. Im Nächsten Schritt möchten wir gerne Wissen, in welchem Zustand sich eine Auktion (im Quellcode und weiter Anfrage genannt) gerade befindet. Noch weiß die Anfrage nichts von Zuständen, also müssen wir von Aussen etnscheiden. Zunächst verantwortlich für den aktuellen Zustand wird die Klasse "RequestStateService": public class RequestStateService{ private Request _request; public RequestStateService(Request request) { _request = request; } public RequestState GetState() { if (Active()) return RequestState.Active; else if (ClosedUnseccessful()) return RequestState.ClosedUnsuccessful; else if (ClosedSuccessful()) return RequestState.ClosedSuccessful; else if (Awarded()) return RequestState.Awarded; else if (ExpiredHavingBids()) return RequestState.ExpiredWithBids; else if (ExpiredNoBids()) return RequestState.ExpiredNoBids; throw new Exception("unknown state" + _request.Id); } ... Eine "RequestStateService" Instanz ist also immer zuständig für einen "Request".   Noch sind Methoden Stubs, die sich dank Resharper von selbst (ALT Enter) generiert haben. ... private bool Active() { throw new NotImplementedException(); } private bool ExpiredHavingBids() { throw new NotImplementedException(); } private bool Awarded() { throw new NotImplementedException(); } private bool ClosedSuccessful() { throw new NotImplementedException(); } private bool ClosedUnseccessful() { throw new NotImplementedException(); } private bool ExpiredNoBids() { throw new NotImplementedException(); }} Im nächsten Schritt müssen wir herausbekommen wie jeder Zustand definiert ist. Die Idee ist es den Zustand über die Eigenschaften eines "Request" Objekts in Erfahrung zu bringen. Der Einfachheit halber nähern wir uns dem Problem mit Kommentaren. private bool Active() { //Not Closed //Auction End Before Now } private bool ExpiredNoBids() { //Not Closed //Auction End After Now } private bool ExpiredHavingBids() { //Not Closed //Auction End After Now //Has Bids } private bool Awarded() { //Not Closed //Auction End After Now //Has Award } private bool ClosedSuccessful() { //Is Closed //Has Award //May be better: Request knows his own state? } private bool ClosedUnseccessful() { //Is Closed //Has No Award //May be better: Request knows his own state? } Um das ganze übersichtlicher zu machen und ein wenig mehr Einblick in die Situation zu bekommen hier ein Klassendiagram eines Requests:   Ein Request enthält also mehrere Bids (Gebote). Ein Gebot ist aus dieser Sicht Teil eines Requests und ist daher aggregiert. Prinzipiell könnte man auch argumentieren, das ein Gebot auch für selbst existieren kann aber die Notation für Aggregation ist in UML (1.0;) irgendwie immer ein bisschen Geschmackssache, eine Assoziation wäre sicherlich auch Okay. Wobei die MDA Verfechter und Verwender sicherlich über die Art der Verknüpfung eine Aussage über die Implementierung treffen würden. Aber dieses Diagramm soll nur einen Überblick geben, also ist das was ein CodeGenerator aus dem Diagramm machen würde egal. Dazu kommt das Diagramm Tool Gliffy nicht ganz UML konform ist, aber einfach und schnell zu bedienen.  U.a fehlen zum Beispiel Quantifier. Hier nochmal ein alternatives Diagramm für das gleiche Thema. Besser herausgestellt ist, dass ein Request (Anfrage) keinen oder einen Award (Zuschlag) hat. Während Request und Bid ziemlich vollständig implementiert sind und es auch schon eine ziemlich umfangreiche Oberfläche dafür gibt, fehlt das Verteilen von Zuschlägen noch komplett. Hierfür müssen erstmal die Anforderungen erarbeitet werden, dazu noch das User Interface. Wenn das geschehen ist, geht es in ein, zwei Tagen weiter mit dieser Miniserie. Abschliessend wie nach jedem Arbeitsschritt: Alles Tests laufen lassen und erst dann weitermachen, wenn alles grün ist :-)

Wo der der Unterschied zwischen "Method Chaining" und einem "Fluent Interface" liegt, ist sicher eine Ermessensfrage. Hier ein Beispiel für Method Chaining: 1 StringBuilder stringBuilder = new StringBuilder(); 2 stringBuilder 3 .Append("Method Chaining -") 4 .Append("die wohl älteste Methode") 5 .AppendLine("der Welt") 6 .AppendLine(":-)"); Ein Fluent Interface liefert hingegen Kontext, nehmen wir diesen Code:   1 PlaceOrder 2 .CreateNew(PremiumOrder.With(22).Items) 3 .For.User("MR-T") 4 .InCase( 5 User.IsFriendlyLevel == AboveAverage && 6 User.Age > 18 7 ).Commit()   Die Implementierung für obigen Code ist deutlich interessanter aufwändiger. Wenn bis zum Ende durch exerziert, ist nach jedem Methodenauswahl nur eine sinnvolle Menge von Methoden, also Kontext Abhängiges Interface nach außen gelegt.    1 public class PlaceOrder 2 { 3 public static IOrderPrepared CreateNew(OrderDescriber orderDesc){ 4 return GetPreparedOrderBy(orderDesc); 5 } 6 7 public static Order GetPreparedOrderBy(OrderDescriber orderDesc){ 8 Order order = new Order(orderDesc.itemCount); 9 return order.ServiceLevel = orderDesc.ServiceLevel; 10 } 11 12 } 13 14 public class OrderDescriber 15 { 16 public OrderDescriber Items{ 17 get{ 18 AmountType = OrderAmountType.Items; 19 return this; 20 } 21 } 22 23 public OrderAmountType AmountType = OrderAmountType.Boxes; 24 25 public OrderDescriber(int itemCount){...} 26 27 public static OrderDescriber With(itemCount){ 28 return new OrderDescriber(itemCount) 29 } 30 } 31 32 public interface IOrderPrepared{...} 33 ...   Der Obige (Pseudo) Code erstellt eine Schnittstelle, die sich per IntelliSense bedienen lässt. Es lohnt sich wohl nur soviel Arbeit zu investieren, wenn der Kontext schwierig ist und sich so Fehler vermeiden lassen. Interessant es auch die Zeit zu investieren, wenn vorrausichtlich viele Entwickler den Code verwenden werden. Alternativ kann man vereinfachen und den Kontext weitestgehend weglassen, also ein Arsenal möglicher Methoden nach außen legen. Ein  Fluent Interface ist aus meiner Perspektive auch "Domain Specific Language" für die gilt: je einfacher die nach Außen gelegte Schnittstelle, desto zeitraubender ist die Implementierung. Wobei die Schnittstelle, das Fluent Interface nur eine Facade für die eigentlichen Domain Objekte sein sollte und nicht die Business Logik komplizierter machen sollte.

Da arbeitet man Tag ein Tag aus mit Visual Studio 2005 und trotzdem lässt sich hier und da noch etwas Neues entdecken. Heute ist mir das "Code Definition Window" über den Weg gelaufen. Steht der Cursor für kurze Zeit über einem Typ, zeigt das Fenster den dazugehörigen Quelltext. Im "Code Definition Window" ist das Schreiben von Code nicht möglich. Steht der Quelltext nicht zur Verfügung, wird die öffentlich Schnittstelle mit Kommentaren angezeigt. Das Bild unten zeigt "Object". Jetzt weiß ich endlich wofür ich den dritten Monitor brauche :-) Ob das beim Arbeiten einen wirklichen Mehrwert hat? Schließlich stehen mit CTRL+SPACE, also der IntelliSense alle nötigen Information über einen Typen zur Verfügung. Und in Resharper genügt CTRL B und man springt zur Klassen, Property oder Funktions Definition.

Guter Einblick in Dependency Injection. Ist zwar für Juice, einem Java Framework aber das Prinzip bleibt das Gleiche. Und ist nicht C# das bessere Java? :-) [Video:] Was ich spannend finde ist, das je klarer die Konzepte werden desto mehr Spass macht es sich damit zu weiter beschäftigen. Die Fragen werden interessanter: Wo sind Gemeinsamkeiten  und Unterschiede zwischen "Service Locator Pattern" u. "Dependency Injection"? Welche Vor und Nachteile habe die jeweiligen Muster? Wo ist der Unterschied zwischen Dependency Injection und Inversion of Control. Und wie kann mir das bei meiner Arbeit helfen. Inversion of Control Container für .NET Castle (Microkernel & Windsor) Spring.NET PicoContainer Object Builder (MS) Structure Map Ninject Unbedingt lesenswert ist der MSDN Artikel von Oren Eini über IoC und Windsor Container.

Sehr lesenswert: Dennis W. Forbes schreibt über seine Erfahrung mit Software Projekten, wie weniger schöne Software unter Druck und Zeitnot entsteht, wie eigentliche Hacks über viele Jahre wesentlicher Teil der Unternehmens-Software Landschaft sind. Und welche Eigenschaften es braucht für einen neuen Entwickler, sich in das bestehende Team einzufügen. Seine Ratschläge Gehe immer zuerst davon aus, dass du falsch liegst Sei vorsichtig mit Kritik. Wie die meisten Menschen, sind auch Entwickler nicht erpicht darauf, zu hören das Ihre Arbeit wesentliche Schwächen hat. Erarbeite Respekt und Glaubwürdigkeit durch harte Arbeit und messbare Ergebnisse Taten sprechen lauter als Worte. Vom neuen wiki, blog, versionskontrollsystem zu sprechen reicht nicht; Neue Techniken wollen erklärt werden und vorgezeigt. Es gilt also Arbeit zu investieren. Nicht jede Software muss den höchsten Ansprüchen genügen Ich wünschte ich hätte diesen Artikel schon früher gelesen. Vieles von obigem habe ich in mehreren Situation falsch gemacht. [Mir noch nicht passiert] Allerdings sollte, wenn der technische Standard das Teams einfach nicht befriedigend ist, wenn möglich, ein Wechsel in Betracht gezogen werden. Man ist vielleicht bei einem anderen Arbeitgeber einfach besser aufgehoben ist. Aus meiner Perspektive, kann ich nur hoffen das Speak-Friend als Arbeitsplatz für Software-Entwickler spannend wird. Die Möglichkeit mit interessanten und großartigen Leuten zusammenzuarbeiten, ist für mich eines der Hauptmotive für die Gründung unserer noch jungen Firma :-)