e ? ?

Es handelt sich nämlich hierbei um das sog. “estimated e” auf Verpackungen. Dieses ist ein Sonderzeichen, welches Windows, Mac und Linux eigentlich unbekannt ist und sich in Word und HTML aber herbei zaubern lässt. Des Rätsels Lösung lautet Unicode: Hier hat das Estimated Symbol die Position 8494 bzw. U+212e und dementsprechend die HTML-Entität ℮ bzw. ℮.

Wenn jetzt dieses “magische e” in einem HTML-Formular eingegeben wird und das Formular in PHP weiterverarbeitet wird, hat man ein Problem. Denn wie ich nach langem Suchen herausfinden konnte, wird dieses magische e bereits vom Browser in die numerische HTML-Entität umgewandelt, bevor der Request an den Server übermittelt wird. Herausfinden konnte ich das im Übrigen mit der genialen Firefox-Erweiterung “Live HTTP-Headers“.

Zurück zu meinem Problem: Es wurde also in einem HTML-Formular dieses böse ? eingegeben und diese Eingabe sollte später in einer E-Mail-Benachrichtigung ihren Platz finden. Da bereits der Browser die Umwandlung in eine HTML-Entität durchführte, musste diese nun PHP-seitig wieder rückgängig gemacht werden. Leichter gesagt als getan. Denn eine String-Konvertierung mittels mb_convert_encoding führte nicht zum Ziel. Egal, ob ich nach ISO-8859-1, ISO-8859-15, Windows-1252 oder auch UTF-8 konvertierte, das Ergebnis blieb das gleiche: Aus ? wurde ?

Nach Rücksprache mit dem Kunden habe ich dann eines gemacht:

$msg = str_replace('℮','e',$msg);

Da das ? kaum von einem normalen e zu unterscheiden ist, steht zukünftig ein normales e in den Benachrichtigungs-Mails geschrieben.

Die letztendliche Implementierung hat nicht lange gedauert. Die Suche, warum sich das ? so seltsam verhält, allerdings über zwei Stunden

Wer eine günstige Übernachtungsmöglichkeit sucht, sollte die Jugendherberge in Köln-Deutz ins Auge fassen. Diese liegt nämlich schräg gegenüber vom Veranstaltungsort.

Ich brauche mich zum Glück nicht um ein Zimmer kümmern, da ich nur eine gute Viertelstunde zu Fuss bis zum Köln Triangel brauche

Wie auf der Konferenz-Website zu lesen ist, findet die Veranstaltung im Köln Triangle (was für ein bescheuerter Name für den Turm) statt und kostet 80 Euro. Neben der Konferenz gibt es auch einen Einsteiger-Workshop. Abgerundet wird der Tag durch eine Party am Abend, an der auch das 10-jährige Jubiläum von Interlusions gefeiert wird. Und da der 4. September ein Freitag ist, kann die Party auch ruhig etwas länger dauern

Via http://www.symfony-framework.nl/nieuws/110

Da es das Jobeet-Tutorial sowohl in einer Ausgabe für Propel und Doctrine als OR-Mapper gibt, sind daher auch beide Tutorials als in verschiedenen PDF-Dateien (Propel-Ausgabe / Doctrine-Ausgabe) verfügbar.

Auf der Dokumentations-Hauptseite sind auch die Links zu finden, um die beiden Ausgaben auch als gedrucktes Werk (Doctrine-Ausgabe / Propel-Ausgabe) zu bestellen. Dort finden sich aber auch weitere interessante Dokus, wie z.B. “What’s new?”, welche die Unterschiede zwischen Symfony 1.0 und 1.2 darstellt.

via Symfony Project Blog

Die Symfony-Gruppe bei Xing

Es wäre doch vielleicht schön, wenn diese Gruppe ein wenig lebendiger wird. Im deutschsprachigen Symfony-Forum ist ja anscheinend auch nicht so viel los und in der deutschen Symfony-Google-Group ist auch eher tote Hose.

1. Prozeduraler Code sei schneller als Objektorientierter Code – hier wird alzu oft Äpfel mit Birnen verglichen
2. Das Backend sei wichtiger als das Frontend – liegt wohl oftmals an der Abneigung / Geringschätzung von HTML / CSS / JavaScript durch “richtige” Entwickler
3. Grafik-Designer sind auch gute Interface-Designer – beide sind zwar Designer, aber der erstere will Aufmerksamkeit erreichen und der zweite soll den Benutezr glücklich machen
4. Es gibt DIE überlegene Programmiersprache – es gibt nicht die eine seelig machende Sprache
5. XML sei schneller bzw. produziere geringeren Overhead als Datenbanken (bzw. DBMS) – auch hier wird nicht sauber verglichen

Der Artikel ist sehr interessant und ich kann Eran in allen fünf Punkten nur beipflichten.

Aus PHP heraus rufen wir ImageMagick sowohl unter Windows als auch unter Linux per exec() auf. Nicht gerade besonders elegant, aber wirkungsvoll Vor allem ist das Ansprechen per exec() in einer Objekt-orientierten Umgebung alles andere als intuitiv. (Wir setzen bei besagtem Projekt Symfony als Framework ein). So haben wir uns also eine Adapter-Klasse geschrieben, die den Zugriff auf ImageMagick hübsch objektorientiert verpackt.

