Rethink yourself…

— Teaser —

Ich mache nun schon eine ganze Weile Software im und für das Internet – seit 1999 um genau zu sein – und heute muss ich meinem Herzen mal Luft machen.
Liebe Juniors, liebe Seniors: Hört auf, mein Internet kaputtzumachen.

— Kleiner Exkurs – Wie alles begann —

Als ich anfing, professionell Software zu entwickeln (ich also Geld für etwas bekam, was ich gerne machte), da schrieb man das Jahr 1999 – es ist also schon eine Weile her. Damals™ war das Netz noch recht neu im Massenmarkt, es gab keine Androiden oder iPhones und Webseiten rief man auf dem Computer zu Hause mit einem Browser ab. Die Leitung in dieses neue Netz war eher langsam und kostete dazu in Deutschland sowohl einen monatlichen Festbetrag als auch noch einen Geldbetrag pro Zeiteinheit (meist ein paar Pfennige pro Minute, lies bei Wikipedia nochmal über die Deutsche Mark nach, wenn dir Pfennige nichts sagen). Kurzum: Zeit war ein doppelt treibender Faktor in diesem Internet. Zum einen war Zeit kritisch, weil die Leitung nicht so schnell war (ein winziger Bruchteil heutiger Technik) und zudem war es auch noch teuer, je länger man online war (Flatrates kamen erst später).

In diesem Umfeld bekam ich nun Kontakt mit dem Internet und lernte, wie die Technik zur Darstellung von Webseiten funktioniert, was das TCP/IP Protokoll ist (und warum dieses Protokoll so toll ist, bis heute) und was alles zwischen dem „ich drücke enter, nachdem ich die URL eingegeben habe“ und „der Browser ist endlich fertig, das Modem kann wieder aus“ so alles passiert – dies prägt mich bis heute. (Zur Erinnerung: Das Modem kann aus heißt, dass ab dann kein Geld mehr bezahlt werden musste … und es heißt auch, dass ab dann auch kein Internet mehr zur Verfügung stand; dies für die jüngeren unter euch).

Ich habe damals also – geprägt von Zeit- und Geldnot – viel gelernt, vor allem darüber, wie man die Informationen einer Webseite schnell und datenoptimiert an den Browser bringt. Generell war die Optimierung von Code an die Aspekte Schnelligkeit und Robustheit (beide sind gleichwertig zu betrachten) von großem Interesse und allgemeiner Usus, ähnlich wie heute Unit Testing zum „guten Ton“ gehört, so war es damals vor allem optimierter Code, der zum Handwerkszeug gehörte; erschien dein Code nicht optimiert, warf das kein gutes Licht auf dich und dein Können.

Das Resultat des Ganzen war Code, der schnell und stabil vom Server zum Browser gesendet wurde und dort komplett (und möglichst fehlerfrei) bis zum nächsten „Cache renew“ verbleiben konnte, damit die Leute sich deine Seite möglichst offline in Ruhe durchlesen konnten.

Wer jetzt ganz genau mitgelesen hat, der erkennt so manchen Kunstgriff, so manche Technik wieder, die heutzutage einen anderen Namen hat oder dem einfach ein neuer Anstrich gegeben wurde. Im Kern ist es aber nichts anderes ist als das, was schon vor über 25 Jahren zum guten Ton gehört hat. Begriffe wie „Client side caching“ kommen da vor, „Server side purging“, „Load balanced optimization“ und der Begriffe vieler sagen dem ein oder anderen bestimmt etwas.

— Paradigmen —

Ouch, ein schweres Wort, ein Wort zudem, bei dem sich 10 Entwickler im Raum nicht einigen können, was es denn genau bedeutet. In diesem Fall hier bedeutet es so etwas wie „verschriftlichte best practices“ im Sinne von: Wir haben damals viel ausprobiert, viel gelernt und haben versucht, dass, was sich als das Beste herauskristallisiert hat, niederzuschreiben, damit es die Leute nach uns nicht so schwer haben. Damit da etwas ist, woraus diese neuen Leute schneller lernen können und die alten Fehler nicht wieder machen (denn das spart Zeit, mit denen man wieder neue Wege beschreiten kann).

