Aus der Praxis: Von der Spezifikation bis zur Auslieferung in 6 Wochen

Kommt ein Kunde zum Dienstleister und sagt: „Wir hätte gerne eine völlig neue Anwendung von Ihnen entwickelt. Den Großteil der Funktionalität haben wir schon detailliert beschrieben. Ein paar Dinge sind noch unklar. Außerdem haben wir noch ein paar Ideen, die bislang noch nicht im Konzept enthalten sind. Wie die UI aussehen soll, wissen wir zwar noch nicht – aber wir haben ein UX-Team, das mit Ihnen die UI abstimmen würde. Wenn wir dann noch UX-Tests mit einer Testgruppe machen und die Anwendung am Ende auch mit UI-Tests automatisiert auf neun unterschiedlichen Betriebssystemen von Ihnen getestet haben möchten, ist das doch sicher in sechs Wochen fertig – oder?“

Was sich im ersten Moment ganz lustig anhört, ist in der Praxis von IT-Dienstleistern oft Realität. Wir werden in dieser Session gemeinsam einen Blick auf das Projektvorgehen, die Software-Architektur und -Entwicklung sowie die QS-Maßnahmen werfen: All das was uns ermöglicht hat, in enger Zusammenarbeit mit dem Kunden am Ende dieser sechs Wochen ein fertiges Produkt auszuliefern! Vom Ergebnis können Sie sich selbst ein Bild machen: Den E-POST MAILER der Deutschen Post finden Sie unter www.epost.de.

Foliensatz zum Vortrag: Kommt in Kürze...

Child Process Debugging Power Tool für Visual Studio 2013.2

Schon seit einiger Zeit gab es seitens der Entwickler den Wunsch, dass Unterprozesse die vom Hauptprozess erzeugt wurden automatisch von Visual Studio an den Debugger angehängt werden, um hier ebenfalls eine einfache Fehleranalyse durchführen zu können. Vor fast zwei Jahren wurde der Wunsch dann auch bei UserVoice eingereicht, und jetzt wurde er tatsächlich umgesetzt. :-)

In der Visual Studio Galerie gibt es jetzt den Child Process Debugging Power Tool zum Herunterladen. Voraussetzung ist hierfür mindestens Visual Studio 2013 mit installiertem Update 2 oder höher (inkl. der aktuellen Beta von Visual Studio 2015). Außerdem wird der native Debugger bei der Ausführung benötigt, den man zum Debuggen von .NET Code in der Regel erst in den Projekteigenschaften aktivieren muss:

[caption id="attachment_7189" align="aligncenter" width="723"]Project Settings > Debug > Application process > Mixed (Managed and Native) Mixed-Debugger für managed und native Code aktivieren[/caption]

Möchte man nun das automatische Child Debugging aktivieren, verwendet man nach der Installation des Plug-Ins den neuen Menüeintrag unter Debug und aktiviert im sich öffnenden Reiter die entsprechende Option. Klickt man anschließend auf speichern ist das Debuggen für alle neuen Sub-Prozesse automatisch aktiviert.

[caption id="attachment_7187" align="aligncenter" width="628"]Debug > Other Debug Targets > Child Process Debugging Setting... Schritt 1: Öffnen der Debugger-Einstellungen[/caption]

[caption id="attachment_7188" align="aligncenter" width="603"]Enable child process debugging Schritt 2: Das Child Process Debugging für alle Prozesse aktivieren[/caption]

In den Einstellung hat man außerdem auch noch weitere Möglichkeiten der Konfiguration. Statt beispielsweise den gleichen Debugger wie für den Haupt-Prozess zu verwenden, kann man hier auch einen bestimmten fest einstellen (Managed oder Native). Auch können anhand der Prozessnamen weitere Ausnahmen definiert werden um beispielsweise einzelne Prozesse gezielt vom Debuggen auszuschließen, oder umgekehrt den Debugger nur an bestimmte Prozesse automatisch anzuhängen:

2671_clip_image006_thumb_048342FC

Mit den Persist settings to-Einstellungen kann man außerdem noch einstellen, wie die Konfiguration gespeichert wird. Standard ist hier die SUO-Datei der Solution, alternativ kann man sie aber auch als XML-Datei exportieren um sie so bsp. in die Versionsverwaltung zu integrieren und anderen Kollegen zugänglich zu machen ohne die eigenen User-Options zu teilen.

