27. Juli 2018
Martin Maier
0

Testgetriebene Entwicklung (TDD) einer Angular-Anwendung

 

 

Grafische Oberflächen von komplexen Systemen wurden lange Zeit hauptsächlich mit soliden, schwergewichtigen Technologien in sehr hoch entwickelten, objektorientierten Sprachen realisiert. Dabei wurden meist Fat Clients durch WPF oder Swing entwickelt. Eher seltener handelte es sich dabei um Thin Clients in Form von Webanwendungen. HTML und JavaScript wurden in diesen Fällen vorwiegend durch große Frameworks wie ASP oder JSF abstrahiert und serverseitig gerendert. Der Sprachkern von JavaScript entwickelte sich jedoch mit ECMAScript 2015 stark weiter und wurde dadurch auch für komplexere Anwendungen interessant. Basierend auf den Vorschlägen zu ECMAScript 2015 entstand mit TypeScript zusätzlich eine Möglichkeit, Webanwendungen auf sehr hohem sprachlichen Niveau und statisch typisiert zu entwickeln. Durch diese starken sprachlichen Verbesserungen und den starken Support durch Giganten wie Facebook und Google, wurden Webtechnologien zunehmend für komplexere Anwendungen in Form von Singe Page Applications (SPA) interessant.

Leider hat der Quellcode solcher auf Webtechnologien basierender Anwendungen oft noch den Ruf, sich hinsichtlich Lesbarkeit, Design und Testabdeckung auf einem qualitativ sehr niedrigen Level zu befinden. Der Wert qualitativ hochwertigen Code zu entwickeln, um eine Anwendung nachhaltig effizient weiterzuentwickeln und warten zu können, ist jedoch technologieunabhängig und bedarf damit verbundener Prinzipien und Methoden um diesen Wert erhalten.

Testgetriebene Entwicklung (Test Driven Development = TDD) ist eine Methode aus dem Extreme Programming (XP), um qualitativ hochwertigen und gut getesteten Code zu entwickeln.

Dabei wird in kurzen Iterationen stets zuerst in Tests das Verhalten spezifiziert, bevor es implementiert und anschließend die Lesbarkeit und Struktur des Codes verbessert wird. Dies führt nicht nur zu gut testbarem und getestetem Code, sondern auch dazu, dass sich Entwickler bereits sehr früh mit der Struktur bzw. dem Design des Codes auseinandersetzen müssen. Zudem wird durch die vorgelagerte Spezifizierung durch Tests auch effektiv nur Funktionalität entwickelt, die tatsächlich gefordert wird und schützt somit davor prädiktiven und unnötig komplexen Code zu entwickeln.

Mit der Angular CLI erstellte Projekte, enthalten „out of the box“ alle Bordmittel um testgetrieben entwickeln zu können.

Dieses Tutorial soll anhand eines einfachen Szenarios beschreiben, wie Angular Projekte testgetrieben entwickelt werden können.

Das Szenario

Wir wollen den Fokus auf die Methodik legen und wählen deswegen ein sehr einfaches fachliches Szenario. Mit der Anwendung sollen rudimentär Kontakte verwaltet werden können. Sie besteht grundlegend aus nur zwei Funktionalitäten:

  • Kontakte anzuzeigen
  • Neue Kontakte anzulegen

Aufsetzen des Angular Projekts

Ein Angular Projekt ist mittels Angular CLI zügig aufgesetzt.

 

 

Wir möchten die Anwendung von Grund auf entwickeln. Dazu

  • löschen wir Komponente app.component
  • bereinigen die davon betroffenen Abhängigkeiten app.module und index.html
  • löschen die End-to-End Spezifikationen im Verzeichnis e2e/src
  • und überprüfen unsere Änderungen indem wir das Projekt mit ng build bauen

Der „Walking Skeleton“

Unser System ist sehr klein, kommuniziert mit keinem Backend und wird einfachheitshalber auch nicht automatisiert ausgeliefert. Damit handelt es sich bei unserem Skelett ausschließlich um einen Durchstich zur testgetriebenen Entwicklung unserer Anwendung. Dieser sollte einen E2E-Test umfassen, welcher über „Page Objects“ mit der Webanwendung interagiert, und einer ersten kleinen Komponente, welche testgetrieben entwickelt wurde. Eine passende erste kleine Story, um den „Walking Skeleton“ zu erstellen, ist das Anzeigen der Kontakte.

Vorgehen

Wir entwickeln in kurzen TDD-Iterationen. Um dieses Tutorial lesbarer und übersichtlicher zu gestalten, verwende ich ein paar Icons, um den Ablauf darzustellen. Als erstes definieren und sprechen wir darüber, was wir in der nächsten Iteration erreichen möchten. Bestenfalls entwickeln wir das nicht alleine, sondern haben uns mit einem anderen Entwickler „gepaired“. Wir spezifizieren einen entsprechenden Test, starten ihn  und beobachten wie er fehlschlägt  . Daraufhin implementieren wir die Funktionalität und starten den Test erneut  bis dieser erfolgreich ist . Wir überprüfen unseren Code Style, führen Refactorings durch und starten danach mit der nächsten kleinen TDD-Iteration.

Spezifizierung der Story in einem ersten E2E-Test