Eines dieser alten und fast vergessenen Paradigmen heißt abgekürzt YAGNI und ausgeschrieben steht es für „you aint gonna need it“ und bedeutet soviel wie „du brauchst das nicht“. Meistens wird dies zusammen mit einem anderen Paradigma gebraucht, dem KISS-Prinzip, was für „keep it simple stupid“ (hier kommt wahlweise ein Komma hin oder auch nicht, ist aber für den weiteren Verlauf nicht weiter wichtig). KISS soll einem sagen, dass man Dinge einfach halten soll, sprich: Gibt es mehrere Lösungswege für ein Problem, dann nimm das simplere. Klingt doch logisch, oder? Wer befasst sich gern mit schwierigen Lösungen, wenn es eine einfachere gibt, die genauso funktioniert. Der letzte Teil ist übrigens wichtig, denn zur Entscheidung, ob ich eine einfachere Lösung nehmen kann, bedarf es natürlich der Forderung an diese Lösung, dass diese bitte auch mein Problem lösen soll. Eine einfache Lösung, die mein Problem nicht oder nur zum Teil löst, ist nutzlos wie eine leere Rolle Toilettenpapier – theoretisch machbar, praktisch aber nicht zu empfehlen.

Bewaffnet mit dem Wissen um diese alten „best practices“ können wir nun einen Schritt weiter gehen.

— Wie Webseiten funktionieren —

Der technische geneigte Leser möge mir verzeihen, wenn ich in diesem Kapitel nur ganz grundsätzlich auf die Funktion des technischen Ablaufes eingehe, aber dieser reicht für ein grundsätzliches Verständnis zum Thema sicherlich aus, ohne den nicht-technischen Leser zu überfordern.

Prinzipiell funktioniert das Netz so, dass „ich“ als Benutzer eine Ressource bei einem Server anfordere und dieser mir eine Information zusendet, ob er mir diese ausliefern kann oder nicht (und dann auch, warum nicht). Im Weiteren gehen wir mal davon aus, dass wir keinen technischen Defekt haben und alle Ressourcen, die wir haben wollen, auch da sind, wo wir diese anfordern.
Ist eine Ressource vorhanden, dann liefert mir der Server eine Information dazu (200-OK) und meistens auch eine Antwort im „body“ welches dann die Ressource ist (ich sagte ja, ganz stark vereinfacht).

Im speziellen Fall einer Webseite können dies folgende Dinge sein:
– Die Seite selbst
– Zur Seite gehörende Dinge wie
— CSS
— Javascript
— Bilder
— sonstiges

Und eines ist noch gut zu wissen: Oben sprach ich von „ich“. Dieses „ich“ in diesem Fall der Browser. Dieser sendet eine Anfrage an den Server, der Antwortet dann und der Browser muss mit dem Ergebnis dann umgehen (und ggf. noch mehr Ressourcen nachladen).
Nur: Was macht der Browser denn da genau?

— Was der Browser spricht —

Der Browser, heutzutage ein Zwiespalt zwischen Chromium-basierten und dem Firefox, kann im Prinzip nicht viel mehr als es schon Browser in der alten Zeit konnten: Er kann HTML.
HTML – die „Hypertext Markup Language“ – ist das Grundgerüst jeder Webseite. Jeder. Wirklich.
Im Prinzip kann der Browser ohne HTML keine Webseite darstellen und egal auf welcher Seite im Netz du bist, du kannst ja mal in deinem Browser auf „Quelltext anzeigen“ gehen und siehst: Ja, HTML, definitiv.

Ok, der Browser kann auch noch ein paar Dinge mehr, dazu gehören z.B. Bilder anzeigen, Töne abspielen, Styles „verstehen“ und JavaScript interpretieren. Was braucht man sonst noch für eine Webseite, egal welche? Genau, nichts mehr. Das war’s. Alle Webseiten bestehen aus diesen Dingen.

Du brauchst ein Grundgerüst aus HTML, damit der Browser überhaupt etwas damit anfangen kann. In diesem HTML stehen dann diverse Dinge, zum Beispiel auch, ob der Browser noch etwas nachladen soll, nachdem er mit dem HTML interpretieren fertig ist. Dazu können Stylesheets gehören – die CSS Dateien – oder auch JavaScript, was eine Seite wieder dynamisch erscheinen lässt.

Aber die erste Sache, der Browser macht, ist HTML laden und interpretieren.

— Damals zu heute —

Die ersten Seiten im Netz bestanden nur aus HTML und dienten in erster Linie dem Informationsaustausch. Das Besondere an diesem Austausch war, dass man nicht nur Informationen darstellen konnte und sie „jeder“ (der es sich leisten konnte) abrufen konnte. Vielmehr war es die fantastische Möglichkeit, diese Informationen auch in Beziehung zueinander zu stellen. Das heißt, sprach man in einer Seite z.B. von Wikipedia, dann konnte man eine Beziehung zu einer anderen Seite herstellen, die dann diesen Begriff näher, tiefer, besser erklärte, so dass man seinen eigenen Kontext nicht immer wieder für Erklärungen verlassen musste. Eine tolle Sache, heute kennt man das als „Links“ auf Webseiten.

