Developer

Aktuelle Themen

It’s #FrontendFriday – Was sind Testpfade und welche gibt es?

Es war eine sehr warme Woche, aber dies haben wir auch überstanden und was fällt euch zu Freitag ein – Ganz genau It’s #FrontendFriday ;)

Im heutigem Post geht es um die Testpfade, welches sowohl im Frontend, Java Projekten, etc. eingesetzt bzw. getestet wird.

Was sind Testpfade?

Im Umfeld eines Projektes werden auch unter anderem andere Services angebunden, da von diesen bestimmte Informationen erhalten werden soll. Ihr möchtet über z.B. einem JUnit-Test testen, ob auch deine Implementierung das tut, was es auch machen sollte. Dies gibt es auch im Frontend.

Hierbei testet man ein Codeausführungsszenario, von dem ein bestimmtes Verhalten erwartet und geprüft wird.

 

 

Welche Testpfade gibt es?

Happy Path

Natürlich möchte man als erstes immer den Erfolgsfall bzw. Good-Case-Fall testen – Happy Path. Dies ist das einfachste Szenario, ohne dass Ausnahmen oder Fehlerzustände eintreten. Dieser Test stellt die Basisfunktionalität des Codeabschnitts dar – Happy Path ist das Mindeste, welches getestet werden sollte.

Natürlich möchte man sehr gerne vom Good-Case ausgehen, aber dieser reicht allerdings nicht aus, um die Funktionalität des Codes mit Verzweigung zu testen.

Scary Path

So schlimm sich dies auch anhört, sollten auch die Szenarien getestet werden, welches den Code zu einem Fehlverhalten oder ein einem Fehlzustand bringt. Der Scary Path ist vor allem dann zu testen, wenn durch das Fehlverhalten bzw. den Fehlerzustand ein hohes Risiko für die Stakeholder besteht.

Angry Path

Was ist wenn der angebundene Service einen Fehler zurückgibt? Ist dann euer Code noch stabil? Oder werden nur noch Fehler geworfen?

Es ist ärgerlich, wenn der angebundene Service einen Fehler zurückgibt, aber dafür hast du dir schon Gedanken gemacht und es auch deinem Code beigebracht, was es wie machen soll, wenn ein Fehler erhalten wird. Angry Path testet den Code, welches es zu einem Ausnahmeverhalten führt, jedoch in einem gültigen und funktionierenden Zustand verbleibt.

Delinquent Path

Du stellst bspw. für dein Projekt auch eine Oberfläche bereit. Du möchtest nicht, dass jede Person, welches die URL hat, darauf kommt – also berechtigst du nur bestimmte Personen mit bestimmten Zugangsdaten. Mit dem Delinquent Path wird die Autorisierung, Authentifizierung, Berechtigung oder andere Sicherheitsmaßnahmen getestet.

Desolate Path

Diesen Test macht im Prinzip jeder Standardmäßig – Was ist wenn null, 0, 1, -1 oder auch NaN zurückgegeben wird? Was soll dann passieren? Hierzu ist der Desolate Path zuständig, welches diesen Fall testet.

Forgetful Path

Um Daten nicht zu verlieren oder auch um diese Weiterzuleiten, werden diese oft in einer Datenbank gespeichert – Aber was ist, wenn die Datenbank nicht vorhanden oder verfügbar ist? Dies soll der Forgetful Path testen.

Ihr habt Kundendaten, welches durch bestimmte Prozesse durchlaufen soll. Ihr speichert initial die Daten die ihr erhalten habt in der Datenbank. Zu diesem Zeitpunkt ist die Datenbank nicht verfügbar – Was soll geschehen? Soll eine Fehlermeldung geworfen werden? Genau hierzu ist der Forgetful Path-Test gut

Greedy Path

Auf der Oberfläche, hat der Anwender die Möglichkeit eine große Anzahl an Optionen zu wählen oder eine Vielzahl von Aktionen ausführen zu lassen – Greedy Path testet, dass die Aktionen innerhalb von kürzester Zeit ausgeführt werden.

Stressful Path

Was ist wenn der HTTP-Request zu lange dauert? Bricht es ab, oder wartet es solange, bis eine Antwort erhalten wird? Wie soll es sich verhalten, wenn es zu lange dauert? Wurde denn schon Gedanken über eine Timeout gemacht? Ja? Nein? Genau dies soll der Stressful Path-Test testen.

It’s #FrontendFriday – Antike HTML-Elemente

