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. 

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!

Windows 8 Store Apps - Education, Industrie und Enterprise

Nach meiner langen Schreibpause soll es endlich wieder Leben im Blog geben und zwar zu einem Thema mit dem ich mich privat und beruflich in letzter Zeit nicht gerade wenig beschäftigt habe - Windows 8 Apps.

Beginnen möchte ich mit der bereits im Windows Store verfügbaren App mit dem großen Namen - Industrial Measurement And Control Engine (zugegeben nicht vor mir aber macht was her). 

Kurz zur Entstehungsgeschichte der App bevor ich auf ein paar technische Details eingehe. Angefangen hat alles mit meiner Diplomarbeit am Institut für Automatisierungstechnik der TU-Dresden, um den trockenem Thema (Untersuchungen zur aspektorientierten Umsetzung von Modell-zu-Text-Transformationen für Benutzungsschnittstellen) mit einem praktischen Zusatz etwas Pepp zu verleihen wurde als Fallstudie eine kleine Windows 8 App generiert. Nach erfolgreich abgeschlossener Arbeit konnte ich meine neuen Brötchengeber Lars und Peggy (HeiReS GmbH) davon überzeugen die App weiter zu entwickeln. Mit der Hilfe und Einwilligung der TU-Dresden wurde aus der einfachen Fallstudie eine vorzeigbare Anwendung die einen Blick darauf zulässt wie zukünftige Systeme zum Bedienen und Beobachten von Industrieanlagen aussehen könnten. Weiterhin dient sie der Technischen Universität Dresden als Lehrobjekt, wodurch die Einstufung im Storebereich Education begründet ist.

Screenshot der generierten App aus der Fallstudie meiner Diplomarbeit

Aus technischer Sicht möchte ich Euch einen groben Überblick darüber geben wie die App Daten mit der Anlage austauscht, auf andere Details wie den Einsatz von Portable Class Libraries und damit verbunden der portablen Version von MVVM Light gehe ich bei Interesse gern in einem späteren Blogpost ein.

Welche Möglichkeiten bietet WinRT uns um mit einer Industriellen Anlage zu kommunizieren?
Nun die Möglichkeiten sind vielfältig, lassen sich aber eingrenzen. So ist eine direkte Anbindung über eine Serielle Kommunikation oder eine Hardware-Erweiterungskarte recht aufwendig, da aus Store Apps heraus nur mit einem extra für die App entwickeltem Treiber auf die Hardware zugegriffen werden kann.
Leichter wird die Sache wenn man über Schnittstellen einer "höheren Ebene" auf die Prozessdaten zugreifen kann. Mit HTTP und TCP Sockets gibt einem WinRT in diesem Bereich viele Möglichkeiten an die Hand. Aber wie kann man diese im Industrieumfeld nutzen? Dazu möchte ich einige recht verbreitete Kommunikationsstandards nennen und kurz darauf eingehen wie man diese auch mit WinRT umsetzt.

• Modbus TCP - der Zugriff ist mit den TCP Sockets grundsätzlich möglich, eine Anbindung aber trotzdem mit etwas Aufwand verbunden, da die Kommunikation selbst implementiert werden muss.

• OPC (DA, A&E, HDA) - Ähnlich wie Modbus TCP ist auch eine Kommunikation mit OPC theoretisch möglich. Hier ist die notwendige Eigenimplementierung aber wesentlich umfangreicher, so dass es günstiger ist einen Gateway zwischen zu schalten (z.B. OPC DA -> OPC XML DA) oder einen eigenen Proxy ( z.B. OPC -> WCF) zu entwickeln.

• OPC XML DA - OPC XML DA ist mit einer Kommunikation über HTTP und der XML-Struktur der Daten sehr gut geeignet um eine Prozesskommunikation für WinRT zu implementieren. Mit OPC XML DA wurden die Prozessdaten in meinen Fallstudien Apps (es waren zwei Apps die mit unterschiedlichen Aspekten generiert wurden) übertragen.

