Über mich
Persönlich
Mein Name ist David Deutsch, ich bin 36 Jahre alt und wohne mit meiner Frau und meinen drei Töchtern in Herne.
Seitdem ich denken kann fällt es mir schwer, mich zwischen Gestaltung, Technologie und Handwerk zu entscheiden - deswegen mache ich alles auf einmal.
Professionell
Ich bin Fullstack Web-Entwickler und Gestalter mit 14 Jahren Berufserfahrung.
Die ersten 8 Jahre davon habe ich eher Backend-orientiert gearbeitet. Mein Hauptprodukt war hier ein E-Commerce Plugin für ein bekanntes CMS. In den letzten 6 Jahren habe ich meinen Arbeitsbereich auch die Frontend-arbeit ausgeweitet.
Ich betreue in meiner selbstständigen Arbeit unterschiedliche Kunden und setze kreative Projekte im Web- und Print-Bereich um.
Ich bin mit allen gängigen und modernen Technologien (insbesondere den öffentlichen Browserstandards) und Produkten - Applikationen, Content Management Systeme, Bibliotheken etc. - im Web Bereich entweder bereits vertraut oder zumindest so informiert, dass ich sie solide navigieren und mich, falls nötig, schnell einarbeiten kann.
Ich lege viel Wert darauf, mir auch bei so grundlegenden Themen wie HTML oder CSS einen tiefen Kenntnisstand erarbeitet zu haben. Das hilft mir dabei, Systemkomplexität empfindlich zu reduzieren - bereits bestehende Möglichkeiten zu nutzen ist in der Regel deutlich effizienter als das Rad neu zu erfinden.
Ich besitze grafisches Talent und die Fähigkeit, auch komplexe Sachverhalte in Wort und Bild verständlich zu kommunizieren.
Ich lege Wert auf ästhetisch ansprechende Gestaltung und Webseiten die einen klaren Erzählfaden haben um den Betrachter oder Nutzer zu informieren und zu leiten. Daneben kann ich aber auch bereits bestehende Designvorgaben exakt umsetzen oder auf einer bereits existierenden Gestaltung aufbauen und diese verbessern.
Selbstverständlich sind die erstellten Internetseiten voll responsive und für alle üblichen Browser kompatibel (oder, falls das nicht möglich ist, mindestens frei von Darstellungsfehlern).
Ich arbeite mit den üblichen Tools der Industrie - Meinen Code schreibe ich in der IntelliJ IDE, ich versioniere in git, welches ich bis hin zu komplexen Rebases und dem Umgang mit dem Reflog beherrsche und bearbeite Bild- und Grafikmaterial mit inkscape, darktable und gimp.
Daneben habe ich einschlägige Berufserfahrung im Printbereich und der Druckvorstufe allgemein. Ich arbeite primär vektorbasiert.
Ich entwickle und forsche an grundlegender Technologie im Web-Bereich.
Seit acht Jahren arbeite ich an einem System zum Erstellen von stark optimierten und komprimierten Webseiten welches ich seit einem Jahr aktiv für meine Kunden nutze. Diese Seite selbst ist ein Beispiel für ein Produkt dieses Systems, unten folgen noch weitere.
Meine Perspektive auf Systemarchitektur ist hier vom Frontend geprägt (unter dem Motto: Wichtig ist, was hinten rauskommt
), meine Fähigkeiten auf Serverseite (vorwiegend in der Shell oder in PHP) ordnen sich dabei dem unter und orientieren sich daran, bereits existierende Werkzeuge klug zu nutzen anstatt das Rad neu zu erfinden.
Allgemein gesagt arbeite ich daran, serverseitige Komplexität - insbesondere dynamischen Code - so weit wie es geht zu vermeiden. Im Idealfall vollständig.
Arbeitsproben Design & Layout
Arbeitsproben Web-Entwicklung
Bei diesen Seiten habe ich die vollständige Gestaltung und Umsetzung übernommen, unter der Nutzung meiner eigenen Software:
(*bei dieser Seite wurde eine bestehende Gestaltungsvorlage - ein WordPress Template - übernommen und angepasst)
Bei diesen Seiten habe ich ebenfalls die vollständige Gestaltung und Umsetzung übernommen, unter Einsatz von bestehender Software:
(Inklusive der Buchcover und aller Logos)
Leitsätze
Vier Leitsätze, die meine Arbeitsweise beschreiben:
1.
Es ist gut, Probleme zu lösen.
Besser, wenn Probleme erst gar nicht entstehen.
2.
Die häufigste Berufskrankheit unter Entwicklern und in Software-Projekten ist mangelhafte Kommunikation.
3.
Es gibt in der Programmierung klare Ziele und Maßstäbe die universell gelten*.
4.
Wenn wir nicht aus der Vergangenheit lernen müssen wir sie mit jeder ES Version neu implementieren.
*(Vor allem: Die Minimierung von verschwenderten CPU Zyklen.)
Wie ich arbeite
Beispiele für die Qualität meine Arbeitsweise:
Reduzierung von serverseitigen Problemen durch clientseitige Lösungen
Für einen Kundenshop mit hoher Benutzerfrequenz sollten zusätzliche, kundenspezifische Daten auf allen Shop-Seiten dargestellt werden. Der ursprünglich geplante Pfad mit serverseitigem Rendering hätte hierbei die Optimierungen durch die Caching-Server verhindert und somit waren aufwendige Änderungen an der Caching-Infrastruktur geplant um diese Dynamik zu unterstützen.
Stattdessen wurde der von mir vorgeschlagene Low-Tech Weg gewählt bei dem die kundenspezifischen Daten bei ihrer Entstehung (zB. bei Click-Events) im Browser gespeichert (IndexedDB/LocalStorage, bzw. Cookies als Fallback) und dynamisch im bestehenden Markup nachgerendert werden.
Optimierung von Build-Prozessen
Im Build-Prozess des dabei genutzen, proprietären CMS Produktes wurde Gulp zum Kompilieren der Browser-Assets genutzt. Je nach Projekt lag hier die Laufzeit des Vorganges zwischen 3 und 6 Minuten. Leider gab es neben der mangelhaften Geschwindigkeit häufig obskure Fehler die nur erfahrene Anwendern beheben konnten - in einem Unternehmen mit überwiegend PHP-Backend-Entwicklern ein Problem. Bei der Suche nach einem Ersatz für Gulp wurden diverse Optionen in Betracht gezogen (zB. webpack, Parcel - die üblichen Verdächtigen die jedes halbe Jahr anders lauten) allerdings waren die in Tests nicht wirklich schneller und meistens schwerer verständlich.
Stattdessen habe ich die bestehende Funktionalität mit Linux/Unix-Basis Tools nachgearbeitet - vorrangig make und der Shell - und die Lücken (zB. das Auflösen der SASS Abhängigkeiten) mit PHP CLI Scripts aufgefüllt. Somit war die Verständlichkeit für die anderen Entwickler gegeben. Die Laufzeit reduzierte sich auf durchschnittlich 30 Sekunden, bzw. 12 Sekunden wenn man vom nativem Threading in make Gebrauch macht.
Das Unmögliche möglich machen
Ich kannHTML mit Regulären Ausdrücken parsen.
Die Software an der ich momentan arbeite
Da ich neben meiner Festanstellung Webseiten-Projekte betreue habe ich mir eine Software zum Erstellen von Webseiten maßgeschneidert. Konzeptionell ähnelt sie bekannten Static Site Generatoren, ist aber speziell auf hohe Produktivität und langfristige Betreuung von Projekten mit geringem Aufwand ausgerichtet. Während herkömmliche statische Generatoren eher wie dynamische Seiten plus Caching aufgebaut (und damit ähnlich wartungsaufwendig) sind ist mein System ein Abhängigkeits-Graph welcher durch eine Zusammenstellung von Prozessen aufgelöst wird.
Schlüsseltechnologien oder -konventionen sind:
- Ein Expression Parser der selbst keine Expressions interpretiert, sondern diese in lauffähigen Code, bzw. Shell Kommandos umformt die dann im Rendering der Seite ausgeführt werden.
- Ein Templating was auf WebComponent-Struktur basiert und beliebig (und mit geringem Aufwand) erweiterbar ist.
- Inhaltsspeicherung als reine Source-Dateien, Vermeidung von Datenbanken und Rendering von Nutzdaten bei Änderung vom Autor anstatt beim Aufruf vom Benutzer.
- Eine automatische Dependency-Auflösung zwischen und innerhalb von Inhaltsseiten und Assets welche einen
makeBuild-Prozess ergeben. - Direkte Einbindung von
git(zB. für parallel verfügbare, lokal gehostete Feature-Branches).
Die Vorteile:
1. Statische Inhalte ergeben sichere Webseiten
Weil immer die komplette Website in Gänze gerendert wird bevor sie auf dem Server landet sind Sicherheitslücken vollständig ausschließbar. Bei tatsächlichen Fehlern in der Software werden diese gelöst bevor der Code auf dem Server landet - insbesondere bei (automatischen) Software-Updates wie zB. bei einem CMS wie WordPress ist das ein bekanntes Problem.
2. Schonung der Serverkapazitäten härtet Websiten für den Erfolgsfall
Wenn der Server wenig zu tun hat (im Idealfall: nur das Ausliefern von fertigen Dateien) kann auch plötzlicher Ruhm wenig Schaden anrichten.
Und wenn doch mehr Kapazitäten nötig sind: Nichts skaliert so gut und günstig wie statische Inhalte.
3. Maximal komprimierte Webseiten die rasend schnell laden
Hier ist peterzwierzynski.de ein gutes Beispiel: eine vollständige Webseite in 141kb. Bei den gängigen Tools zum Performance-Testing (wie Google Lighthouse, GTmetrix, pingdom) schneidet sie mit voller oder nahezu voller Punktzahl ab. Auf einem aktuellen Desktop PC rendert die Seite in unter 150ms ab Aufruf der Domain. Wichtiger noch: bei einer schlechten Mobilverbindung sind es in der Regel unter 2 Sekunden.
Diese Art der Komprimierung ist in herkömmlichen Systemen nicht unmöglich - wird aber entweder aufwendig in die bestehende Systemstruktur eingebaut was die Komplexität erhöht, oder wird an Drittdienste oder Abstraktionsschichten wie mod_pagespeed ausgelagert was wieder eine neue Dimension an Fehlerpotential in sich birgt. In meinem System wird dies alles nativ unterstützt.
4. Native, herkömmliche Tools die pragmatisch Probleme lösen
Anstatt das allumfassende Über-System zu bauen was jede mögliche Funktionalität abbilden kann konzentriere ich mich lieber darauf, bestehende Software gut zu vernetzen und in verständlichen, zentralen Knotenpunkten anzubinden. Man kann sich das in etwa so vorstellen wie ein direkter Zugriff auf alle Daten und die Möglichkeiten einer Unix/Linux Shell direkt im Template.
Das ist natürlich ein stark vereinfachtes Bild und ich bin mir um die mit dem Ansatz verbundenen Probleme bewusst (zuviel Macht in der Hand der Entwickler wodurch auch viel schief gehen kann, undurchsichtige Systeme durch fehlende Auftrennung wie zB. bei MVC…). Mindestens für den aktuellen Scope von Webseiten die ich bisher damit erstellt habe konnte ich aber noch keine solche Schwierigkeiten feststellen und ich vermute, dass sie schlicht Symptome von dynamischen Systemen sind. In kompilierten Systemen ist der Blick völlig anders.