Beiträge aus der Kategorie: Webentwicklung

Zu blöd für Visual-Regression-Tests

Ich habe das Gefühl, dass es an mir liegt, dass ich bei diversen Webprojekten beim Snapshot testing im Rahmen von Visual regression tests Probleme habe. Wie man auch am Screenshot oben sieht.
Ich möchte eigentlich nichts weiter als die Differenz von zwei Screenshots einer kompletten Seite erstellen, einmal vom aktuellen Livestand der Seite und dann vom aktuellen Entwicklungsstand. Bei manchen Frontends habe ich aber das Problem, dass es scheinbar Elemente gibt, die dann beim Screenhot-Erstellen "mitgenommen" werden. Das kann man sich ganz gut hier im Gesamtscreenshot ansehen.

Ich weiß nicht, aber ich denke, dass es an mir liegt, denn die Suchmaschinen dieser Welt scheinen das Problem irgendwie nicht zu kennen. Und es kann doch nicht sein, dass es die Lösung ist, dass ich während des Tests irgendwie JavaScript oder CSS "einschleusen" muss, um diese Effekte zu unterbinden? Das würde ja den Test irgendwie ad absurdum führen.

Ich habe den Effekt bei Codeception/VisualCeption und bei Cypress.io. Es ist auch egal, in welchem Browser ich die Tests fahre. Ob das Selenium-basiert stattfindet oder der native Browser genommen wird. Egal ob headless oder nicht. Egal ob Chromium, Chrome oder Firefox.

Wer also eine Idee hat und mich irgendwie auf den Pfad der Lösung schubsen kann, wird in meiner Liste des Ewigen Dankes verewigt werden. Und wer weiß, wozu die noch irgendwann gut sein wird. ;-)

Hello Linux

Quasi aus der Not heraus habe ich seit langem mal wieder ein Linux als Entwicklungssystem aufgesetzt. Und das in echt kurzer Zeit. Als Basis habe ich die SSD meines Gaming-Laptops um 120 GByte verkleinert und dann per USB-Stick Ubuntu installiert. Und das ging fix und vor allem hat er einwandfrei alle Komponenten erkannt. Das ist man aus den Urzeiten von Linux ja gar nicht gewohnt.

Der Rest an Installation war dann einfach nur ein Kinderspiel. PhpStorm, GitKraken, zsh mit oh-my-zsh als Shell und dann noch der übrige Kleinkram wie docker, SSH/VPN-Konfiguration, GPG/PGP. Alles andere spielt sich in Browsern ab. Ein Wechsel von macOS auf Linux ist also, was das Arbeiten angeht, einfach zu vollziehen und ich denke nicht, dass ich einen Unterschied feststellen werde. Dafür sind die Tools, mit denen ich arbeite, auf allen Plattformen gleich.

Klar fühlt es sich ein wenig besser an, mit quelloffener Software zu arbeiten, aber das Verwenden von Apple-Hardware verbuche ich bei mir als elitäre Attitüde.

Remote Pair Programming

Video-Calls. Wer kennt sie nicht. Mal abgesehen von Team-Meetings, Stand-Ups und so weiter, muss man diese Kommunikationsform verwenden, wenn man mit seinen Kollegen im Home-Office zusammen ein Problem lösen möchte. Dann teilt einer am besten noch seinen Bildschirm mit der IDE und alle schauen zu, wie dort nach der richtigen Stelle in der Datei gesucht wird und dann mit etlichen Vertippern der zugerufene Code angepasst wird.

So ging es mir auch heute, wobei ich mich dann auch während des Meetings dauernd dabei erwischt habe, auf dem geteilten Bildschirm scrollen zu wollen. Aber dabei gibt es mit Tool wie "Code with me" innerhalb von PhpStorm eine hervorragende Lösung für dieses Problem. Ich hatte mir vor zwei (?) Jahren, als die erste Version des Tools erschienen ist, das ganze zwar schon mal angeschaut, aber damals stand das noch auf wackeligen Beinen und war nicht sonderlich performant.

Das heutige Meeting habe ich aber zum Anlass genommen und mir "Code with me" eben erneut angeschaut und ausprobiert. Und: es funktioniert einwandfrei. Und vor allem einfach. Der, der das Problem hat, stellt den Host und kann in PhpStorm in einem einfach gehaltenen Dialog einen Einladungslink generieren. In einer anderen Instanz kann man diesen Link dann entsprechend aufrufen oder im PhpStorm-Plugin eingeben und schon wird die Instanz gespiegelt. Und je nach den Berechtigungen können mehrere Leute dann direkt im Code zusammen arbeiten.

