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

Ähnliche Artikel

• YAP: Framework-Wahl
• Brauchbare Project Management Systeme sind Mangelware?
• Neues Layout

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.

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);
    }
}

Ähnliche Artikel

• PHP 5.4 Feautre: Traits – Horizontaler Code Reuse
• Den Horizont erweitern: Das Zend Framework
• [PHP] Der include path

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.

Traits: Horizontaler Code Reuse

Abhilfe schaffen hier in PHP 5.4 die sogenannten Traits, welche bereits in Perl 6 oder Scala zur Verfügung stehen. Sie erlauben es dem Entwickler Behaviors (also Verhalten) in Code zu gießen. Diese Traits funktionieren im Prinzip wie Klassen können jedoch – ähnlich wie Interfaces und abstrakte Klassen – nicht instanziiert werden.

Sie sind dazu gedacht, Funktionalitäten zu gruppieren. Einer der Vorteile ist, dass eine Klasse mehrere Traits verwenden kann. Traits beheben somit einige Probleme von single inheritance Sprachen wie PHP oder Java.

Um das eben angesprochene Singleton-Pattern-Problem zu lösen genügt nun ab PHP 5.4 folgene Klassen-Definition:

trait Singleton {
    public static function getInstance() { ... }
}

class A {
    use Singleton;
    // ...
}

class B extends ArrayObject {
    use Singleton;
    // ...
}

// Beide Klassen verwenden nun das Singleton Trait und implementieren somit das Singleton-Pattern:
A::getInstance();
B::getInstance();

Es wird noch besser: Wie bereits erwähnt, kann eine Klasse kann beliebig viele Traits verwenden. Da stellt sich der aufgeweckte Coder natürlich die Frage:

Was passiert bei Konflikten?

Sprich: Was passiert, wenn zwei Traits verwenden werden, die beide eine Methode mit der selben Signatur definieren?

trait A {
    public function foo() {
        echo 'a';
    }

    public function bar() {
        echo 'A';
    }
}

trait B {
    public function foo() {
        echo 'b';
    }

    public function bar() {
        echo 'B';
    }
}

class C {
    use A, B;
}

Dazu ist folgeneds zu sagen: Traits werden bereits in einigen Sprachen verwendet und es hat sich gezeigt, dass Konflikte zwar auftreten aber das eher die Ausnahme darstellt. Dennoch muss es natürlich ein definiertes Verhalten geben, das vorschreibt, was passieren soll, wenn Konflikte auftreten.

Diese Konfliktlösung sieht hier wie folgt aus:

Erstmal wirft PHP eine Warning um dem Entwickler darauf aufmerksam zu machen, dass ein Konflikt aufgetreten ist. Und gibt dazu auch die Info, wo der Konflikt genau auftritt. In dem Fall würde es die beiden Methoden foo() und bar() melden.

Und das ist auch gut so, denn keine der beiden Methoden werden in Klasse C zur Verfügung stehen! Richtig, die Konfliktlösung sieht vor, dass alles, was einen Konflikt erzeugt, rausfliegt.

PHP zwingt uns damit, die Traits ordentlich zu verwenden und PHP zu sagen, was wir aus welchem Trait haben wollen:

class C {
    use A, B {
        B::foo instead A;
        A::bar instead B;
    }
}
?>

Dieser Code bewirkt folgendes Verhalten: Klasse C erhält aus Trait B die Methode foo() und aus Trait A die Methode bar().
Entsprechend würde ein Aufruf der beiden Methoden auf Klasse C “b” und “A” ausgeben.

Das ist zwar cool, aber dennoch nicht die sauberste Lösung. Es gibt Alternativen: So kann der Entwickler auch Aliase vergeben:

class C {
    use A, B {
        B::foo instead A;
        A::bar instead B;
        B::bar as bar2;
    }
}

Ok, ich gebe zu, dass sich die Beispiele jetzt nicht gerade durch Kreativität auszeichen, aber solange man erkennen kann um was es geht, reicht das