Ein wenig später kam dann der Wunsch auf, Seiten nicht mehr nur um ihrer Information wegen ins Netz zu stellen. Es kam – wie bei den meisten Dingen – auch darauf an, sie „schön“ zu präsentieren, was nach ein paar kurzen Irrungen und Wirrungen zu dem führte, was die meisten als CSS kennen. Die Möglichkeit, die Inhalte im HTML vom HTML getrennt gestalten. So sahen dann die Informationen ein wenig besser aus und konnten (manchmal, nicht immer) leichter gelesen werden.

Irgendwann zwischen „Wir haben das Internet erfunden“ und heute kam jemand auf die Idee, in diesem Internet doch auch dynamische Inhalte sehen zu wollen. Bis dahin war das Netz recht statisch. Es gab Seiten, Seiten standen in Beziehung zu anderen Seiten, aber im Prinzip hat sich eine Seite, war sie einmal online, nicht mehr geändert … zumindest nicht von selbst.
Die Technologie, die dynamische Inhalte ermöglichte, ist bis heute unter dem Namen „JavaScript“ bekannt (und nochmal: JavaScript hat nichts mit Java zu tun!!1!).

Diese Dinge, von erfahrener Hand respektvoll zusammen gefügt, ergaben zumeist informative Seiten, die überdies auch noch schön waren. Denkt man, in der Masse waren es meist blinkende Terrorwüsten ohne Inhalte, dagegen sind Cookie-Banner schon unaufdringlich – aber ich schweife ab, lassen wir uns die Illusion, dass die Webseiten mit HTML, CSS und JS gut funktionierten und ihren Sinn erfüllten.

Hier könnte die Geschichte nun zu Ende sein … wenn da nicht der „Ruf der Experten“ gekommen wäre.

— Berühmte Zitate —

Berühmte Zitate sind auch sowas wie „best practices“, allerdings nicht mit lehrender- sondern mit mahnender Funktion.
Besonders gut passt hier „Der Weg zur Hölle ist mit den besten Absichten gepflastert“, was uns so langsam in die Neuzeit des Netzes bringt.

— Soziale Medien als Motor —

Irgendwann nach 2010 (dem Datum des ersten iPhones und damit dem Massendurchbruch des mobilen Internets und damit dem Vormarsch sozialer Medien) kamen Entwickler der sozialen Medien auf Ideen, um Ihre Webseiten (nichts anderes ist ein soziales Medium technisch gesehen) schneller und effektiver an jedermann zu bekommen. Mobiles Internet war damals teuer (ähnlich wie das Internet generell ein paar Jahre vorher auch zu Hause) und damit die Leute die sozialen Medien auch unterwegs gern (und damit viel) benutzen, mussten die Seiten schnell geladen werden (auch das passt zu den Erfahrungen der Jahre vorher). Soziale Medien aber möchten auch viele Informationen an den Mann bringen, was zunächst dem Prinzip des „schnell“ eher entgegengesetzt ist. Wie bekommt man nun „schnell“ und „viel“ übereinander?

Das überlegten sich viele Leute, die Ergebnisse waren zumeist recht enttäuschend und alles andere als schnell (oder gar einfach). Dennoch, irgendwann hatten ein paar schlaue Menschen nicht nur die zündende Idee, sondern auch gleich die passende (und funktionierende) technische Lösung dafür: reaktive Webseiten. Du kennst das heute als „infinite scrolling“, d.h. du bist bei deinem Lieblingssocialnetzwork und kannst scrollen bis der Arzt kommt, es geht einfach immer weiter und weiter und weiter (auch als Doomscrolling bezeichnet). Der Trick hierbei ist, dass die Inhalte nicht im initialen Requests deines Browser zu finden sind, sondern die Dinge werden „on the fly“ immer dann geladen, wenn du am Ende der geladenen Daten bist. Heute geht das recht zügig, so dass der normale Netznutzer auch im mobilen Falle nichts oder nicht viel davon mitbekommt.
Und damit fängt das Problem so langsam an, konkret zu werden.

— Die „Lösung“ —

Massenhaft Daten dynamisch ohne Seitenwechsel nachzuladen bedeutet, dass wir mit den Standardmitteln nicht weit kommen. Daten nachladen ohne eine neue Seite zu laden bedeutet, dass wir die Daten per JavaScript nachladen müssen. An und für sich ist das nichts neues und auch, je nach Einzelfall, auch nicht per se schlecht. Es gibt durchaus Szenarien, wo das Sinn macht und auch sinnvoll ist. Das Problem eskalierte allerdings anders.

