Sonntag, 7. April 2013

STC 2013 Berlin - Zwei Köpfe ein Debugger

Damit Ihr nicht sagen könnt "Hey der Alex von HeiReS war nur am Samstag aus der STC zu faul zum Bloggen" und damit ich das spannenden Thema mit ein paar kurzen Sätzen für mich dokumentiert habe gibt es im Nachgang noch einen Blogpost zu der für mich besten Session der diesjährigen STC (von denen die ich gesehen habe natürlich).

Und das ist die Session die Patric Boscolo zusammen mit Immu Landwerth zum Debuging gehalten hat. Viele Features von Visual Studio kannte ich schon einiges war mir jedoch neu - daher jetzt in Listenform, mache Dinge werden nur genannt, auf andere gehe ich mit ein paar Zeilen Erklärungstext ein.


  • Einen Watch auf eine Variable anpinnen - kann ganz praktisch sein ich nutze ehr das Watch Fenster 

  •  Bei einem Breakpoint nur anhalten, wenn dieser n-Mal erreicht wurde - hilfreich wenn z.B. ab dem 10 Aufruf einer Funktion Probleme auftreten und man keine Zählvariable für einen bedingten Breakpoint zur Hand hat. Ihr könnt eine solche Hit-Bedingung im Kontextmenü angeben, dazu Rechtsklick auf den roten Punkt.


  • Wenn ihr eine Ausgabe von aktuellen werten braucht aber der Code nicht von Euch stammt und ihr kein Console.WriteLine(xyz) einfügen könnt (Ich würde Debug.WriteLine nehmen aber dazu später), dann hilft der Eintrag When Hit... weiter. Hier könnt ihr mit einer etwas eigensinnigen Syntax Ausgaben hinzufügen, die unter anderem auch die Thread Id enthalten können. Aber Achtung diese Geschichte ist nicht die schnellste und sollte wenn der Breakpoint oft getroffen wird und nicht alle ausgaben notwendig sind mit einer Bedingung kombiniert werden. 
  • Im Menü unter Debug -> Windows findet man das Immediate Window - hier kann man scripting mäßig Codezeilen hineinschreiben und bekommt direkt eine entsprechende Ausgabe. Was leider nicht möglich ist sind Lambda Ausdrücke. 

  • Die meisten von euch werden debug-visualizer schon kennen, zum Beispiel wenn man sich den Wert eines Strings anzeigen lässt hat man die Möglichkeit unterschidliche Anzeigeformen wie XML oder HTML zu wählen. Neu ist, dass man solche Visualizer jetzt auch mit managed Code selbst schreiben kann. Natürlich gibt es auch schon zahlreiche Visualizer fertig zum installieren - die Suchmaschine deines Vertrauens hilft hier weiter. 

  • Eine weitere Kleinigkeit die durchaus hilfreiche seien kann ist das verursachen eines Ausführungsstopps mit einem Methodenaufruf ohne einen Breakpoint zu setzen mit - System.Diagnostics.Debugger.Break();


So das war der erste Teil zur Debugging Session, Teil 2 folgt in den kommenden Tagen. 

Freitag, 5. April 2013

STC 2013 Berlin - Be lazy with Roslyn

Michael Kokonowskyj erzählt etwas über Roslyn was in Richtung Productivity Tools geht.

Daher kommt auch zu Beginn eine Frage wer Tools wie ReSharper und die Power Productivity Tools einsetzt.

Michael geht darauf ein, dass wir als Entwickler nicht unbedingt Fleißarbeit leisten sollten sondern uns Tools zu nutze machen sollen oder uns Tools bauen sollen.

Die Agenda des Vortrags soll abdecken was hinter Roslyn steht und wie man es sowohl innerhalb als auch außerhalb von Visual Studio einsetzen kann.

Roslyn ist ein "Compiler as a Service" - daher erklärt Michael erst einmal was im grunde ein Compiler ist .. Code rein --> Assembly raus :)

Roslyn kann eingeteilt werden in die Compiler Pipline, eine Compiler API und in Language Services.

Language Services sind z.B. für Codehighlighting zuständig.



Bei Roslyn baut Microsoft aus dem Code einen Syntax Tree auf, der schon bei ein paar Zeilen Code recht komplex werden kann.

Nach den ersten Folien zeigt Michael nun eine Anwendung die mit dem Roslyn SDK mit installiert wird und in der sich alle notwendigen Informationen finden lassen. Unter anderem ein nettes Sample bei dem ich C# Code kopieren und über das Menü als VB Code in eine VB Datei wieder einfügen kann.

Nach diesem Sample wird ein - wie ich finde - sehr cooles VS Plugin gezeigt, den Roslyn Syntax Visualizer, der den aktuell angezeigten Sourcecode farbig als Syntax Tree darstellt.

Nach diesem kurzem Überblick geht es jetzt über zu einem Getting Started.

