Working Draft

Wöchentlicher Podcast für Webdesigner:innen und -entwickler:innen

Unterstützung

Wir optimieren unser Audio mit Auphonic, wo ihr uns Processing-Time kaufen könnt! Alternativ findet Ihr uns auch auf Patreon:

Become a Patron!

Werben bei Working Draft!

Mit zehnjähriger Geschichte und über 5000 Downloads pro Folge ist Working Draft der etablierteste Podcast für Webentwickler im deutschsprachigen Raum. Wenn ihr neue Entwicklerkollegen sucht oder ein Produkt für Webentwickler anbietet, schreibt uns unter sponsoring@workingdraft.de.

Revision 537: Was gibt es Neues in Cypress 9 und 10?

23. August 2022 | Keine Kommentare

Nachdem es vor zwei Revisionen um das Zusammenspiel von Cypress mit Vitest ging, wollen wir diese Revision ganz exklusiv Cypress widmen und über neue Features aus den Major-Releases 9 und 10 sprechen. Das letzte Mal haben wir das nämlich vor anderthalb Jahren gemacht. Dafür haben wir uns und die beiden Deutschen Cypress Ambassadore Ramona Schwering von Shopware und (erneut) Tobias Struckmeier von der Adesso eingeladen.

Schaunotizen

[00:00:58] Neues in Cypress 9 und 10
Das erste neue Feature, das wir beleuchten, ist das „Component Testing„, das derzeit noch in Beta ist. Beta unter anderem auch deswegen, weil es derzeit nur im Zusammenspiel mit React richtig gut läuft, mit Vue nur noch gut und mit Angular noch gar nicht so richtig.

Wie der Name schon andeutet, erlaubt es das Durchtesten isolierter UI-Bausteine, aber in echten Browsern anstatt in einer per JSDom simulierten Browser-Umgebung wie sie oft zum Einsatz kommt. Das ist zwar aufwendiger und langsamer, Fehler können damit aber besser debugged werden, weil die entwickelnde Person bei Auftreten eines solchen einfach den Browser übernehmen, die Devtools öffnen und mit der Fehlersuche beginnen kann. Dieses Feature führt aber leider zu einer neuen Projektstruktur, die zwischen E2-E und Component-Testing aufteilt, und die noch ein paar weitere Änderungen mit sich bringt. Wichtig zu wissen für eine Migration von einer älteren Cypress-Version – die allerdings recht schnell von der Hand geht.

Andere Tools zum Entwickeln von Komponenten wie Storybook ersetzt dieses Feature nicht. Andersherum bietet Storybook aber mittlerweile mit „Storybook Play“ ein eigenes Testing-Feature.

Als nächstes sprechen wir über Cypress Studio, welches man derzeit als experimentell einstufen muss, weil dessen Zukunft in Frage gestellt wird. Cypress Studio ermöglicht es, Cypress-Tests WYSIWYG-artig zu erstellen, was Nicht-Entwickelnden einen Zugang zum Erstellen von Tests öffnet. In Frage gestellt deswegen, weil die Chrome Devtools neuerdings mit dem „Recorder“ daherkommt, der User-Flows aufzeichnet, die man mit Hilfe von Browser-Plugins abgreifen und in eigene Tools und Formate exportieren kann.

Wir widmen uns in dem Zusammenhang der Frage, wie robust und dauerhaft rein visuell anstelle von semantisch zusammengestellte Tests sein können und sind uns darin einig, dass sie deutlich fragiler sind. Allerdings sind sie definitiv ein guter Einstieg in die Welt der Test-Erstellung und mit zunehmender Erfahrung wird es immer mehr möglich, diese als Vorlage zu betrachten, die man Anschluss „robust“ macht. Auch lässt sich Cypress vorab ein Stück weit so einstellen, dass es bestimmte HTML-Strukturen bevorzugt als Orientierungspunkte heranzieht als andere (bestimmte Attribute vs. CSS-Selektorkette).