Ein großes soziales Netzwerk „erfand“ (nicht wirklich, wir vereinfachen aber mal) ein JavaScript-Framework, dessen Grundgerüst nicht mehr die Ergänzung von HTML darstellte, vielmehr begreift sich dieses Framework als Grundgerüst selbst, so dass sämtliche Arbeiten zur Darstellung der Homepage nicht mehr per HTML (und CSS und JS) getätigt werden, sondern samt und sonders in JS selbst durchgeführt werden. Für den jungen und unerfahrenen Entwickler bietet das den „Vorteil“, dass er „seine“ eine Sprache nicht verlassen muss und alles komplett „ohne Stilbruch“ aus einem Guss erledigen kann. Kein Witz, dies ist wirklich eine der Argumentationen für diese Vorgehensweise und dummerweise glauben bis heute viele Entwickler, dass das eine gute Sache wäre.

— Der Stand der Dinge —

Kommen wir nun zu den Details und damit dahin, wo es schmerzt. Nicht im Sinne von „es funktioniert nicht“, sondern im Sinne von „warum glaubt ihr, dass das eine gute Idee ist“. Kurzum, sehen wir die „Lösung“ mal an.
Der aktuelle Stand der Dinge ist der, dass viele junge Entwickler damit groß werden – und auch so ausgebildet werden -, dass alles in JS erledigt werden kann, was dann oft zu dem Irrglauben führt, dass auch alles in JS erledigt werden muss und JS-Frameworks sozusagen alternativlos sind.

Aber was passiert eigentlich bei diesen Frameworks?
Bauen wir uns doch mal ein gedankliches Beispiel: Lass uns eine Seite für eine Arztpraxis bauen, vielmehr, lass uns zwei Seiten bauen, gleiches Layout, gleiche Funktionen, das eine mit einem JS Framework, das andere klassisch.
Beim JS-Framework brauchen wir gar keines konkret heranziehen, da der Funktionskern prinzipiell gleich ist. Von daher können wir einen Pseudo-Funktionsansatz darlegen, der zur Veranschaulichung auch völlig ausreichend ist.

— Der Framework Ansatz —

Natürlich benötigen wir zunächst mal ein installiertes NodeJS nebst npm. Dann brauchen wir entsprechend natürlich auch unser geliebtes JS-Framework (hier Name einfügen) und das zieht sich dann auch gleich mal alle seine Abhängigkeiten in Form diverser JS-Pakete ran. Dabei benötigt natürlich auch jedes Paket wieder seine eigene Abhängigkeiten von anderen Paketen, die npm natürlich auch gern für uns auflöst, runterlädt und an seinen Platz in den `node-modules` Ordner legt. Allein die Vanilla für das Framework wiegt bereits jetzt eine Menge.

Dann müssen wir natürlich auch die Seite selbst bauen, d.h. wir müssen routing einstellen, (Pseudo-)Klassen anlegen, Komponenten registrieren und benutzen, alles so verpacken, dass es das Framework auch versteht und dann am Ende die Inhalte der Seite anlegen.

Anschließend laden wir alles auf unseren Webserver, stellen den entsprechend so ein, dass der auch korrekt in das Framework routet und rufen dann die Seite auf.
Wenn man sich jetzt den Spaß macht und in den Browser eigenen Entwicklertools nachsieht (drück doch mal F12, wenn du nicht weißt, wovon ich rede), dann nimmt sich der Aufruf meist recht viel Zeit und ist auch recht groß. Du siehst das ganz unten in den Entwicklertools bei den „Netzwerkanalysen“ wo steht „xyz Anfragen, xyz übertragen, Beendet: xyz ms“.

Merk dir diese Zahlen mal, sowohl was die Anzahl der Requests angeht, als auch die Größe der übertragenen Daten.

Der Kern des Ganzen, warum ich diesen Ansatz kritisiere, ist der, dass zunächst einmal Tonnen von Daten Clientseitig durch ein Framework geroutet werden, um dann am Ende doch wieder zu einer kleinen Arztpraxis-HTML-Seite zusammenzufallen. Der Aufwand, um hier zum Ergebnis zu kommen, ist recht hoch, gleichwohl der Nutzen doch eher überschaubar bleibt. Möge mir jemand das Buch der Erkenntnis reichen, den bisher sehe ich da keinen Vorteil.

— Der klassische Ansatz —