Es gibt zwei Analyse Roslyn Templates Code Issue und Code Refactoring - Issue kann z.B. helfen Methoden zu analysieren, mit Refactoring kann man Tools bauen um z.B. einen Codeblock zu einer Methode zu extrahieren.

Outliner Projecte könnten herangezogen werden um die Highlight-Farbe von bestimmten Codeelementen zu ändern.

Es folgt eine Demoproject zu Code Issues - es ist wohl ein Teil eines real Produkts - vielleicht gibt es den Quellcode trotzdem später online.
Im Beispiel wird gezeigt wie ich zu einer Methode ein neues Attribut hinzufügen kann - für eine einzelne Methode sicher langweilig, wenn ich das vielen Methoden Automatische machen kann spart es schon einiges an Zeit.
Beim editieren des Codes kommt zur Nutzung unserer Extension eine kleine Glühbirne - wie beim ReSharper.

Weitere Einsatzgebiete von Roslyn sind Scripting Engines und die code Generierung (mit Analyse etc.).

Auch hierfür wird jetzt ein kleines Beispiel gezeigt - ein Formelinterpreter.



Nachteile von Roslyn - es ist wohl schlecht dokumentiert und fühlt sich unrund an und es ist noch eine CTP sprich die Schnittstellen ändern sich und wenn man es schon produktiv einsetzt muss man ordentlich "hineterherrefactoren".

Ich hab jetzt leider einen anderen Termin und hoffe die Folien sind später online - bis hierhin war es sehr spannend und lehrreich! Danke Michael.



STC 2013 Berlin - Patric forscht - Sensoren und Windows 8

Die zweite Session(neben der Keynote) die ich bei der STC 2013 besuche ist von Patric Boscolo zum Thema Sensoren und Co bei Modilen Endgeräten.

Die größten Wachstumsmärkte für mobile Geräte sollen Education & Healthcare sein.

Patric spricht im allgemeinen über Interoperability - bsp. Der Toaster der das Wetter ins Toast brennt.

Jetzt geht es los mit Sensoren bei Windows 8 -
Die erste App besteht aus einem Button und einem Image in einer Blankpage Application.



Im Codebehind der Mainpage erstellt sich Patric einen CameraCaptureUI, holt sich eine StorageFile mit dem  aufgenommenem Bild und setzt es als Source für das angelegte Image. Natürlich geht er noch kurz auf die notwendigen Capabilities ein die in der Appxmanifest angefordert werden müssen.

Und da geht es auch gleich mit der zweiten Demo weiter - GeolocationCenter - Es gibt einen Start und Stop Button mit denen ein Tracking gestartet werden soll.
Dazu wird im Code ein Geolocator angelegt und eine Eventhandler auf OnPositionChanged registriert.
Innerhalb des Eventhandlers wird mit Dispatcher.RunAsync die eigentliche Arbeit verrichtet. Aus einer Geolocation wird eine Bing.Maps.Location erstellt und die Kartenposition auf den aktuellen Standort gesetzt und ein Pin zu den LocationItems hinzugefügt.



In einem wahnsinnigen Tempo fliegt der Patric durch die Demos, es wird um den Beschleunigungssensor gehen denn die Solution nennt sich AcceleometerDemo.  In dieser App gibt es einen Ball auf einem grünem Rasenhintergrund, der anhand der Lage des Tablets gesteuert (bewegt) wird.
Die App besteht grafisch aus zwei Image Containern, dem Ball und dem Hintergrund.
Die Gameloop baut Patric auf dem CompositionTarget.Rendering-Event auf. Im Eventhandler folgt ein bissen Mathematik die Bewegung mit etwas Beschleunigung etc zu versehen - dann wird die Position des Ball.Images neu gesetzt.


Jetzt geht es kurz darum wie man Innovation mit vertretbaren Kosten ermöglich.
Stichworte sind hier Proof of concepts und Rapid Prototyping, bei dem das .NET Gadgeteer-System  ansetzt. Das ganze basiert aus fem .NET Microframework Version 4.2 und bietet neben den Kernfunktionalitäten von .NET (CLR mit Garbagecollection etc.) auch aufbauende Bibliotheken die einem das leben leichter machen.
Was Patric nicht explizit hervorhebt ist die geniale Toolunterstützung mit der ihr hier Hardware entwickeln könnt. Es gibt ein Live debugger, es gibt das VisualStudio mit Intellisens und all den tollen Sachen an die wir uns so sehr gewöhnt haben.
Nun wird mit dem Gadgeteer und einem freundlichem Helfer an der Kamera das Project zu Heidi aufgebaut.



MositureSensor, Tocuscreen, GSM-Modul werden mit dem Basis Gadgeteer-Modul verbunden und dann geht es wieder ab in den Code.

Im Code wird das GSM-Modul mit Strom versorgt und und verbindet sich zum Mobilfunkprovider.
Danach wird in einer Endlosschleife mit dem Moisture-Sensor geprüft ob Heidi (Zimmerpflanze) noch genügen Wasser zum leben hat. Wenn dem nicht so ist wird eine SMS-versendet in der Heidi um Hilfe ruft.



