Mein neues Aufgabengebiet als Ausbilder umfasst natürlich auch das kreative Entwickeln von Aufgaben, mit denen die Azubis neues Wissen leichter aufnehmen können. Im Prinzip geht es darum, dass man nicht stupide ein Buch oder Tutorial durcharbeitet, sondern bereits ein bestehendes Problem hat und an dessen Lösung arbeitet. So wird einem nicht alles vorgegeben und man muss nach individuellen Lösungen für die einzelnen Teilprobleme suchen. Diese Herangehensweise habe ich mir irgendwann angeeignet und konnte damit bisher schneller Sachen lernen, vornehmlich bei Programmiersprachen.

Mein Lieblingsprojekt für dieses Thema ist ein Wordlist-Generator. Wem der Begriff fremd ist: Wordlisten werden verwendet, um mittels geeigneter Tools Passwörter zu knacken. Darum geht es mir hier aber gar nicht, sondern nur um die Erstellung einer solchen Liste. Warum? Nun, wenn man ein solches Tool entwickeln möchte, so muss man fast alle grundlegenden Möglichkeiten einer Programmiersprache nutzen:

- Aufbau und Syntax (z.B. )
- Parameterübergabe
- Bedingungen (z.B. if…)
- Schleifen (z.B. for, while, …)
- Funktionen (auch rekursiv)
- Arbeit mit Strings und Arrays
- Dateizugriffe
- Sortieralgorythmen (optional)
- Klassen (optional)
- Datenbank (optional)
- Optimierung vom Code im Allgemeinen und vor allem der Schleifen

Um ehrlich zu sein habe ich bereits 2 verschiedene Varianten entwickelt: die einfache und die etwas kompliziertere. Variante 1 erzeugt einfach eine Liste mit allen möglichen Zeichenkombinationen und einer durch den Benutzer definierten Länge. Dazu entwickelt man eine Funktion, die alle möglichen Zeichen wiedergibt, und das nacheinander. Diese Funktion kann sich nun entweder rekursiv x-mal (je nach gewünschter Passwortlänge) aufrufen oder man packt diese Logik in Schleifen. Im Endeffekt erhält man dann eine solche Liste (Länge 3 Zeichen):

aaa
aab
aac
…
aba
abb
abc
…
ZZX
ZZY
ZZZ

Je mehr Zeichen man ermöglicht, desto mehr Kombinationen gibt es. Dadurch steigt der Speicherbedarf und natürlich auch die Ausführungszeit. Diese Methode nennt man Bruteforce, da stupide jede mögliche Kombination von Zeichen durchprobiert wird.

Variante 2 baut eine echte Wordlist nur aus Wörtern auf. Das ist wesentlich schneller als Variante 1, jedoch muss man davon ausgehen, dass die zu knackenden Passwörter eben normal vorkommende Wörter sind – was leider sehr oft der Fall ist. Im Prinzip nimmt man sich ein paar Ebooks oder andere Texte und packt diese in txt-Dateien – je mehr desto besser – und wirft sie in einen Unterordner. Das Tool geht diese Dateien nun einzeln durch, wandelt jedes Leerzeichen und Satzzeichen in Zeilenumbrüche um und wirft doppelt vorkommende Einträge wieder heraus. Lässt man das Tool laufen, so baut sich langsam aber sicher eine sehr umfangreiche Wordlist zusammen.

Ihr seht schon, dass bei einer so simpel klingenden Aufgabe doch ein bisschen Arbeit zu erwarten ist. Das tolle an beiden Projekten ist, dass man einen sehr guten Einstieg in neue Programmiersprachen findet, indem man versucht, beide umzusetzen. Die Vorgehensweise ist eigentlich immer die gleiche:

- Syntax anschauen
- Dateizugriffe lernen
- Schleifen, Bedingungen und Stringmanipulation studieren
- um Funktionen erweitern
- testen
- fertig

Probiert es mal aus – mir haben diese Aufgaben bisher immer gut geholfen, sodass ich neben PHP bereits Basic, Python, C, C++, C#, Java und Shellscripting erlernen konnte.

Programmierung besteht nicht nur aus dem Aneinanderreihen von Codezeilen – in der Hoffnung dass es funktioniert. Dazu gehört sehr viel Überlegung und Theorie. Aus diesen Überlegungen entstanden (bzw. entstehen immernoch) sog. Design-Patterns. Das sind Mustervorlagen, wie man eine Klasse oder ein ganzes System aufbauen kann, um bestimmte Optimierungen oder effizienteren Code erreichen kann – losgelöst von einer bestimmten Programmiersprache. Die Patterns sind fast immer allgemeingültig.

Bereits vor einiger Zeit hatte ich das Registry Pattern vorgestellt, welches ich aktiv nutze. Während der letzten Projekte setze ich auf ein neues System, welches eher als Mischform zu bezeichnen ist: Im Kern verwende ich Techniken der event-driven-Entwicklung, das Observer- sowie das Singleton-Pattern. Damit ist es mir möglich, große Teile der Programmlogik auszulagern und – das ist der eigentliche Vorteil – das System wird sehr leicht erweiterbar, da sich neue Funktionen einfach einklinken können. Aber wie funktioniert das nun genau?

