Spekulativ: VisualStudio 2012, TFS in da Cloud, und .NET 4.5

Heute findet die teched North America in Atlanta statt. Die großen Zeiten einer teched sind längst vorbei, als noch Bill Gates die Keynote hielt, oder Dr. Brown mit seinem DeLorean, “zurück aus der Zukunft” kam. Stattdessen erwartet man heutzutage von Konferenzen wie der MIX oder PDC die großen Ankündigungen.

Schaut man sich jedoch die diesjährige Sessionliste an, kann man von der heutigen Keynote ein paar wichtige Ankündigungen erwarten. Einige Informationen sind schon durchgesickert, wie bereits “der Dotnet-Doktor” schrieb.

Wenn Jason Zander die Keynote hält, geht es meistens um VisualStudio und das .NET Framework; er ist nämlich der Hauptverantwortliche dafür. Sicherlich wird er einige Demos von VisualStudio 2012 und .NET 4.5 vorführen. Ich denke aber nicht, dass es bereits jetzt eine Beta geben wird.

Nach der Keynote folgen die Foundation Sessions, d.h. Vertiefungen von den Demos die in der Keynote gezeigt wurden. Diese sind meine Highlights:

• FDN03 | The Future of Microsoft Visual Studio Application Lifecycle Management

• FDN02 | Collaboration in the Cloud with SharePoint: A New World of Productivity

• FDN04 | Microsoft SQL Server: The Data and BI Platform for Today and Tomorrow

Wie es mit TFS/VisualStudio als ALM Plattform weitergehen soll, hat Brian Harry auf der PDC10 gezeigt: Es geht in die Cloud!

Ein weiteres wichtiges Thema wird die “Async" Spracherweiterung für VB und C#sein. Damit wird Asynchrone Programmierung quasi zum Kinderspiel.

• DEV324 | C# and Visual Basic Future: Async Made Simple

Unterstützung wird es vom Framework über neue APIs in der TPL sowie in WCF geben.

• DEV301 | The Future of Parallel Programming in the Microsoft .NET Framework
• DEV340 | Tackle the Complexity of Async Calls in Microsoft Silverlight and WPF Clients
• MID310 | Windows Communication Foundation Futures

Evtl. gibt es auch hier die CTP3

Mal gucken ob ich mit meinem Blick in die Glaskugel recht behalte :-)

PDC10 Sessions online

Die Sessions für die PDC vom 28. / 29. Oktober sind online.

Anhand der Session Beschreibungen lässt sich erahnen, welche Überraschungen uns erwarten werden.

Direkt nach der Keynote, die in den UserGroups zusammen gesehen wird, berichtet Anders Heijlsberg über die Zukunft von C# und VB. Vermutlich wird es aber kein C# 5 oder VB 11 geben. Ich könnte mir aber vorstellen, dass es eine CTP vom “Compiler as a Service” geben könnte.

In dem gleichen Slot behandelt Bart de Smet ein nicht weniger wichtiges Thema, nämlich LINQ und Rx.

Auffällig ist, dass einige Slots noch nicht besetzt sind. Es sind also einige neu Ankündigungen zu erwarten, im Bereich Azure, Windows Phone 7 und sogar VisualStudio. Unteranderem gibt es auch einen Placeholder für Silverlight! Vielleicht erhalten wir einen Blick von Silverlight 5?!

In der letzten Session geht es um die Zukunft von F#.

Alle Sessions werden live gestreamt! Es lohnt sich also statt dem Abendspielfilm, oder dem Besuch im Kino, eine Session von der PDC anzusehen!

The Silverlight Developer Runtime is not installed

Silverlight ist schon eine tolle Plattform…

Heute morgen bin ich auf channel9 gesurft und wollte mir ein Video anschauen. Nach klick auf den Play Button, kam ein netter Bildschirm, der mich darauf hinwies, dass ich nicht die aktuellste Silverlight Version installiert hätte. Da ich das Video unbedingt gucken wollte, und auch sonst keine Probleme damit habe immer die neuste Version zu installieren, lud ich die neueste SL Version herunter und installierte sie.

Gleichzeitig war ich aber auch mit VisualStudio zugange. Während ich also das Video auf channel9 sah, arbeite ich fleißig an einem Silverlight-Spike. Als ich nun F5 drückte, kam folgende Meldung:

Zunächst dachte ich, dass es daran liegen könnte, dass nach der Installation der Silverlight Runtime nun die Silverlight Tools für VisualStudio ebenfalls aktualisiert werden müssten. Die Installation der SL Tools brachte aber keine Lösung.

Nach etwas “bingen” stieß ich auf einige Foreneinträge. Dieses Problem scheint wohl häufiger aufzutauchen,was ich erstaunlich fand. (Jedoch nicht ungewöhnlich für Silverlight)

Für Silverlight gibt es zwei Runtimes! Eine für “Normalos” und eine für Entwickler. Die developer runtime ist jedoch nicht im SDK oder den Tools enthalten, sondern es muss das sog. Silverlight managed debugging package  heruntergeladen werden.

Überlegt euch also gut, ob ihr immer die neuste Silverlight Version braucht, sie könnte euer VisualStudio kaputt machen.

VB – Quo Vadis?

Ja ich gebe zu, ich mag VB.

Ich finde VB10 hat ein paar sehr nützliche Features. So sind z.B. in den meisten Fällen keine underscores (_) als sog. Line continuations mehr nötig.

Auch nett sind die collection initializer, die es momentan in C# in der Form nicht gibt.