Die Funktionalität zeigt und Patric natürlich live und versorgt Heidi aus der Wasserflasche. Idee aus dem Raum - das ins Bierglas einbauen um automatisch "Nachschub" zu bestellen.

Woha eine Stunde voller Demos und cooler Showcases - Danke Patric!

Den Sourcecode und die Folien gibt es unter:
http://blogs.msdn.com/b/patricb/archive/2013/04/02/internet-of-things-spa-223-mit-sensoren.aspx

Am Freitag dem 12.April soll Heidi im Rahmen von AnyKey online gehen.


STC 2013 Berlin - Modelltransformation mit .NET

Heute bin ich auf der Student Technologie Conference 2013 in Berlin und versuche mich mal an kurzem Liveblogging.

Die erste Session die ich besuche ist von Georg Hinkel zum Thema Modelltransformationen (M2M) mit .NET



Nach einer kurzen Einführung was Modelle, Metamodell und Modelltransformationen sind geht es los mit NMF. 

NMF Trnasformations bezieht sich dabei auf Modellltransformationen und stellt eine Bibliothek für Regelbasierte M2M Transformationen dar. 

Die Bibliothek ist in C# implementiert und ermöglicht es damit die Transformationsregeln in jeder beliebigen Sprache auf CLR-basis zu schreiben. 

Was bedeutet es Transformationen in C# zu schreiben? 
 - Volle IDE unterstützung 
 - Modularisierung wird unterstützt
 - Geringerer Lernaufwand 
 - Bessere Integration in bestehende Ecosysteme. 

Für mich persönlich sind die beiden letzten Punkte von besonderer Bedeutung  denn die etablierten Werkzeuge in der Modeltransformation finden sich im Java- und Eclipse-Umfeld.

Jetzt führt Georg ein Beispiel ein und zeigt uns ein Metamodell zu einem endlichen Zustandsautomaten und einem Petrinetz - das ganze scheint begründet mit seiner aktuellem Forschungsdomäne in Kooperation mit ABB. 



Die Transformation soll dann vom Zustandsautomaten hin zum Petrinetz führen. 



Nach der Vorstellung des Beispiels gibt es jetzt Code-Insight zu NMF. 

Eine Transformation wird bei NMF durch eine klasse repräsentiert, für das Beispiel erstellt Georg eine Klasse welche von ReflectiveTransformation erbt. 

In diese Klasse wird eine weitere Klasse eingebettet welche von einer SimpleTransformationRule<FiniteStateMachine> abgeleitet wird, in der nur eine Methode (Transform) überschrieben wird, diese Methode hat drei Parameter - Input, Output und einen Transformationskontext, wobei Input und Output unsere Modelle darstellen.

Mit einer zweiten Klasse soll ein Zustand der Statemachine in einen Platz des Petrinetzes transformiert werden. 

Beim Ausführen der Transformation startet eine Konsolenanwendung und gibt einen kurzen Statusbericht welche Elemente wie umgewandelt wurden.

Es geht weiter mit Requrements die für einen Transformationsreglen (Klassen) definierte werden können.

Ich schreibe jetzt hier nicht weiter über den Code des Beispiels, sondern hoffe, dass Georg diesen im Anschluss bereitstellt. - Update: Das gezeigte Beispiel ist auch Teil der mit NMF ausgelieferten Bespiele oder zumindest online verfügbar - In der Nachbereitung werden ich dann auch einen Link hier einstellen.

In der aktuellen Version von NMF gibt es noch kleine Schwierigkeiten beim Intellisens (etwas größere mit dem ReSharper) - aber ein Update was hier Hilfe verschafft soll bald folgen.

Mit Hilfe des Transformationskontext der überschriebenen "Transform"-Methode lässt sich z.B. bei einer Transition feststellen von welchem Zustand ich komme und zu welchem Zustand die Transition führt.

Ein Vorteil den Georg nennt ist die gute Lesbarkeit und Übersicht über den Code - für mich ist das gerade alles zu neu um das entsprechend abschätzen zu können, die Beispieltransformationen waren aber sehr gut verständlich.

So nach dem Beispiel folgt nun eine kleine Zusammenfassung:
Wir haben eine bestehende Sprache mit starker Toolunterstützung und einen funktionierenden Debugger. Gerade das Debuggen von Transformationen kann beim EMF doch sehr anstrengend werden.

Durch die Basis des .NET Frameworks ist es möglich bestehende Bibliotheken innerhalb der Transformationsregeln zu verwenden.

NMF Transformationen arbeiten bisher nur mit "InMemoryModellen" und erzeugt am Ende Objekte - was wir mit diesen Objekten machen ist natürlich vollkommen offen wir könnten sie im XMI Format serialisieren.

Damit ist der sehr informative Vortrag beendet -Danke Georg!