In Mainz hat heute mit der AJAX in Action eine Konferenz speziell zu AJAX und Rich Internet Applications begonnen. Auch ich hatte dort bereits eine Session, direkt nach der Keynote, als Einführung in Silverlight.

Da ich allerdings nur eine Stunde Zeit hatte, habe ich mich weniger auf die Entwicklung mit Silverlight konzentriert, sondern eher auf die entsprechende Infrastruktur - vom Deployment des Plugins zu den Voraussetzungen auf dem Entwicklerrechner bis hin zum Deployment des eigenen Projektes. Diesen Ansatz hatte ich bereits in meinem Workshop XAML revisited auf der Basta! 2008 verfolgt, was damals großen Anklang gefunden hat, da man genau diese Informationen üblicherweise nicht überall findet.

Als Themen hatte ich dieses Mal ausgewählt:

• tafiti als Silverlight-Anwendung
• Desktop vs Web
• Deployment des Plugins
• Silverlight 1.0 vs 2.0
• Silverlight vs WPF
• Visual Studio vs Expression Blend
• Entwurfsmuster MVVM
• Deployment von Silverlight-Anwendungen
• .xap-Dateien im Detail
• Aufbau eines Silverlight-Projektes
• Silverlight vs Flash & Co

Versprochen hatte ich zudem, an dieser Stelle noch die Links zu den diversen angesprochenen Anwendungen nachzureichen. Prinzipiell reicht hierfür ein Link auf die Webseite von Silverlight 2 aus, da dort alle relevanten Links in kompakter Form aufgelistet werden. Generell eignet sich diese Webseite auch ansonsten sehr gut, um sich über die Entwicklung mit Silverlight zu informieren.

Zu guter letzt möchte ich mich noch bei den Besuchern meiner Session für die Aufmerksamkeit und die anschließenden Fragen bedanken, und hoffe, dem ein oder anderen Silverlight ein wenig näher gebracht zu haben.

Nachdem ich gestern über die Zukunft von Windows und .NET spekuliert habe, hat der heutige Beginn der PDC 2008 die ersten Fragen beantwortet: Die Zukunft liegt auch für Microsoft im Cloud Computing und heißt Windows Azure. Doch was verbirgt sich hinter Windows Azure?

Windows Azure ist eine neue Edition von Windows, die nicht für Entwickler, ISVs oder Endkunden gedacht ist, sondern die ausschließlich in Microsofts Rechenzentren läuft. Windows Azure bietet Entwicklern und ISVs eine Infrastruktur, um Anwendungen und Dienste in der Cloud, wie Microsoft es nennt, zu hosten.

In der Cloud können so wohl Rechenzeit wie auch Speicherplatz gebucht werden, wobei in der finalen Version eine Abrechnung nach Nutzung stattfinden wird. Da die Cloud in Microsofts Rechenzentren läuft, steht hiervon quasi unbegrenzt viel zur Verfügung, was die bisher gängigen Hardwareprobleme der Skalierbarkeit einer eigenen Lösung auf einen Schlag behebt.

Ergänzt wird Windows Cloud durch die Integration diverser Dienste: So wird beispielsweise mit den SQL Server Data Services eine in der Cloud laufende Datenbank angeboten. Außerdem gibt es noch die sogenannten Windows Live Services und die .NET Services, die beispielsweise Dienste zum Identitätsmanagement, soziale Dienste und Konnektivitätsdienste anbietet.

Windows Azure basiert bei all dem auf bekannten und damit auch etablierten Technologien wie .NET, SOAP, REST, XML und RSS, wobei als Entwicklungsumgebung wiederum Visual Studio verwendet wird, so dass sich Entwickler, die bislang auf Basis von .NET gearbeitet haben, nicht all zu sehr umgewöhnen müssen.

Auch wenn derzeit Visual Studio und .NET die einzige Möglichkeit darstellen, auf Windows Azure und die Cloud zuzugreifen, wird sich dies bis zur finalen Version ändern: Die Plattform wird vollkommen offen sein, so dass beliebige Sprachen und Werkzeuge von Drittanbietern integriert werden können. Zunächst soll vor allem Unterstützung für Python und Eclipse hinzukommen.

