Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03548.jsonl.gz/375

Das zweite Packet aus dem aktuellen Refactoring ist cstuder/parse-hydrodaten.
Es decodiert Daten und Metadaten aus dem Fliessgewässermesssnetz Hydrodaten des Bundesamtes für Umwelt BAFU.
Auch die Daten des BAFU sind auf Opendata.swiss publiziert.
Im Rahmen eines Code-Refactoring (auch Refaktorisierung, Refaktorierung oder Restrukturierung) habe ich nach Jahrzehnten von PHP-Coden mein erstes Composer-Package geschrieben und publiziert: cstuder/parse-swissmetnet.
Besonders Freude habe ich an den neuen GitHub-Actions welche die beiliegenden Unittests bei jedem Push automatisch durchführen.
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.
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.
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:
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=<ip-pii>, 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.
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.
Es regnet. Die Wohnung sieht akzeptabel aus. Und ich habe eine neue Idee für eine Webseite. Und das eskaliert dann folgendermassen:
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.
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.
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.