Rückblick Helvetic Ruby 2025

Familiäre Community

Die Helvetic Ruby Konferenz war ein angenehmes Event, um in familiärer Atmosphäre alte Bekannte aus der Ruby-Community wiederzusehen. Das breite Spektrum an Themen hat zu vielen Gesprächen in den Pausen angeregt, teilweise noch unterbrochen durch ein fröhliches Babyglucksen. Der jüngste Teilnehmer war noch nicht mal 1-jährig, was die Familienfreundlichkeit der Community nochmal unterstreicht.

Spannende Lightning Talks

Der Tag begann – nach Gipfeli und Kaffee – mit einem Erfahrungbericht einer Ruby-Contribution. Ausgehend von der Idee zu einer Verbesserung für das CSV-Gem wurde der Weg vom initialen Issue, über einen PR und Diskussionen mit den Maintainern und schliesslich zu einem neuen kleinen PR aufgezeigt. Neben dem Erlebnis wurde hervorgehoben, dass die Kommunikation mit den Maintainern zu einem besseren Ergebnis für alle geführt hat.

Im weiteren Verlauf des Tages kamen Strategien zum Scaling von Rails-Anwendungen zur Sprache. Die Github-Mitarbeiterin zeigte gut auf, dass mit einer hohen Skalierung auch hohe Ausfallraten einhergehen können. Externe Abhängigkeiten und zu enge Koppelung von Daten und Logik wurden als Ursachen genannt. Neben Monitoring und einer passenden Team-Kultur wurden hierfür auch Disaster Recovery-Übungen und proaktives Optimieren von Datenbank und Background-Jobs angesprochen.

Die Lightning Talks unterhielten mit Bullshit Graphs und verwiesen auf Ruby Events.org . Andreas Maierhofer zeigte in seinem Lightning Talk «Custom RuboCop Rule» auf, wie man mit RuboCop eigene, hilfreiche Diagnositics direkt in den Editor bringen kann.

Ronan Duparcneur über das SEAT-Prinzip und musikalische Muster

Ronan Duparcneur hat auf unterhaltsame Weise anhand von «Temple of Love» (1992) von The Sisters of Mercy verschiedene Aspekte guter Test-Suites beleuchtet. So wie der Song in seinen Lyrics, im Schlagzeug und in der Gitarre wiederkehrenden Mustern folgt, sollten auch gute Tests einem klaren Muster folgen.

Er folgte dabei der von Gerard Meszaros ursprünglich vorgestellten SEAT-Klassifizierung: Setup, Exercise, Assert, Teardown. Diesen Rhythmus findet man auf allen Ebenen: vom schnellen fokussierten Unit-Test bis zum grossen integrativen System-Test. Diese Struktur hilf bei der Lesbarkeit und hebt den Zweck der einzelnen Tests hervor. Tests dürfen dabei Wiederholungen haben, das DRY-Prinzip aus dem Production-Code ist hier allerdings nicht hilfreich.

Ein weiterer Vergleich war die sprachliche Ebene. Während bei einem Liedtext poetisch gerne mal bewusst ein vulgärer Vergleich gewählt werden kann, sollten Tests nicht die Abstraktionsebene verlassen. Während einem Integrationstest mit Browserorchestrierung sollte man also nicht direkt in die Datenbank schauen. Passiert dies, weist es eher auf fehlende Funktionalität oder einen (oder mehrere) fehlenden Unit-Test hin. Grundsätzlich ist die «Story» eines Integrationstests oft schon mit dem Happy-Path erzählt. Die Fehlerszenarien können meist besser mit Unit-Test abgedeckt werden. Während der Entwicklung können System-Tests als Implementierungshilfe verwendet werden, letztlich besteht die Testpyramide aber aus vielen, schnellen, fokussierten Unit-Tests und wenigen, aufwendigen System-Tests. Wir wurden mehrfach und eindringlich darauf hingewiesen, «Temple of Love» zu hören.

Kyle d’Oliveira über «Deliberate Practice» und bessere Arbeitsqualität