Bisher mochte ich VB immer verteidigen, wenn es darum ging, ob VB schlechter ist als C#.

Doch mittlerweile kommen mir Zweifel. Das mag daran liegen, dass ich C# doch recht lieb gewonnen habe. Vielleicht aber auch daran, dass ich immer mehr F# Code schreibe und dessen Eleganz einfach umwerfend finde.

Der Grund warum mir Zweifel an VB kommen, folgender VB10 Code, den ich in einem Blog entdeckt habe.

Public Sub LoadPolicyDetail()

Dim client As New Services.Service1Client()

 

AddHandler client.GetPolicyDetailCompleted,

Sub(s As Object, e As GetPolicyDetailCompletedEventArgs)

If e.Result <> Nothing Then

MessageBox.Show("Awesome!")

End If

End Sub

 

client.GetPolicyDetailAsync()

End Sub

 

Dieser Code zeigt, wie man eine anonyme Methode an einen Event bindet. Hier der gleiche Code in C#

void LoadPolicyDetail()

{

var client = new
Service1Client();

client.GetPolicyDetailCompleted += (s,e) => if (e.Result != null) MessageBox.Show("Awesome!");

client.GetPolicyDetailAsync()

}

 

Dieser Code ist doch deutlich lesbarer. Statt 8 Zeilen Code und einer Menge "Rauschen" brauche ich mit C# nur 3 Zeilen. Gut man könnte den Code noch etwas formatieren, dann kommt man auf 5.

Ich verstehe nicht, welche Vorteile eine Programmiersprache bringen soll, für die man bei gleichem Ergebnis 3x so viel Code schreiben muss.

 

 

 

F# und der Umgang mit out Parametern

Jede Funktion bzw. Methode kann zunächstmal nur immer eine Informationen zurückgegeben. Dies wird durch den Rückgabewert oder Rückgabeparameter ausgedrückt. Was macht man aber, wenn man in einer Methode mehrere Informationen zurückgeben möchte, die evtl. sogar optional sein sollen? Eine Möglichkeit ist natürlich einen komplexen Datentyp zu definieren und diesen als Rückgabetyp der Methode zu benennen. Aus Bequemlichkeit macht man das aber eher nicht.

Ein pragmatischster Ansatz ist es, für die zusätzlichen Rückgabewerte jeweils out Parameter zu definieren. Die out Parameter sind in der Regel primitive Datentypen wie string oder int.

Im .NET Framework gibt es einige Methoden die einen out Parameter haben. Eine oft verwendete Klasse ist z.B. das Dictionary.

Hier ein Beispiel:

var dict = new
Dictionary<string, int>();

dict.Add("A", 1);

dict.Add("B", 2);

 

Jetzt versuchen wir Werte aus dem Dictionary zu ziehen. Da nicht garantiert werden kann, dass der gesuchte Wert auch in dem Dictionary ist, verwenden wir die Methode TryGetValue. Da diese nun einen out Parameter definiert, müssen wir bevor wir diese Methode aufrufen können eine Variable mit dem entsprechenden out Parameter Typ definieren und die Methode mit der Variablen aufrufen.Der Rückgabewert von TryGetValue ist ein bool, so dass man erkennen kann, ob der Wert im Dictionary vorhanden ist. Nur wenn der Wert vorhanden ist, hat auch die Variable einen Wert. Aber Vorsicht! Da int ein Werttyp, ist hat er immer einen Defaultwert, nämlich 0. Zur Sicherheit sollte man daher der out Variablen einen anderen Wert als den Defaultwert zuweisen, bei int z.B: -1 statt o.

 

int value = -1;

var success = dict.TryGetValue("A", value);

if (success)

{

Console.WriteLine(value);

}

Soweit dürfte das jedem klar sein und sicherlich schon oft gemacht worden. Für mich ist die o.g. Methode, genauso wie TryParse, ein legitimer Grund out Paramter zu verwenden. Alle anderen Gründe sind eher zweitrangig da hier Bequemlichkeit im Vordergrund steht. Man will halt keinen komplexen Datentypen nur für einen Rückgabeparameter erstellen.

Aber es geht auch anders: mit F#!

F# to the rescue

Da F# eine ganz normale .NET Sprache ist, kann man natürlich auch die Klassen des Frameworks aufrufen. Z.B. auch die Methoden die out Parameter definieren, wie z.B. das Dictionary. Wie geht F# damit um?

In F# können wir ganz normal ein Dictionary erzeugen.

open System.Collections.Generic

let dict = new Dictionary<string,int>()

Nun fügen wir Werte zum Dictionary hinzu

dict.Add("A",1)

dict.Add("B",2)

Schließlich wollen wir die Werte auch wieder auslesen.

let result = dict.TryGetValue("A")

Nun von welchem Typ ist jetzt result? Und warum muss man keinen out Parameter übergeben?

F# Interactive gibt die Anwort.

val result : bool * int = (true, 1)

Result ist vom Typ bool * int
, was in F# bedeutet dass dies ein Tupel ist. In .NET 4.0 kann man dies als Tuple<bool,int>
beschreiben.

Nun können wir diesen Tupel mit den Funktionen fst und snd zerlegen.

let success = fst result

val success : bool = true

 

let value = snd result

val value : int = 1

F# wäre nicht F# wenn man es nicht noch einfacher ausdrücken könnte. Man kann nämlich den Tuple direkt in seine Bestandteile zerlegen.

let (success,value) = dict.TryGetValue("A")

val value : int = 1

val success : bool = true

let (success,value) = dict.TryGetValue("C")