Ich habe keine Ahnung, warum ich das bisher einfach nicht genutzt habe.

My HomeOffice is my castle

Vor zwei Jahren habe ich meinen ersten Tag im Home-Office verbracht. Damals habe ich noch gedacht, dass das einfach nur ein paar Wochen wegen des Lockdowns sein werden. Das daraus ein dauerhaftes Arbeiten von zu Hause aus werden wird, habe ich mir damals nicht ausmalen können. Das stand auch nicht als Ziel auf irgendeiner Liste.

Es funktioniert. Und wird auch weiterhin funktionieren. Das hat sehr viel damit zu tun, dass mein Tag sehr strukturiert und gleich abläuft. Der Rest der Familie verlässt morgens das Haus in Richtung ihrer Schulen, vorher zusammen frühstücken und dem Hund die weite Welt zeigen. Arbeitsphase bis mittags, dem Hund die andere Seite der Welt zeigen und dann bis abends wieder weiterarbeiten. Ohne irgendwelche Sachen wie Hausarbeit oder Ablenkung durch andere Dinge.

Das sehe ich bei anderen nämlich, deren Arbeit nicht so wie die von Entwicklern strukturiert werden kann. Da wird später aufgestanden und die Arbeit von Dingen wie Spülmaschine ausräumen oder sich mal um private Telefonate kümmern gestört. Oder einfach mal längere Zeit auf der Terasse in der Sonne liegen. Sachen, die man halt auch nicht machen würde, wenn man in der Agentur wäre. Die Familie trägt natürlich auch einiges dazu bei. Sie wissen, dass man mich nicht stören darf, um mich nicht aus dem Flow zu bringen.

Trotzdem muss ich sagen, dass es Tage gibt, an denen ich mein "altes" Arbeitsleben gerne zurück haben würde. Mit Kollegen von Angesicht zu Angesicht reden, mit ihnen Mittags Essen organisieren, kickern (auch wenn ich da eigentlich echt schlecht drin bin) oder abends auf ein Getränk länger bleiben. Oder einfach sich mit Teamkollegen stundenlang in einen Raum einschließen, um ein Problem gemeinsam zu lösen.

Das macht schon einiges auch im Hinblick auf Teambuilding aus, das man so aus dem Home-Office nicht erreichen kann. Es wird jedenfalls in den nächsten Jahren sehr spannend werden, wie sich das Arbeiten noch weiter verändern wird. Machen wir das Beste draus!

Disclaimer: ich hatte keine Lust, für das Foto meinen Arbeitsplatz aufzuräumen. So habe ich ihn heute nach der Arbeit verlassen.

Erste Hilfe für Open Source

Alexander Kellner hat die provokante These in den Raum geworfen, dass Open Source kaputt sei und aufgefordert, an der Reparatur mitzuwirken. Dies ist bestimmt überspitzt gemeint und bezieht sich im Artikel dann in erster Linie auf die Wahrnehmung, aber vor allem auf die Wertschätzung von Open Source.

Open Source lebt nicht allein von der Verbreitung, sondern von der aktiven Unterstützung durch deren Nutzer. Diese kann auf verschiedenen Ebenen passieren: manch einer ist in der Lage selber Code beizusteuern, andere verbessern die Dokumentation und wiederum andere können das Projekt finanziell unterstützen. Denn Entwicklung kostet Zeit. Zeit, die die Entwickler nicht mit ihrer regulären Beschäftigung zum Geld verdienen nutzen können oder von ihrer Freizeit abziehen müssen.

Alex´ Idee ist es mit Blick auf TYPO3 und der großen Vielfalt der Extensions, dass die Association eine zentrale Funktion für die Verteilung von Spenden einnehmen könnte. So eine Art Patreon/Steady für Community-Extensions. Es gibt ja selbst auf GitHub die Möglichkeit über das Sponsoring einzelnen Entwicklern etwas in den Topf zu werfen, was ich auch ein wenig mache.

Ich habe mir vor ein paar Jahren einen gewissen Rahmen gesetzt, den ich pro Jahr in Form von Spenden entbehren kann. Der größte Teil geht in Form von Fördermitgliedschaften bei so Projekten wie Sea-Watch oder der Gesellschaft für Freiheitsrechte drauf. Eine Bronze-Mitgliedschaft in der TYPO3 Association finde ich auch bezahlbar. Aber ich unterstütze auch über Plattformen wie Patreon/Steady/GitHub Sponsoring Entwickler und Podcaster, die sonst über keine anderen Wege für ihre Projekte an Geld kommen.

