Und direkt mal 3 Repos erstellt. Eins für mein Backup-Script, eins für die ITWS PHP Tools und eins für YAP, mein Projektmanagement System.

Mal sehen wann ich neben yaana.de Zeit für YAP finde

Es gab in meinem Leben bisher nichts, womit ich so viel Zeit verschwendet habe wie mit Encoding Problemen.

Für mein aktuelles Projekt entwickle ich zur Zeit einen crawler, der Websites zieht und analysiert. Natürlich bin ich da direkt auf sämtliche Encoding-Problemchen gestoßen, die man sich nur vorstellen kann und hatte unglaublich viel Spaß damit …

Ich verwende das Zend Framework und daher entsprechend die Klasse Zend_Http_Client um die HTTP-Requests abzusetzen.
Danach suche ich den Inhalt der Seite raus, sodass lediglich ein String ohne HTML-Tags und damit reinem Text übrig bleibt.
Gebe ich mir diesen nun einfach auf die Shell aus, stimmt das Encoding manchmal und manchmal nicht. Das sieht man dann immer schön an den kaputten Umlauten.

Also habe ich eine Funktion gebraucht, die das Encoding eines Strings konvertiert … Tja, wenn es denn so einfach wäre …
Die letzten Tage habe ich rund 20 Stunden damit verbracht eine Funktion zu schreiben, welche dafür sorgt, dass der String, der am Ende rauskommt, sauber dargestellt wird – unabhängig davon, was rein kommt. Das Problem hier war in erster Linie, dass selbst Strings, die sich als UTF-8 ausgegeben haben und von denen sogar mb_check_encoding() behauptet hat, es sei alles in bester Ordnung, haben kaputte Umlaute mit sich getragen. Also darauf konnte man sich schonmal gar nicht verlassen.

Ich möchte hier das Ergebnis meiner Arbeit mit euch teilen. Nicht erschrecken, es ist keine saubere Lösung (die sauberen Implementierungen haben allesamt nicht funktioniert). Der Code deckt auch nicht alle denkbaren Fälle ab, aber ich konnte bisher jeden beliebigen kaputten String mit deutschem Text und explodierten Umlauten in einen lesbaren String mit intakten Umlauten konvertieren. Da das mehrere 100 Texte aus verschiedensten Quellen aus dem Netz waren, behaupte ich mal, dass der Code recht brauchbar ist. Im Zweifelsfall dient er als gute Basis für eine umfassendere Implementierung.

Der Methode magicFixStringEncoding() kann man also einen beliebigen  String übergeben unabhängig davon ob er völlig in Ordnung ist oder total verstümmelt. Die Rückgabe der Methode sollte immer einen sauberen String mit funktionierenden Umlauten entsprechen.

Für Verbesserungsvorschläge bin ich jeder Zeit offen. Annsonsten viel Spaß denen, die den Code gebrauchen können

 

 

class ITWS_Tool {
	public static function magicFixStringEncoding($strInput) {
		if (preg_match('/[üäöÄÖÜß]/i', $strInput) === 1) {
			$strInput = self::convertEncoding($strInput, 'UTF-8');

			if (strlen(utf8_decode($strInput)) !== strlen(utf8_decode(utf8_decode($strInput)))) {
				$strInput = utf8_decode($strInput);
			}
		} else {
			$strInput = self::convertEncoding($strInput, 'UTF-8', 'ISO-8859-15');
		}

        return $strInput;
    }

    public static function convertEncoding($strInput, $toEncoding, $fromEncoding = '') {
        if ($fromEncoding == '') {
            $fromEncoding = mb_detect_encoding($strInput, array('UTF-8', 'ASCII', 'ISO-8859-1', 'JIS', 'EUC-JP', 'SJIS'), true);
		}

        if ($fromEncoding == $toEncoding) {
            return $strInput;
		}

        return mb_convert_encoding($strInput, $toEncoding, $fromEncoding);
    }
}

Im nächsten PHP Release gibt es ein neues Feature für horizontalen Code Reuse: sog. Traits (engl. Merkmal, Charakterzug). Was das ist und wie es funktioniert, erfahrt ihr im folgenden Artikel.

Vererbung: Vertikaler Code Reuse

class A {
	public function foo() { ....}
}

class B extends A { }

Bei der objektorientierten Vererbung werden alle nicht-privaten Methoden und Attribute einer Klasse auf die Kind-Klasse vererbt. Das ist toll, denn so braucht man viele Methoden nur einmal zu implementieren, kann sie aber in vielen verschiedenen Klassen wiederverwenden. Das ist vertikaler Code Reuse. Tolle Sache, kein Thema.