val value : int = 0

val success : bool = false

Fazit

Für meine Begriffe ist dies ein gutes Bespiel wie ausdrucksstark F# ist. In der Vergangeneheit sind viele Fehler im Programmiersprachendesign gemacht worden. Allem voran C++, aber leider auch bei C#. Tuples sind ein hervoragendes Mittel, um out Parameter zu vermeiden. Da Tuple in .NET 4.0 ein "first Class" Datentyp ist, gibt es keinen Grund mehr diesen nicht auch in C# als Alternative zu out Parametern zu verweden. Letztendlich macht es aber mit F# mehr Spaß!

Over und out!

Cassidy Marie shipped

Beta


Release Candidate


Cassidy Marie shipped

Die glücklichen und schlaflosen Eltern
Marika und Benjamin Gopp

F#: Units of Measure

Mit dem diese Woche erschienenen Release Candidate von VS2010, hat sich auch was bei F# getan. Wie Don Syme in seinem Blog schreibt, ist der F# Compiler auf Version 2.0 heraufgesetzt worden. Das bedeutet F# ist ausgereift um es produktiv einzusetzen (Obwohl viele es bereits mit früheren Version eingesetzt haben). Zeit sich also endlich ernsthaft mit F# und seinen genialen Features zu beschäftigen!

Ein Feature über das ich heute schreiben möchte sind Units of Measure oder zu Deutsch Maßeinheiten. Bei diesem Feature geht es um das Problem bei der Verwendung von unterschiedlichen Maßeinheiten im Code. Wie der Unfall des NASA Mars Climate Orbiter 1999 zeigt, kommt es auch heute noch zu Fehlern auf Grund der Verwendung von unterschiedlichen Maßeinheiten. Mittlerweile wird auch in der USA in Wissenschaft und Technik das Metrische System verwendet. Ein Zulieferer hatte jedoch in Pfund und Fuß gerechnet, was letztlich dazu führte, dass die Mars Sonde verglühte.

Dieses Feature hat also einen relativ ernsten Hintergrund. Damit solche Fehler sich nicht in Produktivcode einschleichen verwendet F# eine erweiterte statische Codeanalyse. Maßeinheiten werden dabei mit Attributen annotiert und bei Ihrer Verwendung vom Compiler auf Korrektheit geprüft. Dabei wird jedoch nicht nur geprüft ob der entsprechende Typ korrekt ist, sondern auch ob die Funktion in dem man diesen Typ verwendet, mathematisch korrekt ist. Durch die intelligente Typinferenz in F# können sogar abgeleitete Maßeinheiten ermittelt werden.

Nun wie funktioniert das? In C# könnte man eine gewisse Art der Typsicherheit hinbekommen, indem man für Maßeinheit einen eigenen Typen erstellt. Somit würde der Compiler beim Verwenden des Types dessen Typsicherheit garantieren. Was jedoch nicht möglich ist, dass auch auf die Einhaltung der mathematischen Regeln geprüft wird. Dies könnte man vielleicht zur Laufzeit realisieren in dem man für Maßeinheiten entsprechende Rules definiert. Letzlich würde aber eine Prüfung zur Laufzeit nicht den Absturz einer 100.000 km entfernten Sonde verhindern können. Die Prüfung muss also viel früher, also zur Compilezeit erfolgen.

Noch ein Hinweis: Units of Measure können nur mit Gleitkommazahlen verwendet werden! Dies liegt daran, dass man nicht nur dumme Maßeinheiten verwenden kann, sondern auch physikalische Größen wie Beschleunigung etc. Dies würde nicht mit Integers oder anderen Typen funktionieren. (Tatsächlich kann man aber Units of Measure mit Komplexen Zahlen oder Vektoren verwenden)

Ein Beispiel:

