- Posted by admin on August 31, 2007
Aus Erfahrung schlau, ist es eine gute Idee vor Projektbeginn den „style guide“ des letzten Projektes aus der Schublade zu kramen. So lassen sich verspätet Diskusionen vermeiden ob nicht „ungarische Notation“ nicht doch besser sei als „CamelCase“. Persönlichkeit ist beim Kodieren ist eh schon einer der entscheidenden Faktoren für das erfolgreiche Ausliefern von Projekten, doch sollte der Besuch einer nicht selbst geschrieben Klasse nicht dazu führen, dass man sich in einer anderen Programmiersprache wähnt. Es gibt genug geistige Arbeit zu tun, um sich damit aufzuhalten zu können ob ein Customer Control nun vielleicht mit „cc“, „die eresten Zwei Buchstaben der Firma“ oder einfach nur gar nicht bepräfixt wurde, oder werden soll. Entscheidend ist es intuitiv und mit IntelliSense bewaffnet, schnell zu finden was man möchte ohne sich darüber Gedanken machen zu müssen, in welcher Form irgendeine Variable benannt werden muss.
Da ich relativ viel Zeit im „CodeBehind“ von ASP.NET .aspx Seiten verbringe (natürlich _nur_ Frontend-Logik ;) und das Page Objekt ein Arsenal von Privaten und Public Membern hat, habe ich mir angewöhnt selbst geschriebene private Membervariablen mit einem Unterstrich zu versehen:
![CropperCapture[5]](http://speak-friend.com/images/speak-friend_com/andrej/WindowsLiveWriter/Privatemitoderohne_underscore_4721/CropperCapture%5B5%5D_thumb.jpg)
Für mich hat das den Vorteil, dass ich an jedem Ort und ohne mein Gedächtnis zu bemühen, die „Privates“ der aktuellen Klasse präsentiert bekomme. Auf diesem Weg finde ich fast immer und schnell was ich gesucht habe. Unterstriche sind sicherlich nicht die ästhetischste Form von Präfixen, aber die aus meiner Sicht erhöhte Produktivität ist den Kompromiss Wert.
(Hier noch eine Screenshoot für das txtPraefix um den Intellisense Faktor besser zu verdeutlichen)
- Posted by admin on August 30, 2007
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 :-)
- Posted by admin on August 29, 2007
Manchmal macht da macht ASP.NET AJAX wirklich glücklich. Da ist mit wenig Zeit und deklarativem Code ein Update Panel platziert, ein Calendar Control poppt auf und während des partiellen Updates dreht sich fröhlich ein Fortschritts Symbol.
Dann gibt es wieder Momente da wünsche ich mich weit weg von dieser monströsen Abstraktion. Da träume ich vom Arbeiten auf dem vorhandenen DOM. Da wünsche ich mir dass ich mich für die Prototype script.aculo.us Kombi oder die YUI entschieden hätte. Wo die Abstraktion, der Abstraktion eines von der Sache her trivialen Models mir nicht im Wege steht. Klar mir fehlt gerade nichts weiter als Wissen. Doch wenn der Erwerb zu lange dauert, dann kann ich auch mit der Besten Technologie auf meiner Seite nicht Zeitnah die Aufgaben erreichen die mir gestellt sind.
Ähnlich ging es mir auch mit dem ASP.NET Page Lifecycle. Vorher hatte ich 2 Jahre PHP auf dem Buckel, dann 1 Jahr (Notgedrungen) ASP (mit VB Script) und war mir eigentlich recht sicher, das ich weiß wie man so einen Webanwendung schnell bauen kann. Dann kam der ASP.NET 1.0 Schock mit CodeBehind und ViewState, verheißungsvoll, schön und an vielen Ecken einfach nur komplex. Selbst in der .NET Communnity ist ASP.NET nicht für alle der Heilsgral. Eine Gegenkonzept ist u.a MonoRail. Ich für meinen Teil genieße vieles was mir ASP.NET heute bietet, angefangen von der Möglichkeit Web-Designern mit dynamischen Inhalten zu lassen bis hin zu MasterPages.
Noch ist ASP.NET AJAX jung und ich habe sicherlich noch zu wenig Erfahrung. Vielleicht ermöglicht das etwas überzogene Abstraktionsmodel auch eine schnellere Entwicklung der Bibliothek? Ich bin neugierig, wobei ich gerade nur den Kopf schütteln kann, warum mir einfaches document.getElementById(<%control.ClientId%>) ein Element zurück gibt in dem der setter für das Style Attribut geschützt ist. (Eigentlich cool das man JavaScript so aufbohren kann :-)
(der Anlass, sollte eigentlich nur ein paar Minuten dauern.. u. jetzt browse ich in den asp.net ajax sourcen ;)
- Posted by admin on August 27, 2007
Was ist schöner? Das klassische Iterieren durch die Collection oder die Predicate, Closure Kombination. Performance spielt erst mal keine Rolle, wobei ich wetten würde, dass der IL Code für Beide Varianten sehr ähnlich ist und es keinen Messbaren Performance Unterschiede ausser beim Build Prozess gibt.
Eindeutig ist der Fall natürlich, wenn die Find Methode nicht innerhalb einer Klasse gekapselt wäre. Aber dann läge die Arbeit beim Verwender der Klasse und das wäre gleich auf mehrere Arten gegen den guten Geschmack (Single Point of Change, Encapsulation, Information hiding).
- Posted by admin on August 17, 2007
Ich arbeite gerade an Testmethoden und habe mich über folgenden Code gefreut, weil er ein relativ komplexes Thema ziemlich lesbar gestaltet. Der Test ist natürlich grün :-)
(Clicken für Originalgrösse)
Das Setup für die Tests ist mir immer noch einen Tick zu lang und ich werde wohl noch refaktorisieren. Auch werde ich gleich noch ein paar mehr Asserts hinzufügen.
Erzeugt werden 8 Angebote mit jeweils 4 und 3 Eigenschaften. Sticker haben hier keinen Preis, sind also kein echtes Angebot aber für den Test reicht das komplett. Die Angebote lassen sich mit einem Einzeiler persistieren.
Die Flyer und Sticker Klassen Definition und Helper Klassen werden via XML Configurationsfiles generiert, was auch den Sprach-Mix erklärt. Ursprünglich war das nur gedacht um schnell und einfach Tests schreiben zu können, nun ergeben sich aber noch ein paar andere Vorteile. Das Endprodukt läst sich so relativ flexibel befüllen. Für ein paar 10 000 Produkte braucht es nur wenige Zeilen...
Komisch, in den letzten 4 1/2 Wochen habe ich 7100 Zeilen Code (oben sieht man 30 Zeilen ;) fürs das Backend unserers Produktes geschrieben. Nach dem ich die letzten Tage ein wenig panisch geworden bin, vor allen Dingen wegen vager Anforderungen und Unwissenheit über Zielgruppen und Märkte, scheint sich doch noch alles zusammen zu fügen. Trotzdem steht jetzt erstmal Crunch-Time an.
Lets Rock'n Roll :-)
- Posted by admin on August 16, 2007
Während langweiliger Tätigkeiten höre ich gerne Hörbücher, gerade "21 Laws of Marketing". Ein eingängiges zweites Gesetz ist: "Wenn Du nicht erster sein kannst in einer Kategorie, dann erfinde eine neue". Beispiel: "Niemand interessierte sich mehr für Personal Home Computers, da erfand Amiga die Kategorie des Multimedia Home Computers und setzt nun jedes Jahr 500 000 Millionen Dollar um".
Erinnert sich noch jemand an Comodore Amiga? Ich glaube ich brauche wohl aktuellere Hörbücher :-)
- Posted by admin on August 14, 2007
Die Kontrahenten
Subtext ist der altehrwürdige Senior, in der Kategorie der Open Source .NET Blog Engines. Das Projekt ist 2005 aus den Sourcen von .TEXT hervorgegangen, dessen Entwickler den kommerziellen „CommunityServer“ ins Leben riefen.
BlogEngine.NET ist der Jungstar der offiziell am 21. Mai 2007 released wurde. Ziele sind einfache Anpassbarkeit und geringe Komplexität.
CodeBasis und Installation
Beide Open Source Produkte setzen auf ASP.NET 2.0 auf. Subtext wartet mit 90 516 (aktueller Trunk) Zeilen Quellcode (Screenhoot unten). BlogEngine.NET kommt mit schlanken 33 562 Zeilen daher. Beide bieten Provider für verschiedene Datenbanken. BlogEngine verwendet als Schmankerl in der Grundeinstellung XML Dateien für die Aufbewahrung von Daten, was zu einem Zero Deployment Gefühl führt. Dateien kopieren, Seite aufrufen und schon steht ein neuer Blog dienbar bereit. Subtext besitzt eine schmerzfreien, webbasierten Installationsprozess.

