Interview mit Garvin Hicking

Nicht zuletzt Jörg Petermann hat mir gezeigt, dass man auch in der Blogosphäre interessante Interviews führen kann. Auch für mich gibt es ein paar Leute die sich mit interessanten Themen beschäftigen oder an interessanten Projekten mitarbeiten an die ich die eine oder andere Frage stellen will.

Das erste Interview habe ich mit Garvin Hicking geführt. Er lebt in Köln, arbeitet als PHP-Entwickler und einen Großteil seiner Freizeit spendet er den Projekten PHPMyAdmin und Serendipity.

Hallo Garvin, vielen Dank das du dir die zeit genommen hast auf meine Fragen zu antworten.

Das tue ich doch gerne. Wer etwas mein privates Blog verfolgt, weiß, dass ich keiner Umfrage bzw. Fragebogen wiederstehen kann. 🙂

Was war dein erster Rechner und was hast du hauptsächlich damit gemacht?

Also wenn man es als Rechner bezeichnen kann, dann war das der Schneider CPC 464. Mit Datasettenlaufwerk. Darauf konnte man sogar Musik hören, wie mein 4-jahre jüngerer Bruder herausgefunden hat – was mich aber eher zur Weißglut brachte.

Eigentlich hätte ich mir lieber damals einen C64 geben lassen, weil ich ja damit spielen wollte wie die anderen Kids – demonstrativ habe ich für meine Eltern damals einen C64 aus Spanholz und Pappschachtel-Disketten hergestellt, bis ich
dann endlich mit dem CPC beglückt wurde. Nach viel Zeit vor dem grünochromen Monitor habe ich dann auch rausgefunden, dass das Ding zum Spielen nicht wirklich gut war. Dann habe ich angefangen, Listings aus Zeitschriften abzutippen, die nie klappten – bis ich dann meine eigenen kleinen Grafik-Spielereien gebastelt habe. RÜckblickend war es wohl gut, dass ich keine bessere Spielekonsole bekommen habe. 🙂

Du arbeitest als PHP-Entwickler in Köln. Könnte man ein bisschen mehr über deine Arbeit erfahren?

Jein; eigentlich arbeite ich festangestellt als PHP-Entwickler bei der Faktor E in Bonn. In Köln arbeite ich (sehr selten) zusätzlich noch freiberuflich, wenn man Dinge anfallen wie z.B. Fachgutachten für PHP-Bücher des O’Reilly Verlages oder ähnliches.

Meine Arbeit ist eigentlich recht vielfältig und beinhaltet so ziemlich alles, was man mit PHP und Webservern machen kann. Von Shellscripts zur Systemadministration, Apache-Spielereien, CMS-Implementationen bis hin zu komplexen datenbankgestützten Web-Applikationen, die so alles tun, was sie laut Kunden tun sollen. Was mir dabei besonders gefällt, ist dass die Arbeit vielfältig ist – ich könnte wohl nicht in einer Firma arbeiten, wo ich auf ein einzelnes Projekt festgelegt würde.

Wie kamst du zu PHP, wann war das und wie hast du PHP gelernt?

Das muss ungefähr ’98 gewesen sein. Damals hatte ich mit einem guten Freund ein Gewerbe gegründet, um hauptsächlich Computerhardware zusammenzubauen und zu verkaufen. Da ich nebenher schon sehr an HTML und Design interessiert war, gelangen wir über PC-Hardware auch in Kontakt mit einem anderen Dienstleister, der eine Onlineshop-Seite für einen Kunden entwickeln sollte. Ursprünglich wollte ich nur das Design entwickeln, aber dann warf mir unser Partner das Stichwort “PHP” entgegen. “Damit kann man wohl im Web tolle Dinge machen” – und dann war’s um mich geschehen.

In einer Woche hatte ich das PHP Manual durchgearbeitet, und mit meiner Erfahrung in Basic und Turbo Pascal war die neue Syntax auch ziemlich einfach. Eine weitere Woche später stand dann meine erste MySQL-Datenbankapplikation eines Shop-Systems. Später habe ich dann meinen Zivildienst in der Caritas-Werkstatt begonnen und konnte dort eine Art Warenwirtschaftssystem entwickeln. Über den Zeitraum von 6 Monaten sind dabei gut 100.000 Codezeilen angefallen – rückblickend natürlich grausliger Spaghetti-Code, aber es hat toll geklappt und sogar mit Barcode-Scannern interagiert. Ich glaube das war dann der Punkt bei dem ich entschieden habe, dass mir logische Software-Entwicklung mehr Spaß macht und mir mehr liegt als das Design.

Was fasziniert dich an PHP?

