€320 für Rundum Sorglos MSDN

by admin 5. October 2007 15:11

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 :-)

Zustandsdiagramm zu Code u. UI (Teil 1)

by admin 28. September 2007 08:06

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 :-)

Fluent Interface vs. Method Chaining vs. DSL

by admin 12. September 2007 21:53

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.

Visual Studio - "Code Definition Window"

by admin 8. September 2007 14:21

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.

Dependency Injection & IoC Container

by admin 7. September 2007 02:52

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.

Team - the new guy

by admin 6. September 2007 05:53

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 :-)

.NET Einstellungsfragen, Bullshit Bingo vs. Skills

by admin 6. September 2007 03:17

Miguel de Icaza steuert ein interessantes Post zur "Einstellungstaktiken und Fragen" Debatte bei. Der übliche Prozess ist wohl die Bewerbung durch Vorstellungsgespräche. Miguel de Icaza beschreibt, dass aus seiner Erfahrung Beispiele von bisheriger Arbeit, also Quellcode, zu besseren Ergebnissen führen, als das persönliche Gespräch. Er favorisiert das Email Interview, in dem es eine nicht triviale Aufgabe, innerhalb von zwei Wochen zu lösen gilt. Die Aufgaben sind so gestrickt, das eine Implementierung in ein bis zwei Tagen möglich sein sollte. Der großzügige Zeitrahmen macht es möglich, parallel zu Job oder Studium zu implementieren. Das klingt für mich wie ein großartiger Ansatz. Alles andere scheint das Potential zu haben, sich Leute ins Team zu holen, die zwar Bullshit Bingo beherrschen (von Design Pattern über Agile bis hin zu Best Practice bei der Speicherverwaltung) aber nicht wirklich Implementieren können. Warum auch immer. Nun ließe sich vielleicht bei einem Bewerbungsgespräch ein einfacher Programmiertest durchführen, aber Software-Entwicklung ist nur zu einem geringen Teil etwas, was man in drei Funktionen sehen kann. Viel spannender ist Struktur, Organisation und die Anwendung von Objekt Orientierten Prinzipien. Ich habe zurzeit nur einen kleinen Eindruck vom Job Markt für .NET Entwickler (speziell ASP.NET) wobei ich die vage Vermutung habe, dass mein Lieblingsszenario „sehr viele großartige Entwickler, wenig offene Positionen" nicht wirklich zutreffen dürfte. Einstellungsfragen für .NET Scott Hanselmann ".NET Interview Questions" und hier einige Antworten Einige Interview Fragen von Ayende hier, hier und hier Ein paar (sehr spezifische) ASP.NET Fragen von Mark Wagner Ressourcen für Die Jobsuche (neben google) http://www.dotnetjob.de/ http://entwickler.com/jobs/ http://gulp.de/ http://www.heise.de/jobs http://www.xing.com/ (?) aspnetzone (forum)

Group By + alle Felder

by admin 5. September 2007 03:40

Meist wollen ja immer die selben Probleme gelöst werden. Mein Standard für ein SELECT auf alle Felder einer Tabelle, abhängig von einer Aggregatfunktionen (min, max, avg. etc.) einer zweiten sieht so aus: Ich möchte gerne für alle Requests, das jeweils höchste Gebot (Bid) haben. Das ganze funktioniert, aber ich Suche nach einem einfacheren Weg. Das gleiche nochmal als subselect, wobei wenn ich mich recht erinnere kann z.B mysql keine subselects. Und ich möchte möglichst Datenbankhersteller agnostisch bleiben. Hier nochmal der Execution Plan für beide Abfragen, wobei die Indizies noch nicht optimiert sind. Auf den ersten Blick verwirrend, ist das umschliessende select für die erste Abfrage. Bleibt die Ergebnismenge aber klein, ist das zu vernachlässigen. Und "premature optimization" ist eh der Feind aller Entwickler :-)

Model Driven Architecture (MDA) - contra

by admin 3. September 2007 07:34

