Am 25. Juni ging unsere Tech’n’Drinks-Reihe mit dem Talk „FROM FLAT TO FANTASTICAL: SO ENTSTEHT 3D FÜRS WEB!“ in die nächste Runde – dieses Mal mit einem spannenden Einblick in die Welt der 3D-Webentwicklung. Unser Kollege Samuel Höra zeigte, wie sich mit three.js und Vue interaktive 3D-Modelle direkt im Browser umsetzen lassen – ganz ohne zusätzliche Tools.

Anhand von Wandbild-Produkten wurde deutlich, wie 3D-Technologien helfen können, Produktvarianten wie Material, Größe oder Textur intuitiver erlebbar zu machen. Nutzer können sich so ein deutlich besseres Bild machen – im wahrsten Sinne.

Zwei zentrale Takeaways aus dem Talk:

Schöne Optik reicht nicht: 3D entfaltet seinen echten Mehrwert erst dann, wenn das Materialerlebnis realistisch wirkt und dabei auch auf mobilen Geräten flüssig läuft (z. B. mit Tone-Mapping, Licht und 60 fps). Dann kann sich das auch in messbarer Conversion und besserem Upsell zeigen.

Ausprobieren gehört dazu: Wir schrauben, testen, verwerfen und finden so die Ideen, die uns wirklich nach vorne bringen.

Neben dem Vortrag gab’s natürlich auch wieder jede Menge Zeit für Austausch bei BBQ und Drinks.

Vielen Dank an alle, die dabei waren!

Am 10.10.24 hieß es „GraphQL – Verheißung oder Verhängnis? Ein praktischer Deep Dive in die kontroverse API-Technologie“

Die Sprache GraphQL bzw. GraphQL APIs versetzten Clients in die Lage, Ihre benötigten Daten je nach Use-Case selbst auszuwählen. GraphQL wurde häufig als Alternative zu REST APIs gesehen und löste in Diskussionen oft Emotionen aus: Fans waren von Typsystem, Flexibilität und Tooling begeistert, Skeptiker bemängelten fehlendes Caching, schlechte Performance und Sicherheitsprobleme.

In diesem Vortrag mit vielen Live-Demos zeigte Nils GraphQL anhand praktischer Beispiele auf. Es wurde besprochen, worin die Stärken und Schwächen von GraphQL liegen, in welchen Fällen es eine Alternative zu REST sein kann, ob und wie eine Migration funktionieren kann und welche Fallstricke es bei der Implementierung zu beachten gibt.

Nils zeigte uns im GraphQL-Backend Code-Beispiele in Java, die auch ohne Java-Kenntnisse zu verstehen waren und auf die jeweilige Programmiersprache mit dem passenden GraphQL-Framework übertragen werden konnten. Nach diesem Vortrag hatten unsere Teilnehmer eine Grundlage, auf der sie einschätzen konnten, ob GraphQL auch für Ihre Anwendung geeignet ist.

Zwei Key Points aus dem Talk:

• GraphQL APIs bieten Clients die Möglichkeit, Daten sehr gezielt für Ihre jeweiligen Use-Cases auszuwählen. Welche Möglichkeiten der Client hat, ergibt sich aus dem Schema, das für jede API angelegt werden muss.
• Die Ermittlung der Daten muss im Backend selbst implementiert werden. Es gibt Frameworks für zahlreiche Programmiersprachen, die bei der Implementierung einer eigenen GraphQL API unterstützen.

Es war wieder ein super spannender und informativer Abend, mit leckerer Pizza, top Drinks, Zeit zum Connecten und einem intensiven Austausch zwischen den Teilnehmenden. Wir sind schon gehypt für das nächste Mal!

Am Mittwoch, den 04.09.2024 hieß es „Off with Their Heads!“

Es war wieder Zeit für unser legendäres Tech’n’Drinks – diesmal unter dem Motto „Off with Their Heads! Design-Revolution mit Storyblok & Headless-Components“. Und was soll man sagen? Zwei unserer Team-Kollegen haben die Bühne so richtig abgerockt! Samuel Höra von myposter GmbH und Jonathan Wilke von JUNIQE haben uns mit Feuer und Flamme in die Welt der „Headless Content Management Systeme“ und „Headless Components“ entführt. Unser Office war gefüllt mit neugierigen Lauschern und der Vibe? Absolute 10/10!

