Den Horizont erweitern, einfach auch einmal über den Tellerrand hinaus blicken und noch dazu jede Menge coole Leute mit Ähnlichen Interessen treffen. All diese Erwartungen wurden für mich durch das Developer Camp 2016 in Würzburg erfüllt.

Die Veranstaltung ging über zwei Tage Freitag und Samstag, wobei mein Arbeitgeber so freundlich war die Kosten für diese ungewöhnliche und erstmalig stattfindende Fortbildung und die Übernachtung zu übernehmen. Für die ein oder andere aktuelle Problemstellung gab es dann auch jede Menge Hinweise und Ideen zur Lösung. Details folgen weiter unten.

Um nichts zu verpassen bin ich mit meinem Kollegen Sebastian sehr früh in Mannheim aufgebrochen auch weil die Strecke nach Würzburg voller Baustellen und Staugefahren ist – Ergebnis: wir waren etwas vor der Zeit am Veranstaltungsort, aber es hat sich gleich die lockere Atmosphäre und die professionelle Organisation des Camps gezeigt – man war bereits auf Frühankommer eingestellt – inklusive “Laufzettel mit Gewinnspiel” und dem wichtigsten für den Informatiker: frischer Kaffee.

So hatten wir bereits vor der Begrüßung die Möglichkeit uns bei den Sponsoren des Camps umzusehen und uns mit deren Entwicklern auszutauschen. Im weiteren Verlauf lagen die Sponsoren-Stände einfach einen Tick zu weit weg “um die Ecke” als dass man sie präsent genug wahrgenommen hätte.

Nach der kurzen Eröffnung und einer Einweisung “how to Barcamp” ging es denn auch schon los: Jeder konnte einzelne Sessions (geplant jeweils 45 Minuten) zu nahezu beliebigen Themen aus dem Developer-Bereich vorschlagen – das reichte von neuen Frameworks bis hin zu Softskills. So entstand binnen 20 Minuten ein fast vollständiger Plan für die kommenden zwei Tage – jeweils 4 Auswahlmöglichkeiten (plus den obligatorischen “null”-Fall: Pause/Essen/Trinken).

Das Format der Vorträge war in der Regel als offen Diskussion gestaltet, zumindest für die Sessions, die ich besucht habe. Durch den direkten Kontakt mit anderen Entwicklern entstanden so häufig neue Einsichten und Ansätze. Hier alle Sessions zu beschreiben die ich besucht habe, würde zu weit führen – daher hier nur die Highlights mit den wichtigsten Fakten in Kürze (ohne spezifische Reihenfolge). Wichtige Beiträge und Ergebnisse finden sich auch hier: https://github.com/developercamp/devcamp16

Völkerverständigung

“Wie erkläre ich das meinem Chef?” oder auch “Wie erkläre ich meinen Wunsch einem Entwickler?” waren in diesem Vortrag die zentralen Fragestellungen

Wichtigste Erkenntnis: Reden hilft! Zudem ist es für beide Seiten extrem hilfreich, wenn sich ein Entwickler (oder auch mehrere) einmal in der Situation des Anwenders wiederfinden (also die Aufgabenstellung einmal selbst lösen müssen), alternativ hilft es, den potentiellen Nutzer einmal bei seiner täglichen Arbeit zu begleiten. Erstaunlicher Weise hilft dies auch bereits in die Gegenrichtung – der Anwender lernt wie ein Entwickler denkt und arbeitet und welche Informationen für ihn wichtig sind – so entsteht eine viel klarere Vision des Produkts.

Performance

Was tun, wenn die Last plötzlich erheblich steigt, z.B. weil die Geschäftsidee so gut war, dass der Ansturm zu groß wurde. Natürlich galt es auch den Fall einer (d)DoS-Attacke zu berücksichtigen.

Die Ergebnisse lassen sich grob in zwei Rubriken einteilen – Sofort-Maßnahmen und Maßnahmen, die man in aller Regel eher mittelfristig umsetzen kann. Die Sofort-Maßnahmen waren schon eher klassisches Handwerkszeug: Caching für statische Inhalte, Offloading durch Anysnchrone Abarbeitung von Anteilen die sich asynchron erledigen lassen.

Eher den Code betreffend und mittelfristig orientiert waren hingegen Vorschläge was man bereits in der Applikation tun kann: Neben dem Einplanen von Lasttests und Profiling zur Identifizierung von Bottlenecks waren auch eher unkonventionelle Vorschläge dabei: Nur weil es ein Framework gibt, dass einem ggf. viel (lästige) Arbeit abnimmt, heißt es noch lange nicht, dass es diese Arbeit (gerne auch “Magic” benannt) immer absolut effizient erledigt. Ein umfassender Überblick über das eigene Datenmodell und die Möglichkeit es ggf. auch “direkt in SQL” mit einer Datenbankengine zu befragen kann oftmals erheblich zur Steigerung der Performance beitragen. Insgesamt wurde auch festgehalten, dass ggf. bereits in der Ausbildung der Blick über den Tellerrand der Software-Entwicklung hinaus erfolgen sollte.

Kommunikation im Team

