SOA lebt! Services mit REST 29.07.2015

Alexander Jung
Alexander Jung, Chief eXpert

Über SOA wird nicht mehr viel geredet, und Web Services sind old-school. Heute macht man REST! REST-Services! JSON über HTTP(S). Nix SOAP.

Ich spare mir jetzt den Rant darüber, dass Web Services nach wie vor ihre Daseinsberechtigung haben und auch absehbar haben werden. Ich freue mich auf der anderen Seite darüber, dass sich in der REST-Welt Erkenntnisse durchsetzen, die in der SOA-Welt kalter Kaffee sind.

 

Die wichtigste: REST-basierte Schnittstelle != Service

Anders ausgedrückt: Nur weil ich mit ASP.NET Web API eine JSON-basierte REST-Schnittstelle veröffentliche, hat das noch nichts mit einem Service (als Konzept im Sinne von SOA) zu tun.

Damit das nicht falsch verstanden wird: Es spricht überhaupt nichts dagegen, die übliche Abbildung von CRUD-Operationen auf REST-Aufrufe zu machen und damit seine AngularJS-Anwendung mit Daten zu versorgen. Nur hat das nichts mit Service-Orientierung zu tun.

Man sollte es sich definitiv zwei mal überlegen, ob man diese Aufrufe (und damit die internen Datenstrukturen und Methoden) auch für externe Clients zugreifbar macht.

Zum einen, weil man sich selbst damit keinen Gefallen tut. Die Gründe sind die gleichen, die schon zu “SOA mit Web Service”-Zeiten galten: Enge Kopplung, Qualitätsanforderungen wie Versionierung, QoS-Tracking, Security, … . Alles aus SOA-Zeiten bekannte Themen.

Zum anderen aber auch, weil simple CRUD-Operationen auf als bekannt vorausgesetzten Datenstrukturen dem Client nicht das bieten, was er erwartet und benötigt.

Service-Orientierung mit REST…

Was unterscheidet einen öffentlichen REST-Service von einer privaten REST-Schnittstelle?

Die weitreichendsten Konsequenzen hat sicher HATEOAS als Designansatz.

Kurz gesagt geht es bei HATEOAS darum, dass eine Datenstruktur die ich über einen REST-Service bekomme, nicht nur die Nutzdaten selbst beinhaltet. Geliefert werden immer auch die notwendigen URLs für Navigation (zu abhängigen Daten), aber auch für die möglichen Operationen (z.B. zum Löschen, wenn die Berechtigungen das zulassen). So kann man sich von einer Root-URL des Service anhand der Daten durch sämtliche Datenstrukturen und Operationen hangeln, ohne dass es weiterer Informationen bedarf.

HATEOAS liefert damit dynamisch die Informationen, die bei einem klassischen Web Service statisch über die WSDL bereitgestellt wird.

Andere Themen (Versionierung, coarse-grained Operationen, …) sind unmittelbar aus der Web Services-Welt übertragbar. Wieder andere haben nur in der einen oder nur der anderen Welt eine Entsprechung. Beispiele: Viele WS-*-Standards auf der einen Seite, HTTP Verbs und Mime-Types auf der anderen Seite.

Natürlich haben die unterschiedlichen Technologie-Stacks und nicht zuletzt auch unterschiedliche Herangehensweise bzgl. Metainformationen (dynamisch bei REST, statische in der WSDL bei Web Services) ihre Konsequenzen bzgl. des Service-Designs. Das ändert aber nichts daran, dass auch bei REST-Services ein bewusstes Schnittstellendesign – unabhängig von den Code-Generierungs-Ansätzen eines Werkzeugs – notwendig ist.

 

Wer sich damit tiefer auseinandersetzen will: Jeremy Likness hat eine Serie von Vorträgen auf Channel 9 veröffentlicht: “Web API Design Jumpstart

  1. Introduction
  2. Basic Design
  3. Configuration
  4. Validation and Error Handling
  5. Security
  6. Advanced Design

Teil 2 ist der interessanteste bzgl. grundlegender Designfragen, Teil 6 ergänzt das Thema Versionierung. Die anderen Teile sind sicher auch nicht uninteressant, werden aber für ASP.NET MVC-Entwickler nichts grundsätzlich neues bringen.