Vor langer, langer Zeit im Erdmittelalter existierten sie, die antiken HTML-Elemente. Diese schon fast vergessenen Elemente sind für browserübergreifende Anforderungen besonders interessant, denn sie werden fast von allen Browsern (teils sogar IE9) unterstützt! Der folgende Beitrag soll den Leser für die Verwendung nativer Dino-Elemente sensibilisieren.

Das HTML “dl” Element

Das HTML Description List Element sieht den Inhalt einer Liste von Begriffspaaren sowie Beschreibungen vor und wird normalerweise für die Implementierung von Schlüsselwertpaaren genutzt. Die Liste kann “dt” sowie “dd” Elemente enthalten.

Das HTML “dt” Element

Das HTML Definition Term Element identifiziert einen Begriff innerhalb einer Description List und kommt in der Regel als Kindelement eines “dl” Elements vor. 

Das HTML “dd” Element

Das Kindelement muss innerhalb einer Description List auftreten und einem “dt” Element folgen. “dd” steht für das HTML Description Element.

Sheldon Cooper
“Ich mag Züge”
Albert Einstein
“Comments must start with a space”

 
Das HTML “datalist” Element 

Das “datalist” Element enthält eine Liste von “option” Elementen, die mögliche Optionen für den Wert eines anderen Elementes repräsentieren und wird in im Verbund mit einem “input” Tag verwendet.


 
Das HTML “details” und “summary” Tags

Mit dem “details” Tag können dem User zusätzliche Informationen sichtbar gemacht werden. Das Ganze wird im Verbund mit dem HTML “summary” Element verwendet.

Klick mich

Herzlichen Glückwunsch! Du hast einen Trojaner erhalten.

 
Das HTML “hr” Element

Der Horizontal Ruler ist zur Darstellung von thematischen Brüchen gedacht und wird als waagerechte Linie dargestellt.

Heute ist Freitag


Morgen ist Samstag

 

Das HTML “optgroup” Element

In einem Webformular erstellt das “optgroup” HTML Element eine Gruppe von Optionen innerhalb eines “select” Elements.


 

Das HTML “address” Tag

Dieses Tag kann zur Darstellung von Kontaktinformationen genutzt werden.

Written by Konfu Panda.

Visit us at:
Zoo
Berlin
Germany

 

Fazit:

Es gibt eine Reihe von kaum benutzten HTML Tags. In diesem Beitrag sind einige aufgezählt. Die meisten Entwickler heutzutage benutzen die “self-build-div-jquery-Konstrukte”, obwohl es native HTML Elemente dafür gibt. Folgend einige Gründe warum man lieber auf native HTML Elemente zurückgreifen sollte: 

Native HTML Elemente werden von allen Browsern, mobile eingeschlossen, unterstützt. Nur HTML kein CSS oder JS.
Semantisches HTML ist W3C Konform und meiner Meinung nach schöner. Stichwort “Clean Code”.
Sie funktionieren ohne Frameworks/Libraries von Drittanbietern und sind somit performanter und einfacher wartbar.

Quellen:

Alle Beschreibungen aus: 

https://developer.mozilla.org/de/

 
Wow, es gibt sogar ein Progress Tag 

Das HTML “progress” Element wird benutzt, um den Fortschritt einer Aufgabe zu visualisieren.

It’s #FrontendFriday – Bootstrap wechselt von jQuery to Hugo.js

Es ist wieder Freitag und das heißt: #FrontendFriday! :)

Heute geht es um das Framework Bootstrap, welches der ein oder andere kennt, angewendet oder auch nur mal gehört hat.

Was ist Bootstrap?

Jeder möchte sich sein Leben einfach machen, deshalb gibt es auch Boostrap, welches ein Frontend-Framework ist. Es werden viele HTML- und CSS-Vorlagen bereitgestellt, um verschiedene Webseite-Elemente unterschiedlich darzustellen.

Hierzu gehören Formulare, Buttons, Tabellen, Navigationsleisten sowie ein Grid-System für Layouts. Über HTML- und CSS-Vorlagen hinaus ist es durch JavaScript-Module möglich, Interaktionen, wie z.B. Bilder-Slideshow, Tabs und Dialogboxen auf der Webseite einzubinden.

Bootstrap bietet alle Voraussetzungen, um responsive Design optimal zu gestalten, sei es für Desktop, Smartphone oder Tablet.

Ihr wollt wissen was Bootstrap an Layout und viele andere Features mit sich bringt, dann könnt ihr euch gerne die Dokumentation anschauen: https://getbootstrap.com/docs/4.3/getting-started/introduction/

Was ist jQuery?

Boostrap erleichtert die Arbeit eines Entwicklers in Sachen HTML und CSS. jQuery hingegen die JavaScript-Arbeit – es ist eine JavaScript-Bibliothek.

