Autoskaleriung: Performancetests noch nötig?

Vor ein paar Tagen saß ich in einem Meeting, in dem es um Monitoring von Web-Anwendungen ging. Dabei ging es um Ende zu Ende Monitoring, also vom Backend bis zum Frontend. Genauer um das Überwachen auf Server-Ebene, Application-Ebene, Netzwerk-Ebene und Enduser-Ebene, also volle Transparenz von der First zur Last Mile, was nicht nur eine gute Sache, sondern in meinen Augen Pflicht ist. Dabei kamen wir auf das Thema Load Testing zu sprechen, da jemand in die Runde einwarf, ob es noch sinnvoll ist Performance- und Last-Tests durch zuführen, wenn man eine automatisch skalierende Infrastruktur betreibt. D.h. also je mehr Last auf das System kommt, desto mehr Ressourcen automatisch bereit gestellt werden. Mit heutigen Cloud und SaaS Technologien ist das durchaus möglich.

Autoskaleriung: Performancetests noch nötig? weiterlesen

RUM: Was soll ich messen?

Wie man in meinem Blogpost RUM: Technischer Einsatz im Web sieht, gibt es beim RUM vielerlei Möglichkeiten Abläufe zu messen. Allein die Möglichkeiten, die die Timing Objekte mit ihren Events bieten, können einem am Anfang erschlagen. Es stellt sich schnell die Frage „Was soll ich messen?“ bzw. welche Metriken sind wichtig? Vorab eine wichtige Info: Es gibt keine allgemeingültige Aussage, da jede Webanwendung individuell ist. Nichtsdestotrotz gibt es ein paar Ansätze, die einem den Weg aufzeigen können.

In der Vergangenheit stand im Kontext von Web Performance oder Web Performance Optimization (WPO) oft die Zeit, die benötigt wird, um den „Download der Webseite“ abzuschließen. Von der technischen Seite hat man dies so definiert bis das loadEvent getriggert wurde. Vor 10 bis 15 Jahren war dies eine eindeutige Metrik, da zu diesem Zeitpunkt wirklich alle Elemente geladen waren. Mittlerweile haben sich die Web-Technologien rasant entwickelt, vor allem durch JavaScript, welches sehr mächtig geworden ist. Vielen Dinge passieren mittlerweile asynchron oder erst nach Interaktion des Nutzers, um ein ansprechendes Erlebnis zu liefern – nicht nur aus Sicht der Performance.

Wie in allen meinen Posts werde ich auch an dieser Stelle nicht müde das Mantra zu wiederholen: Der Endnutzer steht im Mittelpunkt. Um den Endnutzer in den Fokus zu stellen, muss man sich etwas von der rein technischen Sicht entfernen. In diesem Zusammenhang bedeutet dies, weg vom loadEvent hinzu einer Metrik, die wirklich das Erlebnis des Endnutzer widerspiegelt und seine Wartezeit verkürzt.

Die Evolution des Webs bringt es mit sich, dass wir warten bis unserer Ansicht nach die Seite komplett geladen ist. Gelernt haben wir dieses Verhalten durch den Browser, der früher beim loadEvent, uns ein Signal gegeben hat, dass nun nichts weiter passiert, also z.B. die Sanduhr verschwindet. Als Konsequenz daraus fangen wir frühestens an zu interagieren, wenn dieses Signal erscheint oder der sichtbare Teil des Browser sich nicht mehr verändert, also unserer Ansicht nach vollständig ist – ungeduldige und hektische Nutzer mal ausgenommen. 🙂 Dieser sichtbare Teil im Browser heißt „Above the fold“ also „über dem Knick“. Die dazugehörige Metrik heißt entsprechen Above-the-fold-Time (AFT) und lässt sich mit etwas Aufwand erfassen. Allerdings ist AFT auch eine Metrik, die problematisch sein könnte. Je nach Device, Bildschirmauflösung und Fenstergröße gibt es nahezu eine unendliche Anzahl Möglichkeiten wie groß der sichtbare Bereich wirklich ist. Dieser Bereich wird Viewport genannt und ist durch seine Variabilität schwer in Beziehung und Vergleichbarkeit zu setzen. Für mobile Geräte bietet sich dieser Ansatz noch am Ehesten an, da dort der Browser meist im Fullscreen Modus verwendet wird.