Aber ich muss bis jetzt über mehrere Kanäle schauen, dass mein Geldkontingent "klug" verteilt ist und ich ändere auch alle paar Monate meine Unterstützungen, um das Ganze breiter zu streuen. Einen zentralen Pool für TYPO3 und all seiner Extensions würde ich also begrüßen. 

Und ich habe vor auch auf anderen Wegen meinen Obolus beizutragen. Und mich erkenntlich für all das zu zeigen, was mir andere Entwickler möglich gemacht haben. Danke schon mal dafür!

Globales Ignorieren

Es gibt nichts Schlimmeres als fremde IDE-Konfigurationsdateien in einem Repository. Damit ich meine IDE-Konfiguration auch nicht anderen Entwicklern aufdrücke, gibt es eine globale gitignore-Datei, in der wenigstens folgende Zeilen erstmal enthalten sind:

.DS_Store
.idea

Die Datei kann man nennen wie man möchte, muss sie dann lediglich per

git config --global core.excludesfile ~/.gitignore_global

der globalen git-Konfiguration mitgeben.

Von Stöckchen und Software

Vor fast 15 Jahren habe ich ein neues Laptop kaufen wollen und auf der Suche nach einem vernünftig verbauten und soliden Case haben mich die aus Aluminium bestehenden Gehäuse der MacBooks angelacht. Ich kannte zwar den Ein oder Anderen durch die Arbeit mit Agenturen, der mit macOS gearbeitet hat, aber so richtig haben mir nur die ganzen Blogs geholfen, die im deutschsprachigen Raum zu dieser Zeit erblühten.

Damals hat man noch mit Stöckchen geworfen und in der Sidebar Blogrolls gepflegt, um andere auf lesenswerte Seiten aufmerksam zu machen. Und kommentiert. Twitter (oder eher twttr) war in der Pre-Smartphone-Zeit noch unbekannt und auf StudiVZ/Facebook... naja.

Aber es gab unzählige Blogs, die sich mit macOS und der Software dafür beschäftigten. Man bloggte, wie sein System aufgesetzt ist, wo man gerade irgendwelche Rabatte für den Einkauf von Software bekam und so weiter.

Da ich mir gerade durch einen Jobwechsel einen neuen Laptop aussuchen durfte und ich die letzten zwei Jahre wegen eines Windows-Systems geflucht habe, bin ich echt dankbar, dass ich diesen Text auf macOS schreiben darf. Hätte es WSL2 nicht gegeben, wäre ich schon im letzten Jahr mit dem Auto über das Laptop gefahren. Nachdem ich es angezündet und aus einem Hochhaus geworfen hätte.

Und es gibt fast nichts Schöneres als ein neues macOS einzurichten. Ich hätte zwar das Profil und die Software von meinem privaten MacBook während der Installation übertragen können, aber irgendwie war es mir wichtig, das Ganze frisch aufzusetzen. Und da mache ich es doch wie vor 15 Jahren und schreibe auf, was ich so alles installiert habe.

Die erste App, die ich installiert habe, ist iA Writer, mit der ich diesen Text auch schreibe. Schon seit Jahren meine Wahl für Texte schreiben, aber auch Notizen finden hier ihren Platz.

Und dann kommt neben dem ganzen Entwicklerkram das Wichtigste: die Shell. Keine Ahnung, es soll immer noch Entwickler da draußen geben, die so gut wie keine Berührung mit Shells haben, ich kann gar nicht ohne. macOS kommt ja seit 10.15 mit zsh als Standard-Shell daher. Ich haue da noch iTerm2 und oh-my-zsh drauf und in Verbindung mit meiner geliebten Konfiguration, Syntax-Highlighting, Autosuggestions und einem schönen Theme will ich eigentlich gar nicht raus. Aus ihr.

Was schon bei der Installation der Shell nicht fehlen darf, ist Homebrew. Ein Paketmanager für macOS und in Verbindung mit dem AppStore von Apple braucht man eigentlich keine weiteren Quellen mehr, um Software zu installieren.

Neben den üblichen verdächtigen Browsern und Firefox als Standard-Browser, kommen dann noch Tweetbot (Links lasse ich jetzt einfach mal aus Bequemlichkeit weg, ihr könnt ja bestimmt Suchmaschinen bedienen), Slack, Discord und Signal, sowie ReadKit auf den Rechner, um mit der Außenwelt zu kommunizieren und Feeds abzugreifen.