Das Plug-In wird nicht offiziell von Microsoft unterstützt, Feedback könnt ihr jedoch in den Kommentaren des Original-Artikels hinterlassen, oder mit Hilfe des Send a Smile Features direkt innerhalb von Visual Studio.

Übrigens: Wenn ihr bisher nur die Express-Version von Visual Studio verwendet hat, die keine Plug-In Unterstützung bietet, kann übrigens ab sofort auf die neue Edition Visual Studio Community 2013 zurückgreifen. Einfach gesagt erhalten hiermit Open-Source Entwickler und Teams bis 5 Personen kostenlos eine im Umfang dem Visual Studio Professional entsprechende Entwicklungsumgebung; und somit auch unter anderem Unterstützung für Plug-Ins. Die neue Community-Edition wird in Zukunft damit die bisherigen Express-Versionen von Visual Studio ablösen.

XAML Behavior for playing only one sound-clip simultaneously

Sound-listeningI'm working on a Universal App for Windows and Windows Phone 8.1 where you have a list of available sounds. Each entry has a preview button to listen to that sound before adding it to your project. So there were quite a few challenges:

  • those entries are coming from a binding
  • using the MVVM pattern I don't want to use code-behind or other dirty tricks
  • the preview button should have a "play" icon on idle, and a "stop" icon while it's associated sound is playing
  • when pressing the button a second time while the sound is playing, it should stop
  • there should be only one sound playing simultaneously, starting a new one should stop the previously playing
There are a few approaches that didn't worked as expected. For example I saved the currently playing sound in a ViewModel-Property and informed all preview-buttons when it changed so each one decided what icon to display or if they should start/stop playing their sound.

My final solution now works quite well and is also flexible enough for similiar scenarios, so I want to share it with you. I created an Action, containing most of the logic. It is executed in my case by the EventTriggerBehavior from Microsofts Xaml.Interactions.Core Namespace.

You can get the sourcecode of my SoundPreviewAction here: Download SoundPreviewAction.cs

Example how to use it:

// xmlns:interactivity="using:Microsoft.Xaml.Interactivity"
// xmlns:core="using:Microsoft.Xaml.Interactions.Core"

<Button Content="&#xE102;" FontFamily="Segoe UI Symbol" FontSize="22" BorderThickness="0">
  <interactivity:Interaction.Behaviors>
    <core:EventTriggerBehavior EventName="Click">
      <utilities:SoundPreviewAction Source="{Binding Filename}" PlayContent="&#xE102;" StopContent="&#xE15B;" Volume="0.8" />     </core:EventTriggerBehavior>
  </interactivity:Interaction.Behaviors>
</Button>

Screenshots der eigenen Windows Phone App verhindern

Cannot capture protected ContentEs kann Situationen geben, in denen man gerne verhindern möchte, dass der Benutzer der eigenen App einen Screenshot (Lautstärke hoch + Ein-/Aus-Button kurz drücken) erstellen kann. Sei es während der Darstellung von internen Zahlen / Daten im Enterprise-Umfeld, oder auch bei einer App wie Snapchat.

[appbox windowsphone 82fa6341-28dc-4203-bd08-9749b167bc4b]

Es gibt ein API mit dem genau das verhindert werden kann, sowohl für die Silverlight 8.0 Apps (ab GDR 1) als auch für die WinPRT-Apps. Wenn der Benutzer dann versucht einen Screenshot anzufertigen erhält er die Meldung angezeigt, dass das bei geschützten Inhalten nicht funktioniert. Jedoch ist in der Silverlight-API die entsprechende Eigenschaft versteckt und deshalb nur über Umwege erreichbar.

Windows Phone 8.1 WinPRT-App:

Windows.UI.ViewManagement.ApplicationView.GetForCurrentView().IsScreenCaptureEnabled = false;
Windows Phone 8.1 Silverlight-App:
public static void SetScreenCaptureEnabled(this Microsoft.Phone.Controls.PhoneApplicationPage page, bool enabled)
{
    var propertyInfo =
        typeof (Microsoft.Phone.Controls.PhoneApplicationPage).GetProperty("IsScreenCaptureEnabled");
 
    if (propertyInfo != null)
    {
        propertyInfo.SetValue(page, enabled);
    }
}
Eine schöne Lösung als Attached-Property gibt es auch auf GitHub in den XamlEssentials.