Für einen einfacheren und besseren Einstieg schauen wir uns als Beispiel eine typische Nachrichtenseite an – wie etwa spiegel.de. Auf deren Homepage werden viele Nachrichten mit einem Teaser kurz angerissen. Ruft der Besucher die Homepage dieser Nachrichtenseite auf und hat eine interessante Nachricht in der Übersicht gefunden, möchte er schnell den dazugehörigen Artikel lesen und nicht warten bis die Homepage komplett geladen ist. Er will vielmehr direkt zur Nachricht also zum Inhalt gelangen. Daher ist die loadEvent Metrik hier nicht wirklich aussagekräftig. Ebenso versagt AFT, da der Nachricht-Teaser nicht im sichtbaren Bereich sein muss.
Vielmehr ist der Zeitpunkt interessant, zu dem der User auf den Link klicken kann, also wann er mit der Seite interagiert. Dafür bietet sich das domInteractive Event an. Dieses Event wird getriggert, wenn das DOM komplett geladen, geparst und erzeugt ist – auch wenn vielleicht noch Elemente wie Bilder fehlen. In diesem Moment kann der Nutzer auf Links klicken, um so zur nächsten Seite zu navigieren. Eine Stoppuhr, die beim unloadEvent startet und beim domInteractive stoppt, beschreibt also die Zeit bis der Nutzer die Möglichkeit besitzt mit der Seite zu interagieren.
An dieser Stelle muss darauf hingewiesen werden, dass CSS, Fonts und Scripte Einfluss auf das domInteractive Event haben. Es kann sein, dass der User bereits mit der Seite interagieren kann, obwohl ein Script das Event blockiert. Ziel ist es natürlich diese Situation zu verhindern oder eigene Metriken einzusetzen, wie im folgenden Absatz beschrieben. Hierzu passend: SPOFs.

Wichtig zu domInteractive zu erwähnen ist, dass der Besucher die „Möglichkeit“ hat. Das ist nicht gleich zusetzen mit, dass er es auch macht. Zumal ihm nicht zwingend klar sein muss, dass er ab diesem Moment den Link klicken kann. In der Regel gibt es keinen Hinweis vom Browser, dass es so weit ist. Durch sich drehende Sanduhren oder Derivate wird ihm eher das Gegenteil suggeriert. Dem Nutzer wird diese Möglichkeit erst klar, wenn er z.B. mit dem Cursor über einen Link fährt und sich der Mauszeiger dabei ändert.
Um die Zeit zu messen, die der Nutzer wirklich benötigt, um mit der Seite zu interagieren, bedarf es mehr Aufwand. Auch hier gehen wir von einer technischen Standard-Metrik weg und messen wirklich beim Enduser. Und zwar messen wir wann der User klickt, scrollt oder die Maus bewegt. Alle diese unterschiedlichen Aktionen, liefern uns unterschiedliche Informationen darüber, wann der User das Gefühl hat, mit der Seite interagieren zu können.
Leider sind diese Möglichkeiten nicht Build-In in JavaScript oder Bestandteil des Browsers. Daher muss diese Art zu messen per JavaScript Tools oder Frameworks nachgerüstet werden – was natürlich auch wieder einen Einfluss auf die Performance haben kann. Dies kann man aber elegant mit den User Timings umsetzen.