Das dritte neue Feature, über das wir sprechen, ist ebenfalls noch experimentell: Das Multi-Domain-Testing. Multi-Domain-Testing ist traditionell ein blinder Fleck aller Testing-Tools, und zwar weil es technisch aufwändig oder sogar unmöglich ist. Es geht dabei darum, dass Tests auch möglich sind, wenn der User-Flow die primäre Domain zeitweilig verlässt, wie es zum Beispiel bei einem Login via externer Dienste der Fall ist, oder auch bei einer Zahlung über einen externen Zahlungsdienstleister. In Revision 442 sprachen wir dazu auch mit Marvin Hagemeister, der aus diesem Grund zusammen mit Kollegen sein eigenes Testing-Framework gebaut hat, das das kann. Dass sowas jetzt auch mit Cypress möglich ist, ist u.a. in der ebenfalls experimentellen „Session API“ zu begründen. Diese ermöglicht es, Cookies und LocalStorage-Daten über mehrere Tests hinweg zu persistieren. Das macht es auch möglich, bestimmte Arten von Tests zu beschleunigen, indem man die ganze Setup-Arbeit einmal macht, abspeichert und fortan nur noch lädt.

Das führt uns zu dem letzten diskutierten Themenblock, nämlich die Ausführungsgeschwindigkeit von Cypress-Tests und wie man die schnell hält. Ramonas Strategie ist, ein Basis-Set für die schnellen und wichtigsten Tests zu nutzen, um die Pipeline schnell zu halten, und dazu einen „Nightly Build“-Ansatz zu fahren, bei dem jede Nacht alles aufwendig abgetestet wird. Eine weitere Möglichkeit ist die Parallelisierung per Ordner oder Segmentierung via Tags, und das Ganze auf mehreren Maschinen orchestriert via Cypress Dashboard. Am längsten dauert aus ihrer Sicht aber immer das initiale Setup der Testdaten – und da unterscheidet sich Cypress nicht von anderen Tools. Und schließlich sind wir uns auch einig, dass keine 100% Testabdeckung notwendig ist, weil einfach zu teuer.

[00:00:00] Links

An Update on Cypress Studio
Ein Blogpost vom Cypress-Team mit dessen Überlegungen zu Cypress Studio.
Cypress 10.2.0: Run tests up to 2x faster on Apple silicon (M1)
Seit Version 10.2 läuft Cypress nicht mehr in einer Intel-Emulation, sondern nativ mit dem ARM-Befehlssatz.
Storybook Play
Storybook bietet mit Play nun einen eigenen Test-Workflow.
Vitest
Ein auf Vue maßgeschneidertes Testing-Framework. Mehr dazu in Revision 535.

Revision 536: Das Imposter Syndrom bei Entwickler*innen

16. August 2022 | Keine Kommentare

Mit Josefine Schaefer und Manuel Schröder, beide Developer Relations Engineers bei dem Headless CMS Tool Storyblok, bespricht Vanessa das Imposter Syndrom bei Entwickler*innen.

Schaunotizen

[00:01:21] Das Imposter Syndrom bei Entwickler*innen
Vorneweg: Wir haben keine Ausbildung, um als Experten über dieses Thema zu besprechen. Wir tauschen unsere persönlichen und subjektiven Erfahrung aus.
Der Imposter ist ein Hochstapler. Personen können allerdings auch ein Hochstapler-Syndrom haben. Obwohl sie deutliche Beweise für ihre Fähigkeiten bekommen, fühlen sie manchmal, als hätten sie ihren Erfolg, z.B. eine Festanstellung als Software Entwickler:in, erschlichen. Wir besprechen, inwiefern Konferenzen, Social Media und das Arbeitsumfeld Auswirkungen auf Entwickler:innen in Bezug auf das Syndrom haben. Ebenfalls hinterfragen wir uns, welche Personengruppen davon stärker oder weniger betroffen sind. Sind es beispielsweise Selbstlernende oder theoretische Akademiker, die mehr damit zu hadern haben, wie man eigentlich StandUps, Code Reviews, und mehr organisiert. Außerdem sprechen wir über unsere Erfahrungen und weisen auf Artikel hin, mit dem man dem Imposter Syndrom entgegenwirken kann.

