PHP-Buildsystem mit Fehlererkennung für Sublime Text 2 und 3

Im Texteditor Sublime Text können PHP-Dateien folgendermassen direkt ausgeführt werden: Über das Menu Tools – Build System – New Build System… den folgenden Inhalt in eine Datei names PHP.sublime-build speichern.

Unter Linux/Mac OS X:

{
    "cmd": ["php", "$file"],
    "file_regex": ".* in (.*\\.php) on line ([0-9]*)",
    "selector": "source.php",
}

Unter Windows (Den Pfad zum PHP-Interpreter anpasssen):

{
    "cmd": ["c:\\wamp\\bin\\php\\php5.4.12\\PHP.exe", "$file"],
    "file_regex": ".* in (.*\\.php) on line ([0-9]*)",
    "selector": "source.php",
}

Danach führt Sublime Text mit CTRL-B eine PHP-Datei aus und springt mit F4 gegebenenfalls von Fehler zu Fehler.

Debugging

Zum Debuggen gibt es das SublimeTextXDebug-Package. Allerdings habe ich es noch nicht geschafft, dieses erfolgreich zu konfigurieren. Bis es soweit ist, bleibt Eclipse PDT die Entwicklungsumgebung meiner Wahl.

Campus Bern: Symfony 2

CampusAm kommenden Dienstag (23. Oktober 2012, 1900) findet der Campus zum Thema Symfony 2 bei Liip am Kornhausplatz 14 statt.

Wir nehmen das PHP-Framework Symfony2 und Symfony2 Content Management (CMF) unter die Lupe – etwas Theorie und viel Praxis. Vortrag von Tobias Kluge und David Buchmann

Die Veranstaltung ist für alle Interessierte offen und gratis. Anfahrtsinformationen und weiteres wie immer im Campus Wiki.

Freiwillige Anmeldung auf techup.ch.

.NET-Bibliotheken aus PHP aufrufen

Bei meiner Arbeit standen wir kürzlich vor der Aufgabe, eine Windows-.NET-DLL-Funktion aus PHP anzusprechen. Interessanterweise ist die COM-Unterstützung bei allen geläufigen PHP-Versionen für Windows seit Version 4 bereits eingebaut. Auch eine .NET-Unterstützung ist vorgesehen, jedoch schlecht dokumentiert. Dieser Beitrag soll den aktuellen Stand unserer Bemühungen dokumentieren.

Voraussetzung
Nur der Zend Server Community Edition bringt im Moment ein PHP 5.3.5 mit aktivierter .NET-Unterstüzung mit: Die Extension com_dotnet ist enabled.
Weder XAMPP noch WAMP haben diese von sich aus einkompiliert.

Anforderungen an die DLL
Um eine .NET-DLL mit dieser Extension ansprechen zu können, muss sie folgende Anforderungen erfüllen:

  • Die .NET-Frameworkversion darf maximal 3.5 sein. .NET 4.0 funktioniert aktuell nicht.
  • Die DLL muss streng benannt und signiert sein (strongly named & signed)
  • Die Funktionen der DLL müssen COM accessible sein (Kann in den Assembly informations aktiviert werden.)
  • Die DLL muss sich im Global Assembly Cache/GAC befinden. Mit dem Kommandozeilenbefehl gacutil /i NAME.dll wird sie dort hin befördert.

Der letzte Punkt ist wahrscheinlich auch der Grund, warum PHP keine 4.0-DLLs schluckt: Im Gegensatz zum alten GAC unter c:/Windows/assembly befindet sich der neue GAC unter c:/Windows/Microsoft.NET/assembly. Je nach Frameworkversion landet die DLL automatisch im richtigen GAC, wird aber von PHP nur im ersteren gesucht.

Verwendung
Um eine .NET-Klasse aus einer DLL zu instanzieren, benötigt man den vollen Namen der Assembly und den kompletten Klassennamen. Ein Tool wie ILSpy hilft dabei, diesen herauszufinden und wie folgt zu verwenden:

$obj = new DOTNET('Voller.Assembly.Name, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a8425bc35256e463', 'Voller.Assembly.Name.Klassenname');
 
echo $obj->MeineMethode();

Da mit dieser Extension immer eine Klasse instanziert wird, sind dementsprechend nur Klassenmethoden aufrufbar. Statische Klassen und Methoden funktionieren nicht und erzeugen nur kryptische Fehlermeldungen.

Ich hoffe, mit diesem Artikel anderen Benutzern dieser exotischen Kombination von Systemen etwas weitergeholfen zu haben. Kommentare und Anmerkungen sind herzlich willkommen.

Xdebug unter OS X Lion installieren

Ich brachte unter dem neuen Mac OS X Lion das Programm phpize nicht zum laufen und konnte deshalb meine Lieblings-PHP-Extension Xdebug nach dem Update auf Lion nicht frisch installieren. Glücklicherweise fand ich im Verzeichnis /usr/lib/php/extensions/no-debug-non-zts-20090626 noch die Datei xdebug.so von Snow Leopard.

Um diese Extension zu aktivieren, erstellt man mit Rootrechten im Verzeichnis /etc eine neue Datei php.ini und schreibt folgendes hinein:


zend_extension = /usr/lib/php/extensions/no-debug-non-zts-20090626/xdebug.so
xdebug.remote_enable = On

; Und wenn wir schon mal hier sind...
error_reporting = E_ALL | E_STRICT
date.timezone = Europe/Zurich

