Es geschah an einen Dienstag. Die neue Buzzword-Ready Web 2.0 App war am Freitag zuvor nach 4 Monaten harter Arbeit online gegangen. Zur Feier des Tages wurde abends beim Italiener eine Flasche Wein geordert. Es war der erste freie Abend nach vielen Wochen. Der Wein wirkte sofort, für untrainierte ist ein Rausch preiswerter und preiswert ist gut, wenn man sich darauf einstellt ein junges Produkt langsam am Mark zu etablieren und jeder ausgegebene Euro der Firma gehört, nicht einer Bank oder einem Venture Capitalisten. Die ersten 4 Tage waren ruhig verlaufen. Wie erwartet registrierten sich nur wenige Benutzer, denn trotz automatisierter Test und einer ausführlichen Analyse wie sich das Baby unter Last verhalten würde, sollte sich die Anwendung im Live-Betrieb erstmal bewähren. Es war tägliche Routine, etwas gelangweilt arbeitete einer der Entwickler die letzten Tage von Mashable und Techcrunch auf. Keine großen Highlights, das übliche. Die meisten der 275 ungelesenen Posts landeten nach einem kurzen Blick auf den Betreff und Autor im Papierkorb. Genau wie „Special Interest Trading Platform Launches“ … moment … „Special Interest Trading Platform“  ... (??!) ... STRG-Z beförderte den gerade gesehenen Eintrag aus dem Papierkorb wieder zurück in die aktuelle Ansicht. Es war 23:45Uhr. Von den 900 000 Techchruch Lesern hatten 14 325 die junge Seite innerhalb der ersten 30 Minuten aufgerufen und 1500 neue „Special Interest Trading Platforms“ aufgesetzt. Ca. 15-20 davon waren wohl mehr als ein Test. Der Web-Server schnaufte, hielt sich aber mit 25% Prozessorleistung noch ganz gut, der Datenbankserver lief mit 80-90% Auslastung und war am Limit. Um 1:17 hatte Mashable und wohl 3 Dutzend anderer Blogger das Techcrunch Post aufgegriffen und Ihrerseits über die neue Handelsplatform berichtet. Ab 1:26 lies sich der Web-Server nicht mehr via http erreichen. Mit sehr viel Geduld gelang es dann letztlich um 3:40 die Anwendung durch eine freundlich Dankesseite ersetzen. Die nächsten Wochen versprachen wunderbar zu werden. ...................................................................... Okay genug feuchte Träume. Flexiscale bietet skalierbares Hosting. Das Versprechen ist, das man innerhalb von wenigen Minuten von einem Rechner auf einige tausend Rechner aufrüsten kann. Doch statt wie Amazon EC2/S3 nur Linux zu unterstützen, bietet Flexiscale Windows 2003 Server und Windows SBS an. Windows SBS ist insbesondere interessant, da es eine MS-SQL Server Lizenz bundelt. (Wobei man die sich genaue Lizenz des SBS noch mal genauer anschauen müsste um zu entscheiden ob sich Windows-SBS auch legal für Hosting einsetzen lässt.) Die Preise sind absolut konkurrenzfähig. Wir werden uns das definitiv genauer anschauen. Ich kann kaum erwarten den Zugang zu erhalten :-) [via Techchrunch]

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

Nach dem die "Browser Kriege" wohl entgültig vorüber sind und selbst Microsoft   für Safari, Opera und Firefox entwickelt (ASP.NET AJAX, Silverlight) scheint das nächste Schlachtfeld wohl die Browser-Plugin Welt zu sein. Silverlight und Apollo haben das Zeug den Desktop zu ersetzen und den Browser als Platform noch weiter zu etablieren. Was sich heute mit Browser basierten  Anwendungen andeutet scheint nur der Beginn einer Verdrängung der klassischen Betriebsysteme als Platform für Software zu sein. Heute schon haben die meisten eine Vielzahl von Betriebsystemen im Gebrauch (für Handy, PC, Navi, Spielkonsole etc.)  und es werden sicherlich mehr. Microsoft Automotive wird vermutlich nicht das Betriebssystem der Merheit der Autos werden. Die Java Runtime, auch wenn sie erfolgreich ist, hat sich nicht durchgesetzt. Der kleinste gemeinsame Nenner aller Platformen wird der Browser. Wer es schaft ein Standart Plugin für "Rich User Applications" zu etablieren gewinnt den OS Markt für ThinClients. Seit den 80-ziger schon öfter mal gehört und propagiert - aber die Zukunft wird dann doch irgendwann mal ThinClient :-)

Michael Mahemoff zählt 210 Ajax Frameworks. 79 davon sind pur client-seitig, 131 sind server-seitig. Er zählt erstaunliche 19 Ajax Frameworks für ASP.NET.