Es überbrückt technische Unterschiede verschiedene Browsern – ermöglicht komfortablen und kompakten Code, der im Vergleich zu reinem JavaScript häufig sehr viel kürzer ist.

Mehr zu jQuery: https://jquery.com/

Bootstrap verwendete für die JavaScript Modulen jQuery, jedoch nur bis Version 4.3

Warum verwendet Bootstrap 4.3 kein jQuery mehr?

Etwas was die Community wohl bereits länger diskutiert hat, war der Abschied von jQuery für die DOM-Manipulation (Document Object Model) bzw. -Navigation.

Bootstrap wird ohne jQuery auskommen und dies wird derzeit entfernt. Bootstrap ist nicht das erste Tool, das diesen Schritt geht, auch Ember und GitHub arbeiten bereits nicht mehr standardmäßig mit jQuery.

Der wichtigste Punkt hierbei ist: Schonen von Ressourcen auf dem Server!

Bye Bye jQuery – Hello Hugo.js

Bei Hugo handelt es sich um einen Static Site Generator, der in Go geschrieben ist. Hugo beschreibt sich selbst: world’s fastest static website engine.

Hugo zählt zu den Statischen Webseiten-Generatoren und kann ganz ohne weitere Hilfsmittel genutzt werden.

Aber warum nun Hugo.js?

Es handelt sich hierbei um einen statischem Webseitengenerator – Dies bedeutet, dass der Inhalt nicht jedes Mal neu generiert wird, sondern nur, wenn sich der Inhalt der jeweiligen Seite ändert.

Insbesondere ermöglicht es Hugo, dass nur diejenigen HTML-Dokumente der jeweiligen Webseite neu gebaut werden müssen, in denen Änderungen auftraten.

Hierdurch sollen die Ressourcen des Servers geschont und eine hohe Effizienz von diesem erreicht werden.

Mehr zu Hugo: https://gohugo.io/getting-started/

Fazit

jQuery hat viel Arbeit für den Frontend-Entwickler entnommen, vor allem, wenn man Einsteiger ist. Im Gegensatz zum reinem JavaScript war auch der Code häufig viel kürzer und lesbarer.

Um Ressourcen sowohl auf dem Server, als auch lokal beim Entwickeln zu sparen, sodass die Inhalte nicht immer wieder neu erstellt werden müssen, ist Hugo hierbei sehr Ressourcen- und Zeit-Sparender.

It’s #FrontendFriday – Browserengines

It’s Friday that means #FrontendFriday! :)

Heute geht es um das Thema “Browserengines”.

Was ist eigentlich eine Browserengine?

Eine Browser-Engine ist eine zentrale Softwarekomponente eines Webbrowsers.

Die Hauptaufgabe einer Browserengine besteht darin, HTML-Dokumente und andere Ressourcen einer Webseite in eine interaktive visuelle Darstellung auf dem Gerät eines Benutzers zu transformieren.

Eine Browser-Engine ist kein eigenständiges Computerprogramm, sondern ein Bestandteil eines Webbrowsers, aus dem der Begriff abgeleitet ist.

Neben der Browserengine werden in Bezug auf verwandte Konzepte zwei weitere Begriffe verwendet: “Layout-Engine” und “Rendering-Engine”. Theoretisch könnten Layout und Rendering von separaten Engines übernommen werden. In der Praxis sind sie jedoch eng gekoppelt und werden selten getrennt betrachtet.

Zusätzlich zum Layout und Rendering erzwingt eine Browser-Engine die Sicherheitsrichtlinien zwischen Dokumenten und implementiert die Datenstruktur des Document Object Model (DOM), die Seitenskripten ausgesetzt ist. Es werden auch Hyperlinks und Webformulare behandelt.

Das Ausführen von JavaScript (JS)-Code ist jedoch eine separate Angelegenheit, da jeder gängige Webbrowser dafür eine eigene Engine verwendet. Die JS-Sprache wurde ursprünglich für die Verwendung in Browsern entwickelt, wird aber nun auch an anderer Stelle verwendet, so dass die Implementierung von JS-Engines von Browser-Engines entkoppelt ist. In einem Webbrowser arbeiten die beiden Engines über die gemeinsame DOM-Datenstruktur zusammen.

Vergleich von Browserengines