Die Key Learnings aus beiden Talks:

Mit Storyblok und Nuxt kannst Du in kurzer Zeit eine funktionierende Webseite bauen.
Mit Headless Components lässt sich mit weniger Aufwand ein flexibles Designsystem aufsetzten, das sich präzise an die Anforderungen des Designers oder des Corporate Designs anpassen lässt. So steuern wir zum Beispiel Inhalte auf all unseren Landingpages zentral und verwalten sie flexibel.

Und weil es einfach cool war, geht es am 10. Oktober direkt in die nächste Runde! Also STAY TUNDED & SAVE THE DATE!

Am 16. Mai 2024 fand unser zweites Tech’n’Drinks Meetup in diesem Jahr statt und wir hatten das große Vergnügen, Sebastian Springer als Speaker bei uns zu begrüßen. Er stellte uns htmx vor – eine leichtgewichtige Bibliothek, die spannende neue Möglichkeiten für interaktive Webanwendungen bietet.

Sebastian zeigte uns, wie man mit htmx interaktive Webanwendungen bauen kann, ohne auf große Frameworks wie React oder Vue angewiesen zu sein. Mit praktischen Beispielen demonstrierte er, wie einfach es ist, htmx in bestehende Projekte zu integrieren und wie es die Kommunikation zwischen Client und Server optimiert. Dabei erklärte er auch, wo die Grenzen von htmx liegen und wann es besser ist, auf andere Lösungen zurückzugreifen.

Das Thema hat richtig eingeschlagen und bei allen für viel Gesprächsstoff gesorgt. Es war mega, wie viele Leute sich dafür interessiert haben und wie spannend die Diskussionen waren. Danke an alle, die dabei waren!

Wir freuen uns schon auf das nächste Tech’n’Drinks am 05. September 2024!

Freund des Hauses, Alex Lichter, war mal wieder bei uns und hat das Tech’n’Drinks Jahr 2024 eingeläutet. In seinem Talk über Nuxt hat er die neuesten Features, die im vergangenen Jahr eingeführt wurden vorgestellt. Zudem hat er uns, als Insider & Core Member, Einblick in die aufregenden experimentellen Funktionen, die die Art und Weise, wie wir mit Nuxt entwickeln, gegeben.

Sein Talk war mega unterhaltsam und spannend – für Nuxt-Veteranen als auch Neulinge in der Welt des Metaframeworks.

Im April haben wir Benedikt Terhechte bei uns in München zu einem grandiosen hybriden Tech-Meetup bei MYPOSTER begrüßt. Unterhaltsam, kurzweilig und gleichzeitig sehr spannend und aufschlussreich war es. In unserem Blog fassen wir die Insights aus Benedikt’s Talk über Dependency Management in einer komplexen Multi-Team Codebase zusammen und klären, wie am besten mit Abhängigkeiten in der iOS Entwicklung umgegangen werden kann.

Wo liegt eigentlich das Problem?

Aus technischen Gründen ist die Verwaltung von Abhängigkeiten unter iOS von höherer Relevanz als in anderen Sprachen / Plattformen. Das bedeutet aber nicht, dass sie nicht gelöst werden können. Die Erkenntnisse im Streben nach einer wohl-strukturierten Anwendung in anderen Sprachen können und sollten auch hier angewandt werden.

Die Herangehensweise: Creating Frameworks

Um die Abhängigkeiten unter iOS so überschaubar wie möglich zu halten, empfiehlt Benedikt die Aufteilung des Source Code in Module – sogenannte Frameworks oder Packages. Das kann beispielsweise ein Framework für die Chat Funktionalität oder ein Framework für die Settings / Einstellungen sein. Die Vorteile eines solchen Vorgehens sind eindeutig:

• Unterschiedliche Teams können gleichzeitig, quasi konfliktfrei an unterschiedlichen Features arbeiten
• Der entwickelte Code kann für mehrere Produkte (Targets) genutzt werden (z.B. Apple Watch, iOS, Apple TV, macOS). Grund hierfür ist, dass das Target nur den spezifischen Target-Code enthält, während die Frameworks den generischen Applikations-Code beinhalten.
• Die Kompilier-Zeit sinkt durch die Aufteilung in Frameworks deutlich. Dauert das Kompilieren unter iOS mitunter sehr lange, ermöglicht die Aufteilung in Frameworks, dass Swift die jeweiligen Frameworks für sich genommen kompiliert. Gleichzeitig wird der Kompilier-Prozess durch Parallelisieren und Cachen optimiert.