Man definiert zunächst die Maßeinheiten die man verwenden will als Typen. Diese Typen attributiert man mit[<Measure>]. (So sehen Attribute in F# aus. Eine Misschung aus C# und VB Attribute)

[<Measure>] type kg

[<Measure>] type s

[<Measure>] type m

 

Nun können wir Formeln schreiben. Wir wollen wissen, mit welcher Geschwindigkeit wir auf der Erde aufkommen, wenn wir aus einer bestimmten Höhe springen. Zunächst definieren wir die Höhe als Gleitkommazahl und auf welche Maßeinheit sich diese bezieht.

let höhe = 2.0<m>

 

Nun definieren wir die Gravitation. Diese ist eine Beschleunigungskraft: also Gravitationskonstate mal Meter pro Sekunde im Quadrat

let gravitation = 9.81<m/s^2>

 

Wir können nun ausrechnen wie groß die Geschwindigkeit ist, mit der man auf der Erde auftrifft.

let geschwindigkeit = sqrt (2.0 * gravitation * höhe)

 

F# Interactive sagt uns, dass die Geschwindigkeit in Metern pro Sekunde berechnet wird.

val geschwindigkeit : float<m/s> = 14.00714104

 

Demnach schlgt man mit 14 Metern pro Sekunde bei einem Sprung aus 2 Metern Höhe auf der Erde auf. Gut zu wissen!

Im F# Power Pack sind weitere Standardmaßeinheinten definiert, so dass man nicht jedes mal alle Naturgesetze herunterbeten muss. Auf der anderen Seite stellt sich die Frage, wann man dieses Feature wirklich brauch. Hier zeigt sich wieder das F# eine super Ergänzung zu bestehenden C# Code ist, jedoch keinesfalls den Anspruch erhebt C# in seiner Gesamtheit abzulösen. Bisher sind noch keine Überlegungen gemacht worden, Units of Measure auch nach C# zu portieren oder sogar in die CLR. Man wird mit der Zeit sehen müssen, ob dieses und andere Feature auch nach C# portiert werden, oder ob es dann keinen Grund mehr geben würde F# zu verwenden. Das wäre außerst schade!

Viel Spaß beim Ausprobieren mit F#

Benjamin

 

Top Ten Free Extensions for Visual Studio 2010

Kate Gregory hat auf Codeproject eine Top 10 der Erweiterungen für Visual Studio 2010 zusammengestellt.

Darunter auch meine Erweiterung die "ZoomEditorMargin". Meine Beschreibung findet ihr hier: http://hiq-software.blogspot.com/2009/10/vs2010-extension-zoomeditormargin.html

Ein Video von meiner Extension kann man sich bei Youtube ansehen http://www.youtube.com/watch?v=sM_20hptWDc

Weitere Tools und die entsprechenden Videos hierzu findet ihr unter http://www.codeproject.com/KB/macros/TopTenFreeExtensions2010.aspx

 

Benjamin

VSTO 4.0 Runtime

Die VSTO 4.0 Runtime wird nicht installiert, wenn man Office 2010 bereits installiert hat. Stattdessen wird die VSTO 3.5 Runtime installiert!

Warum? Keine Ahnung!

Mehr Informationen findet man unter: http://msdn.microsoft.com/en-us/library/bb608603(VS.100).aspx

Wer die Installation nachholen will kann die Runtime über den entsprechenden Bootstrapper installieren. Der wird nämlich installiert.

Der Bootstrapper Pfad lautet: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\VSTOR40

VS2010 Extension: ZoomEditorMargin

VS2010 Beta2 ist endlich draußen. Kaum heruntergeladen und installiert, habe ich auch schon die erste Erweiterung für den neuen WPF Codeeditor geschrieben!

Besonders gespannt war ich auf die Zoom Funktion des Codeeditors. Als ich VS2010 zum ersten Mal öffnete, war ich jedoch etwas enttäuscht. Auf der linken Seite des Code Editors befand sich lediglich eine Combobox, über die man den Zoom einstellen kann. Aus meiner Erfahrung mit Office 2007, hätte ich jedoch gerne einen Slider gehabt, mit dem ich stufenlos zoomen könnte.

Zum Glück lässt sich der neue WPF Codeeditor in VS2010 an allen Ecken und Enden anpassen. Gesagt getan, habe ich eine eigene "Margin" für den Editor geschrieben. Eine Margin ist ein Bereich im Codeeditor, in dem man ein WPF Control platzieren kann. Dies ist nur eine von vielen Möglichkeiten den Codeeditor anzupassen und zu erweitern.

Wer das ZoomEditorMargin herunterladen und direkt ausprobieren möchte, kann dies in der , oder über den ExtensionManager in VisualStudio tun.

Der Code Editor ohne Zoom Extension

Der Code Editor mit Zoom Extension

In den nächsten Posts werde ich erklären, wie ich diese Extension erstellt habe. Es gibt viele Aspekte, auf die ich näher eingehen möchte. Deswegen verrate ich nicht alles schon in diesem Blog Post.

Viel Spaß und stay tuned

Benny

Stirnrunzeln über: "Stirnrunzeln über das Neuste von Microsoft seit geschnitten Brot"

Ralf Westphal schrieb in seinem Blog "Stirnrunzeln über das Neuste von Microsoft seit geschnitten Brot", über das neue Reaktive Framework (Rx) von Microsoft. Zunächst wollte ich einen Kommentar in sein Blog schreiben. Der Kommentar ist dann etwas länger ausgefallen, so dass ich mich entschieden habe, einen eigenen Blog Eintrag mit meiner Meinung zu diesem Thema zu schreiben. Ralf fordert sogar zu Reaktionen auf: "Oder übersehe ich hier die eigentliche Erfindung? Geht der brillante Innovationshub an mir vorbei? Ich bitte um Erhellung"

Also versuch ich doch etwas Licht ins Dunkeln zu bringen.

Wo ist das Problem?!

Für Ralf besteht das Problem an dieser neuen Technologie, dass er ein "neues Vokabular für etwas Altes" benutzen muss. Nach dem Motto: Raider ist jetzt Twix. Klar, wenn etwas Neues mit einem alten Begriff besetzt ist und das Neue immer mit dem Alten assoziiert wird, sinkt natürlich die Akzeptanz für das Neue. Heißt das aber, dass da Neue schlecht ist? Das kann ich (noch) nicht beurteilen. Trotzdem bin ich Neuem erst mal aufgeschlossen eingestellt.

Was ist also das Alte? Für Ralf ist das Alte: Complex Event Processing (CEP).

"Das ist nicht neu, das ist kein Hexenwerk".

Aber das ist doch mit den meisten Erfindungen so! Irgendwo hat's Irgendwer bereits erfunden. Das Neue sieht nur hübscher aus: "es ist eben keine tolle neue Erfindung seit geschnitten Brot, sondern etwas lange Bekanntes in aufgehübschtes Gewand gekleidet". Ja, das ist vermutlich so.

"Tut mir leid, da ist nichts Neues für mich dabei. Wenn ich im etablierten Paradigma data flow denke, dann ist das etwas uraltes und kann mit heutigen Mitteln bewältigt werden."

Ralf, das mag für dich alles "kalter Kaffee" sein. Aber hallo? Data flow, etabliert? Wo denn bitte? In welcher Firma die Software Entwicklung ist denn dieses Paradigma etabliert? Frag doch aber bitte mal deine Kunden, die Teilnehmer der CCD Seminare, die Besucher einer Konferenz, die Zuhörer deiner Vorträge. Wer von denen:

• hat von CEP, Esper oder CCR gehört?
  
• hat einen Artikel über CEP, Esper oder CCR gelesen (von dir oder jemand anders)?
  
• verwendet CEP, Esper oder CCR produktiv in seinen Buisiness Anwendungen?
  

Antwort: fast
Niemand.

Das ist das Problem: Für Dich und einige Wenige ist das alles Schnee von gestern (siehe 1. Kommentar von Holger Hofstätte). Für die breite Masse, absolutes Neuland.

"Wer das wirklich einmal ausprobieren will, was man mit einer Abfragesprache auf Event-Strömen tun kann, dann kann mit NEsper spielen"

Nein Ralf, ich will nichts ausprobieren, ich will auch nicht nur damit spielen. Ich möchte diese Funktionalität im .NET Framework haben und produktiv sein.

Reaktive Programmierung wird im Core .NET Framework vorhanden sein. Das ist das Neue! Das ist Etablierung!

Was ist mit LINQ

Zur Erinnerung: für Ralf besteht das Problem am Reactive Framework, dass es das alles schon einmal gab. Was war aber gleich nochmal LINQ?

Das Konzept hinter LINQ kommt aus der funktionalen Programmierung (Map, Filter, Reduce). Anscheinend hatte hier Ralf keine oder nicht genügend Berührungspunkte mit der funktionalen Programmierung, dass er automatsch LINQ mit einer längst erfundenen Technologie assoziiert hätte. Zumindest wird Erik Meijer für sein "Brainchild" LINQ gelobt, jedoch nicht für seine anderen Projekte (z.B: Volta und Rx).

Funktionale Programmierung war doch auch nur ein akademisches Thema. Vielleicht ist man im Studium mit LISP, ML oder Miranda in Berührung gekommen. Angekommen im Berufsleben hat man aber seine Daten über geschachtelte for-Schleifen gefiltert. Von wegen Map, Filter, Reduce. Obwohl die Technologie doch bereits in .NET vorhanden war (Delegates, Iteratoren). Trotzdem hat es keiner genutzt. Aber dann kam LINQ daher und mit ein bischen "syntactic sugar" für C#, etabliert sich ein Konzept aus der funktionalen Programmierung auch in einer objektorientierten Programmiersprache wie .NET. Und da das Konzept im Framework verankert ist, ist LINQ sogar für alle.NET basierten Programmiersprachen verfügbar.

Erst mit LINQ hat sich das funktionale Paradigma in der breiten Masse etabliert. Immer mehr Leute benutzen LINQ Queries um ihre Listen zu projizieren, filtern und aggregieren. Immer mehr Leute verwenden Lambda Ausdrücke für die alltäglichsten Dinge.

BetaMax vs. VHS, HD vs. BlueRay

LINQ hat da eine Tür aufgestoßen, das Reaktive Framework wird das gleiche machen und den Weg in den Mainstream finden

"Flows habe ich aber natürlich nicht erfunden. Die sind alt"... "Mainstream ist es aber nicht geworden, wie wir sehen. Schade. Denn die Schritte in einem Flow steigern die Evolvierbarkeit von Software, finde ich"

Ralf, das ist doch genau dein Wunsch, dass das Konzept den Weg in den Mainstream findet. Welche Technologie letztendlich das Rennen macht spielt doch keine Rolle. Ob BetaMax oder VHS, HD oder BlueRay, CEP oder Rx.

Fazit

Es gab schon immer Erfindungen, die nur einem kleinen elitären Bereich in Industrie und Forschung, zugänglich oder erschlossen waren. Nur weil es eine Technologie in einem kleinem Bereich Anklang gefunden hat, kann man nicht sagen die Technologie sei etabliert. Erst wenn sie es in den Mainstream geschafft hat, kann man von Etablierung sprechen. LINQ ist ein super Beispiel dafür, dass ein akademisches Thema dem Mainstream zugänglich wird.

CEP, Esper und CCR haben sich nicht etabliert und werden sich nicht etablieren.Das Reactive Framework wird sich aber etablieren. Warum? Ganz einfach, es wird Kernbestandteil von .NET sein und damit zugänglich und allgegenwärtig für .NET Entwickler. Kein separates Tool, kein irgendwo runterladen, kein rumspielen. Es wird einfach da sein. Bleibt nur noch es auch zu nutzen...

F# - Teil 1

Vorgestern habe ich einen Vortrag bei der User Group Köln über F# gehalten. Dort habe ich über meine Erfahrungen mit F# geredet und ein paar Sprachfeatures gezeigt. Leider waren 30 Minuten viel zu wenig um alles zu zeigen und auch noch Fragen zu beantworten. In den kommenden Blogeinträgen werde ich daher meine Erfahrungen mit F# schriftlich festhalten.

F# ist eine neue Programmiersprache in der .NET Familie. Diese wird in VS2010 neben VB und C# eine der Hauptsprachen für die .NET Entwicklung werden; so der Plan.

Déjà-vu

Als ich zum ersten Mal die Beta1 von VisualStudio 2010 öffnete, hatte ich ein Déjà-vu Erlebnis. F# hatte ich bereits in VS2008 ausprobiert, aber erst mit VS2010 ist mir bewusst geworden, was Microsoft da eigentlich vor hat. Und dann lief es mir eiskalt den Rücken runter. Denn als ich zum ersten Mal vor ca. 6 Jahren ein VisualStudio 2003 installierte, um .NET zu lernen, stand neben VB und C# eine weitere Programmiersprache zur Auswahl; und das war J#.

Welchen Weg J# gegangen ist, muss ich nicht erwähnen. (Wer noch aktiv in J# programmiert, der möge sich bitte bei mir melden!). Könnte das gleiche Schicksal F# ereilen?

J# vs. F#

Die Frage ist, ob nur weil F# in VS2010 bereits vorinstalliert ist und man es sich nicht separat herunterladen muss, dieses dann auch öfters genutzt wird. Bei J# hat das ja auch nicht geholfen.

Nun, auf den ersten Blick hat F# ein schlechtes "Karma". Warum kann man aber doch sagen, das F# seinen Weg machen wird?

	J#	C#	F#
Paradigma	objektorientiert	objektorientiert	funktional
Sprachfamilie	C	C	ML
Kompatibilität	JAVA	-	OCAML

Vergleich von J# und F#

 

Der Vergleich zeigt, dass sich J# und C# einfach zu ähnlich sind, als dass es einen wirklichen Gewinn bringen wurde. Wer Java programmieren will, der macht das mit Java und nicht mit J#. Zumal man mit Eclipse eine weitaus bessere Entwicklungsumgebung hat. F# hat hingegen nichts mit C# zu tun. Die Sprache basiert nicht auf C sonder auf ML (Meta Language). Auch die Art der Programmierung ist anders, nämlich funktional. Microsoft hat jedoch mit F# ein paar Zugeständnisse gemacht. F# bezeichnet sich selber als "Multi Paradigmen" Programmiersprache, im Gegensatz zu reinen funktionalen Programmiersprachen wie Haskell. Man kann z.B. mit F# objektorientierte Klassenbibliotheken definieren, die von anderen .NET Programmen aufgerufen werden können.

Fazit

F# kann nicht mir J# verglichen werden, auch wenn es viele Ähnlichkeiten aufweist. Nicht in der Art der Syntax, sondern in der Art wie F# marketingtechnisch platziert wird. Ich vermute ganz stark, dass F# einen großen Einfluss auf die Weiterentwicklung von C# und .NET haben wird. F# hat dazu beigetragen, dass C# 2.0 Generics erhalten hat. Für C# 3.0 und LINQ wurden weitere Konzepte der funktionalen Welt in die objektorientierte Welt übertragen: Typinferenz, Lambda Ausdrücke und das sehr esoterische Konzept der Monadentheorie. Ich spekuliere dass C# 5.0, nachdem C# 4.0 Features aus der dynamischen Welt bekommen hat, wieder Konzepte aus der funktionalen Welt adaptieren wird. Meine Wunschfeatures für C# 5.0 sind: Pattern Matching, erweiterte Typinferenz, und Metaprogrammierung.

Ich glaube, dass man folgendes plakativ von F# sagen kann (andere funktionale Sprachen eingeschlossen):

Dank F# gibt es Generics. Dank F# gibt es Lambda Ausdrücke. Dank F# gibt es LINQ.

Danke F#!

Ausblick

Ich habe vor ein paar grundlegende Blogeinträge zu F# zu schreiben. Im nächsten Blog Eintrag wird es darum gehen, warum man eigentlich F# verwenden sollte.

Silverlight 3

WOW!

Bereits vor der eigentlichen Ankündigung bei der Keynote auf der Mix09, ist das Silverlight 3 SDK freigegeben worden. Ob es jetzt offiziell ist, weiß ich nicht - auf jeden Fall kann man es jetzt schon downloaden ;-))

