Mein Name ist David Deutsch, ich bin 37 Jahre alt und lebe mit meiner Familie in Herne.
Seit meiner Kindheit faszinieren mich Gestaltung, Technologie und Handwerk gleichermaßen - deshalb vereine ich alle drei in meiner Arbeit.
Als Fullstack Web-Entwickler und Gestalter bringe ich 16 Jahre Berufserfahrung mit.
In den ersten 8 Jahren lag mein Fokus auf Backend-Entwicklung, insbesondere einem E-Commerce Plugin für ein bekanntes CMS. Anschließend erweiterte ich mein Tätigkeitsfeld um Frontend-Arbeit für 6 Jahre. In den letzten 2 Jahren konzentrierte ich mich verstärkt auf Systementwicklung.
Als Selbstständiger Entwickler betreue ich verschiedene Kunden und realisiere kreative Projekte im Web- und Print-Bereich sowie e-Commerce-Lösungen in Eigenentwicklung.
Mit den meisten gängigen und modernen Web-Technologien, Applikationen, Content Management Systemen und Bibliotheken bin ich vertraut oder kann mich schnell einarbeiten.
Ich lege großen Wert auf fundierte Kenntnisse, auch in grundlegenden Bereichen wie HTML und CSS, um Systemkomplexität zu reduzieren.
Mit meinem grafischen Talent und der Kompetenz, komplexe Sachverhalte klar und verständlich zu kommunizieren, gestalte ich ästhetisch ansprechende Webseiten. Dabei lege ich Wert auf einen klaren Erzählfaden, der den Betrachter oder Nutzer informiert und leitet. Gleichzeitig kann ich bestehende Designvorgaben präzise umsetzen oder auf vorhandenen Gestaltungen aufbauen und sie optimieren.
Die von mir erstellten Webseiten sind selbstverständlich vollständig responsive und mit allen gängigen Browsern kompatibel.
Innovation und Forschung im Web-Bereich
Seit acht Jahren entwickle ich ein System zur Erstellung hoch optimierter und komprimierter Webseiten, das ich seit einem Jahr erfolgreich für meine Kunden einsetze. Diese Seite ist ein Beispiel dafür, weitere Beispiele finden Sie weiter unten.
Mein Ansatz zur Systemarchitektur ist frontendorientiert, wobei meine serverseitigen Fähigkeiten unterstützend wirken.
Generell liegt mein Fokus darauf, serverseitige Komplexität – insbesondere dynamischen Code – so weit wie möglich zu reduzieren, im Idealfall vollständig.
Bei diesen Seiten habe ich die 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 Gestaltung und Umsetzung übernommen, unter Einsatz von bestehender Software:
(Inklusive der Buchcover und aller Logos)
Meine Arbeitsweise in vier Leitsätzen:
1.
Probleme lösen ist gut, sie gar nicht erst entstehen zu lassen ist besser.
2.
In der Programmierung gibt es universell gültige Ziele und Maßstäbe*.
3.
Mangelhafte Kommunikation bringt mehr Software-Projekte zum Fall als technische Entscheidungen.
4.
Wer nicht aus der Vergangenheit lernt, wird sie immer wieder neu implementieren.
*(Insbesondere die Minimierung von verschwendeten CPU-Zyklen.)
Beispiele für die Qualität meine Arbeitsweise:
Ein Kundenshop mit hoher Benutzerfrequenz sollte zusätzliche, kundenspezifische Daten auf allen Shop-Seiten anzeigen. Der ursprünglich geplante Ansatz mit serverseitigem Rendering hätte die Optimierungen durch Caching-Server eingeschränkt und aufwendige Änderungen an der Caching-Infrastruktur erfordert, um diese Dynamik zu unterstützen.
Stattdessen habe ich einen Low-Tech-Ansatz vorgeschlagen: Die kundenspezifischen Daten werden bei ihrer Entstehung (z.B. bei Click-Events) im Browser gespeichert (IndexedDB/LocalStorage oder Cookies als Fallback) und dynamisch im bestehenden Markup nachgerendert.
Bei einem proprietären CMS-Projekt wurde Gulp zur Kompilierung der Browser-Assets eingesetzt. Die Laufzeit dieses Prozesses betrug je nach Projekt zwischen 3 und 6 Minuten. Neben der mangelnden Geschwindigkeit traten häufig schwer verständliche Fehler auf, die nur von erfahrenen Anwendern behoben werden konnten – problematisch in einem Unternehmen mit hauptsächlich PHP-Backend-Entwicklern.
Während der Suche nach einer Alternative zu Gulp wurden verschiedene Optionen in Betracht gezogen (z.B. webpack, Parcel), doch in Tests zeigten sich keine signifikanten Geschwindigkeitsvorteile und meist eine geringere Verständlichkeit.
Daher habe ich die bestehende Funktionalität mithilfe von Linux/Unix-Basis-Tools, vor allem make und der Shell, nachgebildet und die Lücken (z.B. das Auflösen von SASS-Abhängigkeiten) mit PHP-CLI-Scripts gefüllt. So war die Verständlichkeit für die anderen Entwickler gewährleistet. Die Laufzeit reduzierte sich auf durchschnittlich 30 Sekunden oder sogar 12 Sekunden, wenn das native Threading von make genutzt wurde.
Ich kann HTML mit Regulären Ausdrücken parsen.
Für die verschiedenen Webseiten-Projekte, die ich betreue, habe ich eine maßgeschneiderte Software zum Erstellen von Webseiten entwickelt. Sie ähnelt konzeptionell bekannten Static Site Generatoren, ist jedoch 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 sind (und damit ähnlich wartungsaufwendig), basiert mein System auf einem Abhängigkeits-Graphen, der durch eine Zusammenstellung von Prozessen aufgelöst wird.
Schlüsseltechnologien und -konventionen umfassen:
make-ähnlichen Build-Prozess ermöglichen.git (z.B. für parallel verfügbare, lokal gehostete Feature-Branches).Die Vorteile:
Obwohl die aktuelle Version meiner Software ein Backend beinhaltet und das Rendering auf dem Server stattfindet, bleibt die Sicherheit der Webseiten erhalten. Die Endkunden erhalten weiterhin nur statische Inhalte, und Schreibzugriffe auf den Server erfolgen über sehr schmale, kontrollierte Schnittstellen. Dadurch wird das Risiko von Sicherheitslücken minimiert, während gleichzeitig die Flexibilität und Funktionalität des Systems erhalten bleibt. Dies ist besonders wichtig, da bei (automatischen) Software-Updates, wie sie bei Content-Management-Systemen wie WordPress üblich sind, Sicherheitsprobleme häufig auftreten.
Ein weniger belasteter Server (im Idealfall: nur das Ausliefern fertiger Dateien) ist auch bei plötzlichem Erfolg besser gewappnet. Statische Inhalte lassen sich zudem gut und kostengünstig skalieren.
Hier ist peterzwierzynski.de ein gutes Beispiel: eine vollständige Webseite in 141kb. Bei gängigen Performance-Testing-Tools (wie Google Lighthouse, GTmetrix, Pingdom) erreicht sie die höchste oder nahezu höchste Punktzahl. Auf einem aktuellen Desktop-PC wird die Seite in unter 150ms nach Aufruf der Domain gerendert. Noch wichtiger: Bei schlechter Mobilverbindung sind es in der Regel unter 2 Sekunden.
Solche Komprimierung ist in herkömmlichen Systemen nicht unmöglich, aber entweder aufwendig in die Systemstruktur integriert oder an Drittdienste/Abstraktionsschichten wie mod_pagespeed ausgelagert, was neue Fehlerpotentiale birgt. In meinem System wird dies nativ unterstützt.
Anstatt ein allumfassendes System zu entwickeln, konzentriere ich mich darauf, bestehende Software effektiv zu vernetzen und an verständlichen, zentralen Knotenpunkten anzubinden. Man kann sich das wie einen direkten Zugriff auf alle Daten und Möglichkeiten einer Unix/Linux-Shell direkt im Template vorstellen.
Das ist natürlich eine starke Vereinfachung, und ich bin mir der damit verbundenen Probleme bewusst (zu viel Macht für Entwickler, undurchsichtige Systeme durch fehlende Trennung, wie z.B. bei MVC). Bisher sind jedoch keine solchen Schwierigkeiten bei den Webseiten aufgetreten, die ich mit diesem System erstellt habe, und ich vermute, dass sie eher Symptome dynamischer Systeme sind. In kompilierten Systemen ist die Perspektive ganz anders.