Framework bedingt Framework bedingt Framework im Quadrat

Der aufmerksame Leser denkt sich nun: “Klingt gut, aber dann bau’ ich mir so schnell Abhängigkeiten zwischen den Frameworks. Wo ist der Gewinn?”

Das stimmt natürlich, theoretisch. Beispielsweise muss eine Homepage wissen, wie viele Chats der Nutzer hat, oder ein Button auf dem Profile erlaubt einen neuen Chat zu öffnen, usw. Dies wiederum führt dazu, dass die unterschiedlichen Frameworks sich gegenseitig importieren.

In seinem Talk hat Benedikt das Prinzip einmal exemplarisch an seiner fiktiven App „Dackel Dackel Go“, Deutschlands führender App für Dackelfreunde, aufgezeigt.

In der App gibt es mehrere Sektionen, die der User besuchen kann – alles dabei, was der geneigte Dackelfreund eben so braucht:

_Daheim: Die Startseite

_Profil: Profile von Nutzern

_DackelTV: Dackel Livestreams

_Schnack: Chat zwischen Nutzern

_Nachrichten: Neuigkeiten und Nachrichten

_Sammlung: Dackel-Sammlung

Und schon allein mit diesen wenigen Frameworks ergibt sich schnell ein Bild wie folgender Abbildung dargestellt:

Es liegen zyklische Abhängigkeiten vor, die drei gravierende Nachteile mit sich bringen:

1. Da sich die Abhängigkeiten bedingen, kann der Compiler nicht ausschließen, dass eine Änderung an einer Abhängigkeit Einfluss auf andere Abhängigkeiten haben kann. Daher muss er zwangsläufig alle Frameworks neu kompilieren, was sehr lange dauert.
2. Da es kein definiertes Öffentliches Interface zwischen den Abhängigkeiten gibt, muss ein Entwickler, der an einem Framework arbeitet (etwa am Chat), im Nachgang immer kontrollieren und sicherstellen, dass alle anderen Frameworks (die Chat importieren) noch korrekt funktionieren.
3. Jedes weitere neue Framework (welches zwangsläufig viele andere importiert) erhöht die Komplexität der Codebase – nicht nur linear, sondern quadratisch.

How to break zyklische Abhängigkeiten: Dependency Injection Pattern

Um zyklische Abhängigkeiten zwischen Frameworks zu verhindern, gibt es laut Benedikt einen sinnvollen Weg: Dependency Injection Pattern. Dabei definiert jedes Framework ein Öffentliches Interface, und nur dieses kann genutzt werden, um auf die Funktionalität eines Frameworks zuzugreifen.

Darüber hinaus verwendet dieser Pattern eine zentrale Stelle, an der alle Abhängigkeiten vorgehalten werden. Somit muss z.B. in unserer fiktiven App „Dackel Dackel Go” die Sektion Schnack niemals DackelTV importieren. Stattdessen importieren sie beide den Dependency Injector (in Benedikt’s Beispiel „Belum“ genannt). Das Vorgehen ist dabei wie folgt:

1. Beim Start der App wird der Dependency Injector Belum initialisiert. Dabei werden alle existierenden Frameworks / Abhängigkeiten in ihm registriert. Dadurch hat nur Belum Zugriff auf alle Abhängigkeiten.
2. Die Individuellen Frameworks werden nun nach und nach initialisiert (je nachdem wann sie das erste mal benötigt werden). Diese bekommen dabei eine Referenz auf den Dependency Injector Belum zugewiesen.
3. Will später Sektion Schnack auf das Profil zugreifen, so fragt er Belum nach dem Profil. Schnack selber importiert aber nie das Profil, es wird nur über Belum zugewiesen.

Dieses Vorgehen erlaubt es, dass zur Zeit des Kompilierens keine Abhängigkeiten zwischen den Frameworks existieren müssen. Diese werden zur Laufzeit aufgelöst, genau dann, wenn die Anwendung beim Start Belum initialisiert.