Nein, hier ging es nicht um Softskills sondern um Software. Es gab einen regen Austausch über die verwendeten Techniken – von IRC bis Skype wurden die jeweiligen Erfahrungen samt aller Vor- und Nachteile diskutiert. Wichtiges Ergebnis: Es hängt davon ab, wer alles mit der Software arbeiten muss – Entwickler unter sich sind auch mit sehr technischen Lösungen zufrieden – wenn es mehr um Projektleitung oder gar ins Management geht, ist ein gutes Benutzerinterface Pflicht. Auch nicht immer unproblematisch sind mittlerweile mobile Clients. Von der Software zurück zum Softskill ging es dann bei der Frage wie man der Meldungsflut ggf. Herr (oder Frau) werden kann: Klare Vorgaben und Strukturen wie ein definierter “Operating”-Chat für absolut wichtige Meldungen helfen hier. Ebenso sollte es für Entwickler möglich sein, sich auch für eine gewisse Zeit voll und ganz auf seine Arbeit konzentrieren zu können und einmal “nicht erreichbar” zu sein.

DevOps

Ein umfassender Bericht verschiedener Leute, die sich breiter aufgestellt haben als nur “Software entwickeln” – immer wichtiger wird es auch (gerade im agilen Umfeld), die Software auch zu betreiben – man baut heute ja kein Produkt mehr, dass einmal ausgeliefert wird und dann erst einmal ohne größere Wartung/Korrektur läuft. Um so wichtiger ist es natürlich auch zu wissen wie das System dazu aussieht und wie man es am Laufen hält. Ein interessanter Aspekt war, dass es noch immer Vorbehalte und Ängste gibt: Ich für meine Seite kann sagen: Die Commandline beißt nicht und jeder der sich mit Software-Entwicklung etwas ernsthafter auseinander setzen will, sollte sich mit diesem mächtigen Werkzeug vertraut machen (vorzugsweise nicht nur mit dem “eigenen Lieblings-OS”).

Jenkins – das Allheilmittel?

Ein sehr unterhaltsamer und interessanter Talk über die Verwendung und die Möglichkeiten von Jenkins. Ergebnis: Mit Jenkins kann man sehr viel machen, die Software ist dank vieler Plugins für viele Aufgaben geeignet, auch wenn der Fokus primär auf Continous Integration (CI) liegt. Für bestimmte geschilderte Anwendungszwecke wie das Provisioning von mehreren Maschinen ist hingegen die Verwendung eines entsprechenden Spezial-Werkzeugs deutlich besser – z.B. Puppet, Chef oder Ansible.

100% Coverage – realistisch oder Illusion

Etwas überspitz formuliert war das Thema dieser Diskussion. Unter anderem wurde klar, es reicht nicht 100% Code-Coverage durch Unit-Tests zu haben. Vielfach ist dies gar nicht möglich oder nur mit sehr großem Aufwand. Vielmehr muss man bei der Coverage auf die Geschäftsabläufe (in Form von Code-Pfaden) und die Schnittstellen achten. Über alle Testarten von Unit über Integration bis hin zu Front-End-Tests 100% Coverage zu erreichen ist ein hehres Ziel, das man anstreben sollte, auch wenn man es wahrscheinlich nie ganz erreichen wird. Fakt ist, dass durch jeden sinnvollen Test die Software-Qualität gesteigert wird.

Provisioning mit Ansible

Für mich als Neuling ein sehr lohnenswerter Vortrag – bisher hatte ich mich kurz mit Puppet oder Chef beschäftigt, Ansible kannte ich nicht. Ich werde wohl in den kommenden Wochen ein wenig damit experimentieren. Der Charme von Ansible liegt in der einfachen Verwendbarkeit – die Provisionierung erfolgt rein durch eine SSH-Shell auf dem jeweiligen System und auch nur auf Anforderung – man kann das natürlich dann noch weiter automatisieren. Aber man braucht z.B. keinen spezialisierten Client/Agent auf der jeweiligen Maschine.

Die Bash-Shell – Bourne Again …

Ein sehr schöner Erfahrungsaustausch mit praktischen Beispielen, die man immer wieder braucht. Selbst als häufiger Shell-Benutzer habe auch ich noch einige Dinge dazugelernt. Insgesamt auch sehr unterhaltsam mit vielen Anekdoten zu den typischen Fehlern und Fehlerausgaben.

Selenium-Testing für GUIs

Aktuell habe ich ein Problem mit Selenium-Tests: Zu langsam und nicht immer aussagekräftig. Durch den Austausch mit anderen Entwicklern habe ich jetzt zumindest einmal neue Ansätze wie den Einsatz von Mink, ich muss einmal sehen was sich daraus in den kommenden Tagen ergibt.

Retro

Keine Agile-Veranstaltung ohne Retro … in dieser Session zum Ende des Camps ging es ganz allgemein um das Feedback über die zwei Tage – was waren echte Highlights, wo hat es geklemmt, wo kann man es noch (und ggf. wie) besser machen?

Insgesamt hat mir das Camp sehr gut gefallen und ich habe einiges neues gelernt und mich mit anderen Entwicklern austauschen können. Dazu trug unter anderem auch die gesellige Atmosphäre am reichlichen Buffet und beim gemeinsamen Grillen am Freitag Abend bei. Ein großes Lob an den Caterer, das Essen war sehr gut, ebenso die Getränkeversorgung. Wenn es eine Neuauflage gibt, werde ich mich wohl schnellstmöglich wieder anmelden.