Geschrieben von Leonard Wagner
am 5. Februar 2024
Für Product Owner, Entwickler und weitere Stakeholder können Bildschirmaufnahmen hilfreich sein, um schnell und einfach einen Einblick in den Entwicklungsstand einer Webanwendung zu erlagen.
In diesem Post berichte ich von meinen Erfahrungen, einen Prozess aufzusetzen, um in einer Build-Pipeline automatisch Videos und Screenshots einer Anwendung aufzunehmen und diese bereitzustellen.
Realisiert habe ich dieses Vorhaben sowohl mit Playwright als auch mit Puppeteer.
Geschrieben von Christian Bittner
am 15. November 2022
Im letzten Artikel zum Thema WebAssembly haben wir uns C und Rust für WebAssembly angeschaut.
Darin konnten wir erfahren, wie WebAssemblies als Hallo, Welt!
in der Browserwelt das Laufen lernen.
Diesmal schauen wir uns ein etwas komplexeres...
Geschrieben von Christian Bittner
am 25. Oktober 2022
Doch wie bekommt man Low-Level Sprachen wie C in den Browser? Das ist einfacher, als man vielleicht glauben mag:
Man kann aus C (oder Rust, Go, C++,…) mit...
Geschrieben von Christian Bittner
am 4. Oktober 2022
Es muss nicht immer Javascript sein. Mit dem WebAssembly Standard hat man die
Möglichkeit, den Browser als Ablaufumgebung für u.a. auf C, C++, Go, Rust sowie Python basierendem Code zu nutzen.
Wir werden uns dies am Beispiel von Python einmal...
Geschrieben von Christian Bittner
am 19. Mai 2022
Um sich in das Thema Penetrationstest einzuarbeiten, wird gerne eine Kombination aus der Pentest Linux Distribution Kali und einer mit Sicherheitslücken versehenen virtuellen Maschine (z.B. von vulnhub) verwendet.
Insbesondere im Kontext von...
Geschrieben von Christian Bittner
am 2. Mai 2022
In unseren modernen Cloud-affinen Zeiten gehen viele Anwendungsfälle in Richtung Serverless Computing.
Auch bei unseren trion-internen Systemen setzen wir zunehmend darauf, u.a. im Kontext Kommunikationskanäle von und zu Kunden.
Geschrieben von Christian Bittner
am 2. April 2022
In dem Artikel Serverless kaskadiert haben wir einen Serverless Service
mit Cloudflare vorgestellt. Dieser Cloudflare Worker hat eine Mail examplarisch via Mailgun versendet.
Was aber macht der Entwickler, wenn er in einem Worker Kontext Daten...
Geschrieben von Thomas Kruse
am 22. Juli 2021
Lighthouse CLI
Lighthouse ist ein Feature des Chromium und Google Chrome Browsers, mit dem Webseiten auf bestimmte Merkmale hin untersucht werden können.
Wichtige Merkmale sind dabei typischerweise die Performance der Webseite oder deren SEO-Eigenschaften. Die Performance ist dabei sowohl fuer die SEO- als auch die Nutzerzufriedenheit sehr wichtig.
Ebenfalls oft gefordert ist ein barrierefreier Zugang, der durch die Accessibility Metric abgebildet wird.
Manuelle Tests werden durch Entwickler - gerade unter Zeitdruck - schnell vergessen und sind auch fehleranfällig.
Lighthouse bietet daher auch einen Modus für CI Server an, um automatisiert und regelmäßig Metrikdaten zu erheben.
Diese können dann auf einem Dashboard-Server gespeichert werden, so dass auch Auswertungen im Laufe der Zeit ermöglicht werden.
Der Server kann dabei lokal betrieben werden, oder der von Google bereitgestellte öffentliche Server kann verwendet werden.
Abbildung 1. Lighthouse Beispielreport ohne zeitlichen Verlauf
Speziell zur Ausführung auf CI Servern gibt es das Paket "LHCI", kurz für Lighthouse CI.
Damit wird die Integration in das Dashboard als auch die Analyse lokaler Anwendungen ermöglicht.
Das erspart das Deployment auf einem Webserver und ist insbesondere für SPA Anwendungen wie Angular, Vue oder React interessant.
Lighthouse Docker Image (auch auf ARM)
Damit Lighthouse CI komfortabel in modernen Buildservern ausgeführt werden kann, empfiehlt sich die Verwendung von Containern.
Das auf DockerHub verfügbare Image trion/chromium-lighthouse
stellt auf Basis von Chromium, Node.js und LHCI eine passende Umgebung sowohl für Intel als auch ARM64 Architekturen bereit.
Damit kann sowohl Lighthouse selbst als auch das LHCI ausgeführt werden.
Beispiel im CI Server
Im folgenden wird gezeigt, wie Lighthouse CI im Build durch ein Container Image bzw. Docker Container integriert werden kann.
Als Beispiel dient dabei eine Angular Anwendung, die ebenfalls im CI Server gebaut wird.
Geschrieben von Thomas Kruse
am 9. März 2021
In vielen Kundenprojekten ist der Wunsch zu beobachten, von klassisch betriebenen Anwendungen sofort in die Cloud oder zumindest nach Kubernetes zu migrieren.
Vielleicht schwingt dabei der Wunsch mit, Zeit zu sparen, indem Zwischenschritte ausgelassen werden.
Oder man ist sich sehr wohl bewußt, dass man in Gewissen Bereichen versäumt hat, Know-How aufzubauen und in Modernisierung zu investieren.
Wir empfehlen regelmäßig zumindest kleine Zwischenschritte einzuplanen, um Erfahrungen mit der Erstellung aber auch dem Design von Anwendungen für Container- und Cloudumgebungen zu sammeln.
Das gilt um so mehr, wenn das Unternehmen sich nicht ganze Teams, die sich nur um Infrastruktur und Support kümmern können, leisten möchte.
Eine gute Möglichkeit zum Start stellt der Einsatz von Docker Containern ohne automatischen Orchestrator wie Kubernetes, Mesos oder Docker-Swarm dar.
Dabei wählt man typischerweise eine Anwendung aus, die nicht absolut essentiell ist, und optimalerweise bereits von einem Team mit modernen Technologien und vor allem Mindset entwickelt und betreut wird.
Mit verhältnismäßig wenig Infrastruktur können dann auch bereits Patterns aus der Cloud-Welt verprobt werden und entsprechende Erfahrungen mit den notwendigen Umsystemen und Prozessen gewonnen werden.
Wichtig ist dabei, dass man den Schwenk auf fertige Lösungen vornimmt, und nicht mit eigenen Mitteln Dinge nachbaut und wartet, die ein Orchestrator mitliefert.
Hat man sich für traefik als Reverseproxy und Loadbalancer entschieden, um Container verfügbar zu machen, kann man bereits von vielen Vorzügen profitieren.
Ein Kunde wünschte sich Canary-Deployments auszuprobieren, und das allein mit traefik.
Wie so ein Canary oder A/B Deployment mit traefik umgesetzt werden kann, zeigt der folgende Beitrag.
Geschrieben von Thomas Kruse
am 10. April 2020
Die durch das neuartige Corona-Virus SARS-CoV-2 ausgelöste Krankheit COVID-19 und die durch die Pandemie veränderten Lebensumstände stellen vieles auf den Kopf.
Remote-Arbeiten, Digitalisierung und potentieller struktureller Wandel sind alles Themen, die den Technologiesektor tangieren, und somit auch viele unserer Kunden.
Die ganz persönlichen Lebensumstände betrifft das bisher einzige Mittel, um mit der Bedrohung umzugehen:
Social Distancing.
Oft stellt sich die Frage, ob das wirklich so viel bringt gegen das Corona Virus.
Wir haben eine kleine Anwendung erstellt, mit der sich jeder selbst ein Bild machen kann: Den Corona Virus Simulator.
Es gibt zwar bereits einige Anwendungen dieser Art, auf denen wir auch mit unseren Beispiel aufbauen wollen, doch das besondere in dieser Version:
Man kann sich einen direkten Vergleich von zwei Populationen anzeigen lassen, und damit die direkten Auswirkungen verschiedener Parameter gegenüberstellen.
Wir simulieren, was in der echten Welt nicht möglich ist:
Nämlich gleichzeitig den Effekt von Social Distancing und weiteren Parametern und parallel dazu zum Vergleich die Entwicklung ohne Social Distancing.
Figure 1. Screenshot der Corona-Simulator-App
Geschrieben von Thomas Kruse
am 28. Januar 2020
Bei der PHP Usergroup Münster stellte Thomas Kruse vor, welche Optionen gRPC für die Entwicklung und Integration von Microservices bietet.
Geschrieben von Thomas Kruse
am 16. Januar 2020
Wie können moderne APIs unter Berücksichtigung von Web Anwendungen definiert und implementiert werden?
Diese Frage stellt sich vor allem bei Microservice Architekturen, wenn viele unterschiedliche Dienste miteinander integriert werden.
Als eine Option stellte Thomas Kruse bei dem Meetup "Frontend Freunde" vor, wie dies auf Basis von gRPC umgesetzt werden kann und welche Implikationen sich ergeben.