Wir definieren den Kontext der Story als Kontaktverwaltung und erstellen dementsprechend eine E2E-Spezifikation /e2e/src/contact-management.e2e-spec.ts.

Wir legen fest, dass die Webseite der Kontaktverwaltung initial die beiden Kontakte „Max“ und „Moritz“ auflistet.

Innerhalb der E2E-Spezifikationen wollen wir auf einer sehr hohen Ebene mit der Anwendung interagieren und delegieren den Zugriff auf die HTML-Elemente deswegen in sogenannte „Page Objects“.

In TDD-Manier schreiben wir unseren E2E-Test als würde eine Klasse ContactManagementPage bereits bestehen, um sie so zu definieren, wie sie aus Client-Sicht am sinnvollsten ist.

Wir erstellen uns eine Instanz der ContactManagementPage, navigieren auf deren Ansicht und stellen sicher, dass dort nur die Kontakte „Max“ und „Moritz“ aufgelistet werden.

 

 

Sind wir damit soweit fertig, erstellen wir die Klasse ContactManagementPage unter /e2e/src/pageobjects/contact-management.po.ts, wie im Testfall angenommen.

 Nun kompiliert der Testfall, schlägt aber – wie erwartet – fehl.

Wir beginnen mit der Implementierung des „Page Objects“ bei der Method #navigateTo, welche zur Kontaktverwaltungs-Ansicht navigiert. In unserem Fall ist das aktuell “/”.

Als nächstes benötigen wir die Namen der aufgelisteten Kontakte. An dieser Stelle definieren wir, dass die Ansicht Elemente der Klasse „contact“ darstellen soll, welche wiederrum ein Element der Klasse „name“ beinhalten.

Wir implementieren also #shownNamesOfContacts indem wir alle Namens-Elemente heraussuchen und deren Textinhalte mappen.

Protractor arbeitet asynchron mit eigenen Promises. Wir müssen also unbedingt darauf achten, die richtige Promise-Klasse von Protractor zu importieren.

 

 

   Der Test schlägt nun fehl mit einem Hinweis, dass keine Angular Seite gefunden werden konnte. Der Grund dafür ist, dass aktuell keine Angular Komponente bootstrapped wird.

Um diesen Fehler zu beheben erstellen wir als nächstes eine Angular Komponente “contact-list” mit Hilfe der Angular CLI.

ng generate component contact-list

Sie wird automatisch dem globalen App-Modul zugeordnet und dort deklariert. Das ist für dieses Tutorial soweit in Ordnung, aber wir müssen diese Komponente auch noch in unsere index.html einpflegen und im Modul konfigurieren, dass die Komponente auch gebootstrapped wird.

   Der E2E-Test schlägt weiterhin fehl, diesmal jedoch wie gewünscht, dadurch dass die Erwartungen nicht erfüllt wurden.

Implementierung der Komponente

Zunächst soll die Komponente eine Liste mit einem Eintrag je Kontakt darstellen.

Wir erstellen uns dafür einen Testfall in der von der Angular CLI mitgenerierten contact-list.component.spec wieder unter der Annahme, dass benötigte Abhängigkeiten bereits existieren.

 

 

Der Code kompiliert nicht. Wir benötigen das Daten Objekt „Contact“ und eine Property „contacts“ im Controller contact-list.components.ts der Komponente, welches die Kontakte bereitstellt.

Wir erstellen also die Klasse /model/contact.ts

 

 

und erweitern den Controller um die Property contacts: Contact[].

   Wir starten diesmal die Karma Tests durch ng test und sehen, dass der eben geschriebene Test fehlschlägt, da wir zwei Kontakt-Elemente erwarten, jedoch keiner dargestellt wird.

Wir können Karma im Hintergrund laufen lassen und bekommen dadurch sofortiges Feedback über unsere Änderungen am Code und deren Auswirkungen auf die Testergebnisse.

Wir erweitern die View contact-list.component.html dahingehend, eine Liste mit einem Eintrag je Kontakt darzustellen.

 

 

 Die Tests sind erfolgreich!

So weit so gut. Nun wollen wir die Namen der Kontakte anzeigen.

 

 

   Der Test schlägt – wie erwartet – fehl.

Wir erweitern also den View, der den Namen des Kontakts darstellt.

 

 Erfolgreich! Unsere Komponente zeigt nun die Namen der Kontakte an.

Ist die Story damit fertig implementiert? Wir lassen die E2E-Tests laufen.

   Dieser schlägt weiterhin fehl. Wir erwarten, dass “Max” and “Moritz” initial als Kontakte angezeigt werden.

Als nächstes wollen wir also, dass die Komponente initial die Kontakte „Max“ und „Moritz“ darstellt.

 

   Der Test schlägt fehl.

Wir initialisieren das Property des Controllers mit den entsprechenden Kontakten.

 Alle Komponenten-Tests sind erfolgreich.

 Nun ist auch der E2E-Test grün und die Implementierung der Story damit abgeschlossen.

 

Weiterentwicklung

Da nun unser „Walking Skeleton“ steht, können wir mit der Weiterentwicklung fortfahren.