Interessant fand ich die Aussage, dass Windows Azure bereits seit etlichen Jahren entwickelt wird, was meine gestrigen Spekulationen gar nicht so abwegig erscheinen lässt. Insgesamt denke ich, dass Microsoft mit Windows Azure ein riesengroßer Schritt in die absolut richtige Richtung gelungen ist, der zudem längst überfällig war.

Insbesondere die von Microsoft stets perfekte Integration aller Produkte und Dienste könnte Windows Azure im Vergleich zu den Mitbewerbern wie Amazon oder Google den entscheidenden Vorsprung verschaffen - doch dies muss die Zukunft zeigen ...

Details zu Windows Azure wie auch ein erster CTP finden sich auf der entsprechenden Webseite, die seit heute verfügbar ist.

Morgen beginnt mit der Professional Developers Conference 2008 die größte hauseigene Konferenz von Microsoft, auf der vor allem die Zukunft von Windows, .NET und den damit verbundenen Diensten vorgestellt wird. Außer einigen vagen Informationen zu Windows 7 und .NET 4.0 ist im Vorfeld noch nichts wirklich relevantes bekannt geworden.

Zum Auftakt hat Microsoft vorgestern ein neues Logo für .NET vorgestellt, das die Aspekte Konsistenz, Stabilität und Benutzerfreundlichkeit von .NET unterstreichen soll, und zudem die Nähe zu den neuen Kerntechnologien Silverlight und Surface ausdrücken soll:

Prinzipiell ist an der Tatsache, dass Microsoft ein neues Logo für .NET vorstellt, nichts all zu ungewöhnliches zu finden – auch wenn die Anzahl der entsprechenden Blogeinträge in den vergangenen zwei Tagen anderes impliziert. Aus diesem Grund werde ich im Weiteren nicht näher auf die Tatsache eingehen, dass es ein neues Logo gibt, sondern mich mit der Frage beschäftigen, was dieses neue Logo symbolisieren könnte.

Denn, um ehrlich zu sein, all zu viel Nähe zu den Begriffen Konsistenz, Stabilität und Benutzerfreundlichkeit kann zumindest ich in dem neuen Logo nicht entdecken. Auch die Erklärung, dass es einer Welle ähneln soll, halte ich für nicht ausreichend – denn welchen Bezug hat .NET zu einer Welle?

Auffällig finde ich, dass das Logo einer DNS-Doppelhelix ähnelt, wenn man es um 90° zur Seite neigt – auch wenn dies außer mir anscheinend noch niemandem aufgefallen ist. Angenommen, diese Ähnlichkeit wäre beabsichtigt, welche Aussage über .NET könnte dann in diesem Logo stecken?

Verschafft man sich einen Überblick über die diversen Technologien von Microsoft der vergangenen Jahre, so fällt auf, dass es schon einmal eine Technologie mit Bezug zur DNS gab: Windows DNA, laut Wikipedia ein Überbegriff für alle Technologien, durch welche die Interaktion von Windows mit dem Internet ermöglicht wird.

Interessant ist dabei nicht nur, dass laut Wikipedia ebendiese Technologie von .NET abgelöst wurde, was auch den Ursprung des Namens von .NET erklärt, sondern insbesondere auch, dass die von Microsoft nun verfolgte Strategie viel tiefere Wurzeln haben könnte, als zunächst denkbar wäre.

Als .NET vor sechs Jahren in der ersten Version veröffentlicht wurde, wurde für einige Zeit vermutet, dass .NET zum einen der Nachfolger der klassischen Win32-API sei, und dass Microsoft zum anderen sämtliche Anwendungen nach und nach auf .NET migrieren würde. Weder das eine noch das andere ist bislang eingetreten, und daran wird auch Windows 7 nichts ändern.