Als WPF Entwickler war ich eher enttäuscht von Silverlight 2. Ein intuitives programmieren war nicht möglich. Eigentlich war es nur ein Krampf. Also habe ich beschlossen "Silverlight" erst mal "silverNight" sein zu lassen. Bis ... ja bis heute.

Auf die Schnell konnte ich folgende interessanten, lang erwarteten und teilweise überraschenden Neuerungen feststellen.

ObservableCollection<T>

Wie bereits aus WPF bekannt, implementiert diese Collection das INotifyCollectionChanged Interface. Damit können Controls feststellen, ob sich etwas an dieser Collections geändert hat, also Items hinzugefügt oder gelöscht wurden, so dass man die UI aktuallisieren kann. Siehe ItemsControl und ListBox

ICollectionView

Eng mit der ObservableCollection sind die sog. CollectionViews verbunden. In WPF gibt es diverse View Implementiereungen, ItemsCollectionView, EnumerationCollectionView, ListCollectionView, BindingListCollectionView. Diese gibt es aber nicht in Silverlight 3.

PagedCollectionView

Interessanterweise gibt es aber die PagedCollectionView; die es aber nicht in WPF gibt...

Nachwievor bewegen sich WPF und Silverlight immer noch stark auseinander. Leider.

Animationen

Für Animationen gibt es jetzt "Ease" Funktionen. Diese interpolieren eine Funktion die z.B. eine Beschleunigung simuliert. So kann man z.B. auch einen Ball springen lassen.