Mögliche nächste Schritte könnten beispielsweise sein:

  • Refactoring: Auslagern und Delegierung der „contact-list“ spezifischen Inhalte in ein eigenes „Page Object“, um das ContactManagementPage-Object übersichtlich zu halten und die „contact-list“ auch in anderen E2E-Tests wiederverwenden zu können.

  • Story: Anlegen neuer Kontakte
    • Über ein Textfeld soll beim Betätigen der Enter-Taste ein neuer Kontakt angelegt werden.

    • Wurde ein neuer Kontakt angelegt, soll das Textfeld zurückgesetzt werden.

  • Optimierung: Auslagern der Datenhaltung in einen Redux-Store

 

Fazit

Frameworks wie Jasmine, Karma oder Protractor unterstützen die testgetriebene Entwicklung von Webanwendungen sehr gut.

Im Falle von Angular sind Projekte, die mit der Angular CLI erstellt wurden, bereits mit Jasmine, Karma und Protractor vorkonfiguriert und können „out of the box“ testgetrieben entwickelt werden.

TDD ist also auch für die Entwicklung von Webanwendungen eine sehr gute Praxis, um qualitativ hochwertigen und gut getesteten Quellcode zu generieren.

Im Zusammenspiel mit anderen Praktiken wie Pair-Programming und Clean Coding ergeben sich sehr gute Synergieeffekte, wodurch Systeme sehr effektiv und effizient weiterentwickelt und gewartet werden können.

20. April 2018
Nico Foerster
0

Erfolgreiche Kooperation zwischen Studenten der Hochschule Zittau/Görlitz und Saxonia Systems

Zum Abschluss des Moduls Softwareengineering im Informatikstudium an der Hochschule Zittau/Görlitz ist ein dreimonatiges Praxisprojekt vorgesehen, in dem Studenten ihre in den vergangenen Lehrveranstaltungen erworbenen Fähigkeiten unter Beweis stellen müssen. Für die Studenten am Hochschulstandort Görlitz ergibt sich der günstige Umstand, dass in der Stadt mehrere kooperationswillige IT-Firmen ansässig sind. So hat sich auch Saxonia Systems bereiterklärt, eine Gruppe von Studenten bei ihrem Praxisprojekt zu unterstützen.

Mit dem Ziel, den Studenten einen realistischen Einblick in die agile Softwareentwicklung zu gewähren, hat sich Saxonia dazu entschieden, das bewährte Vorgehensmodell Scrum anzuwenden. Dabei werden von einem Entwicklerteam unter Leitung des Scrum-Masters in Iterationen bzw. Sprints Softwareinkremente entwickelt, die dem Kunden von Beginn an einen gewissen Mehrwert bieten. Mit jedem Softwareinkrement werden neue Funktionalitäten entsprechend der Priorisierung des Kunden umgesetzt. Die Aufgaben des IT-Unternehmens bestehen darin, das Thema des Projekts vorzugeben und die Rolle des Product Owners einzunehmen. Somit repräsentiert Saxonia Systems den Kunden, der gegenüber dem Scrum-Team durch den Product Owner in Person von Nico Förster (Softwareentwickler) vertreten wurde. Das Scrum-Team setzte sich hauptsächlich aus den drei Studenten Marco Gotthans (Scrum-Master und Entwickler), Paul Bachmann und Johannes Thies (beide Softwareentwickler) zusammen, welche sich folgender Herausforderung stellten:

Es wird eine Software angefordert, die den Benutzer bei der Auswahl und Bestellung von Pizza unterstützt. Dafür sind die Speisekarten von drei Görlitzer Pizzalieferdiensten im Programm zu hinterlegen und auch Besonderheiten wie Pizzapakete und Rabatte zu berücksichtigen. Der Benutzer hat die Möglichkeit, die Anzahl an Personen und die durchschnittlich verspeiste Pizzamenge anzugeben und erhält anhand dieser Eingaben eine optimale Pizzabestellung (bestes Preis-Leistungsverhältnis) zu jeder der drei Pizzerien ausgegeben. Da diese Bestellung zwar den Pizzabedarf deckt, jedoch unter Umständen wenig abwechslungsreich ist, soll der Benutzer die Möglichkeit haben, das Ergebnis durchzuwürfeln. Dadurch werden zufällig unterschiedliche Pizzen ausgewählt, so dass die Bestellung immer noch den Bedarf deckt, jedoch teurer ausfallen kann. Die Software soll auch einen Maximalbetrag berücksichtigen können, um ein gewisses Budget nicht zu überschreiten. Die letzte Anforderung bestand darin, durchgeführte Bestellungen speichern zu können, um sie später z.B. für Abrechnungszwecke erneut aufrufen zu können.
Bei der Auswahl der Technologien wurde den Studenten freie Wahl gelassen, so dass sie sich für eine Spring Applikation mit Webfrontend entschieden. Es wurde folgender Technologiestack verwendet: Java, Spring Boot, Hibernate, H2- und MySQL-Datenbank, Thymeleaf, Lombok, HTML, JavaScript.