Share |

Kovarianz und Kontravarianz 22.07.2015

Alexander Kabisch
Alexander Kabisch, Principal eXpert

So hochtrabend die Bezeichnung Kovarianz und Kontravarianz klingt, so simpel und alt, sehr alt, ist die Idee dahinter.

Spezialisierung und Generalisierung sind Grundkonzepte der Objektorientierten Programmierung. Wie in Zeile 8 aufgezeigt, konnte man schon immer eine spezialisierte Instanz einer Klasse einer generalisierten Variable zuweisen.

   1: public class Control {}
   2: public class ItemContainer : Control{}
   3: public class Item : Control{}
   4:  
   5: public static void Main()
   6: {
   7:     Item i = new Item();
   8:     Control c = Do(i);
   9: }
  10:  
  11: public static ItemContainer Do(Control arg)
  12: {
  13:     ...
  14:     return new ItemContainer();
  15: }

Delegates gab es zwar schon vor LINQ, jedoch erlebten sie damit einen Hype. Folgendes konnte man schon immer tun:

   1: Item i = new Item();
   2: Func<Control, ItemContainer> do = arg => Do(arg);
   3: Control c = do(i);

Im Zusammenhang mit LINQ werden Delegates aber sehr oft selbst als Parameter für Methodenaufrufe verwendet. Nun kommen Kovarianz und Kontravarianz zum Einsatz:

   1: Item i = new Item();
   2: Func<Control, ItemContainer> do = arg => Do(arg);
   3: Func<Control, Control> doGeneral = do;
   4:  
   5: Control c = doGeneral(i);

Während folgende Zuweisungen den gewünschten Effekt haben,

   1: string[] sItems = new string[]{ "abc", "123"};
   2: object[] oItems = sItems;
   3:  
   4: IEnumerable<string> sEnumerable = sItems;
   5: IEnumerable<object> oEnumerable = sEnumerable

führt Zeile 2 zum Fehler. Verständlicherweise zum Fehler, denn man könnte oItems.Add mit beliebigen Argumenten aufrufen.

   1: IList<string> sItems = new string[]{ "abc", "123"};
   2: IList<object> oItems = sItems;

Trotzdem würde ich mir wünschen, dass Microsoft nicht nur Delegates und IEnumerable<> mit dem Feature versieht. Sondern beispielsweise auch:

   1: public interface IControl { }
   2:  
   3: public interface IItemContainer
   4: {
   5:     IEnumerable<IControl> Controls { get; }
   6: }
   7:  
   8: public class Control : IControl {}
   9:  
  10: public class ItemContainer : Control, IItemContainer
  11: {
  12:     public IList<Control> Controls { get; }
  13: }

Der Code  wird witzigerweise erst lauffähig mit folgender Erweiterung:

   1: public class ItemContainer : Control, IItemContainer
   2: {
   3:     public IList<Control> Controls { get; set; }
   4:  
   5:     IEnumerable<IControl> IItemContainer.Controls
   6:     {
   7:         get { return this.Controls; }
   8:     }
   9: }

Für mich leider unverständlich, denn IList implementiert IEnumerable und dort ist eine Generalisierung erlaubt.

Während die Grundkonzepte der OOP für LINQ auf Delegates und IEnumerable eingeführt wurden, ist mir unverständlich warum sie nicht auch für das obige Beispiel gelten. Mir ist klar dass IEnumerable nicht die Sicht auf die Liste ändert sondern nur durch Enumerator.Current die Sicht auf ein Item, aber dies tut IItemContainer auch. Man muss bei der expliziten Implementierung nicht mal casten!

Share |

Cortana, was kann ich tun? – eXpert Artikel in der aktuellen dotnetpro 20.07.2015

Anette Mroz
Anette Mroz, Senior Assistenz Vertrieb

Seit letzten Donnerstag druckfrisch am Kiosk. Der neue Artikel unseres eXperts Max Jäger zum Thema “Sprachsteuerung mit dem Windows Phone”.

Unter dem Titel „Cortana, was kann ich tun?“ erläutert Max, wie moderne Apps die Möglichkeiten der Sprachsteuerung bestmöglich nutzen sollten.

 