Neben Windows 7 wird jedoch auf der PDC noch ein zweites Windows eine ausgesprochen wichtige Rolle spielen: Windows Cloud, das von Steve Ballmer als Betriebssystem für das Internet angekündigt wurde. Auch wenn derzeit noch niemand weiß, was genau sich hinter Windows Cloud verbirgt, so steht fest, dass es die Basis für die serverseitige Zukunft von Microsoft im Web werden wird.

Windows Cloud wiederum wird auf einer Weiterentwicklung von .NET basieren, zudem steht mit Silverlight nun eine auf .NET basierende Technologie für das Frontend im Web zur Verfügung. Windows Cloud und Silverlight stellen damit die Basis für Microsofts Erfolg im Internet dar, oder – pathetisch gesprochen – sie bilden die Grundbausteine des digitalen Lebens, eben die DNS, womit sich der Kreis zu guter letzt schließt.

Insgesamt würde das bedeuten, dass Microsoft im Hintergrund bereits viel länger an einer entsprechenden technologischen Basis für die Zukunft im Internet arbeitet, als die Live-Dienste erahnen ließen. Wenn dem so ist, dürfte das Ergebnis dementsprechend schlagkräftig ausfallen …

Wohlgemerkt, all dies ist reine Spekulation meinerseits, aber dennoch halte ich diese Überlegungen für durchaus interessant und nicht von der Hand zu weisen. Warten wir die nächsten Tage der PDC ab, vermutlich wird sich dann zeigen, welches Ziel sich Microsoft für die Zukunft gesteckt hat.

Nachdem ich vor zehn Tagen das Buch C# in Depth zu Ende gelesen und einen entsprechenden Review geschrieben habe, war mein Interesse an einer grundlegenden Einführung und weiterführenden Details zu LINQ geweckt. Ich habe mir also direkt im Anschluss das Buch LINQ in Action von Fabrice Marguerie, Steve Eichert und Jim Wooley vorgenommen, dessen Lektüre ich nun gestern Abend abgeschlossen habe.

Prinzipiell gliedert sich das Buch in fünf Teile. Zunächst werden darin in kompakter Form die Grundlagen von LINQ erläutert, bevor im Anschluss die drei wichtigsten Ausprägungen von LINQ, die bereits in .NET 3.5 enthalten sind, ausführlich besprochen werden:

• LINQ to Objects: An Hand der Abfrage von im Speicher befindlichen Collections werden zunächst die Arbeitsweise von LINQ und die Standard Query Operators erläutert. Auch Spezialitäten wie die verzögerte Ausführung und Überlegungen zur Performance von LINQ werden vorgestellt.
• LINQ to SQL: Dieser Teil beschreibt, wie LINQ genutzt werden kann, um den SQL Server als relationale Datenbank anzusprechen. Neben der typischen CRUD-Methoden werden auch fortgeschrittene Themen wie Transaktionen, verschiedene Sperrverfahren und der Einsatz von gespeicherten Prozeduren beschrieben.
• LINQ to XML: Schließlich wird auch noch LINQ to XML behandelt, wobei in diesem Teil besonderes Augenmerk nicht nur auf das Abfragen, sondern vor allem auch auf das Erzeugen von XML gelegt wird. Es werden die verschiedenen Achsenmethoden vorgestellt und an Hand von typischen Anwendungsszenarien gezeigt, wie LINQ to XML eingesetzt werden kann.

Als Abschluss werden im letzten Teil fortgeschrittene Themen wie das Schreiben eines eigenen LINQ-Providers und die Verwendung von LINQ in den diversen Schichten einer Anwendung besprochen.

Insgesamt steht mit LINQ in Action eine sehr ausführliche Einführung zur Verfügung, die jedem uneingeschränkt empfohlen werden kann, der in .NET entwickelt. Ein wesentlicher Aspekt, der nach der Lektüre dieses Buches deutlich wird, ist, dass sich LINQ nicht auf Datenbanken und XML beschränken muss, sondern dass zahlreiche Aspekte der tagtäglichen Anwendungsentwicklung durch den Einsatz von LINQ deutlich vereinfacht werden können.