Wir erstellen Seiten+1 Dateien, eine ist für das CSS, die anderen sind die eigentlichen Seiten. Da bauen wir einfach die Seiten, die wir brauchen und nennen die „xyz.html“, die zusätzliche nennen wir „xyz.css“ und die ist nur für das CSS. Okay, wir könnten noch eine machen, eine „xyz.js“, aber mal ehrlich, warum? Das wird eine Arztseite, dynamisch ist anders.

Wenn wir fertig sind, laden wir die alle auf den Server und sind fertig – html und css können alle Webserver per Default ausliefern, dafür sind die gebaut worden *zwinkersmily*.

Auch jetzt schauen wir nochmal in den Netzwerkanalysen nach und siehe da, exakt Seiten+1 (oder +2, je nachdem ob wir eine js mitliefern oder nicht) Requests wurden gemacht. Ich gehe fast jede Wette ein, dass die Größe und die benötigte Zeit für das Abrufen der Seite wesentlich kleiner sind als mit dem anderen Ansatz.

— Von Hämmern und Nägeln —

„When all you have is a hammer, everything looks like a nail!“ … das ist ein schlauer Spruch, den man sich tief im Gehirn verankern sollte. Du bist ein Junior, du kennst dich mit JS aus. Okay, aber warum kennst du dich nur mit JS aus? Weißt du, dass alle JS-Frameworks am Ende auch nur HTML auswerfen? Was anderes kann dein Browser einfach nicht darstellen. Auch Electron nicht (ist auch nur ein gemappter Chromium-Browser). Die wollen alle nur HTML haben.

Und nun mal eine Frage: Warum gibst du ihm nicht einfach HTML?
Es mag sicherlich ganz toll sein, wenn man einen Hammer hat. Damit kann man wunderbar Nägel in die Wand hämmern. Wenn du allerdings nur einen Hammer hast, dann fängst du auch an, Schrauben in die Wand zu kloppen (oder wer-weiß-wohin noch) und oberflächlich betrachtet funktioniert das auch …. zunächst. Aber der Teil, den du nicht siehst, der erhält durch unsachgemäße Benutzung Schäden (in dem Beispiel: Der Dübel wird zertrümmert, die Schraube zerstört). Und offenbar ist das ja auch erst einmal in Ordnung, weil: Das kleine leichte Bild, was du da aufhängst, das hängt doch. Ergo: Funktioniert.

Was bei deinem kleinen Bild noch ok zu sein vermag, das hält allerdings die Analogie zur Softwareentwicklung nicht mehr aus. Sicher mag dein Projekt im kleinen Rahmen (lies: auf deinem Rechner oder kurz nach dem Live-Start) noch funktionieren, was passiert aber, wenn dein Projekt plötzlich ein Erfolg wird? Von jetzt auf gleich strömen nicht mehr 2 Besucher pro Stunde deine Seite, sondern 20.000 pro Minute. Hält dein Projekt das aus? Die Schraube in der Wand wird mit Sicherheit keinen Elefanten aushalten, so kaputt wie die innen drin ist.

Jetzt sagt so mancher „meh, das ist unrealistisch“. Ist es das? Ist es nicht das, was sich alle Entwickler wünschen, dass „dein“ Projekt wie eine Bombe einschlägt und erfolgreich wird? Ich wünsch mir das jedes Mal und aus dem Grund bereite ich mich auch darauf vor, dass es mal so weit kommt. Ich betrachte als verantwortungsvoller Entwickler nicht nur den normalen „alles ist rosa“ Weg, ich betrachte vor allen Dingen die aus der Mathematik bekannten Grenzwerte, die Randbereiche, die „Roten Zonen“, die Kehrpunkte, kurzum: Ich bin da, wo es weh tut, in der roten Zone.
Warum? Ganz einfach: Wenn es in der roten Zone funktioniert, dann funktioniert es überall!

Warum die ganzen Umwege über Frameworks, Komponenten, Abhängigkeiten von eher fragwürdigen 3rd Party Librarys (wann wurden die zuletzt aktualisiert? Welche Sicherheitslücken haben die eigentlich?).

— Security —