Zusammenfassung
Wie bereits am Anfang beschrieben, gibt es nicht die eine Metrik, die einem jedem Schmerz in Sachen Endnutzer-Performance nimmt. Denn gerade der Endnutzer ist so individuell wie die Anwendung, die er verwendet. Daher Bedarf es auch etwas Forschung und Eigeninititative, welche Messmethode die beste für seinen Zweck ist. Niemals verkehrt ist das loadEvent zu erfassen, da es die bekannteste Metrik und ein gängiger Indikator ist. Ebenso liefert domInteractive einen guten Start, um das Endnutzer Erlebnis zu verstehen. Darauf aufbauend kann man dann das Ganze vertiefen. Wirklich interessant wird es, wenn die Performance Metriken mit dem Business Metriken korreliert werden.

Links:

RUM: Technischer Einsatz im Web

Die JavaScript Umgebung bietet seit ein paar Jahren verschiedene Möglichkeiten um so genannte Timings des Enduser zu erfassen. Timings sind eine Art Stoppuhren, um die Dauer einer bestimmten Aktion oder eines Prozesses zu erfassen. Dabei ist zu aller erst das Navigation Timing zu nennen, welches die Zeiten zwischen verschiedenen Surf/Klick Aktionen (also Navigation) des Enduser misst, z.B. dem Klick auf den Suchen Button (unload / navigationStart Event) bis die komplette Suchergebnisseite geladen ist (load Event). Eine weitere Möglichkeiten ist das Erfassen der Resource Timings, wobei hier Metriken zu den in die Seite integrierten Ressourcen gemessen werden. Unter Ressourcen versteht man Objekte wie Bilder, Skripte, Schriften, CSS, etc. die in die Seite eingebunden sind. Mit den User Timings können dann eigene Stoppuhren in der Webseite gestartet und gestoppt werden, um so z.B. die Laufzeit einer Search-Completion zu messen.

 

Da diese Funktionen noch nicht so allzu lange Teil von JavaScript sind (W3C Recommendation seit Dez. 2012), sind sie in älteren Browsern nicht verfügbar. Einige Hersteller tun sich ebenfalls schwer die Funktionalitäten komplett zu unterstützen, so sind z.B. in allen Apple Browsern die Resource Timings nicht verfügbar. Welche Browser ab welcher Version was unterstützen, kann man sehr gut bei caniuse.com herausfinden.

 

Insbesondere Navigation und Resource Timings bieten mit ihrer Vielzahl an Standardevents viele Möglichkeiten ein Timing zu erfassen. Um genau zu sein, wird hier nicht jedes mal eine eigene Stoppuhr gestartet und gestoppt, sondern wenn ein Event eintritt, wird vom globalen Timer die Zeit genommen und diesem Event zu geordnet. Die Subtraktion zwischen dem gestoppten Zeitpunkt und der Zeit vom Start Event ergibt dann die zeitliche Länge der Aktion.

 

In der Grafik unten erkennt man diese vielen Events des Navigation Timings, die als Standard definiert sind. Die Dauer vom navigationStart bis hin zum loadEventEnd Event entspricht dem Klassiker der Annahme der Ladezeit einer Seite, wie sie allgemein verstanden wird bzw. wurde. Also vom Klick auf einen Link, welches den Start der Navigation zu einer anderen Seiten entspricht, bis hin zum vollständigen Laden aller Objekte dieser neuen Seite. Diese Annahme (Achtung: keine Definition!) stimmt mittlerweile nicht mehr, vieles wird heutzutage asynchron geladen, um die Zeit bis zur Interaktion mit der Seite zu verkürzen. Wie erwähnt ist die Zeit bis zum loadEvent heute nicht mehr das Maß der Dinge, um die Ladezeit einer Webseite zu bestimmt. Viel interessanter ist die Zeit bis der Enduser wirklich mit der Seite interagieren kann, um z.B. etwas in den Warenkorb zu legen. D.h. es ist nicht entscheidend, dass alles geladen ist. Aus technischer Sicht kann der Enduser mit dem Auftretens des domInteractive Events die Seite verwenden, z.B. auf Links klicken. Daher wäre die Zeit von navigationStart bis domInteractive  eine sehr interessante Metrik.

