Beiträge aus der Kategorie: Webentwicklung

Bewunderung

Disclaimer vorweg: ich arbeite seit knapp einem Jahr bei in2code. Man kann mir also Befangenheit unterstellen. Muss man aber nicht.

Stefan Busemann hat am letzten Tag der TYPO3 Developer Days 2022 einen Talk gehalten, in dem er die Veränderungen und Verbesserungen der Workflows bei in2code vorgestellt hat. Ich für meinen Teil kann mich und meine Entwicklung darin in großen Teilen entdecken. Wer hat nicht noch im Jahr 2010 Websites über FTP und direkt auf dem Webserver ohne Versionsverwaltung gepflegt und entwickelt?

Auch wenn ich schon im Jahr 2000 den ersten Kontakt mit SVN als Versionsverwaltung (TortoiseSVN anyone?) hatte, hat es noch so bis 2011/12 gedauert, bis es nicht mehr ohne ging. Und auch dass etablierte Workflows immer nach ein paar Jahren evaluiert und entweder in die Tonne getreten oder verbessert wurden, gehört zu unserem Berufsfeld meiner Meinung nach einfach dazu. Ich kenne keinen Software-Entwickler, egal welche Sprache er "spricht", der nicht ständig neuem, heißen Scheiss hinterher jagt und schaut, ob er dieses und jenes nicht in seine Arbeit integrieren kann oder dies und das nicht seine Arbeit verbessert.

Aber zurück zu Stefans Talk, in dem viele Punkte besprochen werden, die in der bisherigen Firmenhistorie verbessert wurden und wichtig für die Firma waren, aber der wichtigste Punkt für mich als Angestellter ist mittlerweile Wertschätzung. Und zwar gegenseitige.

Diese spielt zwar in vielen Punkten, die Stefan anspricht, mit rein, ich finde aber, dass diese viel zu wenig nach Außen getragen wird, wenn es darum geht, eine Firma zu repräsentieren. Was früher der Kicker, Parties oder das neueste MacBook waren, mit dem Firmen hausieren gegangen sind, um neue Angestellte zu gewinnen, müsste in (Post-)Corona-Zeiten eigentlich das Thema Wertschätzung sein.

Ich glaube, dass in der Softwareentwicklungsbranche Remote-Arbeit nicht mehr wegzudenken ist und genauso wie ich es mir früher gar nicht vorstellen konnte, meine Arbeit nur remote auszuführen, mussten sich die Arbeitgeber in ganz schön schneller Zeit auf das "neue" Arbeitsmodell umstellen. Und das war glaube ich härter, da das Risiko ja auf ihrer Seite viel größer war. Damit meine ich zum Beispiel den "Kontrollverlust" über den Mitarbeiter.

Im Office kann man glaube ich viel besser sehen, wie es einem Mitarbeiter geht, ob er mit seiner Arbeit gut vorankommt usw. Das funktioniert meiner Meinung nach per remote nicht so gut. Und hier komme ich so langsam zum Thema Wertschätzung: es ist sehr wichtig, gemeinsam über die Arbeit zu sprechen. Egal, ob es positiv ist oder auch mal schlecht gelaufene Dinge auf den Tisch gelegt werden müssen, um Fehler zu lokalisieren und Workflows zu verbessern. Also genau das, was Stefan in seinem Talk anspricht.

Und da ist die Richtung auch egal. Ein Senior-Entwickler braucht von der Projekt-/Geschäftsleitung Feedback wie von einem Azubi. Oder ein Junior-Entwickler vom Senior-Entwickler. Oder andersherum. Weil es das gegenseitige "Befruchten" ist, was dazu führt, dass man über seine eigene Arbeit nachdenkt und durch die andere Sichtweise erst sieht, dass man sich vielleicht verrannt hat. Oder auch eine positive Seite hat, wenn man mal wieder den geilsten Scheiss ever entwickelt hat. Bis man sich den Code in zwei Jahren anschaut und einem ein "git blame" die Schamesröte ins Gesicht treibt.

Das hat mir eigentlich im letzten Slide von Stefan in seinen "Main learnings" gefehlt. Und wäre ich bei den DevDays gewesen, hätte ich das beim Q&A bestimmt angesprochen.

Werbeblock: wer meine Arbeit mal loben oder kritisieren möchte, soll mal hier schauen. Werbung Ende.

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