Das jemand sich Daten abschreibt oder auch mit einer Kamera vom Display abfotografiert, kann man so natürlich trotzdem nicht verhindern.

Windows 10 Technical Preview: Don't call it Beta-Schnitzel!

Windows 10Das lange Warten auf die Preview der neuen Windows-Version hatte am Dienstag endlich ein Ende, und auch das Rätselraten um den Namen dieser neuen Version: Windows 10 soll es also jetzt heißen, und erscheinen wird es Mitte / Ende 2015. Also vermutlich wieder im Herbst. Wie immer. Warum also jetzt schon eine so unfertige Version veröffentlichen? Wir reden hier nicht von einer Beta und meiner Meinung nach noch nicht mal von einer Alpha-Version. Das, was man derzeit im Rahmen des Insider-Programms herunterladen und installieren kann ist kaum mehr als ein Prototyp, ein Durchstich der einige ganz wenige ausgesuchte neue Funktionen demonstriert. Und schon hört man überall Stimmen, was denn alles schlechter geworden ist, was alles nicht funktioniert und wie unausgereift und unfertig das doch noch alles ist.

Dass das alles provokant ist, die Leute anstacheln und für viele "Klicks" sorgen soll, ist mir bewusst. Microsoft hat es nicht nur ein- oder zweimal ganz nebenbei erwähnt, dass man hier eine "Technical Preview" hat, die bisher nur ein halbes Dutzend ganz gezielt rausgesuchter neuer Features enthält die der User jetzt erst mal testen und bewerten soll - während man am nächsten Schwung von Funktionen arbeitet. Und das alle Journalisten und "Experten" da einfach immer zufällig nicht zuhörten oder entsprechendes auf den Websites überlesen haben, kann ich mir auch nicht vorstellen. Gerade deshalb finde ich diese Art von Berichten auch extrem unseriös. Hier wird ein Produkt schon zerfleddert und schlecht geredet, obwohl mal nur einen Bruchteil von dem gesehen hat was im Laufe des kommenden Jahres noch entstehen wird.

Agile Entwicklungs-Prozesse sind derzeit "in", und werden auch oft von Kunden angefragt, da ja damit immer alles besser wird. Dabei wird oft vergessen, dass ein agiler Prozess wie SCRUM auch zum Rest des Unternehmens und der Organisationsstruktur passen muss in dem es eingesetzt wird. Und es ist auch nicht alles immer besser: Das die Entwicklung transparent ist, wird oft als Vorteil genannt. Man weiß ja immer wo man steht. Aber gerade in der Anfangsphase ist die Transparenz auch ein nicht zu unterschätzendes Risiko, vor allem wenn man mit agilen Prozessen noch wenig Erfahrung hat. Denn gerade in der Anfangsphase geht alles noch langsam vorwärts, Architekturen und andere Voraussetzungen müssen erst geschaffen werden ohne das man davon nach außen hin viel sieht.

Microsoft hat bei der agilen Produktentwicklung schon einige Erfahrung gemacht. Nach außen sichtbar wird das beispielsweise bei Visual Studio Online, welches auf den Funktionen von Team Foundation Server mit zusätzlichen Clouddiensten basiert. Hier wird regelmäßig der live Online-Service am Ende der internen Sprints aktualisiert und mit neuen Funktionen oder Bugfixes versorgt. So ist am 23. September beispielsweise der Sprint 71 online gegangen. Ein großer Vorteil bei der agilen Entwicklung ist dabei unbestreitbar: Das Ergebnis ist in der Regel deutlich näher an dem dran, was der Kunde tatsächlich möchte und braucht, da man oft einen Einblick auf den aktuellen Stand des Produktes erhält und hier sofort korrigieren kann wenn etwas doch nicht so geworden ist wie man dachte.