Ein weiteres Beispiel:
Bei vielen Webshops gibt es eine so genannte Browser-Weiche, die erkennt welche Art von Gerät, z.B. Mobile, Tablet, Desktop, die Seite anfragt und eine entsprechende Seite passend für den Screen des Geräts ausliefert. Oft führt diese zu einem oder mehreren Redirects, die alle wertvolle Zeit kosten, während dieser der Enduser keinerlei Aktion sieht, sondern nur warten muss. Bei so einer Architektur kann es sich lohnen das redirectEvent zu erfassen – eventuell auch für einzelne Objekte wie JavaScripts.

 

Zusammenfassung:
Wie man sieht, gibt eine Vielzahl von Möglichkeiten, welche Timings man erfasst. Die Auswahl welche geeignet sind, hängt auch immer davon ab wie die Web-Application verwendet und technisch umgesetzt wird. Es gibt aber ein paar Faustregeln wie das Erfassen von domInteractive, die dabei helfen die Performance und das Verhalten des Endusers besser zu verstehen. Diese Feld bietet viel Raum zu Experimentieren, wie die meisten Bereiche im neuen Medium Web. Der Einsatz und das Verständnis der Faustregeln kann aber schnell zu sehr guten Erfolgen führen, auf die man aufbauen kann.

 

Links:

 

Was ist RUM und warum sollte ich es einsetzen?

RUM steht für Real User Monitoring oder auch Real User Measurement. Beides ist zutreffend, da es sowohl für eine Überwachung in Echtzeit als auch für eine nachgelagerte Analyse oder Reports steht. Gegenwärtig wird RUM in der Regel über ein JavaScript realisiert, welches in die zu messende Webseite/-anwendung integriert wird. Viele Dienstleister bieten mittlerweile auch native Lösungen für mobile Plattformen wie Android, iOS & Windows an. (Mehr Informationen zur Technik in diesem meinem Blogpost: RUM: Technischer Einsatz im Web)

 

RUM wird oft als Teil von Application Performance Monitoring (APM) gesehen, dessen Aufgabe die Überwachung einer Applikation in Hinsicht auf Ladegeschwindigkeit und Verfügbarkeit ist. Im täglichen Gebrauch spricht man bei APM von der Überwachung der eigenen Infrastruktur, also Datenbanken, Application-Server, Web-Server, Caches, Loadbalancer, Firewalls, etc. Beim RUM steht der End-User im Mittelpunkt und nicht die Applikation. So kann es geschehen, dass das APM zwar grünes Licht meldet – also alles läuft intern wie gewünscht, aber der Enduser erfährt trotzdem eine schlechte Performance oder kann die Applikation gar nicht verwenden (d.h. die Verfügbarkeit ist nicht gegeben). Es gibt also eine große Intransparenz zwischen dem Backend und dem Frontend und diese versucht u.a. RUM zu schließen. Eine komplementäre Möglichkeit wäre synthetisches Monitoring.

 

RUM erhebt die Daten direkt beim Enduser (Browser), z.B. durch die Integration eines JavaScript in eine Web-Applikation, welches beim Aufruf ausgeführt wird. Diese Art des Messens stellt Metriken bereit, die uns die direkte Enduser Erfahrung wiedergeben. Zum Beispiel erfährt man die Ladezeit der Seite in dem jeweiligen Enduser Profil. Das Enduser Profil ist dabei von großer Bedeutung, da jeder Enduser die Applikation mit anderen Eigenschaften anspricht. Diese Eigenschaften bestimmen zum großen Teil wie sich die Performance der Applikation für den einzelnen Enduser darstellt. Es gibt eine Vielzahl von Metriken, die in diesem Zusammenhang erhoben werden können. Eine Auswahl:
  • Performance Metriken: DNS Lookup, TCP Connect, SSL Connect, First Byte Time, Load Time
  • Userprofil: Device-Type, Connection-Type, Geolocation, Bandwidth
  • User Engagement: Session Time, Bounce-Rate, Session-Length, Conversion-Rate, Revenue, Orders

 