Bisher glaubte ich, dass die einzige wirkliche Sprache des .NET frameworks c# sei. VB.NET war für mich bestenfalls eine Pflichtleistung Microsofts für die Unverbesserlichen. Das Konzept der CLR, eine Ausführumgebung für jede beliebige Sprache zu sein, empfand ich als ausserodentlich gutes Marketing. Natürlich ist die CLR technisch schön. Die Idee ist elegant. Aber für die Praxis? Ich meine, wer benötigt denn IronPython oder die PHP-CLR Phalanger, die populäreren Vertreter der vielen (hundert?) CLR Sprachen. In den letzten vier Jahren mit c# habe ich nur wenig die dynamische Typisierung PHPs vermisst. Die immer wiederkehrende Diskussion, statische Typisierung vs. dynamische Typisierung, wurde auch in der x-ten Version nicht spannender. Ruby, Python oder PHP konnten mich nicht neidisch machen. Ich hatte ja mein mein geliebtes c#. Dazu war Resharper in meinen Werkzeugkasten, ein Produkt das für dynamische Sprache so nicht denkbar wäre? Auch die wirklich grossartigen und einflussreichen Entwickler, meine Stars, waren auf meiner Seite. Ich gebe zu, abundzu hätte ich gerne ein wenig duck typing dürfen. Gelegentlich hätte ich auch gerne beherzt down gecasted - ohne zickigen compiler. Aber das waren bestenfals kleine Schäfchenwolken an meinem Programmiererhimmel. Vielleicht hatte für einen kurzen Moment Ruby on Rails mein Herz erweicht, doch da erschien auch schon MonoRails auf der Bildfläche und die Begehrlichkeiten waren gestillt. Interessant. Auf der MIX 07 wurde die DLR vorgestellt. Eine Erweiterung der CLR die das entwickeln dynamischer Sprachen vereinfacht. Die DLR steht unter der Microsoft Permissive License und ist somit Open Source. Microsoft scheint technologisch nicht nur mitzuschwimmen sondern mit LINQ, Generics der entspannteren Lizenspolitik, IIS 7.0 und vielem, vielem mehr auf der Entwickler Seite alles richtig zu machen.

Schon heute mag ich mir entwickeln ohne Resharper von Jetbains gar nich mehr vorstellen. Soviele wunderbare Features, Hier die Suche! Man beachte das Tabs unterstützt werden. Das Fenster selbst wird durch ALT F7 kontext sensitiv aufgerufen und mit ALT Pfeil Hoch/Runter läst sich navigieren, ohne das es nötig ist ein einziges Mal die Hände von der Tastatur nehmen zu müssen. Die nächste Version die jetzt schon als EAP (Early Access Programm) verfügbar ist verspricht ein weiters Feature das ich wohl ständig verwenden werden: Ein sinnvolle To-Do verwaltung. Eigentlich etwas das man schon von Visual Studio hätte erwarten können. Hier mehr darüber und einige Screenshoots: "To Dos verwalten"

Ein Image Button in ASP.NET feuert keinen onClick event - wenn das in "ImageUrl" spezifizierte Bild nicht exisitiert. Wicked. Wobei die Rahmenkonditionen wahrscheinlich nicht Standard sind. Es handelt sich um eine ASP.NET 2.0 Web Application und keine Web Site. Web Applications waren zunächst eine Standalone Erweiterung von Visual Studio und sind nun Teil des  Visual Studio Service Packs (SP 1). (robert)

Subtext ist die Open Source Blog Engine unserer Wahl. Subtext basiert(e) auf den Sourcen von .Text, deren Entwickler sich dem kommerziellen „Community Server“ widmeten – welcher heute so illustre Seiten wie ASP.NET, MSNBC Blogs oder den Windows Vista Blog betreibt. Die ganze Geschichte ist hier zu finden: "Announcing Subtext, A Fork Of .TEXT For Your Blogging Pleasure" Aber zum Eigentlichen – das aktivieren von TrackBacks für Subtext: Der Grund dafür das Subtext bei unserer Erstinstallation nicht bereit war einen TrackBack Ping zu verschicken ist das, als Medium Trust, eingestellte Trust Level. Einer Webseite, die unter Medium Trust läuft ist es nicht erlaubt „WebRequests“ auf Seiten ausserhalb der eigenen Domain oder localhost durchzuführen. Die Lösung ist trivial: In der web.config muß lediglich: <trust level="Medium" originUrl=".*" /> zu: <trust level="High" originUrl=".*" /> geändert werden. Und schon funktioniert es mit den TrackBacks. Mehr über Trust Levels in ASP.NET ist hier zu finden: „ASP.NET 2.0 Hosting Deployment Guide“  (robert)

Das beliebte, begehrte und freie ASP.NET Content Management System plant seine Zukunft, wenn auch in kleinen Schritten: Ein guter Beginn ist solide Plannung, im Cuyahoga-Wiki sammeln sich daher erste Ideen: Wiki Ideen Pool.  (robert)