clip_image002

Der Artikel steht auf dotnetpro.de auch zum direkten Download zur Verfügung.

Wir wünschen Euch viel Spaß beim Lesen!

Share |

Xamarin.Forms im Praxiseinsatz: Die Xamarin Test Cloud 15.07.2015

Markus Demmler
Markus Demmler, Principal eXpert

Eine der großen Herausforderungen in der Cross-Platform-Entwicklung ist es sicherzustellen, dass die zu entwickelnde App auf allen zu unterstützenden Geräten und OS-Versionen entsprechend funktioniert. Vor allem die Anzahl der unterschiedlichen Android Geräte und OS-Versionen ist beachtlich. Dieser Artikel beschreibt, wie die Xamarin Test Cloud durch automatisierte UI Acceptance Tests in der Cloud helfen kann, diese Fragmentierung zu meistern.


Features der Xamarin Test Cloud

Die Xamarin Test Cloud ermöglicht es eine App durch automatisierte UI Tests auf einer Vielzahl von physikalischen Geräten zu testen. Aktuell bietet die Xamarin Test Cloud 37 unterschiedliche Tablets und 137 Phones für die iOS und Android Plattform an. Windows Phone und Windows 8 werden nicht unterstützt. Die einzelnen Geräte stehen zusätzlich noch in unterschiedlichen OS-Versionen zur Verfügung. Eine detaillierte Übersicht findet man hier.

Für die Entwicklung der automatisierten UI Tests stellt Xamarin Unterstützung für zwei Frameworks zur Verfügung:

  • Xamarin.UITest: Dieses Framework ermöglicht die Entwicklung von in C# geschriebenen Tests unter der Verwendung von NUnit.
  • Calabash: Bei diesem Framework werden die Tests in Ruby geschrieben unter Verwendung von Cucumber. Cucumber ist ein Open Source Tool zur Unterstützung von Behavior Driven Development (BDD).

Im Folgenden konzentrieren wir uns auf das Xamarin.UITest Framework.


Notwendige Vorbereitungsschritte in der App

Damit die UI Tests mit der zu testenden App interagieren können, müssen die jeweiligen Controls über ein StyleId Property verfügen. Zusätzlich muss dieses Property noch in ein natives Property kopiert werden. Das genaue Vorgehen für iOS und Android ist im Detail hier beschrieben.


Entwicklung von Tests mit dem Xamarin.UITest Framework

Zunächst wird eine neue Class Library mit folgenden NuGet Packages angelegt:

Innerhalb der Class Library gibt es dann eine oder mehrere Klassen mit plattformunabhängigen Tests:
   1: public class CrossPlatformTests
   2:     {
   3:         protected IApp app;
   4:         
   5:         [SetUp]
   6:         public virtual void SetUp()
   7:         {
   8:             Assert.Ignore("This class requires a platform-specific bootstrapper" 
   9:             + " to override the `SetUp` method");
  10:         }
  11:  
  12:         [Test]
  13:         public void ClickingLoginButtonShouldShowErrorMessage()
  14:         {
  15:             Func<AppQuery, AppQuery> loginButton = c => c.Button("LoginButton");
  16:             Func<AppQuery, AppQuery> messageTextField = c => c.Id("message");
  17:  
  18:             this.app.Tap(loginButton);
  19:  
  20:             this.app.WaitForElement(messageTextField);
  21:             AppResult[] results = this.app.Query(messageTextField);
  22:  
  23:             this.app.Screenshot("Popup mit Fehlermeldung");
  24:  
  25:             Assert.AreEqual("Url, Benutzername und Passwort dürfen" 
  26:             + " nicht leer sein", results[0].Text);
  27:         }
  28:     }