Vor rund zweieinhalb Wochen haben Peter Bucher und ich einander offline kennen gelernt, nachdem wir zuvor über Monate ausschließlich per MSN und E-Mail Kontakt hatten. Als erstes Ergebnis dieses Treffens haben wir beschlossen, in unseren Blogs zukünftig jeweils zum ersten eines jeden Monats eine Art Kommentar zu einem im Vorfeld abgesteckten Thema vorzustellen.

Das Thema entscheiden wir dabei gemeinsam vorab, wobei wir nicht mehr als einige Schlagworte festhalten. Für jeden von uns lautet dann die Aufgabe, bis zum ersten Tag des kommenden Monats einen Kommentar zu schreiben, in dem wir unsere Meinung zu dem jeweiligen Thema erläutern. Wir wissen dabei gegenseitig nicht, was der andere schreiben wird - es werden also nicht nur unsere Leser überrascht.

Am 1. Dezember 2008 wird es beginnen ...

Neben diversen großen Webseiten wie beispielsweise der MSDN oder Live, die man als Entwickler tagtäglich nutzt, gibt es auch einige äußerst lesenswerte private Webseiten oder Blogs. Eine solche Webseite, die ich seit Jahren sehr schätze, enthält eine Sammlung von Artikeln über .NET aus der Feder von Jon Skeet, einem Software Engineer bei Google.

Das Besondere an diesen Artikeln ist, dass Jon Skeet sich jeweils nur einen Aspekt der Sprache C# herauspickt, diesen dann aber in allen Details beleuchtet, und auch vor tiefgreifenden technischen Erklärungen nicht zurückschreckt. Insbesondere sein Artikel über das beforefieldinit-Flag des C#-Compilers hat es mir aus diesem Grund angetan.

Seit April 2008 ist nun auch sein erstes Buch mit dem Titel C# in Depth erhältlich, das sich - vereinfacht gesagt - mit C# 2 und 3 beschäftigt. Allerdings schlägt Jon Skeet darin den gleichen Weg ein, den er bereits mit seinen Artikeln gegangen ist: Er erläutert in diesem Buch nicht, wie zahlreiche andere Bücher es machen, wie LINQ eingesetzt wird. Statt dessen konzentriert er sich auf die relevanten Neuerungen der Sprache und erläutert detailliert, wie sich die Entwicklung dadurch in den einzelnen Versionen von C# verändert.

Allein auf Grund der Idee, zu überlegen, wie Sprachfeatures von C# 3 in einer früheren Version von C# umgesetzt werden mussten, lernt man eine ganze Menge über die Sprache, deren innere Konstrukte und die entsprechenden Paradigmen. Ein Kernaspekt, auf den Jon Skeet zu Recht äußerst ausführlich eingeht, sind Delegaten und deren Weiterentwicklungen wie anonyme Methoden in C# 2 und Lambdaausdrücke und Expression Trees in C# 3.

Selbstverständlich geht auch C# in Depth auf LINQ ein, denn zu wichtig ist dieses Sprachfeature von C# 3, als dass man es einfach unter den Tisch fallen lassen könnte. Allerdings ist diese Sektion bewusst kompakt gehalten, und Jon Skeet verweist an entsprechender Stelle auf geeignete Sekundärliteratur, wie beispielsweise das Buch LINQ in Action.

C# in Depth ist definitiv nicht für Anfänger geeignet, die sich einen Überblick über die Sprache C# verschaffen wollen. Darauf weist Jon Skeet bereits im Vorfeld zur Genüge hin. Wer aber schon einige Jahre mit C# gearbeitet hat, und nun mehr über die Interna der Sprache wissen möchte, und sich zudem dafür interessiert, warum manche Konstrukte so und nicht anders umgesetzt wurden, der wird dieses Buch sehr zu schätzen wissen.

Vor einigen Tagen habe ich einen Blogeintrag über Umbraco, ein CMS auf Basis von ASP.NET, geschrieben. Seither bin ich von einigen Personen gefragt worden, warum ich ausgerechnet Umbraco als verhältnismäßig unbekanntes CMS präferiere, und was aus meiner Sicht gegen den Einsatz eines deutlich bekannteren Systems wie beispielsweise DotNetNuke spricht.