Vor allem die User-Engagement Metriken sind dabei sehr interessant, da es den direkten Zusammenhang zwischen Performance und Business Metrics darstellt. Es beantwortet also Fragen wie: „Bei welcher Ladezeit habe ich die größte Conversion Rate und/oder wird der größte Umsatz gemacht?“

 

Wichtig bei der Wahl eines RUM Tools ist, dass es die Daten in Echtzeit verfügbar stellt, also dass kein größeres Zeitfenster zwischen den Sammeln der Daten (Data Collection) und dem Visualisieren und Analysieren der Daten entsteht. Die Notwendigkeit lässt sich sehr gut an dem Beispiel einer Email-Kampagne zeigen:
Wird der Newsletter raus gesendet und tausendfach geklickt, kommt kurzfristig sehr hohe Last auf die gesamte Infrastruktur. Kommt es zu einer Überlast, kann sich dies negativ auf die Enduser Performance auswirken, d.h. es kann zu langen Ladezeiten kommen, z.B. der Landingpage. Ist die Toleranz-Grenze der Enduser überschritten, brechen sie die Interaktion ab, z.B. den Kauf eines Sonderangebots aus dem Newsletter. Eventuell macht sich der Enduser Luft direkt beim Anbieter oder sogar über die sozialen Medien und lässt seine Meinung bei Twitter, Facebook und co raus. Zudem kommt, dass die Investition in diese lang geplanten Kampagne stark gefährdet ist und einige zehntausend Euro und mehr in Gefahr sind. Viele Risiken, die man mit RUM besser kontrollieren kann.
Denn mit einem RUM  in Echtzeit kann ich die Enduser Erfahrung überwachen und entsprechende Maßnahmen treffen, wie z.B. eine statische Landingpage ausliefern, überlastete 3rd Party Inhalte abschalten oder die User in einen Waitingroom schicken. Ebenfalls wichtig wird der Echtzeit Aspekt, wenn es zu Zwischenfällen (Incidents) kommt. Über solche Incidents soll so schnell wie möglich informiert werden, um Schaden abzuwenden oder zu begrenzen. Daher müssen Alarme (Alerts) schnell getriggert werden können, am Besten direkte in entsprechende Prozesse und Systeme, wie z.B. BigPanda.

 

Auch in der Nachbetrachtung hat RUM viele Stärken. Durch RUM sammele ich sehr viele Daten über meine Nutzer und kann auf dieser „Big Data“ Menge interessante und wichtige Erkenntnisse gewinnen. Ist man an dem Punkt, an den man weiß, dass man zu langsam für seine Nutzer ist – man hat also den Status Quo erhoben – und möchte die Web-Application optimieren, stellt sich die Frage: Wo fange ich damit an? Die erfassten Business Metriken kann man mit den Performance Metriken korrelieren und bekommt so die Antwort. Ist mir z.B. die Conversion-Rate am Wichtigsten, finde ich heraus, welche Seite oder welche Komponente der Applikation den höchsten Einfluss auf die Conversion-Rate hat. Habe ich diese erkannt, analysiere ich diese Komponente und stelle fest, welches Objekt (oder welche Objekte) den größten Einfluss auf das Laden dieser Komponente hat und – voila – ich habe einen Punkt an dem beginnen kann und sollte.

Zusammenfassung:
RUM stellt den Enduser in den Vordergrund und ist daher sehr mächtig, denn wie der Enduser eine Webapp erfährt, ist das Erfolgskriterium das im Mittelpunkt stehen sollte. Es liefert eine Vielzahl von Informationen, die zum Einen Lücken in der bisherigen Transparenz des Monitorings fehlen. Und zum Anderen viele Informationen für meine Business Entscheidungen liefern können.
Der Einsatz von Agenten, wie z.B. beim synthetischen Monitoring, führt nur zu einer sehr eingeschränkten Datenmenge, auf der sich nur sehr schwer Hypothesen bestätigen lassen – Geschäftsentscheidungen kann man auf dieser Grundlage nicht treffen. Beim RUM sammele ich große Datenmengen, die direkt durch meine Endkunden generiert werden. Auf dieser kann ich Hypothesen bestätigen, z.B. durch statistische und mathematische Werkzeuge und Schlüsse in der eigenen digitalen Strategie ziehen.