Darüber hinaus ist es durch die Anwendung des Dependency Injectors möglich, den Import eines Frameworks durch ein anderes Framework individuell zu definieren. So werden bestimmte Basis-Frameworks (z.B. Kryptographie) nicht einfach von jedem beliebigen anderem Framework importiert. Das Spart Zeit und Kapazität.

Wie das im Resultat aussieht, zeigt folgende Abbildung:

Den exemplarischen Code für den Dependency Injector aus Benedikt’s Dackel-App findet ihr in folgendem Repository auf GitHub:

<https://github.com/terhechte/belum>

Danke, Benedikt, für Deinen spannenden Talk und den guten Abend, den wir zusammen hatten. Bis bald hoffentlich!

Benedikt ist als Entwickler für ein Berliner Stealth Startup tätig und bastelt in der Freizeit an der Präsentations-App „HyperDeck“. Zuvor war er als Team Lead an der Entwicklung der XING iOS App beteiligt, und davor viele Jahre mit der Instagram App „PhotoDesk“ als macOS Indie unterwegs. Wenn er nicht gerade Swift macht, macht er Rust.

Mehr über Benedikt:

terhech.de

Twitter

GitHub

Wir haben Alexander Lichter, Web App- und Frontend Entwickler, Nuxt.js Core Maintainer, Gründer und vielfach gebuchter Speaker, zu einem Remote Tech’n’Drinks begrüßt! Er hatte ein spannendes, aktuelles Thema im Gepäck: Nuxt 3! Das Framework von Vue wurde erst vor kurzem als Beta-Version veröffentlicht und bietet neue Möglichkeiten beim Schreiben von SPAs. Alex hat uns die Features der neuen Version gezeigt, die Unterschiede zwischen Nuxt 2 und Nuxt 3 erklärt und im Live-Coding veranschaulicht, warum die Neuentwicklung so viel mehr Komfort mit sich bringt.

In unserem letzten Tech‘n’Drinks am 2. September hat sich Jannis, Android Entwickler in unserem App Team, mit Jetpack Compose auseinandergesetzt, die Basics der reaktiven UI-Entwicklung erläutert und im Live Coding Insights zur Anwendung des neuen Frameworks von Google gegeben. In unserem Blog Beitrag fassen wir Jannis’ Talk für Euch zusammen.

Welches Problem löst reaktive UI-Entwicklung?

Ein grundlegendes Problem der UI-Entwicklung ist es, das UI einer Anwendung korrekt zu aktualisieren, wenn der Zustand der Anwendung verändert wird. Das ist zum Beispiel bei einer Serie von Eingaben des Nutzers der Fall. Hier wird bei jeder Eingabe des Nutzers potentiell eine Anpassung des UIs notwendig.

Klassischerweise wird ein UI initial in einem Grundzustand erzeugt und dann teilweise verändert, wenn es notwendig ist. Problem hieran ist, dass mehrere nacheinander ausgeführte Änderungen miteinander wechselwirken können und dadurch nicht zum gewünschten Ergebnis führen. So muss also bei jeder Änderung der aktuelle Zustand des UI berücksichtigt werden, um den gewünschten  Zielzustand zu erreichen.

Da bei komplexen User Interfaces nicht alle möglichen Zustandsveränderungen bedacht werden können, führt diese Vorgehensweise häufig zu Problemen.

Was ist reaktive UI-Entwicklung?

Reaktive UI-Entwicklung ist ein Überbegriff für eine Kombination verschiedener Paradigmen, die von verschiedenen reaktiven UI-Frameworks alle oder teilweise verwendet werden.

Mehr zu den zentralen Elementen der reaktiven UI-Entwicklung findet ihr hier:

So viel zum Hintergrund reaktiver UI-Frameworks, die wir bei myposter zur Entwicklung unserer nativen Mobile Apps nutzen. 

Für Android hat Google Ende Juli diesen Jahres das neue UI-Toolkit Jetpack Compose veröffentlicht, das die Entwicklung nativer Android Apps laut eigener Aussage schneller und viel einfacher machen soll. Was hinter dem neuen Toolkit von Google steckt und was Jannis davon hält, erfahrt ihr im zweiten Teil unseres Beitrags:

Reaktive UI-Frameworks sind zuerst in der Web-Entwicklung mit React populär geworden. Frameworks für die Entwicklung von nativer Mobile Apps sind nachgezogen: SwiftUI für iOS und Jetpack Compose für Android.

Was ist Jetpack Compose?

Jetpack Compose ist ein neues UI-Framework für Android-Apps, das von Google entwickelt wird. Compose verfolgt mehrere Ziele. Zum einen sollen die Erfahrungen aus der Entwicklung des alten View-Systems in Compose eingebracht werden, um problematische Bereiche des View-Systems in Compose besser zu lösen. Zum anderen sollen Kompatibilitätsprobleme mit verschiedenen Versionen von Android, wie man sie kennt, vermieden werden. Die Lösung: Jetpack Compose wird als Library mit der App ausgespielt und nutzt somit auf allen Versionen von Android das exakt gleiche UI-Framework.

Compose basiertet auf Kotlin

Jetpack Compose wurde für und mit der Programmiersprache Kotlin entwickelt. Das UI wird also komplett mit Kotlin-Code aufgebaut. Die Basis sind fünf Konzepte, die sich klar vom XML-basierten View-System unterscheiden. Wir stellen sie Euch vor:

Die Einschränkungen – aus unserer Sicht

Jetpack Compose ist ein noch sehr junges UI-Framework. Klar also, dass es noch nicht alle Funktionen hat, die man von einem ausgereiften Framework erwartet und die im Android-View-System vorhanden sind. Darunter fallen  z. B. Drag-and-Drop-Funktionen, Screen-Transition-Animation und Animationen für Listen. Wird aber sicher noch kommen.

Die Performance von Compose ist zur Zeit noch nicht so gut, wie die des View-Systems, aber in den allermeisten Situationen gut genug.

Die Preview-Funktion für Compose in Android Studio ist zwar deutlich mächtiger, als Previews für das View-System, aber auch noch wesentlich langsamer. Nach Änderungen am UI-Code muss erst der Code kompiliert werden, bevor die aktualisierte Vorschau angezeigt werden kann.

Eine weitere, eindeutige Einschränkung ist, dass Compose nur mit Kotlin verwendet werden kann. Und dabei auch nur mit bestimmten  Versionen von Kotlin zusammenarbeitet (z. B. funktioniert die aktuelle Version 1.1.1 von Compose nur mit Kotlin 1.6.10). Das kann dann zum Problem werden, wenn eine ältere Kotlin-Version in der App verwendet wird, oder aber eine neue Version von Kotlin, die von Compose noch nicht unterstützt wird.

Google hat eine Roadmap für die zukünftige Entwicklung von Compose veröffentlicht. Demnach soll es bei den genannten Einschränkungen in Zukunft Verbesserungen geben.

Was uns noch wichtig ist: Migration zu Compose

Apps können Compose integrieren, ohne den bestehenden Code komplett hierauf umzustellen. Um die Interoperabilität von Compose und dem View-System zu ermöglichen, enthält das Framework ComposeView und AndroidView. Mit ComposeView kann ein Compose-UI in das View-System eingebunden werden. AndroidView ist eine Composable-Funktion, mit der ein View-basiertes UI in Compose verwendet werden kann.

Was das bringt? Mit ComposeView ist es z. B. möglich, einzelne Screens einer App in Compose umzusetzen, indem ein Compose-UI mit ComposeView in ein Fragment oder eine Activity eingebettet wird. Eine Migrationsstrategie für Compose kann damit also sein, neue Screens mit Compose umzusetzen, aber eine Fragment- oder Activity-basierte Navigation beizubehalten. Bestehende Screens oder Custom Views können dann bei Bedarf mit Compose neu implementiert werden.

Andere von Google entwickelte Jetpack-Libraries, wie ViewModel, Navigation, Paging und ConstraintLayout können mit Compose zusammen verwendet werden und wurden, wo nötig, bereits an Compose angepasst.

Jetpack Compose unterscheidet sich grundlegend vom althergebrachten UI-System in Android. Der Umstieg auf Compose bringt deshalb eine Lernphase mit sich, in der man den deklarativen und reaktiven Ansatz verinnerlicht und die verschiedenen Komponenten von Compose kennenlernt.

