Montag, 16. Mai 2011

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:

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.

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

Evtl. gibt es auch hier die CTP3

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

Freitag, 22. Oktober 2010

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!

Mittwoch, 6. Oktober 2010

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:

untitled

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.

Freitag, 16. April 2010

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.


 


 


 

Mittwoch, 3. März 2010

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!

Mittwoch, 24. Februar 2010

Cassidy Marie shipped


Beta


Release Candidate


Cassidy Marie shipped

Die glücklichen und schlaflosen Eltern
Marika und Benjamin Gopp

Freitag, 12. Februar 2010

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