Nach dem Durchspielen des hervorragenden Return to Monkey Island ist mir in meinem Gog-Account Indiana Jones and the fate of Atlantis über den Weg gelaufen. Und nach knapp acht Stunden war dieses auch durchgespielt. Ich hatte es länger in Erinnerung, was aber auch daran liegen könnte, dass ich mich echt an viele Rätsel erinnert habe, die man sich damals erst mühsam erarbeiten musste. Nur an das verdammte Türen-Rätsel ganz am Ende konnte ich mich nicht mehr erinnern und das hat mich echt lange aufgehalten.

Jetzt fehlt mir nur noch die Rakete, die man bei 200.000 Punkten im A-Mode bei Tetris bekommt. Ich war schon kurz davor, aber wie es dann so ist, kamen nur noch falsche Blöcke. Als ob das Spiel das absichtlich machen würde.

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.

Eins der ersten Computerspiele war Spacewar!, das MIT-Studenten auf einer PDP-1 (1, nicht 11) programmiert hatten. Auf einem Oszilloskop als Monitor konnten zwei Spieler jeweils ein Raumschiff, um einen Stern herum steuern und versuchen, den anderen Mitspieler abzuschießen. Erschwerend kam das simulierte Gravitationsfeld des Sterns hinzu, der die Raumschiffe und auch deren Geschosse beeinflusste. Und das im Jahr 1961.

Und jetzt kann man Spacewar! mit der neuesten Beta des PocketOS auf einem Analogue Pocket spielen! Und ich trete mir in den Hintern, dass ich mir damals nicht gleich das Dock bestellt habe, denn dann könnte man das auch zu zweit spielen. Wer möchte, kann es aber auch im Browser mal versuchen, da gibt es unter anderem diese gelungene Umsetzung.

Nun habe ich das Prequel zum dritten Teil der "Grand Theft Auto"-Serie durchgespielt. Mittendrin hatte ich Gefühl, dass ich diesen Teil damals doch nicht durchgespielt habe, aber als es dann darum ging, diverse Gebäude zu kaufen, um mit diesen Geld zu erwirtschaften, wußte ich wieder, wie nervig ich diesen Part fand. Die Idee dahinter verstehe ich, aber den Part hätte man besser über die gesamte Story verteilen sollen. So spielt man das Spiel in Missionen zu gut einem dreiviertel durch, um sich dann darum kümmern zu müssen, etliche Firmen zu übernehmen. Mitten in der Geschichte und zu einem Zeitpunkt, an dem ich wissen will, wie es weitergeht.

Trotzdem spürt man deutlich, wie sich schon in diesem Teil, der genau ein Jahr nach Erscheinen von GTA III das Licht der Welt erblickt, das Spiel weiterentwickelt hat. Und bis auf die nervige Cop-Land-Mission gab es keine großen Schwierigkeiten das Spiel durchzuspielen. Was aber eigentlich alle Teile der GTA-Reihe auszeichnet: die Spielmechaniken sind simpel und der Hauptaugenmerk liegt auf der Geschichte.

Und jetzt freue ich mich auf CJ und Los Santos.

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. ;-)

In der Entscheidungsphase zur Wahl eines Content Management Systems hört man zu TYPO3 oft, dass das Backend für den Redakteur nicht intuitiv und viel zu überladen ist. Dass es zu viele Optionen und Felder gibt, die man beim Erstellen von Inhalten gar nicht verwenden würde und zu einer Überforderung der Redakteure führen.

Auch habe ich schon viele Backends gesehen, in denen für die Redakteure das Backend nicht angepasst oder sogar gar keine Benutzergruppen mit entsprechenden Rollen verwendet wurden. Und somit alle Benutzer mit Adminstrationsrechten im Backend unterwegs waren.

Das hat in meinen Augen mit der steilen Lernkurve von TYPO3 zu tun, die dem Anfänger entsprechende Steine in den Weg legt. Wenn man aber das Konzept der Konfiguration von TYPO3 verstanden hat, stehen einem alle Türen offen, das Backend so einfach wie möglich zu gestalten. Und zwar lediglich mit den Feldern und Optionen, die man zum Erstellen von Inhalten benötigt.

Um das zu erreichen gibt es einen ziemlich einfachen Weg: das Ausblenden von Feldern mittels TCEFORM, dem Setzen von Default-Werten für Felder mit TCAdefault und dem konsequenten Einsatz von Benutzergruppen. Administratoren sind wirklich nur Administratoren und nicht für das Erstellen von Content zu verwenden. Bei einem ordentlich aufgesetzten TYPO3 sollte man sich also eigentlich nie mit einem Administrator-Account anmelden müssen. ;-)

Nur weil ich eigentlich mal ein paar Apps vom Telefon löschen wollte, habe ich vorhin dann mal Monument Valley in einem Rutsch durchgespielt. Okay, das ist keine Meisterleistung, besteht das Spiel doch nur aus zehn Level. Und die Rätsel sind auch nicht sonderlich schwer, wenn man nur halbwegs in der Lage ist, eins und eins zusammen zu zählen. Aber schön ist es immer noch anzusehen, auch wenn es mittlerweile acht Jahre auf dem Buckel hat. Ich mag solche Rätselspiele auf dem Smartphone, für die man nur ein paar Minuten Aufmerksamkeit benötigt.

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.