Und genau das versucht Microsoft jetzt anscheinend auch mit der kommenden Windows-Version. Meiner Meinung nach sollten wir uns als eine Art Product Owner in dem Entwicklungs-Prozess sehen: Das Team hat gewisse neue Features in seinem Backlog und arbeitet daran in Sprints. Am Ende eines Sprints präsentiert es uns diese - explizit genannten - dann im Rahmen eines Reviews. In der Praxis wird es wohl so aussehen, dass wir die Ergebnisse in Form von Updates aufgespielt bekommen. Unsere Aufgabe ist es jetzt, diese gerade fertig gestellten Features zu begutachten und unser Feedback zurück ans Team zu geben. Was gut geworden ist bekommt einen Haken, was uns nicht gefällt landet zur erneuten Bearbeitung wieder im Backlog. Wir sind also nicht mehr länger nur Tester im Rahmen eines Abnahme- oder Integrationstests (= BETA), sondern wir arbeiten von Anfang an eng mit den Entwicklern zusammen und steuern das Endergebnis somit maßgeblich.

Natürlich sind wir nicht wirklich die Product Owner und wir werden auch vermutlich nicht nach jedem Sprint das Ergebnis vorgesetzt bekommen. Aber mir gefällt die Analogie und das Bild, dass man sich damit vorstellen kann. Denn das macht es sehr deutlich, wie wir die aktuelle (und künftige) Version von Windows 10 einzuordnen haben und was für eine Rolle uns eigentlich zufällt wenn wir uns entschließen sie zu installieren und zu testen. Darüber herziehen und aufmerksamkeitssüchtig darüber mit fragwürdigen Artikeln berichten jedenfalls nicht.

Just my 2 cent :-)

CompiledQueries – Die Pegasus-Stiefel für LINQ

Der nachfolgende Artikel wurde vor zwei Jahren in der Visual Studio One veröffentlicht und ich habe zum Thema auch schon ein paar Vorträge gehalten. Da ich neulich erneut darauf angesprochen wurde, habe ich mich für eine Veröffentlichung hier im Blog entschlossen.

Mit der Einführung der Language Integrated Queries (kurz: LINQ) vor einigen Jahren hat Microsoft das .NET-Framework um eine universelle Abfragesprache für alle nur denkbaren Datenquellen bereichert. Zwar konnte man alles, was LINQ kann auch schon vorher – irgendwie – realisieren, aber jetzt ist es deutlich kompakter und gleichzeitig lesbarer geworden. Doch wo Licht ist, da ist auch Schatten: Vor allem bei der Verwendung von LINQ mit dem Entity Framework oder auch mit LINQ2SQL machen sich einige Probleme mit der Performance bemerkbar.

Woher der Engpass?

Um die Performance zu erhöhen muss zunächst geklärt werden, wo der Engpass entsteht. Dafür ist es notwendig, einen Blick unter die Motorhaube zu werfen und sich mit der Funktionsweise von LINQ in Verbindung mit dem Entity Framework auseinander zu setzen. Zunächst einmal werden die LINQ-Abfragen in Lambda-Ausdrücke umgewandelt, und diese werden wiederum als so genannte Ausdrucksbäume (engl: Expression-Trees) interpretiert. Erst als letzter Schritt wird hieraus dann beispielsweise eine SQL-Anweisung erzeugt und an die Datenbank geschickt. Diese Umwandlungen müssen bei jedem Aufruf der LINQ-Abfrage erneut durchgeführt werden, was schließlich zu dem beschriebenen Geschwindigkeitsproblemen führt.

Es geht auch schneller

Immer wenn Vorgänge unnötig oft wiederholt werden müssen, sollte ein Entwickler hellhörig werden. Wenn man in einer Schleife beispielsweise 10.000 LINQ-Abfragen gegen eine Datenbank schreibt, dann verändert sich das Query jedes Mal nur minimal. Dennoch muss die komplette Umwandlung bei jedem Durchlauf erneut vorgenommen werden. Wesentlich effizienter wäre es also, wenn man die LINQ-Abfrage nur einmal in die entsprechende SQL-Abfrage umwandelt, und dann in jeder Iteration nur noch den variablen Teil beispielsweise des WHERE-Schlüsselwortes anpasst. Die Klasse, die uns genau das im .NET-Framework seit Version 3.5 ermöglicht, heißt CompiledQuery und findet sich im Namensraum System.Data.Linq. Hier heißt die statische und einzige wirklich benötigte Methode Compile<TArg0, …, TResult>(Expression<Func<TArg0, …, TResult>>).