Klasse C würde nach diesem Beispiel nun zusätzlich eine Methode bar2() besitzen, welche der bar()-Methode von Trait B entspricht.

Fazit

Kombiniert man die OOP und ihre Features (Vererbung, Interfaces, Namespaces, Kapselung) nun mit den Traits kann man problemlos PHP-Anwendungen implementieren, die streng dem DRY-Prinzip folgen und gleichzeitg eine konzeptionell saubere Klassen-Hierarchie besitzen.

Es gibt hierzu noch ein wenig mehr zu sagen, aber das ist erstmal das Wichtigste. Alles Weitere kann ich gerne noch in einen zweiten Artikel erklären

over and out

Ähnliche Artikel

• Schei? Encoding …
• Den Horizont erweitern: Das Zend Framework
• [PHP] Der include path

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.

Soll natürlich nicht heißen, dass ihr jetzt versucht einen OS-Kernel in JavaScript zu implementieren, nur weil ihr DIE JavaScript-Gurus seid. Alles im sinnvollen Rahmen natürlich

Ergo: Wir sollten alle etwas gelassener werden (siehe diesen wundervollen Comic mit der Schildkröte in Nils Eintrag) und uns über deutlich wichtigeres den Kopf zerbrechen als unsere Zeit damit zu verschwenden auszudiskutieren, ob die Klammer nun in die selbe Zeile gehört oder in die nächste …

Ähnliche Artikel

• Die Kunst des Programmierens
• Inspiration für Software-Entwickler
• Bürokratie und Erbsenzählerei in Projekten

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.

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.

Ähnliche Artikel

• YAP: Framework-Wahl
• Zend Framework Resourcen
• Schei? Encoding …

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.

Ähnliche Artikel

• Clean Code: Das DRY-Prinzip
• GitHub Account ausgepackt
• Schei? Encoding …

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.

DRY steht für Don't Repeat Yourself und der Name ist Programm(code): Ein Code-Fragement sollte immer nur exakt einmal vorkommen und sollte man dieses Fragment nochmal benötigen, wird es in eine Funktion/Methode ausgelagert. Leider erfordert das klassiche Copy'n'Paste weitaus weniger Aufwand und Gehirn-Aktivität, weshalb dies meist die bevorzugte Vorgehensweise ist. Gerade wenn es schnell gehen muss, spart man sich den  Aufwand eine neue Methode zu implementieren gerne.

Dieses leichtsinnige Verhalten bläht nicht nur den Code auf, wie man erst vermuten mag: Das eigentliche Problem sind die potentiellen Fehlerquellen, die man dadurch erschafft.
Stelen wir uns folgendes Szenario vor:
Wir haben ein Code-Fragment geschrieben, welches die Verbindung zu einem IMAP-Server aufbaut, eine Liste der ungelesenen E-Mails erstellt und die Verbindung wieder schließt. Diese Funktion benötigen wir an einer anderen Stelle in einer anderen Klasse nochmal, also wird das Code-Fragment einfach kopiert. Nach einiger Zeit fällt auf "Ups, hab die Zeile, mit dem close-Aufruf vergessen zu kopieren …". Diese wir dann noch schnell hinterhergeworfen und direkt haben wir den ersten Fehler: Beim Kopieren wurde das Code-Fragment verändert weil ein Teil nicht mitkopiert wurde.

Zwei Monate später, soll ein Kollege einen Bugfix an diesem Code-Fragment durchführen. Er weiß in welcher Datei und in welcher Zeile der Fehler aufgetreten ist, öffnet diese Datei, korrigiert die Zeile, schließt die Datei, führt ein commit durch und damit wars das. Und hier haben wir direkt das nächste Problem: Dieses Code-Fragment, welches gerade korrigiert wurde, kommt (mit genau dem gleichen Fehler) noch an mindestens einer weiteren Stelle im Code vor. Dieser redundante Code wurde nicht korrigiert, entsprechend unterscheiden sich diese beiden Code-Fragmente, welche exakt die gleiche Aufgabe haben, nun voneinander: es herrscht Inkonsistenz.
Der entsprechende Entwickler hätte nun also prüfen müssen, ob dieses Snippet noch öfter vorkommt und entsprechend jede Instanz mit dem Bugfix versehen müssen. Oder das ganze einem Refactoring unterziehen müssen. Beides bedeutet zusätzlicher Aufwand und zwar mehr als es gekostet hätte es direkt ordentlich zu machen.