Apropos Security!
Ich selbst baue nicht nur beruflich Webprojekte, ich baue die auch im Privaten, zum Teil auch für das Ehrenamt. Mein Anspruch an meine privaten Projekte ist nicht anders als der Anspruch für die beruflichen Projekte. Ergo untersuche ich den Code für meine Projekte auch (nicht nur, aber auch) auf die Sicherheit. Dazu gibt es Tools und Anbieter, die einen dabei unterstützen (verlass dich aber nicht nur auf andere, denkt auch selbst).
Meine Web-Projekte basieren zumeist auf dem TALL-Stack, d.h. im Kern ist es PHP auf der einen und JS auf der anderen Seite. Was mir nun auffällt ist, dass ich wesentlich (!) mehr Meldungen zu Sicherheitsproblemen in den JS-Teilen bekomme als in den PHP Teilen. Damit meine ich in beiden Fällen die jeweiligen 3rd Party Librarys, die zwangsläufig sowohl bei PHP als auch bei JS installiert werden. Es ist erschreckend, dass sich da eine Quote von 17:1 rauskristallisiert (nochmal für Juniors: auf 17 Sicherheitsmeldungen zu JS kommt eine für PHP, Tendenz eher steigend auf Seiten JS).

— Fazit —

Eingangs erwähnte ich bereits die best practices aus grauer Vorzeit, „YAGNI“ und „KISS“. Meine Beobachtung ist aber, dass diese Paradigmen entweder nicht mehr beachtet werden oder deren Existenz schlicht unbekannt ist.

Wenn die dir unbekannt waren, dann freut es mich, dass ich es dir näher bringen konnte. Du kannst dich gern weiter in diese Prinzipien vertiefen und diese verinnerlichen, es wird dazu beitragen, aus dir einen besseren Entwickler zu machen.
Wenn es allerdings nicht beachtet wird, dann heißt dies ja, dass diese Paradigmen durchaus bekannt sind und schlicht aus gottgegebener Selbstherrlichkeit missachtet werden. Aber: Warum? Machst du irgendwas besser, weil du mehr Dinge auf das Problem wirfst, ohne es besser zu lösen? Wahrscheinlich nicht. Mein Eindruck bei dieser Sparte („ich ignoriere mal dieses alte Zeug, das ist alt, heute machen alle JS, basst scho“) ist leider, dass viele zum einen gar nicht den Überblick und damit das Wissen haben, was da eigentlich im Hintergrund passiert und zum anderen nur sehr wenige bereit sind, sich dem „alle machen das“ entgegenzustellen.

In meinem Kopf geht dann immer ein Schild mit einem sehr sinnigen Spruch hoch:
„Fresst mehr Scheiße, Milliarden Fliegen können sich nicht irren!“
Soviel zur Weisheit der Masse 😉

Mein persönlicher Anspruch ist, dass ich das immer das „limes(beste Projekt)“ baue und dazu gehört auch, dass ich mir zuerst die Aufgabenstellung anhöre und erst dann entscheide, mit welchen Technologien man das wohl lösen könnte. Mein Werkzeugkasten umfasst mehr als nur eine Sprache und mehr als nur ein Framework und dies alles aus Jahren der Erfahrung, des Scheiterns und Verzweifeln, des Wegwerfen und „Machen wir die Nacht durch und schreiben es neu“-coden.

Aspekte wie Sicherheit, Robustheit und Schnelligkeit (alle sind gleichwertig) haben bei mir immer Vorrang vor irgendeinem „das geht noch hübscher, wenn wir library xyz noch requiren“ Ansatz. Zuerst muss es funktionieren, es muss stabil sein, schnell und sicher.
Hübsch kommt dann und CSS mit HTML kann in der Regel bereits 90% deines JS-Frameworks abdecken, man sollte nur mal die Doku von HTML komplett lesen.

Ständiges Hinterfragen deines Wissens wird dazu beitragen, dass du ein besserer Entwickler wirst; ein Leitstrahl kann für dich derselbe Satz sein wie für mich: „scio me nihil scire“.

Nodejs und npm auf Windows installieren

Um NodeJS und den darin enthaltenen Package-Manager npm kommt man heute nicht mehr rum. Unter Windows hat es leider den Ruf, dass es schwer bzw. umständlich zu installieren sei und in der Vergangenheit war das auch oft der Fall.

Heute, mit Windows 10 oder Windows 11 sieht dies aber schon deutlich anders aus. Ganz im Linux-Stil geht es aber auch heute (noch) nicht per Kommandozeile.

Die Installation von nodejs ist recht trivial, im folgenden gehe ich von Windows 11 aus. Die Prozedur sollte unter Windows 10 wenn überhaupt, dann nur leicht anderes sein.

Zuerst lädt man sich das richtige binary als Installation runter. Dazu geht man auf die NodeJS Homepage in den Downloadbereich und man wählt am einfachsten den „Windows Installer (.msi)“ mit der passenden bitzahl aus (bei den meisten wird dies 64-bit sein).