Bereits am Ende der ersten Iteration konnte das Team dem Product Owner ein überraschend umfangreiches Softwareprodukt präsentieren. Die Optik des Webfrontends hat direkt überzeugt, da sie sich am Design der Saxonia Webseite orientiert. Nach der Abnahme des Inkrements durch den Product Owner wurden durch selbigen die zu realisierenden Anforderungen für das nächste Softwareinkrement vorgestellt. Aufgetretene Fragen wurden gemeinsam geklärt, Probleme und Vorgehensweisen diskutiert. Bei der im Anschluss stattfindenden Retrospektive erhielt das Scrum-Team wertvolle Unterstützung vom Saxonia Mitarbeiter Michael Klose (Softwareentwickler), welcher durch jahrelange Projekterfahrung und die Vorstellung verschiedener Varianten der Scrum-Retrospektive das Praxisprojekt bereicherte.

Mit jedem Sprint im Zweiwochenrhythmus wuchs der Funktionsumfang der Anwendung zur Zufriedenheit des Product Owners. Bei Test und Probebestellungen wurde deutlich, dass sich der ein oder andere Bug eingeschlichen hatte und das Scrum-Team selbst den Drang nach Refactorings (Verbesserung und Härtung des Programmcodes) verspürte. Fehlende Softwaretest (Unit Tests) erschwerten die Refaktorisierung und hätten bereits präventiv Bugs, vor allem in der Berechnungslogik verhindern können. Michael Klose und ich haben auf Wunsch des Teams auch ein Code-Review durchgeführt, dessen Ergebnisse dankend aufgenommen und entsprechende Verbesserungen vorgenommen wurden.

Das finale Produkt wurde sowohl bei der Abschlusspräsentation in der Hochschule Zittau/Görlitz, als auch im Rahmen eines Meetings am Standort Görlitz der Saxonia Systems vorgestellt. Die Reaktionen waren durchweg positiv und das Team hat zu Recht Lob für die gute Arbeit erhalten. Besonders wichtig ist es, dass den Studenten die Vorteile von bewährten Verfahren der Softwareentwicklung wie Scrum, Test-Driven-Development, Clean Code und Refactorings vermittelt wurden. Die intensive Betreuung durch Saxonia, die deutlich über die Anforderungen der Hochschule an das Unternehmen hinausging, hat sich am Ende bezahlt gemacht. Die Studenten haben wertvolle Praxiserfahrungen sammeln können und Saxonia hat im Gegenzug ein optisch und funktional tolles Produkt erhalten, wie die nachfolgenden Bilder beweisen.

Erfolgreiche Kooperation zwischen Studenten der Hochschule Zittau/Görlitz und Saxonia Systems!!!

 

29. Januar 2018
Sven Jänicke
0

Aktuelle Trends und Herausforderungen in der Softwareentwicklung

… das sagten die Teilnehmer der iJS und W-JAX

Dass nicht nur in Sachsen was geht, sondern vor allem auch an unserem Hauptsitz in München, zeigten Ende letzten Jahres die „International JavaScript Conference“ und die „W-JAX“. Beide Konferenzen fanden kurz nacheinander statt und lockten zahlreiche Besucher in die bayrische Landeshauptstadt.

Wie schon die S&S Media Group als Veranstalter der iJS (international JavaScript Conference) feststellt, ist „JavaScript [mittlerweile] überall: kaum ein digitales Business kann heute auf JavaScript und high-level Frameworks, wie Angular, React, oder NodeJS verzichten.“ Da wundert es kaum, dass diesem Thema auf der iJS vom 23.-27.10.2017 im Holiday Inn Munich City Centre eine eigene Konferenz mit zahlreichen Keynotes, Sessions und Power Workshops gewidmet wird. Auch die W-JAX beschäftigt sich zum Teil mit diesen Themenfeldern, bietet aber zusätzlich noch zahlreiche weitere Impulse im Bereich Enterprise-Technologie, Softwarearchitektur, Agilität & Java.

 

Wir nutzten bei beiden Konferenzen die Gelegenheit, uns intensiv mit der Community auszutauschen und hatten deswegen einige Fragen im Gepäck, die wir an die Teilnehmer der Konferenzen richteten. Insgesamt konnten wir fast 100 Umfragen durchführen, die sich in gleichen Teilen auf die beiden Veranstaltungen aufteilten. Wir danken an dieser Stelle noch einmal allen, die sich die Zeit genommen haben, sich an unserer Befragung zu beteiligen. Nur durch einen intensiven Austausch mit Partnern, Kunden und Community kann es gelingen, sich stets zu verbessern. Diesen Ansatz der kontinuierlichen Verbesserung, der auch im agilen Manifest verankert ist, verfolgen wir nicht nur in unseren Projekten, sondern leben wir auch unternehmensweit.

Während unsere Experten Manuel Mauky und Alexander Casall zu Themen wie „Angular-Anwendungen mit Redux“ und „Offlinefähige Desktopanwendungen mit Angular und Electron“ sprachen, wollten wir von unseren Interviewpartnern zuallererst wissen, welche Frameworks und Sprachen sie in ihren aktuellen Hauptprojekten einsetzen. Am häufigsten wurden Angular und JQuery genutzt, dicht gefolgt von JavaEE und Spring. React kam dagegen beispielsweise noch recht selten zum Einsatz. Dabei nutzten 72 von 88 Befragten JavaScript, 69 HTML und 51 Java als Programmiersprache. Ruby, Groovy und Coffeescript dagegen wurden kaum verwendet und bekamen jeweils maximal 5 Stimmen.

 