Ein Tool, das beim Finden von doppelten Code-Fragmenten hilft, ist die so genannte Copy'n'Paste-Detection. Dies ist in den meisten Continous Integration Systemen enthalten und hilft ungemein, den Code zu verbessern.

Fazit: Doppelte Code-Fragmente, welche durch Copy'n'Paste quer im Projekt verteilt werden, erzeugen schnell Inkonsistenzen, erhöhen die Fehleranfälligkeit und sind Gift für die Wartbarkeit eines Projekts. Bei jedem Programmierer sollten also alle Alarmglocken läuten, wenn er die selbe Funktionalität mehr als einmal benötigt. Hier sollte immer eine neue Methode/Funktion implementiert werden.

Ähnliche Artikel

• Clean Code: Das KISS-Prinzip
• GitHub Account ausgepackt
• Schei? Encoding …

Was ist ein (include) path?

Das Wichtigste vorweg: was ist ein path eigentlich? Der path ist eine Variable, welche einem System eine Sammlung von Verzeichnis-Pfaden angibt. In diesen Verzeichnissen sucht das System Bibilotheken oder ausführbare Dateien. Linux beispielsweise verwaltet den  path in der PATH-Variable welche wie folgt aussieht:

[ghost@spacebox ~]$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/var/lib/gems/1.8/bin

Die Verzeichnisse werden durch einen Doppelpunkt ":" getrennt.

Gibt man in der BASH nun einen Befehl ein, durchsucht das System die Verzeichnisse, welche im PATH angegeben sind, ob eine ausführbare Datei existiert, deren Namen dem eingegeben Befehl entspricht und führt dieses script oder diese binary im Anschluss daran aus.

In PHP gibt es auch einen path: den include path. Diese Variable wird in der php.ini gesetzt und gibt die Verzeichnisse an, in denen include-Dateien zu finden sind.

Wie funktioniert der include path?

Verwendet man in seinem script nun require, require_once, include oder include_once, versucht PHP den Dateinamen in den, im include path angegebenen, Verzeichnissen zu finden. Da der erste Eintrag im include path "." ist, welcher dem aktuellen Arbeitsverzeichnis des scripts entspricht, durchsucht PHP dabei zuerst das Verzeichnis, in dem das Script ausgeführt wird.

Wie trage ich ein Verzeichnis in den include path ein?

Wir bereits erwähnt, wird der include path in der php.ini gesetzt. Die entsprechende Variable kann jederzeit um weitere Pfade erwetiert werden.

Beispiel:

include_path = ".:/usr/share/php"

wird zu:

include_path = ".:/usr/share/php:/usr/lib/php"

Des Weiteren gibt es die Möglichkeit, den include path für das aktuelle Script anzupassen. Dazu stehen die Funktionen set_include_path() und get_include_path() zur Verfügung.

Beispiel:

<?php
    
    set_include_path(get_include_path() . ':/usr/lib/php');

Mit der Funktion restore_include_path() kann der originale include path wiederhergestellt werden.

Zusätzliches know how

Auch die Funktionen fopen, file, file_get_contents und readfile verwenden den include path!

Ich hoffe, ich konnte euch das Thema path etwas näher bringen. Fragen dürfen natürlich gerne als Kommentar verfasst werden

Ähnliche Artikel

• [Linux] Apache/MySQL/Eclipse PDT unter Ubuntu einrichten
• Debian: Von Apache zu Nginx – Teil 3: PHP
• Debian: Von Apache zu Nginx – Teil 1: Vorwort

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.

Ähnliche Artikel

• Debian: Von Apache zu Nginx – Teil 1: Vorwort
• [PHP] Der include path
• Debian: Von Apache zu Nginx – Teil 4: Einen Tomcat anbinden