Der erste Parameter ist der Objekt-Kontext für den Datenzugriff, bsp.vomEntity Framework oder von LINQ2SQL. Der letzte übergebene Parameter ist der Typ des Rückgabewertes. Alle weiteren Parameter dazwischen sind optional und können zum Beispiel innerhalb einer where-Abfrage verwendet werden. In Version 3.5 des .NET-Frameworks und in der Silverlight-Untermenge stehen hier noch bis zu drei weitere Parameter als überladene Methode zur Verfügung. Wenn man mehr benötigt, muss man auf eine einfache Helferklasse zurückgreifen, in der man zusätzliche Eigenschaften vorhält. Mit Version 4.0 des .NET-Frameworks hat sich die Anzahl der Überladungen deutlich erhöht, so dass nun sogar bis zu 15 weitere Parameter möglich sind.

Achtung: Statisch!

Ein häufiger Fehler beim Verwenden der vorkompilierten Abfragen ist die Verwendung analog zu den „einfachen“ Abfragen in einem instanziiertem Kontext. Der erste Aufruf eines Compiled Query dauert ein wenig länger als der direkte Aufruf, da der kompilierte Ausdruck erst noch zwischengespeichert wird. Verwendet man dies nun in einer nicht-statischen Klasse, kann der Vorteil des Zwischenspeicherns nicht greifen und die Abfragezeit verlängert sich dadurch sogar noch. Es empfiehlt sich deshalb, für die CompiledQueries eine eigene, statische Klasse anzulegen und hier die Abfragen als ebenso statische Delegaten.
public static class Queries {
    public static Func<DataContext, id, IQueryable<Personen>> PersonGeworbenVonId =
        CompiledQuery.Compile<DataContext, id, IQueryable<Personen>>(
        (dc, id) => from person in dc.Mitarbeiter
        where person.ReferrerId == id
        select person
    );
}
Der eigentliche Aufruf erfolgt dann über diese statische Klasse und der Übergabe aller benötigten Parameter:
var db = newMyDataContext();
for (inti = 0; i < 20; i++) {
List<Personen> result = Queries.PersonGeworbenVonId(db, i).ToList();
/* ... arbeite hier mit result ... */
}
Beim ersten Durchlauf der Schleife wird unsere LINQ-Abfrage intern in sein entsprechendes SQL-Pendant umgewandelt und dieses anschließend als Funktion zwischengespeichert. Da der statische Kontext bis zur Beendigung der Anwendung (bei Websites bis zum Recyclen des App-Pools) erhalten bleibt, ist eine erneute Kompilierung des gleichen Queries danach nicht mehr notwendig. Für die folgenden 19 Durchläufe unserer Schleife ist die Verarbeitungsgeschwindigkeit also deutlich höher und kommt an die von der direkten Verwendung einer Abfrage mittels ADO.NET heran.

 

[caption id="attachment_7146" align="aligncenter" width="606"]CpmpiledQueries - Geschwindigkeitsvergleich Abfragen von 3.000 Datensätzen aus einer Datenbank mit und ohne CompiledQueries[/caption]

Einschränkungen

Die größte Besonderheit des CompiledQuery ist sicherlich, dass man als Ergebnis eines Methodenaufrufes keinen Wert zurück bekommt sondern eine weitere Methode. Dem einen oder anderen ist diese Funktionsweise vielleicht auch schon aus Sprachen wie F# bekannt, im Umfeld von C# und VB.NET ist es jedoch eher selten zu sehen.

Das CompiledQuery sollte man jedoch nicht als Universalmittel verstehen. LINQ-Abfragen, die nur selten aufgerufen werden, profitieren nur wenig hiervon. Da der erste Aufruf länger dauert ist die Verwendung bei einmaligen Abfragen sogar kontraproduktiv. Auch relativieren die CompiledQueries die bessere Lesbarkeit von LINQ-Ausdrücken wieder, da man nun nur noch Aufrufe der statischen Queries-Klasse sieht. Erst wenn man die Definition des verwendeten Delegaten nachschlägt sieht man wieder den eigentlichen Abfrageausdruck. Da alle kompilierten Abfragen als statische Klasse zwischengespeichert werden, verbraucht die Anwendung natürlich auch mehr Arbeitsspeicher. Hier muss man also abwägen, ob der erreichbare Geschwindigkeitsvorteil groß genug ist, um dies in Kauf zu nehmen.