Sicherlich ist "Model Driven Architecture" einer der verheißungsvollsten Trends der letzten Jahre. Keinen schmerzhaften CRUD Code schreiben, die Abstraktionsebene auf das eigentliche Problem heben und gelegentlich den „Erstellen“ Button drücken um einen Prototypen zu erzeugen. Das Frontend benötigt dann, zur Projektabgabe nur noch den letzten Feinschliff. So schön die Theorie. Ich muss natürlich gestehen, das alle meine versuche zum Thema bisher rudimentär waren. Ich habe und das ist wirklich schon ein wenig länger her, mit Rational XDE  und „Enterprise Architect“  Klassen generiert. XDE konnte damals (2003) schon „roundtrip engineering“ und hat das Klassen Model in beide Richtungen aktualisiert, also vom Designer Richtung Code und zurück. Gierig habe ich mir auch Microsofts „Domain Specific Language Tools“ angeschaut (die nicht wie der Name vermuten läst DSLs im klassischen Sinne bearbeiten u. erstellen lässt sondern eher in die MDA Tool Kategorie gehört). Alles natürlich keine reinen MDA Tools aber sie decken eine Schnittmenge ab, von dem was ich von einem derartigen Tool erwarten würde. Leider waren alle diese Versuche nur einziges Zeitgrab. Eine Klassendiagram ist nur ein Ausschnitt eines Problems und repräsentiert die Implementierung nur eben ungefähr. Alles andere führt zu einer Informationsexplosion, die das eigentliche Ziel von Uml-Diagrammen, Modellierung und Kommunikation, obsolet werden lässt. Meine zweite Erfahrung war, dass das eigentlich Implementieren in händischer Manier, inkrementell, von Problemfeld zu Problemfeld von Klasse für Klasse zu sauberem Code führte. Das Ergebnis lebt davon, dass Zeit in das Modellieren von Ausschnitten investiert wurde, was zu vielen kleinen, auf die Anforderung angepassten Detail-Lösungen führt. In allen Schichten der Anwendung. Drittens: Für mich die schnellste Form eine Anforderung zu verstehen, ist eine Skizze auf Papier und eine schnelle Implementierung, die auch gern ein Mock-up sein kann. Das führt zu vielen kleinen Iterationen, die Stück zu Stück zu einem runden Ganzen führen. Es gibt die schöne Analogie, die so entstandene, organisch gewachsene Software mit Orten zu vergleichen, die sich um eine Kirche herum scharen, mit vielen kleinen Geschäften. Hingegen MDA generierter Code so ist, wie eine am Reisbrett entworfene Vorstadt, mit eine großen Supermarkt, nebst großem Parkplatz in der Nähe. Ich weiß für meinen Teil wo ich lieber arbeiten und wohnen möchten ;-) Ein oft gehörtes pro MDA Argument ist, das man teuren Architekten das Designen überlassen kann, während billige Standard Coder für das Grobe zuständig sind. Für mich hat dieser Grundansatz schon eine Reihe von Fehlern. Architekten die nicht Coden verlieren an Fähigkeit. Sie programmieren nicht aktiv. Sie können kein Beispiel geben für guten Code. Und viele B-Klasse Coder, das klingt auch nicht wie ein erfolgreiches Dream-Team? Zu all dem muß hinzugefügt werden, das ich ein großer Freund von Code-Generierung bin :-) Was aber erstmal nichts mit MDA gemein hat.

"The Cool Cam" - "European Air War"

by admin 30. August 2007 07:01

Ich habe lange nicht mehr so gelacht; worse than failure (früher "what the fuck") berichtet über eine abstruse Entwicklung, in einem (eigentlich) zum Scheitern verurteilten Software Projekt: "The cool cam". Unglaublich aber anscheinend wahr :-)

About Oliver

shades-of-orange.com code blog logo I build web applications using ASP.NET and have a passion for javascript. Enjoy MVC 4 and Orchard CMS, and I do TDD whenever I can. I like clean code. Love to spend time with my wife and our children. My profile on Stack Exchange, a network of free, community-driven Q&A sites

About Anton

shades-of-orange.com code blog logo I'm a software developer at teamaton. I code in C# and work with MVC, Orchard, SpecFlow, Coypu and NHibernate. I enjoy beach volleyball, board games and Coke.