Prinzpiell ist es die Einfachkeit, und der hohe Verfügbarkeitsgrad. Es gibt kaum noch Webserver, bei denen man kein PHP anwenden kann. Zudem ist die Sprache extrem simpel und bietet für viele algorithmische Probleme direkt integrierte Funktionen an. Die Einrichtung von PHP ist ziemlich einfach, und viele Entwickler die sich damit auskennen, stehen zur Verfügung.

Besonders die einfache Verknüpfung von HTML und PHP hat mich wohl damals fasziniert, und macht es auch heute noch möglich extrem schnell zum gewünschten Ziel zu gelangen. Ausserdem hat PHP eine sehr flache Lernkurve aber bietet auch nach Jahren immer noch neue Möglichkeiten zur Optimierung, so wie die neuen OOP-PHP5 Features.

Was meinst du was wir von PHP in den nächsten 2-3 Jahren erwarten können und wie siehst du den Stand von PHP in Anbetracht der “Konkurrenz” (Python, Ruby)?

Ich denke der große Vorteil von PHP ist, dass es kommerziell etabliert ist. Viele Web-Agenturen haben sich darauf bereits eingelassen, der Support von Hostern ist entsprechend groß.

Der Ur-Konkurrent Perl ist meiner Meinung einfach zu ‘obfuscated’; Perl-Code ist (für mich) einfach hässlich zu lesen, und kann aufgrund seiner Syntax durchaus die ein oder andere Gehirnwindung verdrehen. Zudem ist Perl schon zu sehr auf’s
“Alles Können” spezialisiert, und daher für den einfachen Webentwickler zu komplex.

Wie man an vielen PHP-Projekten sieht, sind viele PHP-Entwickler Anfänger, die schnell Ergebnisse produzieren – das ist das Hauptproblem von Python und Ruby. Durch die strenge Syntax von Python wird kaum ein Anfänger damit klarkommen –
denn wie man an PHP-Code sieht, ist der überwiegend “hässlich” erstellt.

Einsteiger denken bei der Programmierung auch eher in funktionaler Strategie – kaum jemand wird direkt den Umgang mit Objektorientierung begreifen, worauf Python und Ruby aber basieren. Und das Web gewinnt man letztlich nur mit geringen Anfangshürden und flacher Lernkurve, aber mit Möglichkeit zum “sauberen Code”. Beides bietet PHP, und wird es auch in Zukunft bieten.

Ich hoffe sehr darauf, dass durch die aktuellen Anstrengungen Zend-Framework und ezComponents der generelle Code von Entwicklern mehr vereinheitlicht wird. Gute Komponenten entschlacken den eigenen Code und machen ihn leichter
wiederverwendbar. Worauf PHP sich auch “besinnen” muss, ist den faulen Entwickler einfacher zu sicherem und sauberen Code zu zwingen. Sicherheitslücken wie XSS und SQL Injection müssen für den User begreifbar in Programmierkonzepte umgewandelt werden, und die Entwicklung von PHP6 scheint da schon in eine gute Richtung zu gehen.

Das Fallbein wird da die Backward-Compatibility werden; das schönste, neue und sichere Konzept nutzt nichts, wenn jeder die “alte Syntax” verwendet. Hier wird es schwierig werden, einen guten Weg zu finden.

Gibt es für PHP Einsatzgebiete wo PHP noch gar nicht oder zu wenig eingesetzt wird obwohl PHP dort viel Potential entfalten könnte?

Prinzpiell denke ich, dass jedes Einsatzgebiet speziell betrachtet werden muss, und man schauen muss, welche Programmiersprache für ein Projekt am geeignetsten ist. Bei freien oder langjährigen Projekten sollte man auf die Verbreitung der Programmiersprache achten, um nicht irgendwann zu wenig Entwickler zu haben. Aber genauso wichtig ist, ob die Sprache performant und stabil genug für den Anwendungszweck ist.

Als Einsatzgebiet für PHP noch wenig geeignet erscheint mir der Einsatz von stark parallelisierten oder geclusterten Anwendungen. Die nur rudimentäre Unterstützung von persistenten Objekten über mehrere Requests hindurch ist noch eine Sache, die PHP lösen muss um in diese Region der JSP/Java-Anwendungen sinnvoll vorzudringen. Gleichzeitig sollte PHP aber keinen so massiven Footprint und Systemvoraussetzungen wie für JSP/Java vorbringen.

Für Desktop-Anwendungen macht PHP, trotz allen PHP-GTK-Spaßes meiner Meinung nach wenig Sinn. PHP ist eine Scriptsprache, und kann/sollte mit solchen Anwendungen nicht konkurrieren.

Welche Neuerungen dürfen kurz- und mittelfristig vom PHPMyAdmin-Projekt erwarten und was ist deine Aufgabe dort?