Der höhere Arbeitsspeicherverbrauch lässt sich am ehesten vermeiden, indem man aufwändige SQL-Abfragen direkt im Datenbankserver als Stored-Procedure abspeichert.Die CompiledQueries bieten sich aber immer dann an, wenn das Anlegen von Stored-Procedures im SQL-Server entweder nicht möglich oder auch nicht gewünscht ist, da mit ihnen die Anwendungslogik an völlig unterschiedlichen Stellen gepflegt werden muss. Kombinieren lassen sich beide Verfahren übrigens nicht: Der Aufruf einer Stored-Procedure innerhalb eines CompiledQueries führt zu einer Fehlermeldung.

Da die kompilierte Abfrage zwischengespeichert wird, muss man für alle weiteren Abfragen auf denselben Delegaten natürlich auch immer denselben Data-Kontext verwenden. Wird hier ein anderer Kontext übergeben, erhält man eine Fehlermeldung aufgrund der veränderten Instanz. Auch erhält man nach Aufruf des CompiledQueries ein one-time Enumerable zurück, da der Data-Kontext danach nicht länger zur Verfügung steht. Selbst das Verwenden der Count()-Methode sorgt in diesem Fall schon dafür, dass der nächste Aufruf fehlschlägt. Um das Problem zu umgehen empfiehlt es sich wie im obigen Beispiel angedeutet direkt nach dem Aufruf die ToList()-Methode auf das Ergebnis anzuwenden.

Uhrzeit unter Windows Phone automatisch einstellen? Besser Finger weg.

[caption id="attachment_7140" align="alignleft" width="150"]Windows Phone - Einstellungen - Datum und Uhrzeit Windows Phone - Einstellungen - Datum und Uhrzeit[/caption]

Mancher hat in den Datum- und Uhrzeit-Einstellungen von Windows Phone schon mal die Option "Automatisch einstellen" gesehen, und sich gefragt ob - bzw. wie - die überhaupt funktioniert. Denn viele sehen die genannte Option entweder gar nicht (muss explizit in der Firmware vor Auslieferung aktiviert werden) oder sie bewirkt anscheinend nichts.

Dahinter steckt eine bereits seit 1996 in unserem Mobilfunk-Standard "GSM" vorgesehene, jedoch nur optionale, Funktion zum Übertragen von Datums-/Zeitangaben und Provider-Informationen. Technisch basiert das auf dem so genannten "Network Identity and Timezone"-Mechanismus (kurz: NITZ). Hier in Deutschland wird der jedoch nur von O2 als Provider verwendet um die Zeit-Informationen bereit zu stellen. Interessanterweise macht bsp. T-Mobile das auch, jedoch in Polen und nicht in Deutschland.

Hat man die genannte Option in den Einstellungen seines Smartphones und aktiviert sie obwohl der eigene Provider sie nicht unterstützt, passiert allerdings auch nichts dramatisches. Genauer gesagt es passiert gar nichts. Naja, schon: Windows Phone blendet jetzt die Möglichkeiten Datum und Uhrzeit manuell einzustellen aus. Eigentlich ja auch logisch. Aber wenn vom Provider keine Zeitdaten kommen, wird das halt auch nie korrigiert und es gibt auch keine Hinweismeldung. Doch selbst wenn der Provider eine Aktualisierung unterstützt: Die Genauigkeit liegt bei NITZ im Bereich von Minuten.

Obwohl unter Windows Phone derzeit alternative Verfahren zum automatischen Stellen der Uhrzeit (bsp. über den eingebauten GPS-Empfänger oder mit Hilfe von Internet-Zeitservern über NTP) nicht verfügbar sind, erreicht man also oft eine wesentlich genauere Einstellung durch das manuelle Stellen. Auch das erfolgt "nur" minutengenau, aber mit einer entsprechend genauen Uhr daneben und dem gezielten Speichern zur "vollen Minute" erreicht man trotzdem eine höhere Genauigkeit als es mit NITZ über GSM möglich wäre. Also "Finger weg" von der "Automatisch einstellen"-Option und hoffen, dass Microsoft bald entweder selbst die Unterstützung für Internet-Zeitserver nachliefert, oder aber eine API zum Setzen von Datum / Uhrzeit per App zur Verfügung stellt. :-)

Retrospektive 2013

