Webentwicklung im Alltag

Heute kam es an! Mein kostenloses Zend Framwork Poster von Mayflower. In der Firma haben wir auch schon eins hängen.
Ein super Cheat-Sheet im Posterformat mit allen wichtigen Dingen zu Zend.

Wer auch eines haben möchte, kann es sich kostenlos unter http://bit.ly/10TtZS bestellen.

Ich stand heute mal wieder vor dem Problem kaputte Dateien von einer DVD zu retten. Für so etwas gibts es natürlich tolle Tools wie Isobuster etc. Aber diese haben ein kleines Problem: sie versuchen die Dateien in sehr kleinen Blöcken zu lesen. Wenn man da mal einen Bereich von 30 – 40 MB hat der zerschossen ist, dauert das Auslesen mal locker 24h und mehr. Wenn man aber bereit ist auch etwas mehr Verlust in Kauf zu nehmen aber die Datei dafür in absehbarer Zeit da zu haben ist man aufgeschmissen.

Jedoch nicht als Programmierer. Also habe ich mir schnell ein kleines Programm in PHP geschrieben, welches eine Datei in 1 MB Blöcken kopiert und bei Fehlern diese einfach mit 0×00 Zeichen auffüllt. Ich poste es einfach mal, falls es jemand einmal brauchen kann

/**
 * Eine Datei kopieren und kaputte Sektoren überspringen
 */
 
 
define('BLOCKSIZE', 1024*1024); // 1 MB
 
 
if (count($argv) != 3) {
    showHelp();
}
else {
    copyFile($argv[1], $argv[2]);
}
 
function showHelp()
{
    echo "COPYIGNORE FROM TO\n";
}
 
function copyFile($from, $to)
{
    echo "Kopiere: $from => $to\n";
 
    if (!file_exists($from)) {
        die("$from nicht gefunden");
    }
 
    $handleFrom = fopen($from, "rb") or die ("$from konnte nicht geöffnet werden.");
    $handleTo = fopen($to, "wb") or die ("$to konnte nicht geöffnet werden.");
 
    $size = filesize($from);
    $c = 0;
    while ($c < $size) {
        $chunkSize = ($size - $c > BLOCKSIZE) ? BLOCKSIZE : $size - $c;
        $data = fread($handleFrom, $chunkSize);
        if ($data !== false) {
 
            fwrite($handleTo, $data);
 
            // Wenn wir einen Lesefehler finden mit 0x00 auffüllen und zum nächsten Block springen
            if (strlen($data) != $chunkSize) {
                fwrite($handleTo, str_pad('', ($chunkSize - strlen($data)), chr(0)));
                fseek($handleFrom, ($c+ $chunkSize)); // positionieren wo er sein sollte
                echo 'x';
            }
            else {
                echo '.';
            }
        }
        else {
            fwrite($handleTo, str_pad('', $chunkSize, chr(0)));
            echo 'x';
        }
        $c += $chunkSize;
    }
 
    fclose($handleFrom);
    fclose($handleTo);
    echo "done.\n";
}

So da nun auch Teil 3 auf PHP hates me veröffentlicht wurde (danke nochmal an Nils) hier nun auch nochmal die Veröffentlichung in meinem Blog

Nachdem ich nun an einem (zugegebenermaßen unschönen) Beispiel gezeigt habe, wie so ein Container funktioniert möchte ich den Container aus dem Symfony Framework vorstellen. Zend hatte mal einen Container im Programm (zumindest im Labratory) jedoch wurde dieser wieder verworfen. Die genauen Hintergründe sind mir leider nicht bekannt. Ansonsten gibt es noch den einen oder anderen Container für PHP, jedoch macht Symfony mir in diesem Bereich den besten Eindruck. Von der Stabilität als auch von der Geschwindigkeit her. Er ist mit einer Code-Coverage von 100% getestet (das sagt noch nicht alles aus, aber schonmal, dass man da wirklich dahinter ist!). Und ansonsten lassen sich alle Konfigurationen und Zusammenstellungen zu 100% als PHP darstellen und kompilieren. Man kann also bei Bedarf die Unterstützung eines PHP-Opcode-Caches voll ausnutzen.