Zusätzlich gibt es noch jeweils pro Plattform abgeleitet eine Klasse mit einem plattformspezifischen Setup und optional plattformspezifischen Tests:

   1: [TestFixture()]
   2:     public class AndroidTest : CrossPlatformTests
   3:     {
   4:         public string PathToAPK { get; set; }
   5:  
   6:  
   7:         [TestFixtureSetUp]
   8:         public void TestFixtureSetup()
   9:         {
  10:             string currentFile = new Uri(Assembly.GetExecutingAssembly().CodeBase).LocalPath;
  11:             var fi = new FileInfo(currentFile);
  12:             string dir = fi.Directory.Parent.Parent.Parent.FullName;
  13:             this.PathToAPK = Path.Combine(dir, "KMS.Forms.Android", 
  14:             "bin", "Release", "eisTIK.mobile.apk");
  15:         }
  16:  
  17:         [SetUp]
  18:         public override void SetUp()
  19:         {
  20:             this.app = ConfigureApp.Android.ApkFile(this.PathToAPK)
  21:             .ApiKey("ENTER-YOUR-API-KEY-HERE").StartApp();
  22:         }
  23:     }

Ein detailliertes Tutorial zum Erstellen der Tests findet man hier.


Lokales Testen

Diese Tests können lokal auch ohne einen Test Cloud Account ausgeführt werden. Dabei gelten folgende Einschränkungen:

  • iOS Tests können nur gegen einen IOS Simulator ausgeführt werden.
  • Android Tests können nur gegen den Android Emulator oder den Xamarin Android Player ausgeführt werden.
  • Die Laufzeit eines Testszenarios ist auf 15 Minuten begrenzt.

Weitere Information diesbezüglich findet man hier.


Cloud Testing