Anschließend führt man die Installation aus und läßt diese wie gewohnt komplett durchlaufen. Sobald die Installtion abgeschlossen ist, kann man eine neue Konsole öffnen und wie gewohnt nodejs bzw. npm Befehle ausführen.

Eine kurze Prüfung, ob nodejs und npm erfolgreich installiert wurden.

Wenn diese beiden Kommandos, die einfach nur nach der installierten Version fragen, keine Fehler ausgeben, wurde nodejs mit npm erfolgreich installiert.

Get started with PHP + MariaDB on Windows

Even the longest journey starts with the first steps…

– Some wise guy

Welcome

Hej you ?, you want to start your developer career with php and you have no clue how to start and you do not want to pay hundreds or more dollars to start?

No problem, welcome to this post.

First: You do not have to pay anything to get started and make your first steps. All you need is a computer with windows (for this tutorial) and an internet connection (you can read this, you sure have one ?). And some time …. time is your currency to get into this developer thing.

PHP

To install php, you need to download it from the windows download section of the php homepage. Go to https://windows.php.net/download/ and choose your desired version. I recommend using the latest x64 „threat safe“ version – in most cases, this is the second option to download. You will propably learn about „thread safe“ and „non-thread safe“ in the future, but for starting, choose the „thread safe“ one ?.
Download the ZIP file!

Once downloaded, unzip it to a destination you like. I do have my php in „d:\php“ but the coise is up to you. Once you unzipped it, remember the file path to your php.

Now, you have downloaded php and unzipped it, but you will not be able to work with it properly. We have to setup the „path“ variable to your installation.

⚠ I assume you to be on at least Windows 10 for the next steps, for older versions locations may differ.

Open your system settings by pressing `Win` (the windows logo key) and `i` the same time. In the search field, type `path` and chose `edit system variables`. Chose the middlest tab called „Advanced“ and on the bottom there, click on „System variables„.

You see a new dialog, in the lower one search for „PATH“ and double-click that. Say „New“ and insert the path to your php installation. After that click on „Ok“ and close all dialogs with „Ok“. A reboot might be required (never had that, maybe you need to do it, just saying).

You can test it simply by opening your console (right click onto the windows-logo and chose „PowerShell“) and type `php -v`. You should get a result like this:

If you get an error, check the path you entered in your `path` variable; maybe you are the one who needs the reboot!

So, php is installed and ready to run ?.

MariaDB

The next thing you will need is a local database. For this MariaDB is a very good choise. It’s a fork of MySQL and full compatible with it … and on top: it’s free for you as learner ?.

Go to https://mariadb.org/download and choose your favorite. I recomend using the default (latest version, x64, Windows, MSI Package) for this is the easiest to start with.

After downloading, installed it as normal. The installer will ask you to setup a passwort for the `root` user … for this is a local installtion you can also leave it empty; in all cases, you will need this password in your code often, so choose one you do remember!

Ok, MariaDB is also installed now ?

If you courious how to start it: In the installtion you hopefully set it up as service, so just hit your windows-key, type „service“ and start the „services“ app, there you will find a service called „MariaDB“ and you can start/stop/reload it from there.

Connecting to MariaDB from php

When ever you want to connect from your php to your MariaDB and you let the setup use all as default, your database is reachable with

Host 127.0.0.1
Username root
Passwort whatever you setup
Port 3306

Simple as that.

Next steps?

Now, you are ready to develop great things with php and a database. Let’s finish this post with another quote:

Build something great!

– Some other wise guy

How to fix „SSL certificate problem: unable to get local issuer certificate“ on Windows

Du weißt bestimmt, dass ich auf Windows entwickle. Im Gegensatz zu vielen, die auf Macs oder Linux schwören, bleibe ich hartnäckig auf Windows – auch wenn dies bedeutet, dass ich Probleme sehe, die für andere unsichtbar sind. Ich sehe da allerdings die Chance, mehr zu lernen.

Eins dieser „mehr lernen“ Erfahrungen hatte ich heute. Meine phpunit tests laufen automatisch bei github und travis durch, keine Fehlermeldungen, alles gut.
Bis ich dann eben die Tests auf meiner Konsole ausführen wollte:

Anstelle des Erwarteten Fehlers SSL: no alternative certificate subject name matches target host name 'domain.xyz' erwartet mich:

SSL certificate problem: unable to get local issuer certificate

Wie seltsam … jetzt starte ich phpunit mal in meiner WSL Umgebung und siehe da, die Tests laufen alle durch. Das wieder so ein „Typisch Windows“ Problem.