Natürlich interessierte uns nicht nur, mit welchen Technologien momentan gearbeitet wird, sondern vor allem in welche Richtung sich die Trends der Softwareentwicklung bewegen. Immer mehr Anwender von Geschäftsanwendungen erwarten moderne Webanwendungen anstelle bestehender Desktop-Software. Die Usability von Bestandssoftware trifft in Zeiten von modernen B2C-Applikationen oft nicht mehr die Erwartungshaltung der Nutzer und es werden immer mehr webbasierte Lösungen etabliert, die ihre Nutzer aktiv in der Arbeit unterstützen. Daher ist es auch nicht verwunderlich, dass 70 % der Befragten planen, in nächster Zeit mit Angular, React oder einer anderen reactiven Technologie (z.B. ReactiveX, RxJS, …) zu arbeiten. Vue.JS (14 Stimmen) und JavaFX (3 Stimmen) spielen dagegen bei den Umfrageteilnehmern nur untergeordnete Rollen.

 

Die Hälfte der Befragten konnte sich schon recht genau positionieren und hatte sich auf Angular, React oder zumindest eine reactive Technologie festgelegt. Rund 20 % dagegen waren noch indifferent und konnten sich noch nicht zwischen Angular oder einer reactiven Technologie entscheiden. Hilfestellung könnte hier die von uns evaluierte Entscheidungsmatrix bieten, die mithilfe eines Fragenkatalogs eine persönliche Technologieempfehlung gibt. Diese basiert auf den Erfahrungen unserer Webexperten.

Weiterhin entscheidend bei der Auswahl einer geeigneten Programmiersprache oder eines Frameworks ist selbstverständlich auch der Inhalt des eigentlichen Projektes. Wir fragten daher, was die Umfrageteilnehmer in ihrem Hauptprojekt tun. Der Großteil der Befragten beschäftigte sich hier mit Softwareevolutionsprojekten (61 Stimmen), dicht gefolgt von Neuentwicklungen (56 Stimmen). Rund ein Fünftel der Umfrageteilnehmer beschäftigte sich in ihrem Arbeitsalltag mit DevOps. Je nachdem, ob man eine bestehende Software wartet oder ein „grüne Wiese“-Projekt auf dem Tisch hat, sind die Spielräume bei der Auswahl der Programmiersprachen und verwendeten Tools natürlich sehr unterschiedlich breit.

 

Nachdem wir nun etwas näher herausgefunden hatten, womit die Befragten, bei denen es sich zum Großteil um Softwareentwickler verschiedenster Nationalitäten und aus unterschiedlichsten Branchen und Unternehmensgrößen handelte, wollten wir auch wissen, was sie im aktuellen Projekt am meisten behindert. An dieser Stelle gaben wir bewusst eher offene Antwortmöglichkeiten, wie „schlechter Code“ oder „schlechte Architektur“ vor, die dem Interviewteilnehmer noch Spielraum für Interpretation gaben und somit die Befragten bewusst dazu auffordern sollten, näher auf die Probleme einzugehen und gegebenenfalls einen ersten Dialog zu Problemlösung zu fördern.

Die häufigsten genannten Probleme sind der folgenden Grafik zu entnehmen. Neben den hier auftauchenden Antworten, bei denen sich „unklare Anforderungen“ nach wie vor als eines der Hauptprobleme darstellte, gab es auch einige freie Antworten. Relativ häufig wurde hier „legacy code“, „Warten auf den Auftraggeber / den Kunden“ oder „stark gewachsene und unübersichtliche Softwarearchitektur“ genannt.

 

 

Schlussendlich wandten wir uns noch einigen Fragestellungen aus dem Bereich „Moderne Webentwicklung“ zu, um hier zu prüfen, welche Trends sich tatsächlich von der Community bestätigen lassen oder welche Themen zwar im Netz „gehypt“ werden, aber im tatsächlichen Entwickleralltag noch nicht angekommen sind. Einer dieser Trends in der IT ist beispielsweise GraphQL. Hier stellten wir erst einmal die grundsätzliche Frage, wie die Konferenzbesucher zu der Technologie standen. Lediglich ein Viertel der Befragten plante den Einsatz dieser REST-Alternative für die Zukunft oder hatte GraphQL bereits im Einsatz, während immerhin fast die Hälfte noch nie von der Technologie gehört hatten.

 

Wir wollten hier außerdem noch wissen, ob die Befragten in ihren Projekten Cloud-Technologien einsetzen. Hier war das Verhältnis der Antworten relativ ausgeglichen. 45 % der Umfrageteilnehmer bejahten hier, während die restlichen 55 % nicht, oder zumindest nicht in ihrem Hauptprojekt, mit Cloud-Technologien arbeiteten. Die zweite Frage aus diesem Themenblock war, welche Technologie die Befragten aktuell für das State-Management verwendeten. Zur Auswahl standen React/Angular (ohne Dritt-Framework für das State-Management), Redux oder MobX. Während letzteres lediglich eine Stimme bekam, setzte der Großteil der Umfrageteilnehmer (knapp 50 %) kein Drittframework ein und rund 25 % arbeiteten mit Redux, während wiederum ca. 20 % hier keine Antwort gaben, was das Ergebnis der Umfrage leider etwas verfälscht.