Das Interessante an dieser Frage ist, dass ich sie nicht aus dem Stegreif beantworten konnte, sondern lediglich auf mein Gefühl verweisen konnte, dass Umbraco das bessere System sei. Nachdem mich diese Frage nun in den vergangenen Tagen immer wieder beschäftigt hat, bin ich inzwischen zu einer Antwort gekommen, die ich rational begründen kann.

Zunächst muss jedoch eine andere Frage beantwortet werden, nämlich, was die grundlegende Aufgabe eines CMS ist. Vertraut man auf Wikipedia, so lautet die Antwort:

Ein Content-Management-System (kurz CMS [...]) ist ein Anwendungsprogramm, das die gemeinschaftliche Erstellung und Bearbeitung des Inhalts von Text- und Multimediadokumenten ermöglicht und organisiert, [...] Der darzustellende Informationsgehalt wird in diesem Zusammenhang als Content (Inhalt) bezeichnet.

Relevant ist dabei meiner Meinung nach insbesondere weniger das, was in dieser Definition genannt wird, als vielmehr das, was in dieser Definition nicht genannt wird. Folgt man nämlich strikt dieser Definition eines CMS, so beschäftigt sich ein CMS ausschließlich mit dem reinen Inhalt, aber nicht mit der grafischen Repräsentation oder den zugehörigen Workflows - genau dies besagt schließlich auch der Begriff CMS.

Die gängigen Content Management Systeme am Markt erfüllen diese Definition jedoch nicht. Zwar ist es mit allen Systemen möglich, Content zu verwalten, aber die meisten Systeme liefern darüber hinaus noch eine Unmenge an Modulen mit, die für die grafische Repräsentation oder für Workflows zuständig sind. Sobald man versucht, sich außerhalb der Grenzen dieser Module zu bewegen, wird der Weg sofort steinig und häufig auch unnötig schwer.

An dieser Stelle weicht Umbraco ganz eklatant von dem für Content Management Systeme üblichen Weg ab: Die grafische Darstellung obliegt vollständig dem Designer der Lösung, insbesondere verändert Umbraco die vorgegebene Darstellung in keiner Weise. Das System beschränkt sich darauf, seine Kernaufgabe zu erfüllen, nämlich das Verwalten des Contents - aber nicht mehr.

Diese strikte Trennung von Content und Darstellung, die sich bei Umbraco direkt im System findet, hat zur Folge, dass es zwar zunächst ein wenig aufwändiger ist, eine Lösung zu erstellen, dass der eigenen Kreativität aber zugleich auch keinerlei Schranken auferlegt werden. Und genau dieser Fakt ist es, was mir an Umbraco wesentlich besser gefällt als an den meisten anderen Content Management Systemen: Die Konzentration auf das Wesentliche.

Schon seit geraumer Zeit bin ich auf der Suche nach einem Content Management System (CMS), das auf ASP.NET basiert, kostenfrei und idealerweise Opensource wie auch leistungsfähig und skalierbar ist. Zugleich darf die Einarbeitung in ein entsprechendes System aber auch nicht zu aufwändig und kompliziert sein, schließlich geht es mir ausschließlich um den privaten und KMU-Einsatz.

Aus verschiedenen Gründen scheiden die Platzhirsche der Branche leider aus, allen voran AxCMS.net der Firma Axinom, das zwar so wohl kostenfrei wie auch ausgesprochen leistungsfähig ist, für das genannte Einsatzgebiet aber leider zu umfangreich ist, wodurch der notwendige Einarbeitungs- und Wartungsaufwand in nicht mehr zu vertretende Höhen schießt.

Nach einiger Suche bin ich nun, wie es scheint, auf ein System gestoßen, das alle meine Anforderungen erfüllt und zudem äußerst flexibel und zudem erweiterbar ist: Die Rede ist von Umbraco. Dieses System basiert auf ASP.NET 2.0, unterstützt verschiedene Datenbanken, unter anderem auch SQL Server 2005 und 2008, und legt dem Webdesigner keinerlei Einschränkungen auf, wenn es um das Design der Webseite geht.