Dennoch gab es ein paar Dinge, die sich mit einfacher Vererbung nicht umsetzen ließen. z.B. eine Basis-Klasse für das Singleton-Pattern. Gerade in PHP ist das Hauptproblem hier, dass keine Mehrfach-Vererbung möglich ist – also eine Klasse nicht von mehr als einer anderen Klasse abgeleitet werden kann. Das zwingt uns leider oft dazu, dass wir uns der unangehmen Entscheidung stellen müssen, ob wir nun konzeptionell sauberen Code oder aber möglichst gute Wiederverwendung von Code haben wollen. Um dennoch irgenwie horizontalen Code Reuse zu realisieren mussten Methoden kopiert werden (also praktisch kein Reuse) oder Methoden bis in die Wurzel der Klassen-Hierarchie geschoben werden, was alles andere als schön ist.

(weiterlesen …)

Einen netten Artikel gab es heute von Nils. Und den fand ich direkt so gut, dass ich das – ähm reblogge? Wie nennt man denn einen retweet per Blog? Egal. Es geht um den Beitrag Worüber ich nicht mehr streiten werde!

Ich möchte jetzt nicht nochmal genau das schreiben, was er geschrieben hat, das könnt ihr selbst lesen. Ich möchte nur die Kernaussage weitergeben: Hört auf euch über Betriebssysteme (Linux, Windows, OSX, …), Grafische Oberflächen (Gnome, KDE, XFCE, …), Template-Engines (smarty, dwoo, …), IDEs (Eclipse, Netbeans, …), Coding Guidelines etc. zu streiten.

(weiterlesen …)

Gestern war ich auf der Suche nach einem neuen geeigneten Framework für ein Projekt (bisher Codeigniter verwendet, aber das hat nie so ganz meinen Bedürfnissen entsprochen). Nach dem ich nochmal auf die Websites von codeigniter 2.0, cakePHP, akelos etc. gesurft bin und jeweils einen Blick reingeworfen habe, habe ich beschlossen mich mal von meinem Vorurteilen zu befreien und mir das Zend Framework anzusehen.

Vor diesem Framework habe ich mich lange Zeit zurückschrecken lassen, da ich der Ansicht war, dass das nur ein Haufen sinnlos zusammengestückelter PHP Files ist und das praktische Arbeiten mit dem ZF nicht besser aussieht.

Aber man muss auch mal über seinen Horizont hinausblicken, weswegen ich mir mal die Dokumentation des Frameworks angesehen habe. Erst auf deutsch. Dann auf englisch, weil die Übersetzung so schlecht ist, dass ich viele Sätze fünfmal lesen musste, bis ich sie verstanden habe
Den Quickstart Guide fand ich bis zu einem gewissen Punkt sehr gut, dann wurd es aber sehr schwammig und viele wichtige Punkte haben gefehlt, weswegen ich den Guide an dieser Stelle verlassen habe und beschlossen habe die Dokumentation zu lesen. Auf englisch natürlich. Die Doku ist soweit also nicht ideal aber auch nicht ausgesprochen schlecht.

Das Framework an sich ist deutlisch komfortabler als ich dachte, das autoloading erspart viel Arbeit und die saubere objektorientierte Implementierung der Komponenten ist wirklich gut.

Bisher sieht es also ganz danach aus, als würde ich das anstehende Projekt mit dem Zend Framework umsetzen. Das hat verschiedene Konsequenzen. Zu erstmal bin ich froh, diesen Schritt getan zu haben und mich endlich mit dem Framework zu befassen. Zum Anderen wird mir das wohl auch einiges an Stoff liefern, über den ich hier im Blog schreiben kann und zum anderen kann ich endlich mal wieder ein Projekt starten und habe was zum coden. Wurde auch mal wieder Zeit.

Diejenigen, die wissen um was es geht, wundert es nicht, dass der nächste Artikel meiner Clean Code-Reihe dem KISS-Prinzip gewidmet ist.

Dem Rest sei gesagt: Dieser Artikel hat nichts mit  der US-Amerikanten Hard-Rock-Band aus den 70er zu tun Es handelt sich dabei vielmehr um eine Disziplin beim Programmieren: KISS steht für Keep It Simple, Stupid! im Sinne von "Halt es einfach, Idiot!".

Aber was heißt "einfach"? Einfach bedeutet in diesem Fall, dass man nicht unnötig mehr macht, als wirklich nötig. Denn das kostet im Zweifelsfall nur unnötig Zeit und macht den Code schwerer zu lesen und zu warten.

Leider lassen sich die Entwickler nur zu gern von der "Feature-Geilheit" erfassen und coden wahnsinnige Dinge, die zwar verdammt cool sind, aber niemand braucht und im schlimmsten fall auch sonst niemand versteht. Dies lässt sich wohl darauf zurückführen, dass das Coden an sich eine recht langweilige Sache ist. Selten entwickelt man wirklich innovative und einzigartige Systeme. Meistens implementiert man stattdessen stupide Datenbank-Abfragen, langweilige Business Logiken und unspektakuläre Oberflächen. Im öden Einheits-Code sucht man Herausforderungen und Möglichkeiten seine Fähigkeiten einzusetzen. KISS bedeutet genau diesem Drang zu widerstehen und brav und artig einfach exakt das zu implementieren, was benötigt wird. Nicht mehr, nicht weniger und möglichst aus einer Mücke keinen Elefanten machen.