In WPF kann man solche Effekte über "KeySplines" erzeugen, aber auch diese gibt es nicht in Silverlight.

 

Weitere Neuerungen werden noch gepostet. Stay tuned.

So jetzt schnell nach Hause, damit ich mir die Keynote live gestreamt angucken kann!

WPF Window als Vollbild

Ein WPF Fenster kann auch im Vollbildmodus angezeigt werden und somit den gesamten Bildschirmplatz einnehmen ohne die Windowsstartleiste

Wie funktioniert das?

Nun, es ist einfacher als man denkt. Dafür braucht man keine nativen Windows APIs aufzurufen.

Folgender XAML Code zeigt wie es geht:

<Window x:Class="WpfApplication1.Window1"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

Title="Window1"

WindowStyle="None"

WindowState="Maximized"

WindowStartupLocation="CenterScreen">

<Grid Background="Red">

</Grid>

</Window>

Zunächst wir der WindowState mit Maximized angegeben. Das bewirkt natürlich dass das Fenster den gesamten Bildschirm ausfüllt.

Den ganzen Bildschirm? Nein, denn unten (oder oben) [oder auch an den Seiten] befindet sich die Windows Taskbar.

Wird nun der WindowStyle wird auf None gesetzt, hat das Fenster keinen Rahmen, also auch keine Titelleiste und Controlbar.