Mit Thunderbird versuche ich mal wieder warm zu werden. Sonst gefallen mir auf macOS eigentlich bisher gar keine Mail-Clients. Die Hübschen haben zu wenig Funktionen wie Verschlüsselung und die Funktionalen sehen alle scheisse aus.

Neben den üblichen Tools wie 1Password (auch wenn die gerade böse geworden sind) und Lastpass für das Passwort-Management, Things für ToDos (obwohl ich das eigentlich kaum noch benutze, es spielt sich ja zum Glück alles in Ticketsystemen ab), odrive für das Handling aller Cloud-Dienste, VLC für Videodateien und Pixelmator für Bilder, werkelt dann noch Little Snitch herum. Ja, ist ne Software-"Firewall", aber zum Placebo-Blocken von Ressourcen ist es halt was fürs "besser fühlen".

Die GPG Suite fürs Verschlüsseln (Keybase ist ja auch böse geworden und hat sowieso kaum einer genutzt) und Tunnelblick für die VPNs. Achso, Moom als Fenstermanager. Warum Apple sowas immer noch nicht in macOS integriert hat, ist mir schleierhaft. Die ganzen Standardtools wie einen PDF-Reader und Office... geschenkt.

Kommen wir nun zum eigentlich Wichtigsten: dem Enwicklerkram. Da ich die meiste Zeit PHP schreibe, sollte es nicht verwundern, dass PhpStorm meine IDE der Wahl ist. Mit VSCode mögen Frontendler klarkommen, mir reicht das aber nicht. GitKraken ist der schönste Git-Client, da lasse ich mir nichts anderes erzählen und mit Sequel Ace kann man schön Datenbanken kaputtmachen. Atom ist auch dabei, aber wirklich nur im Notfall einen einfachen Text-Editor starten zu können. Und ja, ich habe sogar noch Transmit installiert. In der Hoffnung, es nie brauchen zu müssen.

Neben der Installation von Docker und DDEV habe ich dann noch git aktualisiert (die Version von macOS ist zwar halbwegs aktuell, aber neuer und sicherer ist immer gut) und sowas wie wget/curl kann man auch immer gebrauchen.
So bin ich schon mal bereit, da kommt aber mit der Zeit bestimmt noch mehr Software nach.

Gib dem Code Statik

Ja, ich weiß, Statik und statische Code Analyzer haben in erster Linie nicht viel miteinander zu tun, aber im Endeffekt wird Code durch deren Verwendung trotzdem um einiges besser. Härter. Und tragen somit zu einem soliden Code-Gerüst bei, das unsere Anwendungen noch stabiler und besser macht.

Wie Roland Golla in der 5.2021 vom Entwickler Magazin schreibt: "Legacy-Code macht krank." In seinem Artikel geht es um PHPStan. Wie man diesen Static Code Analyzer in seine Entwicklungsumgebung (und damit ist nicht nur die IDE gemeint) einbinden kann, um nicht nur bisher unentdeckte Fehlerquellen zu finden, sondern um seine Fähigkeiten und vor allem sein Wissen als Entwickler zu verbessern.

Man kann einfach nicht alles wissen, die Entwicklung in PHP findet auch in immer kürzeren Releaes-Zyklen statt. Auf der anderen Seite pflegt man die in die Jahre gekommenen Anwendung des Kunden. So muss jeder Entwickler eine ungeheure Bandbreite von Features abdecken, die einem die im jeweiligen Projekt eingesetzte PHP-Version zur Verfügung stellt.

Das unfassbar schöne und immer wieder faszinierende am Beruf eines Softwareentwicklers ist in meinen Augen, dass man jeden Tag etwas lernt. Wirklich jeden Tag. Und Tools wie Static Code Analyzer helfen einem dabei. Ich glaube jeder kennt das Gefühl, wenn man Code von vor drei, vielleicht vier Jahren anschaut, den Kopf schüttelt und dann nach einem beherzten "git blame" am liebsten im Boden versinken möchte, wenn man feststellt, dass man selber diesen Legacy Code produziert hat.

Static Code Analyzer setzen hier schon beim ersten Entwickeln an und helfen einem, sehr viel sauberen Code zu schreiben. Sie helfen einem jetzt nicht unbedingt, bessere Programm-Logiken zu schreiben, man kann also immer noch die Business-Logik so dermaßen unnütz verschachteln und schwer zu verstehen umsetzen. Aber hey, dafür gibt es ja wiederum andere Tools wie Performance Profiler (Blackfire usw.), die man auf dieses Problem werfen kann.