Dies ist der erste Teil meiner Artikel-Reihe "Clean Code", welchem noch einige Weitere folgen werden und welche sich hauptsächlich damit befassen, wie man sauberen, wartbaren und stabilen Code schreibt. Ich versuche dabei möglichst von der Programmiersprache selbst zu abstrahieren und mich nur mit den prinzipiellen Mustern und Vorgehensweisen zu beschäftigen. Dennoch muss ich ab und an Code-Beispiele einbringen und da werde ich mir dann wohl mit PHP und Java helfen.

in diesem Artikel geht es also um das DRY-Prinzip, welches nicht nur die einfachste Regel darstellt, sondern zugleich auch die, die am meisten misachtet wird.

(weiterlesen …)

Oft liest man, dass man bestimmte Verzeichnisse in den sog. include path aufnehmen soll oder im include path irgendwelche scripts ablegen soll und das meist ohne weitere Erklärung. Der Include Path und das Administrieren des Selbigen gehört also mehr oder weniger zu den Grundkenntnissen. Dennoch ist es für viele ein Mysterium.
Da ich gestern ein wenig damit gearbeitet habe, dachte ich, ich blogge mal ein wenig drüber. Warum? Weil ichs kann. Und weil ich eine kleine Hilfestellung zum Thema path im Allgemeinen und dem PHP include path im Speziellen zur Verfügung stellen möchte.

(weiterlesen …)

Hier eine kurze Anleitung wie man sich unter einem aktuellen Ubuntu eine Entwicklungsumgebung mit Apache, MySQL und PDT einrichtet.

 

Schritt 1: Das Arbeitsverzeichnis

Zuerst legen wir uns ein Arbeitsverzeichnis an, der Eclipse-Workspace. Hier werden später die Projekte abgelegt. Außerdem dient das Verzeichnis als DocumentRoot für den Apache:

ghost@spacebox:~$ mkdir workspace

Fertig. Langweilig, ich weiß

 

Schritt 2: Der Apache

Installieren des Apachen mit mod_php5:

ghost@spacebox:~$ sudo aptitude install apache2 libapache2-mod-php5

Einrichten der DocumentRoot:

ghost@spacebox:~$ sudo vim /etc/apache2/sites-avilable/default

Es öffnet sich der vim mit der default site, welche wir wie folgt anpassen ([i] zum Bearbeiten):

<VirtualHost *:80>
    DocumentRoot /home/ghost/workspace

    <Directory />
        Options FollowSymLinks
        AllowOverride None
    </Directory>

    <Directory /home/ghost/workspace>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
        Order allow,deny
        allow from all
    </Directory>

    (...)
</VirtualHost>

[esc], ":wq", [enter] speichert und schließt die Datei.

Anschließend muss der Apache reloaded werden, das funktioniert wie folgt:

ghost@spacebox:~$ sudo /etc/init.d/apache reload

Zum Testen legen wir innerhalb des workspace-Verzeichnisses eine index.php an:

ghost@spacebox:~$ cd workspace
ghost@spacebox:~/workspace$ echo 'Hallo Welt!'  > index.php

Im Anschluss dazu rufen wir im Browser die URL "http://localhost/index.php" auf.
Wir erhalten eine weiße Seite und ein "Hallo Welt!".

 

Schritt 3: Der MySQL-Server

Zuerst den MySQL-Server und den Client installieren:

ghost@spacebox:~$sudo aptitude install mysql-client-5.1 mysql-server-5.1

Während der Installation wird man dazu aufgefordert ein root-Passwort für den MySQL-Server festzulegen, dort ein beliebiges Passwort eingeben und selbiges bitte merken

anschließend ein Verbindungstest zum Server:

ghost@spacebox:~$ mysql -h localhost -u root -p

Nach der Eingabe des korrekten Passworts, welches wir eben bei der Installation festgelegt haben, startet die mysql-Shell:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 34
Server version: 5.1.41-3ubuntu12 (Ubuntu)

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>
 

 

Schritt 4: Die PDT

Die PHP Development Tools ist eine auf Eclipse basierende Entwicklungsumgebung für PHP.

Zuerst laden wir uns das tar.gz-Archiv, welches wir auf der offiziellen Website finden und entpacken dieses anschließend nach /opt/eclpse:

ghost@spacebox:~/Desktop$ sudo tar xvzf eclipse.tar.gz -C /opt/

Über einen Rechtsklick auf das Gnome bzw KDE-Menü kann mit Hilfe des "Menü bearbeiten"-Tools ein Menü-Eintrag für Eclipse angelegt werden. Der Befehl zum starten von Eclipse lautet:

/opt/eclipse/eclipse

 

Nun stehen  Apache und MySQL zusammen mit PDT zur Verfügung. Der Apache und der MySQL-Server starten bei jedem Booten des Systems automatisch und müssen daher nicht manuell gestartet werden.