Nehmen wir uns als Beispiel ein einfaches Blogsystem: Man kann Artikel schreiben (natürlich nur nach einer Passwortabfrage) sowie die Artikel lesen. Ich möchte nun, dass all diese Vorgänge geloggt werden, mein Twitter-Account automatisch auf neue Artikel hinweist, ich über fehlerhafte Logins per Mail informiert werde und ein Visit-Counter über die Artikel läuft (ich also sehen kann, welche Artikel wie oft gelesen wurden). Das stellt natürlich keine große Schwierigkeit dar und kann so direkt in den bestehenden Code implementiert werden. Es geht aber auch anders.

Zuallererst benötigen wir unseren Observer. Dieser bietet Methoden, mit denen man sich für Events registrieren kann (per Listener) und über die man aber auch Events auslösen kann (Fire Event). Da der Observer als Singleton aufgebaut ist, kann man alle Kommandos jeweils mit einer Zeile Code erledigen. Man spart sich die Instanzierung und das Observerobjekt wird nur ein einziges Mal erstellt – was für seine Funktion essenziell ist.

Im ersten Schritt werden also die Listener registriert, was möglichst am Anfang eures Programmes passieren sollte, damit die Listener alle Events hören können. Mein Observer nimmt dazu folgende Daten für einen Listener entgegen: Event, Klasse und Methode. Das Event ist ein einfacher String, wie z.B. “NewArticleCreated”, “Fail_UserLogin” oder “PageVisit” – kann aber auch ein “*” sein. In diesem Falle lauscht der Listener auf jedes Event, was z.B. für das Logging oder Debugging interessant sein könnte. Die “Klasse” ist eine von mir frei wählbare Klasse, die auch die angegebene “Methode” enthält. Der Observer speichert diese Angaben nun in einem Array und behält sie während der gesamten Laufzeit

Im zweiten Schritt benötigen wir nun noch die Events. Der Observer kennt die Methode “fireEvent”, welche zusätzlich die Parameter Eventname sowie Eventdata enthält. Beispiele für die Eventnamen gab’s weiter oben schon, interessant ist hier eher der Parameter eventData. In diesem kann ich nämlich weitere Infos zum Event mitgeben – sei es als String oder als Array. Das Datenformat sollte natürlich vorher definiert werden.

Und was passiert nun, wenn ich ein Event abfeuere? Der Observer nimmt das Event entgegen und vergleicht es mit seinem Listener-Array. Trifft er eine Übereinstimmung, instanziert er die gegebene Klasse und ruft anschließend die Methode auf. Der Methode wird das Event sowie die eventData übergeben. Klingt alles etwas wirr, deswegen versuchen wir uns wieder an unserem Blog-Beispiel.

Im Initbereich meines Blogsystems registriere ich erstmal folgende Events:

Observer.addListener("*", "Logger", "logEvent");
Observer.addListener("Fail_UserLogin", "Informer", "noticeAdmin");
Observer.addListener("PageVisit", "Visitor", "countVisit");
Observer.addListener("NewArticleCreated", "TwitterTools", "sendNewArticleTweet");

Ab sofort sollten wir an allen relevanten Stellen im Code Events feuern. Ganz wichtig an dieser Stelle: Auch Events feuern, auf die ihr noch gar nicht regieren wollt. Das macht es euch, aber auch anderen Programmierern später leicht, neue Programmlogik hinzuzufügen.

Observer.fireEvent("NewArticleCreated", articleID);
Observer.fireEvent("ArticleUpdated", articleID);
Observer.fireEvent("ArticleDeleted", articleID);
Observer.fireEvent("PageVisit", pageID);
Observer.fireEvent("Fail_UserLogin", userID);

Die Events werden natürlich nicht direkt hintereinander abgefeuert sondern an den entsprechenden Codestellen hinterlegt. Der Observer geht bei jedem fireEvent seine Liste durch und aktiviert die Listener:

NewArticleCreated --> Logger.logEvent(eventName, eventData),
TwitterTools.sendNewArticleTweet(eventName, eventData)
ArticleUpdated --> Logger.logEvent(eventName, eventData)
ArticleDeleted --> Logger.logEvent(eventName, eventData)
PageVisit --> Logger.logEvent(eventName, eventData),
Visitor.countVisit(eventName, eventData)
Fail_UserLogin --> Logger.logEvent(eventName, eventData),
Informer.noticeAdmin(eventName, eventData)

Der Vorteil an dem System ist, dass ich beliebig viele Listener auf bestimmte Events lauschen lassen kann, aber auch beliebig viele Events abfeuern kann. Das System ist also extrem dynamisch.

