Sessions in this room

1. 12:50 in Talks B

   Integration und Migration von systemkritischen Legacy-Anwendungen (Christoph Ehlts & Marcus Deiters)

   Vor zwei Jahren sind wir mit einer PL/SQL-Anwendung aufgebrochen in die funktionale Welt. Auf dem bisherigen Weg Richtung Elixir/Erlang erlebten wir viele technische und organisatorische Überraschungen, viele erfreulich, einige nicht.

   Ein Erfahrungsbericht über …

   • die organisatorischen Hürden in der Umsetzung einer technischen Vision

   • die Migration und Integration von Legacy-Anwendungen in eine funktionale Umgebung.

   Die Hoffnung ist, Argumente zu liefern, um den üblichen Bedenken beim Wechsel in die funktionale Welt entgegenzutreten.

2. 10:30 in Talks B

   Effizient arbeiten mit Architecture Decision Records (ADR) (Johannes Dienst)

   Dokumentation gehört oft nicht zu den Lieblingsaufgaben im Softwareentwicklungsalltag. Das resultiert in vielen Fällen daraus, dass nicht klar ist, warum etwas dokumentiert werden sollte. Der in der Praxis gelebte Ansatz einen Dokumentationsort, zum Beispiel in Form eines Wikis, ist zum Scheitern verurteilt. Entweder es wird kaum dokumentiert oder zu viel und es wird schwer Informationen zu finden, die man sucht.

   Ein leichtgewichtiger Ansatz ist arc42, bei dem je nach Bedarf die vorgegebenen Unterpunkte ausgefüllt werden. Dort werden im Unterpunkt neun Entwurfsentscheidungen dokumentiert, also genau die Entscheidungen, die die Softwarearchitektur entscheidend prägen. Die Auswirkungen von nicht dokumentierten Entscheidungen gehen von immer wiederkehrenden Diskussionen, bis hin zu fehlerhaften Folgeentscheidungen die das Projekt zum Scheitern bringen können. Doch wie können viele Entscheidungen effizient und nachvollziehbar dokumentiert werden?

   In diesem Vortrag wird ein kompaktes Format namens Architecture Decision Records (ADR) vorgestellt und gezeigt, wie sie effizient eingesetzt werden können. Neben Kleinigkeiten wie der Titelvergabe für eine ADR wird ein Lösungsvorschlag aufgezeigt, um bei einer großen Sammlung von Entwurfsentscheidungen (>50) nicht den Überblick zu verlieren. Dabei kommt der Docs-As-Code Ansatz mit AsciiDoc und JBake zum Einsatz, mit dem die technische Architektur in einer Microsite gerendert wird. Durch Tagging und eine effiziente Suche, wird die Dokumentation nicht nur lebendig, sondern zum täglichen Arbeitsmittel.

3. 12:00 in Talks B

   Opening Doors to Open Source (Jigyasa Grover)

   According to a recent survey by Github, only 4 % of open source participants & ideators are women and/or non-binary.

   This might be due to the fact that women especially find it intimidating to get started with contributing to open source. The talk will answer questions, throwing light on the issues that women usually have. It aims at introducing the audience to the world of FOSS and elaborate the vast range of opportunities ranging from coding to documentation, design, outreach and research. The talk aspires to inspire budding girl developers and showcase women who’ve made significant contributions to technology.

4. 14:30 in Talks B

   Leveraging Algebraic Data Types (Franz Thoma)

   In functional programming languages, Algebraic Data Types and Pattern Matching are ubiquitous, and they are a very powerful and expressive tool. Unfortunately, many mainstream languages, especially in the object-oriented spectrum, lack these features and resort to rather cumbersome subtyping and inheritance.

   But not all is lost! Leveraging an old GoF pattern together with Lambda syntax that by now has spread to most modern programming languages, we can emulate ADTs and pattern matching in virtually any programming language.

   Applications range from implementation of standard ADTs like Maybe, Tuples and Either over standard functional data structures like Linked Lists and Fingertrees, up to complex structures like ASTs or DSLs.

5. 15:20 in Talks B

   Self-Documenting Computation (Olaf Klinke)

   Undoubtedly, the standard format of sharing computations in the business world is the spreadsheet. But this quickly becomes unwieldy when complex algorithms are involved or deeply structured data are more appropriate for the problem at hand. So how to present the inner workings of an algorithm in such a way that it may be part of an invoice, to be checked by accountants? We advertise an idea that is actually as old as spreadsheets and show how, building on top of some popular Haskell packages, one can obtain an embedded domain-specific language for self-documenting computations.

6. 16:35 in Talks B

   Bringing experimentation to JavaScript (Yulia Startsev)

   What is the cost of changing an api? How can we measure it? JavaScript is one of the most widely used and run languages in the world. The committee behind the design of JavaScript, Technical Committee 39 of Ecma, has to keep in mind many potential use cases, and errors that might occur as the result of a design change. However we do not have a framework of how to do this. As a delegate, I felt that this was an area where the committee could benefit from. This talk will cover the work that is happening now to introduce such a framework of experimentation to our process, where we are and what kind of experiments we are currently running.

7. 17:25 in Talks B

   Engineering Principles of a highly effective team (Steve Robinson-Burns)

   So you know how to write code. You know how to work as an individual. But… how about as a team? When a team works well together, they can best fulfil the business function, while meeting personal emotional needs.

   In the past few years, at five companies, I’ve experienced a lot of different ways of working. Finally, at Previse, I was part of a team that solved problems together effectively. Sounds simple, but it had taken them a combined 80+ years of expertise to get there!

   The engineering team at Previse identified a methodology that guided their collaboration. Every day they engaged in the process of evolving it and embodying continuous learning.

   This talk is about better ways of working together. It’s worth accounting for how you’re just a bunch of emotional mortals. Identify your team’s unique characteristics, and get everyone on board.