Nachdem die UI Tests lokal erfolgreich durchgelaufen sind, können anschließend die Tests und die zu testende App direkt aus Visual Studio (Rechtsklick auf das Projekt mit den UI Tests und Klick auf "Run in Test Cloud…) in die Xamarin Test Cloud geladen werden. Hier werden noch die zu verwendenden Geräte ausgewählt und der Testlauf wird in der Xamarin Test Cloud vorgemerkt.xamarin test cloud - device selection

Sobald die jeweiligen Geräte in der Xamarin Test Cloud verfügbar sind, starten die Tests und abschließend ist ein konsolidierter Report verfügbar:

xamarin test cloud - report

Für jeden fehlgeschlagenen Test wird auch automatisch ein Screenshot von dem jeweiligen Gerät angelegt:

xamarin test cloud - screenshots


Kosten

Xamarin lässt sich die Test Cloud teuer bezahlen. Die kleinste Lizenz (Basic) kostet 1.000 Dollar im Monat und beinhaltet monatlich 200 Teststunden. Diese Grenze erreicht man leicht: Bei einem täglich zu durchlaufenden Testszenario von 1h auf 10 ausgewählten Kombinationen von Geräten und OS-Versionen kommt man schon auf 300 Teststunden im Monat (1h x 30 Tage x 10 Kombinationen von Gerät und OS-Version).


Fazit

Die Xamarin Test Cloud stellt eine teure, aber überzeugende Möglichkeit dar, sicherzustellen, dass sich die entwickelte iOS und Android App auf möglichst vielen Geräten wie geplant verhält. Was leider noch fehlt ist die Unterstützung für Windows und Windows Phone Geräte.

Share |

Close existing Connections by SQL Script 08.07.2015

Alexander Kabisch
Alexander Kabisch, Principal eXpert

Beim Löschen einer Datenbank kann man “close existing connections” auswählen. Beim Restore oder Detach kann man es leider nicht, hier bekommt man nach längerem Warten eine Fehlermeldung.

Die wohl bekannteste Möglichkeit Verbindungen zuschließen bietet der Activity Monitor. Hier sieht man alle Prozesse, diese kann man filtern und den gewünschten schließen. Leider nur einen Prozess nach dem anderen. Bei zu vielen Prozessen braucht man unter Umständen recht lange und läuft Gefahr dass in der Zwischenzeit wieder neue Verbindungen erstellt wurden.

ActivityMon1

ActivityMon2

Man kann aber auch per Script alle Verbindungen außer der eigenen schließen, indem man KILL verwendet:

   1: DECLARE @dbName AS VARCHAR(200) = 'xyz'; -- DB_NAME()
   2:  
   3: DECLARE @kill AS VARCHAR(max) = '';
   4: SELECT @kill = @kill + 'KILL ' + STR([SPID]) + ';'
   5: FROM master..sysprocesses 
   6: WHERE [DBID] = DB_ID(@dbName)
   7: AND [SPID] <> @@SPID;
   8:  
   9: EXEC(@kill);

Leider erlebe ich es oft, dass die Testumgebung blockiert ist und ein Update auf eine neue Version verhindert. Dann kommt man leider nicht dran vorbei alle Verbindungen zu schließen.

 

Ich persönlich lege solche Scripte ungern in der Datenbank ab, da sie meist in Produktion nicht benötigt werden. Besser finde ich es sie als Toolset zu sammeln. Dies kann man zusammen mit den Sourcen des Projektes oder als Teil des Projektes einchecken.

Share |

Windows 8.1 App-Entwicklung: der Weg zu ­Windows 10 01.07.2015

Alexander Jung
Alexander Jung, Chief eXpert

Windows 10 steht vor der Türe und mancher Entwickler, der sich allen Unken zum Trotz mit Windows 8 AppStore-Anwendungen auseinandergesetzt hat, wird sich fragen, was das für ihn bedeutet.

 

Es gibt da durchaus einiges Neuerungen: Universal Apps als neuer Anwendungstyp, AppStore-Anwendungen im Fenster, die Charm-Bar verschwindet.

Matthias Jauernig hat sich die Details dazu näher angeschaut. Sein Fazit:

Auch bei der Übertragung von Windows-8.1-Apps nach Windows 10 wird deutlich, dass Microsoft die klassischen Desktop-Benutzer fokussiert. Ist das schlimm? Nein! Wenn Tablet-Benutzer nicht vernachlässigt werden, ist die Ausführung von Apps in Fenstern nur zu begrüßen…

Das ist in der Tat die Crux: Microsoft muss beide Nutzergruppen bzw. –szenarien angemessen unterstützen. Mit Windows 8 hatte Microsoft zu einseitig auf Tablet-Nutzung fokussiert und den Desktop-Nutzer nicht nur ignoriert, sondern auch (mindestens gefühlt) benachteiligt. Kompromisse zugunsten eines Formfaktors dürfen aber nicht zulasten des anderen gehen. Hoffen wir, dass Microsoft das mit Windows 10 besser hinbekommt…

Share |

Xamarin Hackathon 26.06.2015

Stefan Gründig
Stefan Gründig, Chief eXpert

Hackathons sind toll. Und weil das so ist, haben der Chris, der Markus und ich (“die Organisatoren”) einen mit unseren eXperts-Kollegen abgehalten. Ziel war, unsere Erfahrungen mit Xamarin – und im speziellen Xamarin.Forms – mit den Kollegen zu teilen und sie in die Lage zu versetzen, selbst die ersten Schritte in der Cross-Plattform-Entwicklung von Mobile Apps zu gehen.

Aber was ist eigentlich ein Hackathon? Der Begriff erweckt die Assoziation einer motivierenden, ungezwungenen und dennoch zielgerichteten Arbeitsatmosphäre, die eine gute Basis ist für einen nachhaltigen Wissensaustausch unter den Kollegen. Wikipedia meint, dass es sich um eine kollaborative Software- und Hardware-Entwicklungsveranstaltung handele. Dabei werde zunächst ein Thema vorgestellt und dann dazu Umsetzungsvorschläge diskutiert. Im Folgenden werde innerhalb kurzer Zeit ein gemeinsames Produkt erstellt. In diesem umfassenden Sinne fand dies bei uns jedoch nicht statt. Wir hatten den Begriff des Hackathon etwas uminterpretiert…

Unser Hackathon hatte den Charakter eines Workshop, bei dem Wissen und Erfahrungen vermittelt werden. Die Organisatoren hatten ein Beispielprojekt entwickelt, anhand dessen die Arbeit mit Xamarin.Forms demonstriert und erfahren werden sollte. Es ging um eine Mobile App für Android, iOS und Windows Phone. Den Funktionsumfang hielten wir handlich klein, um den einen Tag, den wir für den Hackathon angesetzt hatten, nicht mit fachlichen Diskussionen vollzustopfen. Stattdessen konzentrierten wir uns auf die Technologie. Eben Xamarin.Forms. Dazu gibt es hier im Flurfunk übrigens auch den einen oder anderen Beitrag, der sich zu lesen lohnt.

Die Anforderungen an die zu entwickelnde Anwendung waren überschaubar. Sie sollte eine Liste von Elementen darstellen, welche editiert und gelöscht werden können. Auch das Hinzufügen von Elementen sollte möglich sein. Durch die Liste sollte man scrollen und im Kontext einzelner Listenelemente interagieren können. Bei der Eingabe eines Elements sollten verschiedene Tastatur-Layouts (normal, numerisch) berücksichtigt sowie einfache Validierungen durchgeführt werden.

Als Vorbereitung hatten wir eine Xamarin.Forms Solution angelegt, quasi als Referenzimplementierung, die dann während des Hackathon nach und nach aufgebaut werden sollte. Die Steps dafür hatten die Organisatoren quasi als “roten Faden” durch den Hackathon notiert. Ebenfalls im Vorfeld wurden alle Teilnehmer über die technischen Voraussetzungen informiert. So musste beispielsweise jeder Teilnehmer eine Xamarin-Trial oder -Business-Lizenz zur Verfügung haben. Weiterhin musste Xamarin auf dem Entwicklungsrechner installiert sein und geeignete Emulatoren oder Hardware Devices zum Testen bereitstehen.

Ablauf

Und so haben wir uns morgens neun Uhr zu zehnt in unserem Konferenzraum um einen Tisch versammelt, die Notebooks ausgepackt und losgelegt. Die Organisatoren sorgten per Beamer für ein gemeinsames Bild von Architektur und Code.

Zunächst stellten wir sicher, dass bei allen Teilnehmern die technischen Voraussetzungen gegeben sind. Danach ging es dem “roten Faden” folgend ans Implementieren. Dabei teilten wir den Gesamtumfang der Implementierungsschritte so auf, dass drei Leute nacheinander jeweils einen Teil davon demonstrierten. Ich legte den Grundstein für die Applikation und implementierte das architektonische Grundgerüst. Markus setzte dann fort und demonstrierte plattformspezifische Implementierungen für Windows Phone. Chris schloss daran an und vervollständigte die Applikation am Beispiel der Android-Plattform. Im Ergebnis hatten wir eine lauffähige Software mit dem geplanten Funktionsumfang auf zwei Plattformen zur Verfügung – Windows Phone und Android.

Was ist mit iOS? Dafür kann man doch mit Xamarin auch entwickeln? Selbstverständlich. Leider machte uns an diesem Tag aber Murphy einen Strich durch die Rechnung, indem er verhinderte, dass sich unser MacBook Air ins interne Netz integrierte. Damit stand es als Xamarin Build Host nicht zur Verfügung und wir konnten die iOS App zwar nebenbei mitentwickeln, aber nicht deployen und testen. Da gerade für Einsteiger in Xamarin das Entwicklungs-Setup für die Entwicklung von iOS-Applikationen besonders interessant ist, war es umso ärgerlicher, dass wir das im Hackathon nicht zeigen konnten.

Was wir gelernt haben

Am Ende des Hackathon – so gegen 16:30 – erbaten sich die Organisatoren ein Feedback von den Teilnehmern. Sozusagen was gut und was verbesserungswürdig war. Daraus ergaben sich die folgenden Erkenntnisse.

  • Was das Erklären einer laufenden Implementierung anbelangt, so ist das Zeitempfinden zwischen Teilnehmern und demjenigen, der etwas codiert, stark unterschiedlich. Demonstriert man eine Implementierung, ist man meistens zu schnell für jemanden, der dies zum ersten Mal tut und verstehen sowie nachimplementieren soll. Die Gefahr besteht, dass Teilnehmer “abgehängt” werden. Als Demonstrierender ist man von der Geschwindigkeit dann genau richtig unterwegs, wenn es einem zu langsam vorkommt.
  • Es ist aus didaktischer Sicht unbedingt empfehlenswert, zu Beginn der Veranstaltung die fertige App mit vollem Funktionsumfang vorzustellen, also das Ziel des Hackathon. Zusätzlich hilft es den Teilnehmern während der Veranstaltung dabei, die gerade durchgeführten Aktionen in den richtigen Zusammenhang zu stellen, also zu wissen, warum man gerade dieses und jenes tut.
  • Die gemeinsame Entwicklung der App teilte sich in mehrere Schritte, z. B. das Projekt-Setup, ein erstes Hallo-Welt-Beispiel, Einbinden von Ressourcen, Integration eines Dependency-Injection-Containers, Implementierung von plattformspezifischem und Shared Code. Es ist sehr hilfreich, auch vor jedem dieser einzelnen Schritte darzustellen, was das Ziel dieses Schrittes ist. Damit ist dann auch jedem klar, warum z. B. jetzt ein Interface als Abstraktion angelegt wird und was damit erreicht werden soll.
  • Um sich auf die Technologie zu fokussieren, ist es empfehlenswert, die Fachlichkeit der zu entwickelnden Anwendung klein zu halten.

Fazit

Die Technologielandschaft im Bereich der Software-Entwicklung ist bekanntermaßen immer dynamischeren Veränderungen unterworfen. Kein Mensch kann mehr in allen Themen selbst fit sein oder hat die Zeit, sich von Grund auf fit zu machen. Dafür ist das Umfeld zu komplex, zu groß die Auswahl der Technologien, zu gering die zur Verfügung stehende Zeit.

Es braucht also auch andere Wege als “Selbststudium”, um neben der eigentlichen Arbeit up-to-date zu bleiben. Wir in der SDX haben dafür bereits unterschiedliche Formate etabliert, um für Wissenstransfer innerhalb des Unternehmens zu sorgen. So halten eXperts regelmäßig zu unterschiedlichsten Themen kleine Vorträge und führen Diskussionsrunden, so am Abend, mit Pizza und Bier. Zu diesem Portfolio an Möglichkeiten der Wissensvermittlung stoßen immer mehr auch die Hackathons.

Alles in allem ist so ein Hackathon eine hervorragende Art und Weise, um noch fokussierter und intensiver Wissen zwischen eXperts auszutauschen. Und zwar hands-on, unmittelbar, praktisch, am Code. Man kann damit sehr gut Hürden abbauen, sich selbst mit neuer Technologie auseinanderzusetzen. Und die Dauer von einem ganzen Tag sorgt dafür, dass sich jeder Teilnehmende wirklich einen Tag ausschließlich der jeweiligen Thematik widmen kann.

Unsere Erfahrungen mit diesem Hackathon sind durchweg positiv. Wir haben einiges gelernt, was wir noch besser machen können. Und wer weiß, vielleicht laden wir mal zu einem öffentlichen Hackathon ein, damit auch Du mal ein bisschen SDX-Luft schuppern kannst und hoffentlich Neues mit nach Hause nimmst.

Share |

Die Affen sind los! Nachlese Developer Week 22.06.2015

Svenja Henß
Svenja Henß, Senior Assistant

3 Tage auf der Developer Week in Nürnberg liegen hinter uns und ich muss sagen – auf der DWX waren die Affen los. Smiley

Insgesamt nahmen 180 DWX Besucher an unserem Gewinnspiel teil und konnten das kniffelige Bilderrätsel lösen. Am schnellsten gelang dies in 13 Sekunden und der Gewinner konnte sich über einen Reisegutschein in Höhe von 350 Euro von Ab-in-den-Urlaub freuen.

WP_20150617_002

Außerdem wurden unter allen Teilnehmern 2 große Affen verlost.

WP_20150617_003WP_20150617_004

WP_20150617_16_12_18_ProWP_20150616_10_12_59_Pro

Wir freuen uns, dass all unsere Xamarin Affen ein neues Zuhause gefunden haben.

Einen herzlichen Dank an die zahlreichen Standbesucher für die interessanten Gespräche und das positive Feedback zu den beiden Vorträgen von Max (NFC mit Windows Phone) und Till (One Business App, Multiple Devices).

WP_20150616_10_37_19_ProFlurfunk1

Abschließend noch ein Foto eines glücklichen Gewinners. Smiley Über weitere (Affen-)Fotos von euch freuen wir uns natürlich sehr. Bitte sendet sie direkt an info@sdx-ag.de.

image2

Share |