Links

Verwandte Revisionen

Revision 535: Testing mit Cypress und Vitest

29. Juni 2022 | Keine Kommentare

In den letzten Monaten hat sich eine neue Kombination an Testing-Tools für die Frontend-Entwicklung gebildet, die von vielen Entwickler:innen favorisiert wird. Markus Oberlehner erklärt, wie man Cypress Component Testing und Vitest am besten verbinden kann.

Schaunotizen

[00:00:00] Testing mit Cypress und Vitest
Cypress und Vitest sind Test Runner. Test Runner sind Tools, die von Entwickler:innen geschriebene Tests auszuführen. Dabei kommt Cypress mit einem virtuellen Browser, während Vitest unschlagbar in der Ausführungszeit ist. Vitest kommt aus dem gleichem Universum wie Vue und Vite. Vitest, wie auch Cypress, sind allerdings Framework agnostisch und können mit beliebigen Bibliotheken eingesetzt werden, wie React und Angular. Eine Benutzung von Vitest zusammen mit dem Bundler Vite ist sinnvoll, da beide Tools die gleiche Konfiguration nutzen können. Es ist allerdings keine Voraussetzung.
Markus Geheimtipp ist ein unabhängiger Driver, der Tests sowohl in Cypress, als auch in Vitest ausführen kann.
Im Laufe der Revision geht Markus auf die Begrifflichkeiten von Unit, Integration und System Tests ein. Außerdem erklärt er, in welchen Fällen er es bevorzugt Mocks und Stubs zu benutzen, und in welchen nicht.

Links

Verwandte Revisionen

 

Revision 534: CSS Houdini, gescheitert?

24. Juni 2022 | Keine Kommentare

In dieser Ausgabe legt Schepp Vanessa und Hans seine Überlegungen zu CSS Houdini dar.

Schaunotizen

[00:00:59] CSS Houdini, gescheitert?
Nach einem Recap, was CSS Houdini ist und warum es beinahe „WhatTF“ geheißen hätte, stellt Schepp die These auf, dass das Houdini-Projekt gescheitert sei. Es gibt aus seiner Sicht dafür einige Indikatoren, sowohl was den Implementationseifer der Non-Chromium-Browser-Hersteller angeht, also auch Kritik aus der Entwicklerschaft, u.a. die Paint API sei nichts weiter als -webkit-canvas() in neuem Gewand.
So schwarzmalerisch seine Schlussfolgerung ist, so sehr freut er sich über einen Teilfeature von Houdini, nämlich die @property At-Rule. Diese ergänzt CSS um die Möglichkeit zur Typ-Annotation von Custom Properties, so dass der Browser diese fortan nicht mehr nur als dumme Strings betrachtet, sondern als Fließkomma- oder Ganzzahl, als Farbe, Rotation oder Längenmaß. Und das wiederum eröffnet einem in Kombination mit CSS Animationen und calc() eine Welt an Möglichkeiten, die man zuvor nicht hatte, z.B.:

Schepps Wunsch wäre daher, dass sich die Browser-Hersteller auf die kleineren Dinge konzentrierten und dass @property zukünftig auch in Firefox und Safari implementiert würde (eventuell auch per Crowdfunding durch die Firma Igalia):

Was ist Eure Meinung zu CSS Houdini? Schickt uns einen Tweet an @workingdraft, oder diskutiert mit in unserem Community Slack!

Revision 533: Frontend Performance Metriken – Die Core Web Vitals

15. Juni 2022 | Keine Kommentare

Es ist mal wieder ein schöner DienstagMittwoch und wir hauen die nächste Folge raus. Diesmal mit von der Partie sind der Schepp und der Hans. Schepp berichtet über die Core Web Vitals – mehr dazu unten.

Schaunotizen