Diese Lernphase hat sich für uns bei myposter ausgezahlt. Wir haben mittlerweile mehrere Projekte mit Compose umgesetzt und dabei weniger UI-bezogene Bugs, höhere Produktivität und, last but not least, mehr Developer-Happiness festgestellt :).

Rund 100 Tech-Begeisterte kamen zu unserem Tech’n’Drinks mit Golo Roden. An diesem Abend drehte sich alles um TypeScript, eine Programmiersprache von Microsoft, die JavaScript um neue Fähigkeiten erweitert – allen voran ein statisches Typsystem. TypeScript soll es einfacher machen, große und komplexe Anwendungen zu entwickeln, und deren Wartbarkeit verbessern. Da es vollständig abwärtskompatibel zu JavaScript ist, liegt die Einstiegshürde sehr niedrig. Aus diesem Grund wird in verschiedenen Projekten zunehmend zu TypeScript gewechselt. 

Was sich zunächst verlockend anhört, wirft aber auch Fragen auf: Läuft man nicht Gefahr, in einen Vendor-Lock-In zu geraten? Was, wenn TypeScript nicht so kompatibel ist, wie behauptet wird? Wie sieht es mit Support in der Community aus? Und wie gut verträgt sich TypeScript mit dem eigenen, etablierten Stil, JavaScript-Code zu schreiben? Das alles sind Fragen, die eine Migration nicht nur verzögern, sondern auch verhindern können. 

Der Speaker: Golo Roden 

Schon zum zweiten Mal war Golo Roden bei uns zu Gast. Golo ist Gründer und CTO der the native web GmbH, eines auf native Web- und Cloudtechnologien spezialisierten Unternehmens. Für die Entwicklung moderner Webanwendungen bevorzugt er JavaScript, TypeScript und Node.js und hat mit „Node.js & Co.“ das erste deutschsprachige Buch zu diesem Thema geschrieben. Darüber hinaus ist er journalistisch für verschiedene Fachmagazine und als Referent und Content Manager für Konferenzen im In- und Ausland tätig. Für sein qualitativ hochwertiges Engagement in der Community wurde Golo von Microsoft vierfach als Most Valuable Professional (MVP) ausgezeichnet. 

TypeScript ist JavaScript mit Superkräften

Im ersten Talk ging Golo auf die Theorie hinter TypeScript ein und erklärte uns, mit welchen Zielen es entwickelt wurde. Er zeigte uns, dass TypeScript JavaScript mit Superkräften ist. Das statische Typsystem hilft ungemein, besser strukturierten Code zu schreiben – aber es geht einem auch aus dem Weg, wenn man es nicht haben will. Auch wenn TypeScript jede Menge Vorzüge bietet, gibt es dennoch so manche Fallstricke und Stolpersteine, die man beachten sollte. So ist das größte Problem von TypeScript, dass man die Wahl zwischen einem mathematisch korrekten und einem pragmatischen Typsystem hatte – und man sich leider für zweiteres entschieden hat. Golo stellte in seinem Talk aber heraus, dass dennoch die Vorteile von TypeScript deutlich überwiegen und sich die Migration deshalb wirklich lohnt. 

Migration von JavaScript auf TypeScript

In seinem zweiten Talk tauchte Golo tief in die Praxis ein und teilte seine eigenen Erfahrungen mit uns. Er selbst haderte auch lange mit der Entscheidung von JavaScript auf TypeScript umzustellen. Erst im Herbst 2019 und nach langen Überlegungen fasste er dann doch den Entschluss, sein Kernprodukt von heute auf Morgen komplett auf TypeScript umzustellen. Anhand konkreter Beispiele zeigte er uns bei einem Live Coding wie sich ein JavaScript-Modul zu TypeScript migrieren lässt. Dabei ging er auch auf mögliche Komplikationen bei der Umstellung ein und zeigte uns, wie man diese relativ einfach beheben kann.

Insgesamt konnte uns Golo von TypeScript überzeugen und uns zeigen, dass sich die Migration von JavaScript auf TypeScript wirklich lohnt und gar nicht so schwer ist. Darüber hinaus hat sich Golo mit seiner lockeren und humorvollen Art wieder Mal als ein hammer Speaker präsentiert und so viele neue Golo-Fans gewonnen. Es war einfach ein toller Abend! Wir freuen uns schon sehr, Golo bald wieder bei uns begrüßen zu dürfen!