WTF ist ein SPOF?

Eine Webseite ist ein wunderbarer Spielplatz für Marketing & Business (und manchmal auch IT), um verschiedene Tools auszuprobieren, die es ermöglichen sollen den (potentiellen) Kunden und sein Verhalten zu verstehen. Von den klassischen Analyse-Tools wie Google Analytics bis hin zu Heatmap Tracking Tools, wie crazyegg, ist die Bandbreite weit gefächert. Letztere zeichnen auf wie es sich mit der Aufmerksamkeit des Users auf einer Seite verhält. Oft wird die einfache Einbindung in die Seite über so genannte Tag Manager ermöglicht, so dass der Aufwand für die IT sehr gering ist. So weit so gut.

Leider kommt es häufig vor, dass sich diese Ressourcen als Single Point of Failure (SPOF) in einer Seite entpuppen. Ein SPOF ist ein Element in einem Konstrukt, dass, wenn es „bricht“, es zu einem Scheitern des gesamten Konstrukt kommt. Im Kontext von Webseiten bedeutet es, dass die Webseite verlangsamt geladen wird. Dieses verlangsamte Laden kann nur ein paar Millisekunden bedeuten, was für den Besucher vielleicht kaum merkbar ist. Es kann aber auch bedeuten, dass die Webseite sehr lange braucht, um komplett geladen zu werden. So lange dass ein Besucher das Laden abbricht und woanders hin surft, da er denkt, dass die Seite nicht mehr reagiert. Im schlimmsten Fall sieht der Nutzer nur ein leeres Browserfenster – auch White Screen of Death (WSoD) genannt.

Dabei ist nicht die Ressource selber das Problem oder die Verwendung eines Tag-Managers. Es kommt darauf an, wie die Ressource in die Seite eingebunden wird. Oft sind solche SPOFs JavaScripte, die das Laden weiterer Elemente blockieren, so lange sie selber nicht komplett geladen, geparst und prozessiert sind. Dies ist übrigens das Standardverhalten von Webbrowsern, wenn ihm nix anderes mitgeteilt wurde. Wird ein Script ganz zu Beginn in einer Seite referenziert (z.B. HEAD), kann es zu einem WSoD kommen.

Dieses Verhalten ist natürlich unschön und mindert das User-Engagement deutlich, da steigender Ladezeit der Besucher der Seite ungeduldiger wird. Daher ist es wichtig SPOFs zu identifizieren und nach Möglichkeit zu entfernen. Insbesondere bei 3rd Party Integrationen fällt das Erkennen manchmal schwer. Zur Analyse eignet sich das Tool SPOF-O-Matic sehr gut, dass als Chrome Erweiterung erhältlich ist. Es wurde von den Betreibern von webpagetest.org entwickelt und enthält eine Möglichkeit ein Video mit dem Worst Case zu generieren – also dann wenn die Ressource nicht geladen werden kann.

Dabei gibt es zwei Kategorien von Ressourcen: Die Einen, die einen wesentlichen Bestandteil der Aufgabe der Seite liefern – visuell oder funktional. Und die, die sekundäre Aufgaben erfüllen, wie Analytic Tools. Bei der ersten Kategorie muss bewertet werden, ob sie wirklich das Risiko eines SPOFs wert ist. So können nachgeladene Schriften (z.B. von Google) ebenfalls blockieren. Natürlich hat eine Schrift keinen funktionalen Wert, aber der visuelle Character der Seite geht ohne diese Schrift eventuell verloren. Die zweite Art sollte ganz klar entschärft und asynchron nachgeladen werden, denn die Enduser Experience steht im Vordergrund. In diesem Zusammenhang sollte man sich die Frage stellen, ob die eingebundene Ressource es überhaupt wert ist, dass sie in der Webseite enthalten ist und Ladezeit kostet.