[00:00:59] Core Web Vitals
Wenn man sich die aktuellen Performance-Metriken im Frontend so anschaut, guckt man meistens auf die Web Vitals von Google. Schepp erklärt, warum wir die Web Vitals haben und wie die Core Web Vitals funktionieren. Auf alle Metriken der Web Vitals ist er auch schon mal im Wo Wir Sind Ist Vorne Podcast eingegangen. Außerdem sprechen wir über die kürzlich neu eingeführte Metrik Interaction to Next Paint.
Wer mehr zu den Web Vitals lernen möchte, schaut am besten Mal hier vorbei.

Revision 532: Infrastructure as Code

7. Juni 2022 | Keine Kommentare

Wir sind wieder mit einer neuen Episode am Start und diesmal geht es um das Thema „Infrastructure as Code“. Hans spricht mit Thomas Eisenbarth über seine Erfahrungen mit dem Thema. Ein richtig interessanter Talk, der die Seite der Development Operations etwas näher beleuchtet.

Schaunotizen

[00:01:33] Infrastructure as Code
Den meisten von euch ist der Begriff Infrastructure as Code bestimmt mal über den Weg gelaufen. Mit der Entwicklung, die Hardware, wie Netzwerk und Server, nicht mehr selbst zu betreiben, sondern alles in die Cloud zu schieben, ist die Reproduzierbarkeit von Infrastruktur relevant geworden.
Wir diskutieren, woher wir kommen, warum wir Infrastruktur in Code beschreiben wollen und welchen Effekt das auf die Zusammensetzung eines Teams haben kann. Außerdem gibt Thomas Tipps, wie man sich selbst dem Thema annähern kann, auch wenn man noch nicht so viel Ahnung davon hat.
Erwähnt haben wir unter anderem:

Ihr wollt über das Thema etwas diskutieren? Dann schaut mal in unserer Community auf Slack vorbei: draft.community.

Revision 531: Mehr Eloquenz im Web!

31. Mai 2022 | Keine Kommentare

Diese Ausgabe haben Vanessa und Schepp sich mit Manuel Matuzović (@mmatuzo / Webseite), Frontend-Entwickler und Barrierefreiheitsexperte, zusammengetan und gemeinsam ein Plädoyer für mehr Markup-Eloquenz im Web gehalten.

Schaunotizen

[00:01:00] Mehr Eloquenz im Web!

Revision 530: Von Katas, Craft Camps und Code Retreats

17. Mai 2022 | Keine Kommentare

Schepp begrüßte diesmal jemanden, dessen Aktivitäten er schon seit Jahren auf Twitter verfolgt: Wolfram Kriesing aus München (Blog / Twitter).

Schaunotizen

[00:01:00] Von Katas, Craft Camps und Code Retreats
Wolfram ist nicht nur ein Urgestein der IT, sondern war auch Early Adopter der Sprache JavaScript. Zeitgleich mit dem Aufkommen der ersten JavaScript-Just-in-Time-Compiler gründete Wolfram mit einer Handvoll weiterer Visionäre die auf JavaScript spezialisierte Firma uxebu. Dort hantierte man schon frühzeitig mit Enterprise-JavaScript-Frameworks wie dem Dojo Toolkit und entwickelte einen Konverter für Flashs SWF-Dateien namens Pixel Plant und zahlreiche weitere Open Source Lösungen.

Wolframs Passion für die Sprache führte ihn immer tiefer in den Fuchsbau und schließlich zum Konzept des Test-Driven-Developments (TDD). Wir reden darüber, wieso TDD nicht nur ein guter Ansatz zum Entwickeln ist, sondern sich mindestens ebenso gut zum Lernen und Verstehen einer Sache eignet.