Das Jahr 2013 ist vorüber und ein frisches und unverbrauchtes 2014 ist angebrochen. Eine gute Gelegenheit, um einen Blick zurück auf die vergangenen 12 Monate meiner Community-Aktivitäten zu werfen – im Prinzip also eine Retrospektive bevor der neue Sprint "2014" beginnt. Alles in allem bin ich sehr zufrieden mit dem Ergebnis, aber gehen wir der Reihe nach vor. J

Im Oktober 2012 lag ich in der warmen Sonne am Strand von Ibiza, nuckelte selbstgefällig an einer Pina Colada und genießte meinen ersten Urlaub seit etwa 10 Jahren. Und genau da kam mir die Idee, eine Vortrags-Reihe zur Windows Phone Entwicklung im Stil einer "Roadshow" durch die .NET-Usergroups in ganz Deutschland zu machen, ganz nach dem Vorbild von Gregor Biswanger der selbiges 2012 für Windows 8 unter dem Namen "Entdecke eine neue Welt" machte. Und dank der großartigen Unterstützung von Eugen Palnau, Developer Experience und Developer Outreach Manager bei Nokia in Deutschland, und vor allem zu Beginn auch von Microsoft und Holger, war ich dann 2013 tatsächlich über ein Dutzend Mal in ganz Deutschland bei .NET Usergroups mit meiner Roadshow "CSI: WP – Dem Windows Phone auf der Spur"! Aus rund 30 Themen konnten die Teilnehmer jedes Mal ihre Favoriten wählen, und so war kein Vortrag wie ein anderer. Größtenteils drehten sich die Themen um die Entwicklung auf der Windows Phone 8 Plattform, aber auch wie man seine App sicher in den Store bekommt und das Marketing 1x1 für Entwickler kamen zur Sprache.

Doch nicht nur auf den eigenen Veranstaltungen bei den Usergroups war ich 2013 mit Vorträgen unterwegs. Auch mehrere Konferenzen, OpenSpaces und Hackathons standen auf dem Programm; und wenn ich gerade nicht als Sprecher mit einem eigenen Vortrag beschäftigt war unterstützte ich die Kollegen am Nokia-Stand. Übrigens Nokia: Anfang 2013 wurde ich von den Finnen ausgezeichnet als "Nokia Developer Champion" für Windows Phone. Dabei handelt es sich um ein ähnliches Programm wie das MVP-Programm von Microsoft. An dieser Stelle noch mal vielen Dank an Eugen und Antoine für ihre klasse Unterstützung und das Engagement mit dem sie die "Champions" bei Nokia unterstützen!

Die vielen Vorträge haben natürlich ihren Tribut gefordert und 2013 sind daher kaum Print-Artikel von mir in Fachzeitschriften erschienen, wie es 2012 noch mit 11 Artikeln der Fall war. Allerdings habe ich seit August 2013 wieder regelmäßiger angefangen zu bloggen – immerhin 14 Postings sind so zustande gekommen. Außerdem habe ich im Rahmen unseres firmeninternen Fortbildungs- und Schulungsprogrammes von September bis November eine Fortbildung zum IT-Architekten gemacht. Ob sich daraus auch in Zukunft Themen zum Bloggen oder für Vorträge ergeben muss ich mal schauen – wenn Interesse besteht könnt ihr ja einen entsprechenden Kommentar als Motivation hinterlassen. J

2013 in Zahlen:

  • Als Sprecher auf 11 Konferenzen (inkl. OpenSpace, BarCamp, Hackathon, ..)
  • 14 Roadshow-Termine bei .NET-Usergroups
  • Hierfür 18.829 gefahrene Kilometer mit dem Auto
  • Insgesamt 548 Folien mit PowerPoint erstellt
  • Etwa 76 Stunden Sprechzeit (Vorträge und Stand-Unterstützung)
  • 14 Blog-Artikel und 2 Print-Artikel veröffentlicht
  • 1 Poster im Rahmen der "CSI: WP"-Roadshow
  • 5 Gewinnspiele mit Nokias Unterstützung durchgeführt
War es anstrengend? Klar. Hat es mir Spaß gemacht? Auf jeden Fall! Und ich hoffe, dass es allen die bei meinen Vorträgen dabei waren ebenso viel Spaß gemacht hat aber auch vor allem etwas gebracht hat. In den nächsten 12 Monaten werde ich bestimmt weiterhin aktiv in der Community sein. Aber nach einem Jahr voller Vorträge vielleicht zum Teil mit leicht anderer Ausrichtung. Habe da schon über so manche Idee nachgedacht, lasst euch überraschen!

