... solche Phrasen in Stellenangeboten wirken auf mich eigentlich abschreckend. Hier wird wertvoller Platz mit Allgemein-Punkten verschenkt. Hat schon wer den egozentrischen Einzelkämpfer gesucht? (Auch wenn das vielleicht in einigen, wenigen Situation ein interessanter Schritt sein könnte.) Wohltuend anders ist hingegen das hier zu findende Job-Angebot. Wer fit ist in WPF oder Winforms, begeistert von .NET 3.5 und Agilen Entwicklungsmethoden wird sich sicherlich sehr angesprochen fühlen.

In einem online verfügbaren Talk, spricht Anders Hejlsberg kurz über die Geschichte von C# und dann ausführlich über die neuen Features von C# 3.0. Er zeigt die Entwicklung Anhand von Code Beispielen, zum Beispiel die C# Evolution von Generics, Lambda Expressions, Extension Methods zu LINQ. Automatic Properties und Expression Trees werden kurz angerissen und einiges mehr. Interessant ist auch der Blick von Anders auf die Zukunft von C#. Wie immer ist es eine Freude den Architekten von c# über Code sprechen zu hören. Ein hervorragendes Schulungsvideo, sehr sehenswert:-) Silverlight wird benötigt und zeigt seine Streaming Qualitäten. [Lang.NET Symposium Videos]

Microsoft MVC beschreitet einen alternativen Web Anwendungen mit ASP.NET Webseiten zu entwickeln. Der Name ist Programm, Model, View und Controller werden vollwertige Entitäten. Folgendes Video bietet eine kurze musikalische Einführung :-) Das WebForm Model soll nicht abgelöst werden, sondern lediglich durch eine eigenständig supportete Lösung ergänzt werden. WebForm und MVC Controls (die erst noch entwickelt werden müssen) werden nicht kompatibel sein. Konzepte wie ViewState und den damit verbunden Zugriff auf die vom Benutzer manipulierten Daten über Controls kennt das MVC Framework nicht. Der Einsatz von MS-MVC sollte also nicht Paradigma sein, sondern wohl überlegt. In Szenarien die eine große Anzahl von Benutzerzuständen und unterschiedliche Controls beinhalten ist der klassische WebForms Ansatz, der wahrscheinlich deutlich schnellere Entwicklungsweg. Abzuwarten bleibt auch die Qualität der Visual Studio Integration, bei der Arbeit mit Webdesignern, eines der großen Pluspunkte von ASP.NET. Nicht zu vergessen, das die Trennung von Model, View und Controller auch schon heute mit Webforms zu erreichen ist, wenn auch nur auf logischer Ebene. Interessant ist, das Microsoft Implementierung ist auf den ersten Blick MonoRail (http://www.castleproject.org/) erstaunlich ähnlich ist. Eine Politik und gänzlich anders als in der Vergangenheit (Beispiel NUnit vs. VS Testcases) ist, das auch die Koexistenz und sogar Integration mit dem MonoRail und Castle Development Stack angedacht ist. Nicht nur das Microsoft nun auch zum ersten Mal im .NET Umfeld einen Entwickler eines Open Source Frameworks (Subsonic) auf der Gehaltsliste hat, der auch dafür bezahlt wird, an seinem alten Projekt (mit der gleichen Restriktionsfreien "Mozilla Public License" Lizenz) weiterzuarbeiten, Microsoft hat auch in letzter Zeit ein Reihe von Community Persönlichkeiten, wie Scott Hanselman und Philip Hack angeworgen. Es verspricht also weiter Spass zu machen mit .NET und insbesondere ASP.NET arbeiten zu dürfen. (Unabhängig davon, dass WPF der Hammer ist :-) Mehr Links: Scott Gutherie über MVC (Teil 1) Scott Hanselmann (mit Link auf Screencast) ASP.NET MVC Pipeline

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.

Wir machen gerade ein kleines PHP Projekt (<40h). Es handelt sich um eine Synchronisationslösung zwischen einer Desktop Applikation in .NET mit MSDE und eine Front Office PHP Lösung. Dynamische Sprachen sind von der Sache erst einmal was sehr schönes. Für vieles sicher einfacher und schneller (Buildtasks, DSLs, Konfiguration). Nicht nur aus technischer Spielerei gibt es Dinge wie die DLR, Boo oder IronPython. Doch für echte Anwendungslogik fühlt sich das arbeiten mit PHP deutlich langsamer an.   Am schmerzlichsten vermisse und ich Resharper. Mir war gar nicht bewusst, wie oft ich kleinere Refaktorisierungen durchführe. Meist "Methode Extrahieren" und Umbenennen. Aber auch die Navigation im Code ist mit a href="http://www.zend.com/products/zend_studio">Zend Studio schmerzhaft. Permanent suche ich im Projekt nach irgendwelchen Strings. In Resharper dauert es 5sec alle Zuweisungen einer Variablen zu finden und dabei die Verwendungen auszublenden. Mit Zend ist es immer wieder ein Browsen, durch viele, viele Suchtreffer. Ich vermisse auch NHibernate, meinen TestRunner und all die Bibliotheken, die mir sonst den Alltag versüßen. (Wobei wer Tag ein Tag aus mit PHP arbeitet, hat sicher verlgeichbares) Schon nach 20h, .NET I miss you :-)

Schade, dass wir noch kein .NET 3.0 einsetzen. (Aber aus Zeitgründen, sind die Zeiten wo jede Beta sofort installiert werden musste leider Passe. Aber noch drei Wochen, dann können wir migrieren :-) Brad Vincent baut gerade eine Utility Klassen Sammlung auf, die viele schönes hat, aber Extension Methods erfordert. Links: UberUtils auf CodePlex Blog Post von Brad Vincent

Kopiert aus dem Net 3.5 Poster . [via Stefan Falz]

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.

Big News today: Scott Guthrie kündigt an, dass die Sourcen des .NET 3.5 Frameworks mit samt Code und Kommentaren veröffentlicht werden. WCF, Workflow und LINQ Code wird zwar erst später nachgeschoben, soll aber kommen. Dass ist unerwartet, aber nach einer langen Serie von wirklich wundervollen Dingen die das .NET Team produziert, mehr als Zuckerguss:-) Auch wenn schon durch Reflector bisher wenig geheim war, ist Debuggen ein neues Level von Transparenz. Ich bin schon gespannt und neugierig auf die Entwickler-Kommentare!  Das .NET Team rockt und Scott Guthrie rückt auf in den Olymp meiner persönlichen Helden :-)

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.