Sie interessieren sich für weitere Umfrageergebnisse? Dann stöbern Sie doch einfach noch ein wenig in unserem Blog, und lesen Sie, welche aktuelle Trends und Herausforderungen in der Softwareentwicklung wir auf der solutions.hamburg 2016, der OOP 2017, der WJAX 2016 oder der DWX 2017 erfragen konnten.

 

30. November 2017
Max Wielsch
0

In Sachsen, da geht was

Ein Bericht vom JUG Saxony Day 2017

Am 29. September 2017 fand im Hotel Radisson Blu Radebeul der nunmehr 4. JUG Saxony Day statt. Über 500 Teilnehmer zählte die Konferenz dieses Jahr und konnte damit ein erneutes Wachstum verzeichnen. Trotz bisher stetig steigender Teilnehmerzahlen konnte dennoch eine familiäre Atmosphäre bewahrt werden. Mit welchen Erwartungen wurde die Konferenz gestartet und wie sollen diese weiterhin erfüllt werden? Diese und weitere spannende Fragen konnte ich in einem Gespräch mit den “Machern der Konferenz” — dem JUG Saxony (e.V.) — klären.

JUG Saxony Day 2017

Copyright JUG Saxony e.V. Quelle: hier.

Der Ursprung der Konferenz sind die regelmäßigen Veranstaltungen des JUG Saxony, die immer an wechselnden Orten stattfinden, um eine Vernetzung von Java-Entwicklern und an der Softwareentwicklung Interessierten zu ermöglichen. Die Treffen in Form der User-Group-Veranstaltungen mit Vorträgen zu Themen rund um Java und Softwareentwicklung stellen ein Angebot für jedermann dar, der an der Lösung von praktischen Problemen in der Softwareentwicklung interessiert ist. Zusätzlich zu den vielen Informatik-Studiengängen in Sachsen, die ein theoretisches und teilweise praktisches Fundament für die Ausbildung von Softwareentwicklern in Sachsen bilden, stellen die Veranstaltungen von User Groups wie dem JUG Saxony ein praktisches Ergänzungsangebot dar.

In Sachsen, da geht was!

Die Veranstaltungen des JUG Saxony kamen gut an und das Feedback aus der Community ergab, dass eine ganztägige Veranstaltung wohl zu einer noch stärkeren Beteiligung und einem noch effizienteren Weg der Wissensvermittlung führen würde. Schließlich wurde 2014 der erste JUG Saxony Day (JSD) an der TU Dresden organisiert. Um einen “Blick über den Tellerrand” zu werfen und sich in der Community auszutauschen, kamen nun Jahr für Jahr mehr Besucher. Es treffen sich Softwareentwickler und Unternehmen aus Sachsen und ganz Deutschland.

Im nun vierten Jahr merkt man, dass alles “wie am Schnürchen“ läuft. Das Radisson Blu als aktueller Veranstaltungsort, aber auch die Organisation der Speaker-Tracks und Themen tragen dabei sehr zur angenehmen Atmosphäre auf dem JSD bei. Ab acht Uhr morgens trifft man die ersten bekannten Gesichter beim JSD. Mal ist es ein ehemaliger Kommilitone aus Studienzeiten. Dann sind es Kollegen, die früher einmal mit in derselben Firma oder sogar im selben Projekt gearbeitet haben. Ein Plausch über den Stand der aktuellen Projekte und das anstehende Programm des JSD sind dann natürlich Pflicht.

Neun Uhr ging der Keynote-Vortrag los: Stefan Zörner gab einen Einblick in die Methoden und Werkzeuge von Architekten und beantwortete die Frage, wie Software-Architektur im Team umgesetzt wird. Thematisch waren viele der Vorträge beim JSD sehr gut einem Teilgebiet der Architektur zuzuordnen. Mit Architektur als Meta-Thema und einem sehr breiten Spektrum an Vorträgen war also für jeden etwas dabei. Zwischen den Vorträgen fand man immer wieder zueinander, um weiter zu diskutieren. Man hatte das Gefühl, das Ambiente führte die Wege der Teilnehmer automatisch zueinander.

Die Größe des JSD ist laut dem JUG Saxony jetzt genau richtig – und laut einer Umfrage des JUG Saxony ist es genau die bereits erwähnte familiäre Atmosphäre, die die Teilnehmer so begeistert und nun schon seit vier Jahren immer wieder anlockt. Statt weiterem Wachstum wird die Erhaltung der Qualität angestrebt. Für die Zukunft hofft man auf eine stärkere Unterstützung von Community getriebenen Veranstaltungen wie dem JSD durch Politik und kommunale Institutionen. Denn mit dieser Konferenz hat die Java Community in Form des JUG Saxony eine Veranstaltung geschaffen, die Leute aus ganz Deutschland und auch dem Ausland anzieht und zeigt, dass in Sachsen in Sachen Softwareentwicklung was geht. Dieses Wertes sollte sich jedermann und insbesondere das Land Sachsen bewusst sein.

Mich persönlich haben dieses Jahr Vorträge zu Themen wie Refactoring von monolithischen Systemen, Überblick zu den Architekturbestandteilen bei Microservice-Umgebungen und auch das Logging in solchen Umgebungen und die Überwachung der Systeme angezogen.