Unter Linux bereitet diese Art der Einbindung von ImageMagick uns keinerlei Kopfschmerzen. ImageMagick ist ebenso wie GhostScript auf den meisten Linux-Servern schon installiert oder mit geringem Aufwand über die Distributions-eigene Paketverwaltung schnell nachinstalliert. Auch die Performance lässt sich sehen. Und unter Windows? Die Installation von IM und GS klappt mit den grafischen Installern noch ohne Probleme. Aber die Performance von ImageMagick lässt per PHP und exec() doch ein wenig zu wünschen übrig (für das Rendern einer Vorschau benötigt unsere Applikation die doppelte bis dreifache Zeit unter Windows – trotz schnellerem Prozessor und mehr Hauptspeicher). Man merkt halt schon, für welche Plattform sowohl IM als auch GS entwickelt wurden.

Als native Schnittstelle gibt es schon seit Jahren das PECL-Paket Imagick. Es wurde jedoch seit 2004 nicht mehr weiter entwickelt. Erst im Frühjahr dieses Jahres haben sich wieder zwei Entwickler der Weiter-Entwicklung angenommen. Mittlerweile ist Imagick auch als Version 2.0.x stabil. Die 2er-Version wurde konsequent auf PHP5 und Oojekt-Orientierte Programmierung ausgelegt, so dass es keine Probleme bereiten sollte, Imagick in vorhandenen Projekten einzusetzen. Einziges Problem unter Windows ist jedoch, das PECL-Pakete nicht in PHP, sondern in C implementiert sind und man deshalb entweder vorkompilierte DLLs benötigt, oder selber den Compiler anwerfen muss. Da ich nicht über Microsoft Visual Studio verfüge und auch sonst ein wenig mit C auf Kriegsfuß stehe, blieb nur noch Variante eins übrig.

Der Finne Mikko Koppanen, seines Zeichens einer der beiden Entwickler von Imagick, hat aber über sein durchaus lesenwertes Blog die vorkompilierten DLLs für Windows bereitsgestellt. Die passende DLL herunter zu laden und in mein PHP-Extensions-Verzeichnis zu speichern war noch nicht wirklich schwierig. Aber den Kram ans Laufen zu bekommen schon. Das alte HowTo, auf welches auch Mikko hingewiesen hat, war nur ansatzweise hilfreich. Vor allem hat es irgendwie das Layout zerschossen und ich kann daher nur jedem nahe legen, der sich dieses HowTo durchlesen möchte und Firefox mit installierter Web-Developer-Toolbar zur Verfügung hat, die Funktion zum Deaktivieren von Inline-Styles zu nutzen. Andernfalls lassen sich manche Quotes nicht lesen…

Nach Studium des o.g. HowTos habe ich mich dann an die Arbeit gemacht, Imagick auf meinem Notebook (Windows XP Pro, Apache 2.2.4 als Service, PHP 5.2.3 als CGI) ans fliegen zu bekommen:

• Die heruntergeladene DLL php_imagick_dyn-Q8.dll landet im Extensions-Verzeichnis meiner PHP-Installation (bei mir C:\php5\ext)
• Die DLL muss natürlich in der php.ini aktiviert werden:
  extension=php_imagick_dyn-Q8.dll dem Block mit den Erweiterungen hinzufügen
• Eine info.php mit folgendem Inhalt ins htdocs-Verzeichnis gelegt:
  <?php
phpinfo();
?>
  und im Browser aufgerufen.
• Und was ist passiert? Nichts! Kein Imagick wird mir unter den aktivierten PHP-Erweiterungen angezeigt. Wenn ich PHP auf der Kommando-Zeile anspreche, dann bekomme ich die Fehlermeldung angezeigt, dass es nicht möglich wäre die besagte DLL zu laden.
• Dem obigen Howto konnte ich entnehmen, dass der Pfad zu ImageMagick-Installation der PATH-Umgebungsvariable von Windows hinzuzufügen sei. Gesagt, getan, aber der Kram will immer noch nicht.
• Der Vorschlag mit dem Setzen von
  SetEnv MAGICK_HOME="C:/Programme/ImageMagick"
  in der httpd.conf des Apache will auch nicht so richtig funktionieren.
• Letztendlich hat es dann damit geklappt, indem ich die Umgebungsvariable MAGICK_HOME mit dem Wert C:\Programme\ImageMagick Windows beigebracht habe.
• Aber erst nach einem Windows-typischen Neustart konnte ich endlich das Ergebnis meiner Bemühungen nach Aufruf der info.php im Browser bewundern:
  

  

Nachdem jetzt alles läuft, wollte ich doch mal ausprobieren, ob der Performance-Zuwachs tatsächlich so toll ist, wie es Mikko als Ergebnis seines “Micro-Benchmark” in seinem Blog gepostet hat. Das Ergebnis war doch etwas ernüchternd: Teilweise hat es mit Imagick doppelt so lange gedauert, als über den Aufruf von convert via exec().

Ich werde mal ein wenig an ein paar Stellschrauben drehen (z.B. wie sich das Einstellen der “Ressource Limitations” auswirkt) und was ich noch mit den ganzen anderen Parametern anstellen kann, die im Manual zu Imagick genannt, aber kaum bzw. nicht weiter beschrieben sind.

Auch werde ich demnächst ein wenig Code und Beispiel-Dateien posten, mit denen meine Versuche nachvollzogen werden können.