Ist man zu dem Schluss gekommen, dass man die Ressource benötigt, muss dafür gesorgt werden, dass sie asynchron und nicht blockend geladen wird. Dazu bieten sich die Möglichkeiten DEFER und ASYNC als Attribut von <script> an. Beide verhindern das Blockieren der Weiterverarbeitung der Webseite im Browser. In der Regel ist DEFER die richtige Wahl, da die Ressource dann parallel zum restlichen Inhalt geladen wird, aber erst geparst und prozessiert wird, nach dem das HTML Dokument selbst komplett geladen und geparst ist (DOMContentLoaded). Es gibt nur sehr wenige Situationen in denen ASYNC über DEFER gewählt werden sollte, da bei ASYNC die Ressource zwar auch parallel geladen wird, aber sobald sie vollständig geladen ist, sofort geparst und prozessiert wird. D.h. wenn sie schnell geladen ist, kann sie sich wieder blockierend auswirken. Daher ist eine genaue Kenntnisse der Webseite bzw -applikation von Nöten. Insbesondere bei Applikationen, die sich aus vielen Quellen zusammensetzen. Darüberhinaus gibt es noch weitere Möglichkeiten mit JavaScript Ressourcen asynchron nachzuladen, auf diese gehe ich in einem späteren Blogpost ein. Das Beispiel „Web Font Loader“ sei hier aber erwähnt.

Um es noch einmal zu verdeutlichen: Die in diesem Beispiel angeführten Analytic Tools sind nicht die einzigen Ressourcen, die blockieren können. Sie fallen allerdings häufig auf, da sie vermehrt zum Growth Hacking eingesetzt werden. Social Media Plugins sind ebenfalls ein oft gesehener Kandidat und diese haben meist nichts mit der Aufgabe der Seite zu tun. Aber auch extern geladene Web-Schriften können das Laden blockieren, wie wir gesehen haben.

 

Anmerkung: Den Begriff White Screen of Death (WSoD) verwende ich nicht ganz korrekt, da er eher beschreibt, dass die Anwendung oder das Device überhaupt nicht mehr reagiert. Das ist aber wie beschrieben weder für Browser noch Webseite der Fall. Es kommt nur zu einer Verzögerung. Diese kann allerdings sehr lang sein und ich kenne niemanden, der bereit ist 20 Sekunden und mehr auf eine Antwort zu warten. Und das ist auch gut so.

 

Hallo Welt!

So, nach einer langen langen Weile habe ich nun die Zeit und Muße gefunden diesen Blog zu beginnen. Über Jahre hinweg habe ich immer meine gesammelten Ideen, zusammen getragenes Wissen und interessanten Beobachtungen und Gedanken aufgeschrieben, aber nie digital veröffentlicht. Nun ist diese Zeit endlich gekommen und ich hoffe, ich kann das Veröffentlichen aufrecht erhalten.

Die gehorteten Werke drehen sich natürlich hauptsächlich um die Themen, die im Zentrum einer digitalen Arbeit stehen, so z.B. Digital Performance, Entwicklung, DEVOPS, Data Analytics, etc. Hier erkennt man schon, dass die Terminologie in der IT Welt aus dem Englischen stammt, dennoch ist es mein eigener Anspruch den Block auf Deutsch zu führen – es dient aber selten dem Verständnis diverse englische Begriffe einzudeutschen.

Der Blog dient in erster Linie mir selber, da ich beim Schreiben von Einträgen den Sachverhalt noch einmal durch denke. Daher erhebt dieser Blog keinen Anspruch auf Richtigkeit oder Vollständigkeit. Dennoch bin ich für Diskussionen offen und Kommentare sind gern gesehen. Leider muss ich diese moderieren, da zu viel Bots mir bereits ein leeres WordPress zu gespammt haben.

Gruß,
Tobi