Auch hier wird ein Container verwendet. Das tolle ist aber, dass sich jeder aussuchen kann wie er seinen Container konfigurieren möchte. Man kann ihn direkt als PHP programatisch beschreiben. Oder mit INI-Dateien, mit XML-Dateien oder als YAML-Dateien. Und wenn der Container geladen ist, kann man ihn auch in jedes dieser Formate abspeichern egal wie man ihn geladen hat. Man kann so also wenn man maximale Performance will in der Entwicklung mit XML arbeiten und auf dem Live-System eine gespeicherte PHP-Konfiguration deployen.

Zuerst einmal wie eine Konfiguration von Hand ohne DI aussehen würde:

$transport = new Zend_Mail_Transport_Smtp('smtp.gmail.com', array(
  'auth'     => 'login',
  'username' => 'foo',
  'password' => 'bar',
  'ssl'      => 'ssl',
  'port'     => 465,
));
 
$mailer = new Zend_Mail();
$mailer->setDefaultTransport($transport);

Und hier als Beispiel wir er im Symfony als XML konfiguriert wird:

<?xml version="1.0" ?>
 
<container xmlns="http://symfony-project.org/2.0/container">
  <parameters>
    <parameter key="mailer.username">foo</parameter>
    <parameter key="mailer.password">bar</parameter>
    <parameter key="mailer.class">Zend_Mail</parameter>
  </parameters>
  <services>
    <service id="mail.transport" class="Zend_Mail_Transport_Smtp"
shared="false">
      <argument>smtp.gmail.com</argument>
      <argument type="collection">
        <argument key="auth">login</argument>
        <argument key="username">%mailer.username%</argument>
        <argument key="password">%mailer.password%</argument>
        <argument key="ssl">ssl</argument>
        <argument key="port">465</argument>
      </argument>
    </service>
    <service id="mailer" class="%mailer.class%">
      <call method="setDefaultTransport">
        <argument type="service" id="mail.transport" />
      </call>
    </service>
  </services>
</container>

Man beachte, dass hier auch Variablenersetzung verwendet wird. So kann man den Benutzernamen auch mehrfach verwendet und dann schnell für alle Klassen ändern.

So wie wird der Spaß nun aber verwendet? Ganz einfach. Zuerst wird der Container erzeugt und mit der XML-Datei befüllt.

require_once '/PATH/TO/sfServiceContainerAutoloader.php';
sfServiceContainerAutoloader::register();
 
$sc = new sfServiceContainerBuilder();
 
$loader = new sfServiceContainerLoaderFileXml($sc);
$loader->load('/somewhere/container.xml');

Wenn man den Container nun als PHP-Datei speichern will um ihn schneller zu laden geht das wie folgt:

$dumper = new sfServiceContainerDumperPhp($sc);
$code = $dumper->dump(array('class' =>'Container'));
 
file_put_contents('/somewhere/container.php', $code);

Das ist aber nur optional.

Zugriff auf die Objekte holt man sich nun über:

$transport = $sc->getMailTransportService();
$mailer = $sc->getMailerService();

Ein ebenfalls sehr nettes Feature ist, dass man den Container auch als .dot-Datei ausgeben kann und mit dem dot-Programm in ein PNG-Bild konvertieren kann. Auf diese Weise hat man schnell einen Überblick über seine bestehende Anwendung und kann dies auch für die Dokumentation verwenden.

$dumper = new sfServiceContainerDumperGraphviz($sc);
file_put_contents('/somewhere/container.dot', $dumper->dump());

$ dot -Tpng /somewhere/container.dot > /somewhere/container.png

So damit hoffe ich nun einen guten Einblick in das Feld der DI und IoC gegeben zu haben. Und wie einfach und komfortabel man diese Pattern mit Symfony einsetzen kann.