Nächstes Jahr stehen dann gleich zwei Jubiläen an, die es zu feiern gilt: Der JUG Saxony e.V. veranstaltet sein 100. User-Group-Treffen und der JUG Saxony Day feiert seinen 5. Geburtstag. Ich persönlich freue mich schon sehr auf den nächsten JUG Saxony Day und bin sicher, dass ich auch nächstes Jahr bekannte Gesichter treffe und mir neue spannende Themen aus der Praxis von Profis anhören darf.

17. April 2017
Stefan Saring
0

LeafletMap – a map component for JavaFX

JavaFX is the new de facto standard for desktop Java application for some years now. Although, it already provides lots of typical UI components, there is always demand for other controls with special requirements for the application to be build.

mehr

10. März 2017
Denny Israel
0

React + Redux + HATEOAS

When developing a web application with ReactJS it is often a good idea to use it in combination with the Redux architecture. This gives us good and precise control about the application state and all actions that change the state. All view changes must be executed as actions on the redux store and thus the central application state. When dealing with a RESTful backend we have to cope with asynchronous requests and thus have to deal with long running requests, error responses, missing data. Furthermore when the backend uses HATEOAS we have to deal with getting and managing the necessary request links. mehr

3. März 2017
Sven Jänicke
0

Zusammenarbeit – eingespielte Teams als Erfolgsgarant?

Alle Jahre wieder – im November 2016 waren wir auf der WJax in München. Wie es viele der Teilnehmer schon gewohnt sind, haben wir erneut eine Umfrage durchgeführt. Bei den letzten Veranstaltungen, wie der DWX mit Desktop vs. Web oder der solutions hamburg mit dem Thema Digitalisierung, haben wir uns immer einem speziellen Thema gewidmet. Im Falle der wjax lag der Fokus diesmal nicht auf einem inhaltlichen Fachthema, sondern dem Arbeitsumfeld der Befragten.

mehr

27. Februar 2017
Stefan Barth
0

Raspberry Pi Hackathon

hackathon-raspberry-pi-saxonia-systems

Hackathon

Am 4. und 5. Dezember fand der mittlerweile zweite Hackathon am Standort Dresden statt. Während es im ersten Event um die Entwicklung eines Chatclients mit unterschiedlichen Technologien ging, lag diesmal der Fokus auf der Entwicklung von mehreren HMI (Human Machine Interface) Showcases für das Raspberry Pi. Die Besonderheit lag darin, dass jedes Raspberry mit einem neuen 7” Multitouch Display ausgestattet war und dafür eine passende HMI Anwendung auf Basis von JavaFX entwickelt werden sollte. Im Vorfeld wurde dazu ein Maven Projekt aufgesetzt, welches ermöglicht dass die Anwendung als Jar auf das Pi kopiert und ausgeführt wird. Mit dieser Vorlage konnten alle Teilnehmer zum Hackathon ohne Einarbeitung gleich loslegen und mit dem Programmieren starten. Nach ca. 24h Hacking sind am Ende sechs tolle Anwendungen entstanden, die hier kurz vorgestellt werden:

Team Aqua

Der Grundgedanke bei dieser Idee war es eine Teambuilding Möglichkeit für verteilte Teams zu haben. An jedem Standort gibt es für jedes Team ein Raspberry Pi auf dem ein Aquarium mit Fischen angezeigt wird. Die Nutzer können mittels Interaktionen auf dem Bildschirm die Fische entweder füttern oder verjagen und die Tiere reagieren darauf. Mittels des SynchronizeFX Frameworks ist es geplant, dass sich mehre Aquarien untereinander synchronisieren können und das Team sich somit um nur ein Aquarium kümmern muss.

team-aqua-saxonia-systems

Team Auto

Fernsteuerbare Modellautos / Flugzeuge / Drohnen etc. erfreuen sich zur Zeit großer Beliebtheit. Umso neugieriger ist man, wenn eine eigene Fernbedienung entwickelt werden kann. Dazu wird eine Schnittstelle angeboten (bei diesem Beispiel lief die Kommunikation über WLAN), mit der Befehle direkt an ein RC Auto gesendet werden können. Die Anwendung für das Raspberry Pi besteht aus zwei Slidern zum Regeln der Geschwindigkeit und der Steuerung der Achse. Das Auto besitzt als zuätzliches Modul noch eine Kamera, dessen Bild direkt auf das Display des Raspberries übertragen wird. Mittels eines Switches können die beiden Slider dann auch zur Steuerung der Kamera verwendet werden, wodurch man eine eigene, fernsteuerbare Kamera hat.

team-auto-saxonia-systems

Team Poolplatz