Das ist eine stechende Frage. Leider ermöglicht es mir meine beschränkte Zeit und andere Aufgaben in letzter Zeit kaum, im phpMyAdmin-Team anders als strategisch-beratend tätig zu sein.

Kurzfristig wird gerade sehr viel an einem Menü-basierten Installer vorgenommen, der schon gut voranschreitet. Auch MySQL5-Unterstützung ist in letzter Zeit besser geworden.

Was phpMyAdmin mittelfristig leisten muss (meiner Meinung nach) ist ein komplett überholtes Framework. Der jetzige Spaghetti-Code mit vielen HTML-Brocken ist bei der Menge an Code sehr unübersichtlich geworden. Hier bietet es sich an, über eine Objekt-Orientierung zur Abstraktion nachzudenken, und auch ein Session-Handling zu konzipieren. phpMyAdmin initialisiert einen gewaltigen Wust an Initialdaten, und muss bei JEDEM Seitenaufruf die gesamte Konfiguration parsen. Das wird heutzutage immer mehr zu einem einschränkenden Faktor.

Weiterhin soll(t)en die Funktionalitäten für Rapid-DB-Prototyping ausgebaut werden; der Editor zur Behandlung von Referenz-Tabellen/Spalten und Fremdschlüsseln müsste mehrdimensionale Verknüpfungen zulassen, um so auch das Layout von komplexen Datenbank-Strukturen zu erleichtern.

Gerade bei phpMyAdmin würde der Einsatz von Ajax und einem leichten Framework extrem viel Sinn machen.

Diese drei Zentralpunkte (Framework-Neubau, MySQL5, Relationen) sind essentiell wichtig, um den Nutzen des Tools voranzutreiben. Ich sehe da allerdings wenig Licht am Ende des Tunnels, da diese Aufgaben mehrere Monate Entwicklungszeit und kompetenter, vorausblickender Entwickler bedürfen.

Du arbeitest auch am Serendipity-Projekt mit. Was ist deine Aufgabe dort?

Ich arbeite dort inzwischen fast nicht mehr nur mit, sondern verbringe den 99%igen Großteil meiner Freizeit-Programmierzeit damit.

Meine Aufgabe dort umfasst (leider) eigentlich fast alles: Release-Manager, Support, Feature-Entwicklung, PR.

“Leider” deshalb, weil ich mir eine größere Community mit stärkerer Aufgabenteilung wünsche. Ich mache das ganze zwar aus Leidenschaft und Spaß am Projekt, aber möchte auch, dass das ganze nicht nur von einer handvoll Personen abhängt.

Könntest du in Kurzform erzählen warum man Serendipity als Weblog-Software einsetzen sollte?

Es wäre einfacher zu erklären, warum man Serendipity nicht verwenden sollte. Dann wäre ich jetzt fertig. 😉

Spaß beiseite. Serendipity bietet ein aufgeräumtes, Plugin-orientiertes Framework. Damit ist es extrem flexibel und sehr anpassbar. Wir verwenden das Smarty-Template System, mit dem man alle möglichen Anpassungen vornehmen kann – und darum geht es dem Blogger ja häufig.

Mehr als 100 Plugins lösen bei Serendipity so ziemlich jedes Problem und jeden Wunsch, den man beim bloggen entwickeln könnte.

Doch da hört Serendipity nicht auf, denn auch zum Einsatz für “normale “Webseiten ist es inzwischen gut geeignet.

Eine detailierte Benutzer- und Rechteverwaltung, eine Online-Plugin-Verwaltung und eine ausgebaute Mediendatenbank runden das ganze Paket gut ab.

Letztlich muss man natürlich sagen, dass Blogger eigenwillige Zicken sind. Es gibt immer spezielle Wünsche, damit man sich individuell präsentieren kann, und so zählt auch die Auswahl der Weblog-Software dazu. Ob Serendipity, WordPress, Textpattern oder MoveableType: Alle bedienen das Metier fast gleich gut. Serendipity sticht durch seine Flexibilität, geordneten Code und hohe Integrierbarkeit hervor.

Generell gilt: Probieren geht über studieren. 🙂

Wie schaut die Zukunftsplanung für Serendipity aus?

Wir haben derzeit viel vor. Version 1.0 steht vor der Tür, und rundet die mehr als 3 Jahre Entwicklungszeit in einem schnuckeligen, stabilen Release ab. Dafür polieren wir gerade viel am Design und der Präsentation. Denn eine Community kann nur dann größer werden, wenn auch mehr Leute von Serendipity wissen und auf den ersten Blick umfassend informiert werden können. Das ist derzeit in der Tat eher nur für denjenigen möglich, der sich mehr mit Serendipity befasst.