Nicht vergessen, den Webserver danach neu zu starten.

Wochenendprojekt eskaliert

Es regnet. Die Wohnung sieht akzeptabel aus. Und ich habe eine neue Idee für eine Webseite. Und das eskaliert dann folgendermassen:

  • Idee!
  • Hmm, wenn ich alles so machen will, dann könnte ich gleich mal Backbone.js ausprobieren.
  • Hmm, ist kompliziert. Egal, ich fange einfach mal an.
  • Hmm, eine neue Version von Eclipse PDT ist erschienen, ich installier erst mal.
  • Hmm, eine neue Version vom Framework ist erschienen, ich aktualisiere mal.
  • Hmm, ich habe noch nicht genug Erfahrung damit, um mein NoSQL-Modul für MySQL zu bauen, vielleicht fange ich mal mit einem einfacheren Projekt an.
  • Hmm, dafür könnte ich meine HTML-Tabellenbibliothek benutzen, wenn sie fertig wäre.
  • Hmm, zuerst mal eine Git-Einführung lesen, ich erinnere mich an gar nichts mehr.
  • Was denn, der Tag ist schon vorbei?

Upgrade von Eclipse PDT 2.1 zu 2.2: Breakpoints für XDebug löschen

Seit ich meinen Arbeits-PC auf Windows 7 aufgerüstet hatte und dabei alle Software auf den neuesten Stand gebracht habe, funktionierte XDebug, der Debugger für PHP, unter Eclipse PDT 2.2 (Helios) nicht mehr. Zahlreiche verschiedene Versionskombinationen von Apache, PHP und XDebug wollten schlichtwegs nicht miteinander kommunizieren. Und das Entwickeln ohne Debugger macht schlichtwegs weniger Spass.

Heute stolperte ich zufällig über die Lösung: Es lag nicht an den Serverkomponenten, sondern an einem Clientproblem: Wegen eines Eclipse-Bugs stören die aus PDT 2.1 übernommenen Breakpoints den Debugger. Nachdem ich alle Breakpoints gelöscht hatte, funktionierte XDebug auch unter PDT 2.2 wieder einwandfrei.

Das Leben ist ohne dauerndes var_dumpen irgendwie schöner.

Ich glaube, ich habe soeben ein OSS-Projekt zerstört

Vielleicht nicht zerstört, aber dessen Reputation stark beschädigt.

Vor einigen Monaten bekam ich den Auftrag, einen Onlineladen einzurichten. Da wir vorwiegend PHP-Webapplikationen betreiben, sah ich mich nach einer Open Source-PHP-Lösung um. Der Platzhirsch Magento ist Overkill, das klassische osCommerce sieht langweilig aus, andere Lösungen kosten ein Vermögen oder haben ein komisches Preissystem.

Übrig blieb das nett aussehende OpenCart. Du kannst dir unsere Instanz unter http://www.meteo-shop.ch/ ansehen.

Ah, wie ich vom Design und vom Backend geblendet wurde: Der Code hat einige gravierende Schwächen in seiner Objekt-orientierten Architektur. Er funktioniert zwar, macht aber den Entwicklern von Erweiterungen (In meinem Fall eine Saferpay- und eine Postcard-Zahlungslösung) das Leben schwer.

Open Source-Projekte leben vom Feedback und Austauch, also poste ich im Community-Forum von OpenCart einen längeren Artikel mit Verbesserungsvorschlägen, sowie in einem anderen Thread eine Vorlage für weitere Erweiterungen. Ich bin der Meinung, dass ich dabei differenziert und sachlich argumentiert habe, sowie meinen Willen zur Mitarbeit aufzeigte.

Die Antwort des Entwicklers: Idiot. Plus noch ein paar Beleidigungen und Vorwürfe mehr.

Damit war das Projekt für mich gestorben und diese Geschichte eigentlich abgeschlossen.

Einen Tag später, allerdings, hat jemand einen Linke auf den Thread auf der populären Diskussionsseite auf Reddit gepostet veröffentlicht, inklusive Screenshot des Dialoges. Mit der Konsequenz, dass das Forum dem Ansturm nicht standhielt und offline gehen musste. Und dass die Reputation des OpenCart-Projektes jetzt ziemlich angeschlagen ist…

Tut mir leid, das war nicht Absicht. Aber etwas Schadenfreude verspüre ich trotzdem: Die Antwort des Entwicklers war völlig unqualifiziert und das negative Karma hat zu Recht eingeschlagen.

mtChart – Graphenbibliothek für PHP

mtChart LogoNicht ohne Stolz präsentiere ich die aktuelle Version meiner Graphenbibliothek: mtChart V0.1.2 (GPL V3).

Jetzt fühle ich mich auch langsam revolutionär: Nach Jahren als Anwender und Nutzniesser von freier Software ist das das erste Mal dass ich mich an einem komplett eigenen Projekt versuche. Wobei ich hier auch nur auf bereits getane Arbeit aufbaue: mtChart ist eine Abspaltung (Ein sogenannter Fork) von pChart. Dank der offenen Lizenz konnte ich den Code dieses ins Stocken geratene Projekt einfach übernehmen und meinen Bedürfnissen anpassen.

Greif zu und geniesse.

Temperatur Meteotest Dachstation
Beispiel: Lineplot aktueller Temperaturdaten (Dachstation Meteotest, Bern)