Ich kann jedem eigentlich nur Tools wie PHPStan, rector, Psalm usw. neben den hoffentlich schon seit Jahren verwendeten Tools wie PHP-CS-Fixer oder PHPMD ans Herz legen. Um Code zu analysieren, zu refactoren und vor allem zu lernen. Quasi als Pair-Programming mit einem Tool und nicht mit einem anderen Entwickler. Oder als Code review vor dem eigentlichen Code review.

Disclaimer: Roland Golla hat mir die oben erwähnte Ausgabe kostenlos zur Verfügung gestellt, wofür ich ihm herzlich Danke. Print-Produkte habe ich schon lange aus den Augen verloren, wenn es um Programmierung oder Themen im Web geht. Es war aber mal wieder eine wunderbare Erfahrung, beim Lesen Papier in der Hand zu haben. Ich werde jetzt zwar kein Abo abschließen, aber sollte ich mal wieder irgendwelche Reisen per Bahn oder so unternehmen, werde ich am Bahnhofskiosk auf die Suche nach solchen Zeitungen gehen. Ansonsten kann ich euch seinen YouTube-Kanal "Never Code Alone" ans Herz legen, den ich regelmäßig verfolge. In seinen Videos geht es vor allem um Testing, Refactoring und allgemeinen Themen rund um das Entwicklerdasein.

2021-2

In Zukunft möchte ich einmal die Woche die besten und nützlichsten Artikel/Websites in einer Liste zusammenfassen, um auf der einen Seite meine Liste an noch zu lesenden Artikeln in Pocket klein zu halten und vielleicht hilft es auf der anderen Seite dem ein oder anderen. Wenn jemand überhaupt mein Blog liest. Was ich nicht annehme.

Fangen wir also an:

  • Xdebug bzw. eigentlich die Sponsoring-Seite von Derick, dem Maintainer und Erfinder des besten Debug-Tools für PHP. Los! Unterstützen! Denn auch Entwickler wollen Geld verdienen.
  • TYPO3 Rector: eigentlich wollte ich meinen Urlaub über die Feiertage für ganz viel Lernen und Anschauen nutzen, nur kam wie es so nun mal so ist ganz anders. Wird aber für das nächste Refactoring/Migration verwendet und werde darüber bestimmt berichten
  • Laragon: ich bin ja strenger Verfechter von DDEV als Serverumgebung für die lokale Entwicklung für TYPO3. Laragon möchte scheinbar so etwas ähnliches sein. Leider auch noch nicht angeschaut, weil ich halt auch mit DDEV mehr als zufrieden bin
  • Ein schöner "Früher war alles besser (anders)"-Artikel über die OpenSource-Entwicklung: The Golden Age of Open Source is Over

Alles muss raus

Im letzten Jahr, das man nicht beim Namen nennen darf, hatte ich so viel vor und echt mal wenig davon geschafft. Irgendetwas mache ich nämlich falsch (oder anders) als alle anderen, die auch im HomeOffice waren und gefühlt dauernd Freizeit hatten oder wenigstens sowas von tiefenentspannt waren, dass ich im Spätsommer mit Meditation angefangen habe, um auf das gleiche Level zu kommen. Das mit der Meditation habe ich dann schnell wieder verworfen, das klappt bei mir einfach nicht. Da muss man scheinbar genauso wie bei Homöopathie dran glauben und dafür ist mein Gehirn einfach nicht gemacht.

Zum Bloggen bin ich dann nämlich auch nicht gekommen, wie ich mir das so vorgenommen hatte. Einfach mal Texte schreiben. Für mich. Und die ins Internet stellen. Warum auch immer. Weil man das im frühen Internet auch so gemacht hat. Wo das Internet noch nicht ganz so kaputt war wie heute.

Vielleicht werde ich sogar demnächst hier eine Blogroll veröffentlichen, denn es gibt sie immer noch! Die kleine Blogosphäre und auch die Tech-Blogger. Anfangen werde ich aber mit einer Auswahl von Artikeln und Websites, die ich im letzten Jahr in Pocket abgespeichert und mit Vergessen gestraft habe. Von den knapp 300 Einträgen habe ich diese mal hier gelassen, vielleicht findet der ein oder andere ja noch was, was ihn weiterbringt.

Webdesign

TYPO3

DevOps

PHP

Programmierung allgemein