Engine
Status
Verwalter
Lizenz
Eingebunden in
WebKit Aktiv Apple GNU LGPLBSD-style Safari sowie alle Browser, die im iOS App Store zufinden sind
Blink Aktiv Google GNU LGPLBSD-style Google Chrome und alle anderen Chromium-basierten Browser wie Microsoft EdgeBrave und Opera
Gecko Aktiv Mozilla Mozilla Public Firefox und Thunderbird email client, sowie forksSeaMonkey und Waterfox
Servo Aktiv Mozilla Mozilla Public Versuchsbrowser (Kann unvollständig oder fehlerhaft sein)
Goanna Aktiv M. C. Straver Mozilla Public Pale Moon und Basilisk browser
NetSurf Aktiv Hobbyisten GNU GPLv2 NetSurf
KHTML Nicht fortführend KDE GNU LGPL Konqueror
Trident Nicht fortführend Microsoft Proprietary Internet Explorer und Microsoft Outlook
EdgeHTML Nicht fortführend Microsoft Proprietary formerly in the Microsoft Edge browser

Unterstüzung von HTML, CSS, Grafiken und Typographie

Engine
Status
WebKit Aktiv
Blink Aktiv
Gecko Aktiv
KHTML Nicht fortführend
Presto Nicht fortführend
EdgeHTML Nicht fortführend
Trident Nicht fortführend

Bevor ich mich mit Browserengines beschäftigt hatte:

 

 

 

 

 

 

 

Und jetzt:

Entwickleralltag bei uns: Livehacking DB Performance

Jürgen hat nach Hilfe gerufen und laut in den Wald geschrien. Durch bilateralen Austausch saßen dann am Ende zwei Klugscheißer Experten neben Jürgen. Durch eine Datenanalyse auf der Produktivdatenbank war die Ursache für die furchtbar langsame Abfrage schnell gefunden. Jürgen hat das 1×1 der DB Analyse nicht beachtet und keinen Index angelegt. Jürgen beruft sich dabei darauf, dass KEIN Full Table Scan beim Ausführungsplan zu sehen war. Antwort von Klugscheißer 1: “Schau mal ob Seq Scan drin steht. Das ist der verschlüsselte Code bei Postgres für Full Table Scan.”

Ergebnis von „EXPLAIN ANALYZE“:

Nach gemeinsamer Überprüfung die Bestätigung: Es fehlte ein Index auf die Spalten der WHERE-Bedingung.
Daraufhin wurde Jürgen von Klugscheißer 2 gemobbt, dass er doch einen Index auf diese Spalte(n) anlegen sollte.
Bevor zur Tat geschritten wurde wollte Klugscheißer 1 jedoch noch überprüfen, ob der Index für die Abfrage überhaupt sinnvoll ist, und wenn ja, für welche Spalte der WHERE-Bedingung. Wenn bpsw. 80% der Tabelleneinträge auf die WHERE-Bedingung zutrifft, wird weiterhin direkt auf die Tabelle gegangen statt den Umweg über den Index zu nehmen.

Ergebnis: Nur 0,003% der Daten besitzen den Status ‘PENDING’. Somit würde ein Index auf diese Spalte herangezogen werden.
Das haben wir dann auch ganz ordentlich auf der Test-Umgebung getestet und haben gesehen, dass tatsächlich der Index herangezogen wird. Klugscheißer 1 wollte dann voller Tatendrang den Index auf der Produktivumgebung anlegen (bei 40 Mio. Daten). Daraufhin hatte Jürgen einen Geistesblitz und brachte die Frage auf, ob dies währenddessen die Tabelle sperren könnte … immerhin werden dort ständig INSERTs getätigt. Klugscheißer 2 meinte daraufhin: “Der tut doch nichts, der liest doch nur ….”

Google brachte dabei folgendes Ergebnis:
“Creating an index can interfere with regular operation of a database. Normally PostgreSQL locks the table to be indexed against writes and performs the entire index build with a single scan of the table.” [1]

Jürgen wurde bei dem Wort “Normally” hellhörig: “Da muss es doch eine Alternative für geben.” Diese Alternative bietet Postgres bei vielen Statements (Index, View, etc.) via dem Zusatzwort “CONCURRENTLY”:
“PostgreSQL supports building indexes without locking out writes. This method is invoked by specifying the CONCURRENTLY option of CREATE INDEX. When this option is used, PostgreSQL must perform two scans of the table, and in addition it must wait for all existing transactions that could potentially modify or use the index to terminate. Thus this method requires more total work than a standard index build and takes significantly longer to complete.” [1]

Der „CREATE INDEX …“ ist nach 123 Minuten und 44 Sekunden erfolgreich durchgelaufen. Das Select-Statement dauert jetzt noch 214ms (zuvor lag die Zeit bei knapp einer Minute). Damit war das wohlverdiente Wochenende am Freitagnachmittag gerettet. So erfolgreich kann Teamwork sein :-)

Viele Grüße von


Quellen:

  1. https://www.postgresql.org/docs/current/sql-createindex.html