Da ich DI und IoC auch jahrelang im Javaumfeld eingesetzt habe und es nun auch in PHP nun ausprobiert habe, kann ich sagen, dass es eine feine Sache ist. Grundsätzlich ist es ein wenig Mehraufwand. Die so oft hochgehaltene Flexibilität tritt in der Praxis aber eher nie ein. Weil bei einem Ansatz ohne DI kann man sich Stück für Stück seine Klasse aufbauen. Bei DI muss man sie konfigurieren. Bei jeder Änderung fasst man die Klasse als auch die Konfigurationsdatei an. Ebenso bekommt man damit einen Single-Point-of-Failure. Wenn die Konfigurationsdatei kaputt geht geht im Zweifel gar nix mehr. Ebenso arbeiten so alle Teammitglieder an der Konfigurationsdatei, was zu häufigeren Merges führen kann. Dies kann man jedoch durch aufteilen in mehrere Konfigurationsdateien und entsprechende Includes verringern. Bleibt noch der Aufwand, das man jedesmal zwei Dateien anfasst anstatt nur eine. Soweit zu den negativen Aspekten. Die Vorteile sind aber auch sehr deutlich. Jeder weiß wo er schauen muss wenn ein Logger oder eine Klasse konfiguriert werden soll. Kein Wühlen mehr durch viele Bootstrap und Konfig-Klassen oder gar durch die halbe Anwendung. Man hat einfach Ordnung. Man kann Anwendungsweit einen Logger schnell mal aktivieren oder deaktivieren. Man kann durch ein geschicktes Deployment konfigurativ auf einem Live-System einen Debugger deaktivieren ohne in der Entwicklung irgend etwas verändern zu müssen. In der Entwicklungsumgebung hat man also weiterhin seine Debugausgaben.

Das ganze ist also auf jeden Fall ein guter Schritt in Richtung saubere Architektur, weil es eine Menge kleiner Schweinereien die man so gerne macht unterbindet. Und aus diesem Grund gehört dieses Pattern ab einer gewissen Projektgröße eigentlich zu den Must-Haves.

Auf phpperformance.de kann man eines von zwei Jahresabos für das PHP-Magazin gewinnen. Man muss nur einen Artikel mit Trackback auf die Seite veröffentlichen. Dann hoffe ich mal, dass ich einer der glücklichen Gewinner bin

Im Blog von Guido Mühlwitz habe ich heute über das neue interessante Workdpress Plugin AntispamBee gelesen und habe es auch sofort installiert. Damit hat Akismet nun wohl ausgedient.

Wieso das ganze? Google oder Facebook stehen in der Kritik, dass sie mit sensiblen Benutzerdaten nicht sorgsam umgehen und dass Daten deutscher Benutzer auf Servern in den USA gespeichert werden, was problematisch ist, da dort nicht mehr die Gesetzte des deutschen Datenschutzes gelten. Was jedoch kaum einer beachtet, ist dass auch das WordPress Plugin Akismet alle Kommentare nach Amerika schickt, um sie dort nach Spam zu durchsuchen. Was dann dort wirklich passiert kann keiner wirklich nachprüfen und auch wenn da nichts passiert so muss das doch nicht sein.

Was macht AntispamBee anders? Es gleicht die Kommentare mit dem öffentlichen Spammer-Datenbank Project Honey Pot ab. Ebenso kann man auch Kommentare aus bestimmten Ländern ganz sperren. Wer braucht zum Beispiel Kommentare aus Russland? Oder anders: Wie hoch ist die Wahrscheinlichkeit, dass ein Kommentar aus Russland in einem kleinen deutschen Blog wirklich ein echtes Kommentar ist? – Eben!

Also dann hoffe ich, dass auch viele andere Blogger dem Beispiel folgen und AntispamBee einsetzen. =)

So das ist der erste Eintrag.

Noch ein Blog. Wozu? Die Geschichte dazu ist ganz einfach erklärt:

Vor kurzem bin ich auf die Clean Code Developer Initiative gestossen. Dabei geht es darum sich als Software-Entwickler auch weiter zu entwickeln und einen besseren Code zu erzeugen. Dafür gibt es verschiedene Ränge. Ich werde das ganze Projekt sicher noch in einem weiteren Artikel weiter beleuchten. Auf jeden Fall ist eine Regel des grünen Grades, dass man sein Wissen auch weitergeben soll. Dafür ist dieser Blog gedacht.

Ich möchte einige Erfahrungen aus meinem Projektalltag weitergeben und auch bestimmte Themen aus der PHP-Welt beleuchten oder einfach meine Gedanken dazu kund tun. Und auf diese Weise mit der Entwicklergemeinde in Kontakt treten.

Nun denn, dann bin ich mal gespannt was daraus wird