Möchte ich später z.B. Abonnenten darüber infomieren, dass es einen neuen Artikel gibt oder dass ich einen Artikel geändert habe, erweitere ich die Klasse Informer um die nötigen Methoden (oder bau mir eine neue Klasse) und registriere diese als Listener:

Observer.addListener(“NewArticleCreated”, “Informer”, “noticeUser”);
Observer.addListener(“ArticleUpdated”, “Informer”, “noticeUser”);

Da mir das Event gleich mit übertragen wird, kann ich innerhalb der Methode unterscheiden, welchen Mailtext der User erhalten soll – “Neuer Artikel in meinem Blog” oder “Ich habe einen Artikel bearbeitet”.

Ich hoffe, dass das Prinzip nun etwas verständlicher war…

Beim Wort “Framework” war mir bisher etwas unwohl, stand es für mich neben den Annehmlichkeiten auch für Einengung. Kann sein, dass ich da die falsche Sichtweise auf die Problematik habe. Aber nach meinem Exkurs in die Ruby on Rails Welt und Tests mit diversen anderen PHP Frameworks war das Thema für mich ein rotes Tuch. Die automatisierte Code-Generierung sah für mich eher wie eine Einschränkung an Stelle einer Erleichterung aus.

Bei der Entwicklung von NetzCMS hatte ich anfangs auch mit dem Gedanken gespielt, auf ein Framework zu setzen. Jedoch erschienen mir die getesteten Systeme zu unflexibel und es sah nicht gerade so aus, dass ich damit so programmieren konnte, wie ich es mir vorstellte.

Leider hatte sich diese Ansicht bei mir fest eingenistet und trübte die Sicht auf die restlichen Frameworks. Naja, das führte dann letztlich dazu, dass ich ein quasi-Framework für das CMS selbst schrieb. Man kann davon nun halten was man will, fakt ist aber: ich habe dadurch extrem viel gelernt. Sei es nun die Optimierung von Code, aber auch das Verständnis von Software-Architekturen. So gesehen war diese Entwicklung also für mich persönlich ein großer Vorteil.

Natürlich hatte der Spaß auch eine Kehrseite: Zeit. Wenn ich auf ein fertiges Framework gesetzt hätte, hätte ich einen Großteil der Entwicklungszeit einsparen können. Ich hätte es wahrscheinlich auch so gemacht, wenn ich mir zu dieser Zeit das Zend Framework angesehen hätte. Es ist mir noch immer nicht ganz klar, warum ich mich nie näher damit beschäftigt hatte…

Doch was macht das Zend Framework nun so anders? Es ist kein klassisches Framework, sondern eher eine sehr gute Sammlung von Klassen, die man einzeln, aber auch im Zusammenspiel verwenden kann. Das macht es zum perfekten Partner in bestehenden Projekten, aber auch bei Neuentwicklungen. Man behällt nämlich alle Freiheiten und spart sich trotzdem ordentlich Zeit. Benötigt man z.B. nur einen schnellen und einfachen Zugriff auf eine Datenbank, bindet man die zend_db Klasse ein und arbeitet mit deren Methoden. Man muss keine weiteren Klassen einbinden bzw. verwenden.

Ein Blick in die Zend Dokumentation der Datenbankklasse ließ mich frohlocken, basiert sie doch auf den gleichen Absichten, unter denen ich meine eigene Datenbank-Klasse entwickelt hatte. Die Methoden sind den meinen sehr ähnlich, nur dass es noch ein paar mehr gibt. Das hat für mich persönlich den Vorteil, dass der Umstieg kaum Umgewöhnung bedeutet. Aber auch, dass ich mit meiner Entwicklung gar nicht so falsch lag.

Neben der gut ausgebauten Datenbank-Klasse bietet Zend u.a. Module für die Benutzerauthentifizierung, Logging und auch eine komplette Implementierung des MVC Patterns (Model-View-Controler, sprich, der Code ist vom Design komplett getrennt). Das alles sind Punkte, die ich für zukünftige Projekte wahrscheinlich selbst entwickeln bzw. weiterentwickeln würde. Mit der Verwendung von Zend kann ich mir das sparen.

Die Ordnerstruktur des Frameworks ist zwar in leichten Zügen vorgegeben, stellt aber eher eine Best Practice Methode dar. Sie baut von vornherein auf MVC auf. Man kann die Struktur aber auch komplett nach den eigenen Wünschen bzw. an das eigene Projekt anpassen.

All das sind Punkte, die das Zend Framework für mich interessant machen. Vorerst. Sobald ich damit die ersten Projekte umgesetzt habe, kann ich es wahrscheinlich besser beurteilen.

Hinter dem Zend Framework stecken Andi Gutmans und Zeev Suraski , die selbst auch für die Entwicklung von PHP 5 verantwortlich sind. Man kann sich denken, dass die Leute, die die Sprache entwickeln, wahrscheinlich auch mit den optimalsten Code für diese Sprache liefern. Auch ein Punkt, der für Zend spricht. Ob sich das nun bewahrheitet, wird sich zeigen.