Nach der Mittagspause haben wir von Kyle d’Oliveria einen Talk gehört, der schon länger in ihm schlummerte. Er erzählte uns von «Deliberate Practice» (etwa: reflektierte Praxis) als Methode zum besseren Erwerb und Verbesserung von Fähigkeiten. Imperfektion ist dabei nicht nur ein üblicher Bestandteil jeder Kunst, sondern eine essenzielle Zutat. In seiner Laufbahn als Entwickler und auch als Manager für Entwickler:innen hat er mehrfach beobachten können, wie ein einfaches Schema schneller zu höherer Arbeitsqualität führen kann:

• Ein Ziel setzen und den Weg planen
• Das Ergebnis sehen und Feedback sammeln
• Über das Feedback reflektieren
• Konzepte entwickelt, um es anders (besser) zu machen

Er zeigte die Ergebnisse eine Studie, die diesen Ansatz mit höherem Fähigkeitenzuwachs in Verbindung brachten. Der «Trick» ist in den meisten Fällen, einen Ablauf öfter zu machen und aktiv auf das Feedback zu achten. Ob das Feedback von anderen Menschen oder von Messwerten kommt, ist dabei weniger wichtig. Eines der Beispiele war, dass man in CodeReview schneller werden kann, wenn man es öfter macht. Hierfür kann es insgesamt schneller sein, wenn jedes Feature von zwei Personen reviewed wird, da so jeder im Team mehr Review-Übung bekommt und damit schneller wird. Gleichzeitig wird das Wissen breiter im Team gestreut und mehr Fehler gefunden, bevor sie im produktiven System landen. Ähnliches gilt für das Debugging, hierzu gibt es bereits den Talk The Mindset of Debugging. Im Kern gilt: «Quantity of feedback becomes quality of expertise».

Himmelslügen und lesbarer Code von Remu Hannequin

Das dritte Highlight wurde uns nach den Lightning Talks präsentiert. Remu Hannequin startete mit grossen, verschwörerisch klingenden Worten: «The Sky is a Lie», «Everything we See is in the Past» und «Sunrise and Sunrise Times are Fake». Anhand seines Gems Astronoby zeigte er, dass diese vermeintlich bedrohlichen Aussagen schlichte Wahrheiten sind, wenn man sie aus wissenschaftlicher Perspektive betrachtet. Das Gem modelliert mehrere Aspekte der Astronomie mithilfe von Domain Driven Design. Etwas vereinfacht gesagt verwendet er im Code strikt die Sprache der Domänenexperten, was auch zu lesbarem und verständlichen Code führt.

Die reinen Berechnungen könnte man natürlich auch mit normalem Ruby vornehmen. Mit der konsequenten Einführung und Nutzung von Value-Objekten wie Angle, Instant (ein Zeitpunkt) und Distance und Entities wie z.B. Jupiter oder Observer kann man aber die Berechnungen an den richtigen Stellen mit den Namen der Domäne versehen. So kann man Fehler bei Einheiten vermeiden oder Umrechnungen vereinfachen. Hiermit nutzte Remu Hannequin die Flexibilität von Ruby aus, um den Code nicht nur für Maschinen lesbar zu machen, sondern auch den Menschen stimmig abzuholen. Wer die Wissenschaft versteht, versteht auch sofort den Code.

Umsetzungsbeispiele waren die Kapselung von Rubys Time in der Domänenklasse Instant oder auch das Inkludieren von Comparable und der Definition von <=> in den Value-Objekten, um so Berechnungen und Logik in der Domänensprache umsetzen zu können. Bezogen auf das Testing wurden damit die Tests, die vorher mit Temple of Love veranschaulicht wurden, noch um die Zielsetzung der «Scientific Validation» erweitert. Hier zeigte sich das Geschick der Veranstalter, passende Talks zu einem gelungenen Event zu sammeln.

Zwischen Struktur und Kreativität: Ein Tag im Zeichen von Ruby

Der finale Talk «The Art of Code» zeigte anhand von Gemälden und Kunstepochen Parallelen zwischen Kunst und Code auf. Da der Tag bereits recht lang war, nehme hier nur den Hinweis auf die Kunst von Robert Gonzales auf.

Alle Talks sollen in Kürze auf der Helvetic Ruby 2025-Seite von RubyEvents.org veröffentlicht werden. Es wird nicht die letzte Helvetic Ruby gewesen sein, eine Konferenz in 2026 ist geplant. Wir freuen uns darauf.