In mittelfristiger Zukunft liegt der Ausbau der Dokumentation. Parallel befriedigen wir eigentlich immer Feature-Requests und kurzfristige Pluginwünsche. Gerade das Plugin zur Bearbeitung von “statischen Seiten” wird noch einen wichtigen Punkt darstellen, und wird derzeit vom Hauptentwickler des Plugins detailiert vorbereitet.

Weitere Zukunftsplanung ist die Integration offener Schnittstellen, wie die Atom REST-API, den Ausbau des Online-Repositories. Auch dem User-Interface wollen wir uns stärker widmen, und dort stehen uns in naher Zukunft voraussichtlich eine Usability-Expertengruppe der OpenUsability.org zur Verfügung.

Auch Ajax (an den Stellen, wo es wirklich Sinn macht!) wird nach wie vor ein Thema bleiben. Vieles wird sich anhand der neuen Wünsche der Blogger zeigen, auf die wir immer sehr großen Wert legen. Wir sind ein offenes und flexibles
Projekt, und werden dies nicht durch 2-jährige Vorausplanung zunichte machen.

Braucht ihr (PHPMyAdmin und Serendipity) Hilfe und wie könnte man euch unterstützen?

Hilfe braucht man natürlich immer. Gerade im Bereich der Dokumentation, Design und User Interface haben wir großes Bedürfnis. Doch auch Entwickler, die sich gerne mit dem Framework an sich befassen möchten, sind immer willkommen.

Ein aktuelles “Problem” in Verbindung mit PHP sind Kontaktformulare. Viele Kontaktformulare werden von Spamern als Spam-Schleudern missbraucht. Gefährdet sind sogar Formulare, die bis dato als “sicher” galten. Also auch Formulare die eine feste Empfänger-Adresse hatten und die auch htmlspecialchars und stripslashes intus hatten. Könntest du uns kurz erklären, welches Prinzip wird hier ausgenutzt, wie kann man testen ob man gefährdet ist und wie kann man sich gegen so was schützen?

Leider gibt es im heutigen Spam-Zeitalter immer neue Mittel und Wege, wie Spammer ihre Sachen an den Mann kriegen. Nicht nur Viren, Trojaner und Phishing werden genutzt, sondern auch bestehende Webseiten.

An dem Wust von aktuellen Sicherheitslücken (XSS, XSRF, SQL Injection, Header Injection, DDOS, …) gibt es vieles, worauf PHP-Entwickler achten müssen. Seiten wie www.hardened-php.net widmen sich dem sehr ausführlich, daher möchte ich nur kurz darauf eingehen.

Das oben angesprochene Problem der Kontaktformulare war insofern tückisch, als dass man mit der Anwendung der “üblichen Sicherheitsfunktionen” htmlspecialchars()/stripslashes()/*_escape_string() einen Fall nicht bedacht hat:

HTTP-Anwendungen und auch E-Mails erlauben beide die Festlegung von Metadaten, sogenannter Header. HTTP-Header geben Meta-Informationen zur Dokumentgröße, Cookies und Systemzeit aus, während E-Mail Header den Absender, Absendezeit, Inhaltstyp u.ä. angeben.

Beide Header unterteilen die einzelnen Felder mit einfachen Zeilenumbrüche (\r\n). Wenn irgendwo in den Header einen Benutzereingabe auftaucht (z.B. “From: $user”), dann kann es sein, dass ein böswilliger User in dieser Variable einen
Zeilenumbruch mit weiteren individuellen Headern eingeschleust hat. Diese Header werden dann vom HTTP-Browser oder E-Mail-MTA durchaus interpretiert, und können sowohl zu gefälschten HTML-Seiten als auch zu völlig anderen Spam-E-mails
umgewandelt werden.

Seit PHP 5.1.2 und 4.4.2 besteht das Problem bei HTTP-Headern nicht mehr, da Zeilenumbrüche nicht mehr erlaubt werden. Für E-Mails die mittels der mail() Funktion versendet werden, gilt dies jedoch nach wie vor. Daher muss der Programmierer darauf achten, dass er aus allen Benutzereingaben ungültige Zeichen wie \r, \n, \t, \0 alle entfernt.

Wir arbeiten seit 20 Jahren mit WordPress und bieten diverse Dienst­leistungen rund um das System an. Kontaktiere uns für weitere Informationen oder für ein Angebot.

Verwandte Beiträge:

• Was hat Tolkien mit WordPress zu tun?
• Interview: WordPress-Nutzung an der FAU Erlangen-Nürnberg
• Interview: WordPress ist für PHP ein zweischneidiges Schwert
• Interview mit Robert Kaiser
• Interview mit Torsten Rox