Die Ursache liegt darin, dass du bei Windows-PHP-mit-Curl keine Zertifikatsinformationen per default eingestellt hast … das kann jetzt gut und schlecht sein, auf jeden Fall führt das zu dem Fehler.

Es gibt dazu allerdings auch eine Lösung und die funktioniert recht einfach:

1. Downloade gültige Zertifikatsinformationen von https://curl.se/ca/cacert.pem
2. Benenne die Datei um in curl-ca-bundle.crt
3. Kopiere die Datei, wo du sie gut verwalten kannst, bei mir liegt die in D:/www
4. Editiere deine php.ini. Du musst folgende Einträge ändern:
4.1. curl.cainfo = D:/www/curl-ca-bundle.crt
4.2. openssl.cafile=D:/www/curl-ca-bundle.crt
5. Speichern und Apache neu starten

Und nun laufen auch meine Tests durch ?

 

Laravel – „production.ERROR: No application encryption key has been specified.“

Puuuh, was habe ich an diesem Fehler gesessen und wie einfach doch die Lösung war.

Aber von Anfang an: Beim Zusammenspiel meiner API mit einer Anwendung, die diese API aufruft lief zuerst alles ganz gut. Allerdings: Sobald ich diese zweite Anwendung testen wollte, erschien sporadisch dieser Fehler. Sporadisch im Sinne von: Er trat auf, und das jedesmal, allerdings immer an völlig zufälligen Stellen.

Lange Geschichte kurz: Bei zu vielen Anfragen konnte die .env nicht mehr korrekt geladen werden. Meine Vermutung ist, dass das Dateisystem von Windows einfach zu lahm ist, weil es bei einem Kollegen auf einem Mac funktioniert und er noch nie diese Meldung zu Gesicht bekam.

Der Fix dazu ist relativ einfach: Du musst die Config cachen, dazu einfach dieses Kommando eingeben:

php artisan config:cache

Und dann hat es wunderbar funktioniert mit dem Zusammenspiel.

CouchBase RAW Query ausführen

Mit den Couchbase-Treibern von Marcel funktioniert ein Connect und arbeiten mit Couchbase ganz simpel.
Im Zuge meiner Arbeit stieß ich irgendwann auf das Problem, einen RAW-Query ausführen zu müssen. Damit ihr nicht auch so lange suchen müsst, hier meine Lösung:

DB::connection()->executeQuery(CouchbaseN1qlQuery::fromString($myRawCouchbaseQueryAsString));

 

SourceTree startet nicht mehr (Fehler CLR20r3)

Mein SourceTree startet nicht mehr.
Das so etwas passiert, ist nicht schön, besonders, wenn man dieses tolle Tool beruflich benötigt. Es macht die Arbeit einfacher, gerade dann, wenn man viele Repos verwaltet und einfach auf dem laufenen bleiben möchte.

Schaut man in die Ereignisanzeige, dann offenbart sich der Fehler CLR20r3. Dieser Fehler liegt tiefer und wenn man ein wenig sucht, dann findet man die Lösung dazu:

  1. Deinstallieren von SourceTree
  2. Nun nicht direkt neu installieren, sondern in das VZ „%localappdata%\Atlassian\“ gehen und dort alle Unterverzeichnisse mit „SourceTree“ löschen!
  3. Nun SourceTree neu installieren.

Nun muss man leider das Programm nochmals neu konfigurieren, aber immerhin läuft es nun wieder 😀

 

Im jQuery tablesorter nach deutschem Datum sortieren

Den jQuery tablesorter kennen bestimmt viele, ich benutze diesen sehr häufig und gern. Allerdings kann das Ding von Haus aus nicht nach dem deutschem Datumsformat (dd.mm.yyyy [hh:mm]) richtig sortieren.

Hier dazu mein „Plugin“, dass in die entsprechende JavaScript Datei gehört:

$.tablesorter.addParser({
 id: 'germanDate',
 is: function(s) {
 return false;
 },
 format: function(s) {
 var dateMatches = s.match(/([0-9]{1,2})\.([0-9]{1,2})\.([0-9]{2,4}) ([0-9]{1,2}):([0-9]{1,2})/i);
 return dateMatches[3]+dateMatches[2]+dateMatches[1]+dateMatches[4]+dateMatches[5];
 },
 // set type, either numeric or text
 type: 'numeric'
 });

$('#tblApps').tablesorter({
 sortList: [[1,0]],
 headers: {
 0: { sorter: false },
 2: { sorter: 'germanDate' },
 3: { sorter: false }
 }
 });

Damit kann mein Frontend nun auch innerhalb von Tabellen nach Terminen im deutschen Datum richtig sortieren.