(Oben LineCounter Output für Subtext, unten für BlogEngine.NET )
SprachUnterstützung
BlogEngine.NET ist internationalisiert und besitzt eine gute deutsche Übersetzung. Die Internationalisierung von Subtext steht, wenn der Zeitplan eingehalten wird, erst für Ende des Jahres an. Für diesen Blog dauerte das hinzufügen der deutschen Übersetzung ca. 2h. Als Folge der Übersetzung entstanden Problem beim updaten, da sowohl Source- als auch Resourcedateien verändert und wurden.
Templates
Das Template System von Subtext ist eine Krankheit. Die Anpassungen verteilen sich über 33 einzelne Controls, was schwierig zu erfassen und anzupassen ist. Im Gegensatz dazu besitzt das Template für die BlogEngine.NET lediglich 3 Dateien, ein MasterPage und 2 Controls. Das ist leicht zu verstehen und kinderleicht anzupassen. Statt mit ASP.NET Controls um sich zu werfen werden Variablen verwendet.

(Links BlogEngine.NET, rechts Subtext)
Community
Die Subtext Community schart sich um Phil Haack und hat sein Zuhause auf Sourceforge. Als zentrales Kommunikationsmittel dient eine Mailinglist, auf der monatlich zwischen 66 (Juli) und 512(April) Nachrichten auflaufen. Im letzten Jahr waren 11 Entwickler aktiv.
BlogEngine.NET ist auf CodePlex beheimatet und hat 5 aktive Entwickler, von denen die treibende Kraft Mads Kristensen ist, der durch seinen Blog große Popularität geniest.
Fazit:
BlogEngine.NET ist für mich ganz klar das bessere Produkt, vor allen Dingen da eine Anpassung viel schneller möglich ist und die Code Basis deutlich aufgeräumter erscheint, ohne das mir Features fehlen würden.
Subtext bleibt ein beobachtenswerter Konkurrent auf dessen RoadMap Multi Blog Support und bessere Erweiterbarkeit stehen.
- Posted by admin on August 1, 2007
Die "Standish Group" untersuchte über 40 000 Software-Projekte innerhalb von 10 Jahren.
Hier der (gekürzte ;-) "Standish Chaos Report":
Software projects:
1995:
- 16% succeed
- 31% fail
- 53% are challenged
2004
- 29% succeed
- 18% fail
- 53% are challenged
via "Scott Rosenberg @ google talks" - wenig technisch und immer nett zu hören wenn proklamiert wird, das Software Entwicklung ein hartes Geschäft ist. (Leider) nichts für Mädchen :-)
Für den liquiden Interessierten sind die "Standish Group" Reports hier zu kaufen.