Allerdings verschwindet nun auch die Taskbar und das Fenster füllt tatsächlich den gesamten Screen aus.

Nun kann z.B. eine Photoshow starten.

Problematisch wird es, wenn der Anwender versucht das Fenster zu schließen, denn es fehlt ja die Titelleiste mit dem Schließen bzw. Minimieren Button. Man sollte daher noch auf Events der Tasten ESC oder F11 reagieren. Diese werden standardmäßig in Vollbild Applikationen verwendet, um in den normalen Fenstermodus zurückzukehren.

public
partial
class
Window1 : Window

{

public Window1()

{

InitializeComponent();

this.KeyDown = RootKey;

}

void RootKey(object sender, KeyEventArgs e)

{

if ((e.Key == Key.Escape) (e.Key == Key.F11))

{

if (this.WindowStyle == WindowStyle.None)

{

this.WindowStyle = WindowStyle.ThreeDBorderWindow;

this.WindowState = WindowState.Normal;

}

else

{

this.WindowStyle = WindowStyle.None;

this.WindowState = WindowState.Maximized;

}

e.Handled = true;

}

}

}

Ob dieses Feature beabsichtigt ist; weiß ich nicht. Ob dieses Feature jede Anwendung benötigt? Eher nicht.

Wer allerdings eine Vollbild Anwendung entwicklen will, der kann auch das mit WPF tun, und zwar mit relativ wenig Aufwand.

PDC08: new XAML features

XAML ist DIE deklarative Programmiersprache für .NET.

Sie findet hauptsächlich Anwendung in WPF, aber auch in WF und WCF

Auf der PDC wird sich eine Session rund um XAML drehen. Es wird gezeigt wie eine Anwendung komplett deklarativ in XAML geschrieben werden kann.

XAML wird außerdem mit XOML aus der Workflow Foundation vereinigt. Man darf gespannt sein auf welche Anwendungsbereiche XAML ausgeweitet werden wird.

Neue XAML Features werden sein:
- support für generics
- object references
- non default constructors


cu @ PDC
Benjamin

C# 4.0: dynamic

C# wird dynamisch!

Das erste publik gemachte Feature von C# 4.0 sind dynamic lookups. Diese werden durch das neue Schlüsselwort - dynamic - ermöglicht.

Dynamic lookups ermöglichen das Auflösen von Namen zur Laufzeit und nicht zur Compilezeit. Das bedeutet, dass dies ein neues Runtime Feature ist, denn ein Sprachfeature von C#. Alle .NET Sprachen können also diesen dynamic lookup verwenden. VB.NET konnte dieses Szenario bereits umsetzen - besser bekannt als "Late Binding" - , musste jedoch deafür auf eigene Methoden aus der Microsoft.VisualBasic.dll zurückgreifen. (Daher musste man bisher immer diese DLL deployen, wenn man .NET in VB programmiert hat).

Dynamic Lookups sind in der DLR (Dynamic Language Runtime) implementiert und für dynamische Sprachen unerlässlich.

Das folgende Beispiel ist den Slides der Keynote von Anders Hejsberg auf der JAOO entnommen

Olso und D#

Während die PDC immer näher rückt, werden die ersten heiß erwarteten Neuerungen bekannt. Unteranderem kommen immer mehr Details zum Vorschein, zu der langerwarteten Plattform Olso, die Teil des .NET Framework 4.0 sein wird.

Don Box ist einer der Architekten von Oslo und gibt in seinem Blog kleine versteckte Hinweise. Heute wies er auf einen interessanten Artikel hin, der weitere Geheimnisse zu Olso enthüllt.

Nach LINQ wird dieses Jahr ein weiterer Hammer vorgestellt werden:
Textuelle Domain Specific Languages (DSL)

Microsoft hat bereits ein DSL Toolkit mit dem man graphische DSL erstellen kann. Diese können dann über einen Designer in VisualStudio verwendet werden. Das Neuartige and denOslo DSL ist, dass sie wie eine eigene Programmiersprache funktionieren; also textuell. Diese TDSL basieren auf dem Microsoft Research Projekt TLA+ (T-emporalen L-ogik der A-ktionen)

Übrigens der Codename für diese TDSL ist "D".
Vielleicht bekommen wir nach C# nun ein D# !?

C.U. at PDC
Benjamin

PDC2008 I'm comming

Bei der letzten PDC habe ich mir noch alle Sessions online angesehen.

Jetzt bin ich LIVE dabei!

Themen werden sein:

- The Live Developer platform, including the MESH.
- Cloud Computing" from computation, to storage and much more!
- Visual Studio 10" and .NET Framework 4.0
- ASP.NET Futures including v.next of MVC, Ajax and Dynamic data
- Silverlight Futures, including Silverlight for business applications
- And much, much more.

StackPanel Items in umgekehrter Reihenfolge anzeigen

Das StackPanel in WPF kann Controls untereinander anordnen.

Mit der Eigenschaft Orientation=Horizontal ist es möglich auch die Elemente von Links nach Rechts anzuordnen.

Es gibt aber keine Eigenschaft StackItemsFrom="Top|Bottom".

Natürlich kann man ein eigenes StackPanel implementieren, das dies kann. Es geht aber auch einfacher.

Am Anfang war das ItemsControl

Wir benötigen zunächst ein ItemsControl. Ein ItemsControl kann beliebige Objekte, also auch Double, Boolean, Person etc., aufnehmen. Ein Panel hingegen nur Controls.

Das ItemControl benötigt jedoch ein Panel um die Objekte darstellen zu können. Standardmäßig ist dies ein StackPanel.

Über die Eigenschaft ItemsPanel können wir ein ItemsPanelTemplate definieren, und ein anderes von Panel abgeleiteten "Panel" angeben, in das nun die Items angeordnet werden.

Wie die Objekte aussehen bestimmt ein DataTemplate. Für jedes Objekt generiert das ItemsControl einen Container (ContentPresenter, für ListBox -> ListBoxItem). Da man auf diesen Container nicht direkt zugreifen kann, definiert das ItemsControl eine Property um den Style für den "ItemContainer" festlegen zu können.

Verkehrte Welt

Um nun die Elemente von unten nach oben statt von oben nach unten anordnen zu können, wie es das StackPanel macht, benötigen wir ein anderes Panel. Ein DockPanel ist geeignet, da es mehr als eine Möglichkeit gibt, Elemente in ihm anzuordnen. (Top,Left,Right,Bottom).

Nun müssen wir noch im ItemContainerStyle festlegen, dass die Elemente jeweils von Unten angeordnet werden sollen.

 

<ItemsControl>

<ItemsControl.ItemsPanel>

<ItemsPanelTemplate>

<DockPanel VerticalAlignment="Top" LastChildFill="False" />

</ItemsPanelTemplate>

</ItemsControl.ItemsPanel>

<ItemsControl.ItemContainerStyle>

<Style>

<Setter Property="DockPanel.Dock" Value="Bottom"/>

</Style>

</ItemsControl.ItemContainerStyle>

 

<Button>1</Button>

<Button>2</Button>

<Button>3</Button>

</ItemsControl>

Et Voila

 

AttachedProperties richtig initialisieren

Manchmal ist es angebracht, nachdem sich ein Objekt bei einem AttachedProperty registriert hat, einige Initialisierungen durchzuführen. Hierbei kann in der Set Methode, nach dem Setzen des AttachedProperty, z.B. eine Initialisierungsmethode aufgerufen werden.

public
static
void SetAttachedProperty(DependencyObject obj, int value)

{

obj.SetValue(AttachedProperty, value);

InitializeProperty();

}

Die Set-Methode macht nichts Weiteres, als bei dem übergebenen DependencyObjekt SetValue aufzurufen. Der eigentliche Wert der AttachedProperty wird also wie eine ganz normale DependencyProperty gesetzt. Stellen Sie sich einfach vor, eine DependencyProperty ist nichts anderes als ein Schlüssel der zusammen mit einem Wert in einem Dictionary gespeichert wird. Jedes DependencyObject hat so ein Dictionary. Die Werte können aber auch von anderen Objekten abgefragt und gesetzt werden.

Um eine AttachedProperty zu setzen, reicht es tatsächlich lediglich die DependencyProperty am eigenen Objekt zu setzen und nicht am Containerobjekt durch Set[Property]! Das bedeutet aber auch, dass die Initialisierungsmethode nicht mehr aufgerufen wird, da die AttachedProperty über einen anderen Weg gesetzt wird. Nun kann man es natürlich zur Konvention machen in dem in einem API vorschreibt, dass AttachedProperties immer über Set[Property] gesetzt werden müssen. So ist der XAMLReader drauf angewiesen, dass wenn er eine AttachedProperty im Markup erkennt, auch eine entsprechende Set-Methode verfügbar ist, die er aufrufen kann.

Trotzdem ist es besser eine Initialisierung anders durchzuführen. Wie? Über einen Callbackmechanismus. Jede DependencyProperty verfügt über Metadaten die es erlauben, Code bzw. Callbacks für Validierungen, Änderungen etc. zu hinterlegen. Ändert sich z.B. der Wert einer DependencyProperty, so wird der Callback aufgerufen und die Initialisierung kann durchgeführt werden. Dieser Mechanismus funktioniert unabhängig davon wie eine DependencyProperty, gesetzt wurde.

public
static
readonly
DependencyProperty PropertyWithCallback;

 

//Definition der Metadaten mit Callback

PropertyMetadata metadata = new
PropertyMetadata();

metadata.PropertyChangedCallback += OnPropertyWithCallbackChanged;

 

//Registrierung der DependencyProperty

PropertyWithCallback = DependencyProperty.RegisterAttached("PropertyWithCallback",

typeof(int), typeof(Window1), metadata);

 

//Der Callback ruft die eigentliche Initializierungsmethode auf

private
static
void OnPropertyWithCallbackChanged(DependencyObject obj, DependencyPropertyChangedEventArgs value)

{

InitializeProperty();

}