Mitarbeiter, die die meiste Zeit beim Kunden vor Ort und nicht am Hauptsitz in Dresden sind, stehen häufig vor dem gleichen Problem: An welchem Poolarbeitsplatz kann ich heute sitzen? Früher musste man sich im Intranet mit Hilfe eines Excel Sheets einen freien Platz für einen bestimmten Zeitraum suchen oder sich bei der Sekretärin melden, damit diese die Suche für einen übernimmt. In Folge dieses Problems entstand eine Webanwendung namens Poolplatz, mit dessen Hilfe Plätze einfach und schnell gebucht werden konnten. Um diesen Prozess noch weiter zu vereinfachen, wurde eine Anwendung für das Raspberry Pi entwickelt. Dieses steht nun am Empfang und der Mitarbeiter kann darüber seinen Arbeitsplatz buchen. Dazu wählt er mittels einer Swipegeste sein Wunschstockwerk aus und sieht auf einem Blick welche Plätze noch zur Verfügung stehen. Um einen freien Platz zu buchen klickt der Mitarbeiter einfach auf einen solchen und bestätigt die Buchung.

team-poolplatz-saxonia-systems

Team Smart Home

Mit Smart Home werden alle elektronischen Geräte im Haushalt vernetzt und diese können über weitere Eingabegeräte bedient werden und das sogar von außerhalb. Möchte man morgens ein warmes statt kaltes Bad haben, so hatte man früher nur die Möglichkeit die Heizung am Vorabend aufzudrehen. Dabei wurde jede Menge Energie verschwendet. Mittels Smart Home kann man sich einfach einen Zeitplan ausdenken, wann die Heizung betrieben werden soll, z. B. um 4 Uhr morgens. Dann hat die Heizung immer noch genug Zeit das Bad vorzuwärmen ohne Energie zu vergeuden. Genau diesen Anwendungsfall hat sich das Team Smart Home angenommen, indem die Heizung gesteuert und der Energiehaushalt abgefragt werden kann.

team-smarthome-saxonia-systems

Team Synthesizer

Mittels dieser Anwendung ist es möglich das Raspberry Pi in einen Synthesizer bzw. einen Hüllkurvengenerator zu verwandeln und damit mehr oder weniger Musik zu erzeugen. Die Hüllkurve bezeichnet die vier Phasen, die für die Generierung eines Tones notwendig sind. Durch das Drücken eine der Tontasten beginnt die Attack Phase. Dies ist die Zeit, in der die Spannung von 0 bis auf ihr vorgegebenes Maximum ansteigt. Nachdem das Maximum erreicht wurde, beginnt die Decay Phase, in der die Spannung absteigt in der der Ton gehalten wird (Sustain Pegel). Dieser Pegel gibt an wie hoch die Spannung ist, während die Taste gehalten wird. Sobald die Taste wieder los gelassen wird, beginnt die Release Phase, in der die Spannung wieder auf 0 absinkt.
Die Anwendung zeigt diese typischen ADSR Phasen und erlaubt deren Modifikation (daher auch Hüllkurvengenerator). Für ein wenig Abwechslung gibt es zusätzlich noch 12 Tasten um verschiedene Töne abzuspielen.

team-synthie-saxonia-systems

Team Meeting

Wer kennt das Problem nicht auch? Ich brauche in 5 Minuten einen Konferenzraum um ein kurzfristiges Meeting einzuberufen. Bisher musste etwas umständlich per Outlook ein passender Raum gesucht werden. Zudem ist es bisher auch schwer einsehbar von außen, welcher Raum gerade belegt ist. Gängige Praxis ist dann das Lauschen an der Tür oder einfach mal rein schauen. Das kann allerdings sehr peinlich aussehen. Diese Unannehmlichkeiten werden jetzt von der Meeting-App beseitigt. An jedem Konferenzraum befindet sich ein Raspberry Pi, auf dem die Anwendung installiert ist. Diese wird synchronisiert mit dem bisherigen Terminbuchungssystem (Outlook) und zeigt an welches Meeting oder ob derzeit ein Meeting im Raum abgehalten wird (auch praktisch um zu sehen, ob ich vor dem richtigen Raum stehe wenn ich einen Termin habe) und welche als Nächstes anstehen. Ist der Raum frei, so kann problemlos mittels einer einzigen Aktion der Raum für eine Stunde blockiert und auch wieder freigegeben werden.

team-meeting-saxonia-systems

31. Oktober 2016
Sven Jänicke
0

Digitalisierung – Industrie 4.0 oder nur Papierloses Büro?

Vom 07.-09.09.2016 waren wir als Saxonia Systems AG mit mehreren Speakern und Teilnehmern auf der solutions.hamburg unterwegs. Der Kongress zu Digitalisierung, Business und IT beschäftigte sich 3 Tage lang in 333 Sessions mit der Frage: „Wie funktioniert Digitalisierung in Unternehmen?“ und konnte damit wieder zahlreiche Interessierte auf das Gelände des Kampnagel in Hamburg locken.

mehr

22. Februar 2016
Andreas Post
0

Die dunkle Seite des Parsens

Performance Unterschiede bei der Verwendung von Nativen Queries vs. Prepared Statements mit Oracle

Native Datenbankabfragen in einer Anwendung erschweren im Allgemeinen deren Wartbarkeit bzw. die Möglichkeit, unabhängig von einer spezifischen Datenbank zu entwickeln. Im Rahmen der Performance Analyse einer Java-Altanwendung mit Oracle Datenbank konnten wir noch einen weiteren Aspekt entdecken, der gegen die Verwendung solcher Abfragen spricht: die Performance gegenüber Prepared Statements im Kontext einer Oracle Datenbank.

mehr