Natürlich gilt auch 2014, dass ich gerne bei euch vorbei schaue – sei es für einen Vortrag, einen Workshop oder für ein völlig anderes Format. Beispielsweise war ich noch nie bei einer .NET-Talkshow. ;-)

In dem Sinne wünsche ich euch allen ein Frohes Neues Jahr 2014!

Impressionen vom Nikolaus-Hackathon 2013 in Frankfurt

Heute vor genau einer Woche fand deutschlandweit in 11 Städten der Nikolaus-Hackathon für Windows (Phone) 8 statt. Zeit also, ein paar Fotos zu veröffentlichen. :-)

[gallery link="none" columns="5" ids="7103,7101,7068,7069,7071,7076,7078,7079,7080,7081,7082,7083,7084,7086,7087,7088,7089,7090,7092,7093,7094,7095,7096,7097,7098,7099,7100,7104,7102,7105,7106,7107,7108,7111,7112,7045,7046,7050,7052,7055,7054,7058,7057,7060,7059,7061,7063,7064,7065,7066"]

Noch einmal ein großes Dankeschön an alle Teilnehmer des Nikolaus-Hackathon, die Helfer, die Veranstalter, Microsoft, Nokia, ... ach, an alle halt, die dieses tolle Event möglich gemacht haben. Es hat uns allen, und mir ganz besonders, viel Spaß gemacht dabei zu sein! :-)

Seit ihr auch bei einem Nikolaus-Hackathon gewesen? Posted doch mal eure Impressionen dazu. Oder sind sogar schon Apps von letzter Woche inzwischen auf dem Weg in den Marketplace? Waren sicher ein paar gute Kandidaten dabei! :-)

Erhalte das Nokia Universal-USB-Ladegerät DC-16 für die Erstellung deiner ersten Windows Phone App!

Geschenk!Der Nokia Universal Portable USB Charger DC-16 ist nur einer von vielen interessanten Preisen, die ihr bei DVLUP, dem kostenlosen Entwickler-Programm für Windows Phone (und Asha) von Nokia eintauschen könnt! Ebenfalls mit dabei sind Ladekissen von Fatboy, Smartphones, Token für die unterschiedlichsten Services wie Infragistics NetAdvantage oder BugSense und viele andere Produkte der teilnehmenden Partner.

Was ihr dafür machen müsst? Zunächst einmal euch kostenlos registrieren unter www.dvlup.com. Das sollte innerhalb weniger Minuten erledigt sein und erlaubt euch danach für die Erfüllung verschiedener Herausforderungen, dem Lösen von Quiz-Fragen, etc. Punkte zu sammeln um diese dann im Prämien-Shop einzutauschen. :-)

Ready to DVLUP?

default-img-challenge-update-150x150Was noch? Nun, ihr müsst eine Windows Phone App schreiben! Klingt kompliziert, ist es aber gar nicht: Mit Hilfe des Windows Phone App Studio - einer Web-Anwendung von Microsoft - könnt ihr unter Anleitung mit einer einfachen Oberfläche, vorgefertigten Designs und Grafiken und ganz ohne eigene Programmierung eure erste App einfach, schnell und ohne fremde Hilfe fertigstellen. Also ideal für alle Einsteiger!

Noch etwas? Nun, ihr müsst eure gerade erstellte App noch für die "Deine erste App"-Challenge einreichen. In der Beschreibung dort findet ihr auch noch einmal alle wichtigen Informationen und vor allem Links zu noch mehr Hilfeseiten, die euch den Einstieg ganz leicht machen werden.

multimedia-presentationGut aussehende Apps mit praktischen Funktionen für das Windows Phone zu erstellen ist also wirklich ganz einfach. Probiert es selber aus, und lasst euch überraschen wie ihr in unter einer Stunde eure erste professionell wirkende Mobile-App selbst erstellt habt! Noch weitere Fragen zur App-Entwicklung für das Windows (Phone) 8? Dann kommt am Freitag, den 6.12., zu einem der 11 Nikolaus-Hackathons von Microsoft - der Eintritt ist natürlich frei und ihr bekommt hier den ganzen Tag (und Nacht) Hilfe von professionellen Entwicklern von Microsoft und Nokia.