• OPC UA - Bei OPC UA gilt es die einzelnen Versionen zu unterscheiden. Die reine Binary-Ausführung dürfte einiges an Implementierungsaufwand mit sich bringen, dank TCP Sockets aber grundsätzlich möglich sein. Am leichtesten zu implementieren sollte die SOAP Variante sein, so diese denn zur Verfügung steht (was ein festes Vorhandensein im Standard voraussetzt ;) ). Ebenfalls mit überschaubarem Aufwand kann der Hybridmodus implementiert werden, da hier die Daten und Befehle im Binärformat über HTTP übertragen werden. Dies hat auch einen Vorteil bezüglich des bei SOAP (XML) nicht zu unterschätzendem Overhead. 

• Eigene Proxydienste (Stichwort WS*) - Wie bereits unter dem Punkt OPC erwähnt ist es in manchen Situationen sowohl technisch als auch wirtschaftlich von Vorteil eigene Proxydienste zu implementieren. Die Komplexität fällt meist recht gering aus und sie ermöglichen es ,ursprünglich fehlende Funktionalität nachzurüsten. So kommt auch bei der im Store veröffentlichten App ein Proxy-Webservice der Technischen Universität zum Einsatz der sowohl einen Datencache bereitstellt als auch eine Authentifizierung der Nutzer ermöglicht, was bei OPC XML DA leider nicht direkt vorgesehen ist. 

Mit der Kommunikation ist auch schon der mir wichtige Teil an technischem Hintergrund besprochen. Für die Darstellung des Livebilds der Kleinversuchsanlage wird der MJPEG Decoder von Gerg Duncan verwendet (ursprünglich habe ich ihn von Silverlight zu WinRT portiert, mittlerweile gibt es eine fertige WinRT-Version).

Um auch nicht Studenten einen einblick zu gewähren wie die Steuerung der Anlage von statten geht wird eine Simulationsmodus bereitgestellt, mit dem einige Funktionen ohne Zugriff auf die Anlage ausprobiert werden können.

Screenshot der aktuellen Version im Windows Store

Das war noch nicht alles!

Nicht schlecht du hast den Artikel bis hier hin gelesen, das wird belohnt mit einem Ausblick auf kommende Funktionen der Industrie App.

Zu den kommenden Funktionen.

• Eine Funktion welche schon beispielhaft implementiert war, aus Zeitgründen aber vorerst wieder entfernt wurde ist der Semantic Zoom, welcher dazu dienen soll sowohl einen Überblick über eine größere Anlage ( R&I-Fließbildebene) zu ermöglichen als auch spezielle Anlagenteile (wie unsere Tanks) detailliert zu Betrachten und zu Bedienen. 
• Weiterhin wird es für Studenten in den kommenden Semestern umfangreiche Erklärungen zu den einzelnen Funktionen und den dahinter stehenden technischen Grundlagen geben (z.B. zum PI-Regler für die Durchflußregulierung). 
• In unserer UI/UX Abteilung qualmen die Köpfe denn es gibt einige neue Bedienkonzepte die ausprobiert und vorgeführt werden wollen - was eignet sich dafür besser als eine App die genau für diese Demo-Zwecke und den "Blick in die Zukunft" gebaut wurde? 
• Der Simulationsmodus wird wenn die Zeit vorhanden ist auf den vollständigen Funktionsumfang der realen Anlage erweitert. 
• Die Darstellung des Anlagenzustandes (Stichwort Flüssigkeiten in den Rohren) wird besser visualisiert, das bestehende Glasdesign lädt ja gerade dazu ein Flüssigkeiten beim Umpumpen "plätschern" zu lassen.

Es sind noch weitere Ideen vorhanden aber ich kann Euch ja nicht alles verraten, sonst baut ihr noch vor mir die erste große SCADA-Anwendung die auf WinRT basiert und das wäre nicht fair!

Ich freue mich wie immer über Kommentare, Kritik und Verbesserungsvorschläge!
Update - Sorry die Kommentarfunktion war aus einem mir nicht bekannten Grund deaktiviert.