Und schließlich reden wir auch über zahlreiche Lernplattformen und Events, die Wolfram zu den zuvor genannten Themen aus der Taufe gehoben hat:

  • Das JSCraftCamp – eine Software-Crafting-Unkonferenz, nur eben fokussiert auf die Sprache JavaScript. Das nächste Camp wartet am 17. und 18. Juni 2022 in München auf Euch!
  • Die JavaScript Katas – eine Sammlung von Coding-Herausforderungen, genannt Katas, die einem helfen sollen, sich mit der Funktionsweise einzelner JavaScript-Bestandteile vertraut zu machen. Der Clou ist, dass das Ganze natürlich in einen TDD-Unterbau eingebettet ist.
  • Die JavaScript Code Retreats – eine weitere Event-Serie, in der Wolfram mit einem Münchener Ableger mitmischt. Diese Ein-Tages-Events finden zeitgleich weltweit statt und auch dort geht es darum, seine Skills mit Hilfe von TDD auf das nächste Level zu hieven.
  • Das JavaScript The Language Meetup – hier wird nur aller feinstes JavaScript in Form von TDD-getriebenem Mob-Programming serviert und verköstigt.

Revision 529: Richtig schätzen

10. Mai 2022 | Keine Kommentare

In einer offenen Diskussionsrunde bespricht Vanessa mit Nikolaus Rademacher, Senior Product Engineer bei Accenture Song, das Thema Software Schätzungen im Rahmen von Sprints. Zuvor war Nik bereits zu Gast, um über die Rolle und Verantwortung von Entwickler:innen in agilen Teams in Revision 510 und Revision 512 zu sprechen.

Schaunotizen

[00:00:58] Richtig schätzen
Wie schätzt man eigentlich richtig? In dieser Revision widmen wir uns Schätzungen, egal ob Fibonacci, T-Shirt Größen, oder einfach nur Zahlen. Wir besprechen, ob man Bugs schätzen sollte, was Spill-Overs sind und welche Vor- und Nachteile es hat, die Schätzungen von Tickets in Bearbeitung nochmals anzupassen, wenn man as Gefühl hat, dass man daneben lag. Wir klären auch die Antwort auf die Frage: „Was ist besser? Zeit- oder Komplexitätsschätzungen“. Oder wie wäre es mit „Kundenwert“ stattdessen? Sie ist: „es kommt darauf an!“ ;)
Nik stellt das Cynefin Framework vor. Es ist ein nützliches Tool, um Tasks in „komplex“, „kompliziert“, „chaotisch“ und „klar“ zu kategorisieren.
Als Online Scrum Planning Poker Tool empfiehlt Vanessa Planning Poker Online.

Revision 528: Svelte und SvelteKit

5. Mai 2022 | Keine Kommentare

Wieder einmal zu Gast ist Jon Uhlmann (@jonnitto), mit dem wir diesmal über Svelte und SvelteKit sprechen.

Schaunotizen

[00:00:58] Svelte und SvelteKit
Bei Svelte hat sich in den letzten Jahren wieder einiges weiterentwickelt. Treu geblieben sind sie sich allerdings, denn wie gewohnt ist die Dokumentation sehr hilfreich, übersichtlich und umfassend. Im Gegensatz zu React ist Svelte tatsächlich „reaktiv“. Dabei kommt es mit einem eigenem Compiler. Seit einiger Zeit gelangt SvelteKit an immer mehr Beliebtheit. Das Framework ist der Nachfolger von Sapper. Wer von Sapper auf SvelteKit migriert, kann sich an den offiziellen Guide halten. Zwei tolle Eigenschaften von Svelte sind der eingebaute Accessibility-Support und die Unterstützung von Transitions und Animations, die an die Transitions von AlpineJS erinnern. Wer sich nun für Svelte interessiert und auf der Suche nach mehr Informationen ist, kann bei der Webseite vom SvelteSummit vorbeischauen. Erst vor Kurzem fand die diesjährige Remote Konferenz statt. Die Videos findet man auf YouTube: Svelte Summit Sprint. Um sich sonst auf dem Laufenden zu halten, empfehlen wir den Svelte Blog mit monatlich erscheinenden Artikeln.

Weitere Revisionen mit Jon Uhlmann

Weitere Revisionen zum Thema Svelte