Auch wenn der erste Anfang ein wenig mühsam ist, so ist das Konzept von Umbraco doch letztlich sehr durchdacht und übersichtlich, wenn man sich erst einmal an die Terminologie gewöhnt hat:

• Das grundlegende Element in Umbraco sind sogenannte Document Types, die analog zu einer Tabellenbeschreibung in einer Datenbank vorgeben, aus welchen Element ein einzelnes Objekt bestehen kann - im einfachsten Fall wird durch einen Document Type eine ganze Seite beschrieben, die beispielsweise aus einer Überschrift, einem Bild und einer Textbox für Richtext besteht. Ein Document Type muss aber nicht zwingendermaßen eine ganze Seite beschreiben, auch der Teil einer Seite ist abbildbar.
• Passend zu jedem Document Type gibt es ein sogenanntes Template, das als beliebiger Code in HTML oder XHTML definiert sein kann, und welches die optische Darstellung des Document Types definiert. Auch hier gilt wiederum, dass ein Template im einfachsten Fall die ganze Seite beschreibt, in komplexeren Szenarien durchaus aber nur einen Ausschnitt der Seite beschreibt. Da sich so wohl Document Types wie auch Templates ineinander verschachteln lassen, ist es problemlos möglich, hierarchische Strukturen zu erstellen, die dem Konzept der Masterseiten in ASP.NET ähneln.
• Gefüllt wird die Kombination aus Document Type und Template nun mit Leben, indem der Benutzer Content zur Verfügung stellt, der sich von seiner Struktur an den Document Type und von seiner Optik an dem passenden Template orientiert.
• Ergänzt wird das ganze durch die Möglichkeit, dynamischen Content in ein Template einbinden zu können - dies geschieht über sogenannte Makros, wobei ein Makro im Grunde genommen nichts anderes als ein Wrapper um ein Stück Code ist. Dieser Code wiederum kann in verschiedenen Sprachen angebunden werden, beispielsweise in XSLT, C# oder Python.
• Ein XSLT-Makro bietet sich immer dann an, wenn Daten verarbeitet werden sollen, die bereits in Umbraco vorliegen - intern bildet Umbraco sämtlichen Content und sämtliche Strukturen nämlich als XML ab, so dass sich der Einsatz von XSLT anbietet. Sollen hingegen externe Inhalte wie beispielsweise Datenbank- oder Webserviceabfragen eingebunden werden, so bietet sich der Einsatz von C# an. In Umbraco ist es sogar möglich, ASP.NET-Webcontrols direkt als Makro einzubinden, so dass keine spezielle Vererbungshierarchie notwendig ist.

Aktuell ist derzeit noch die Umbraco-Version 3, Version 4 ist aber bereits für Ende des Jahres angekündigt. Diese Version wird dann die Fähigkeiten von ASP.NET noch deutlich besser ausnutzen, da zahlreiche Konzepte nicht mehr proprietär umgesetzt werden, sondern so, wie man es in ASP.NET auch machen würde - begonnen bei Masterseiten für Templates über die Verwendung von ASP.NET-Membership- und -Role-Providern bis hin zu einer Überarbeitung aller Umbraco-eigenen Schlüsselworte auf eine Syntax, die der von ASP.NET entspricht.

Alles in allem bietet das System zwar nicht so viel out of the box wie manch kommerzielles oder größeres System, dafür bietet es dem Entwickler aber alle Freiheiten, seine Wünsche und Ideen umzusetzen, ohne ihm irgendwelche Einschränkungen aufzuerlegen.

Als einziger Wermutstropfen bleibt derzeit eigentlich nur, dass sich ein Einstieg in Version 3 derzeit nicht mehr wirklich lohnt, da Version 4 dermaßen viele Neuerungen mitbringt, dass man dann lieber direkt auf dieser Version aufsetzen sollte. Wem es aber nicht auf ein paar Monate ankommt, dem sei dieses System uneingeschränkt empfohlen.