Dieses Mal ist es phpbench.com. Chris Vincent hat dort viele PHP Code Snippets einem Geschwindigkeits Vergleich unterzogen. Es sind oft nur Millisekunden die den Unterschied machen, aber auch Kleinvieh macht Mist

Ich werde jedenfalls versuchen mich an einige Regeln zu halten, um auch die letzte Millisekunde rauszuholen.

Aptanas “Smartsync”

Eigentlich die perfekte Lösung: Ein Klick, und alles im www-root wird auf den neuesten Stand gebracht. Dummerweise klappt das nicht ganz so einfach. Meistens lädt es nahezu alle Dateien neu hoch, auch die, die eigentlich noch aktuell sind. Das führt zu nervenden Wartezeiten. Ein Ticket im Aptana Support ist bereits erstellt.

Ich will Aptana nicht schlecht reden, im Gegenteil. Aptana ist hervorragend, es hat eine sehr gute Unterstützung für PHP (per Plugin, lass dich davon nicht abschrecken!), HTML, JavaScript, CSS und viele mehr. Sogar eine iPhone Testumgebung wird (ebenfalls per Plugin) angeboten. Sieh am besten selbst auf http://www.aptana.com vorbei, kann ich nur empfehlen.

Subversion

Ich hab irgendwo im Internet schon ein Mal davon gelesen, dass man ein Versionskontrollsystem wie Subversion gut dazu benutzen kann, direkt durch ein Update-Befehl die neusten Dateien aus dem Repository in den www-root zu laden. So ein System berücksichtigt dabei automatisch, ob die Dateien überhaupt geändert wurden und entscheidet dementsprechend ob ein Upload einer Datei vorgenommen werden soll oder nicht. Da ich sowieso schon immer so ein System bei mir installieren wollte, habe ich die Gelegenheit genutzt und es einfach getan.

Das Problem und dessen Lösung

Nach der Installation eines SVN Servers konnte es losgehen (ich benutze CollabNet Subversion). Zuerst müssen zwei Batchfiles angelegt werden, eins auf dem Arbeitscomputer, eins auf dem Server. Das erste sorgt für das Commit ins Repository, das zweite für ein SVN-update vom Repo in den www-root (Nähere Informationen zur Installation und Benutzung von SVN entnimmst du am besten dem SVN Book).

Nun müsste man erst das Commit-Script auf dem einen, und dann das Update-Script auf dem anderen Computer ausführen. Und hier ist das Problem: Das ist mir schlicht weg zu umständlich. Der Haken ist, dass das Update-Script auf dem Server ausgeführt werden muss, und nicht über eine Freigabe auf meinem Computer. Jedesmal mit einer Remote Software auf den Server zugreifen um das Script aufzuführen macht es nicht besser.

Theoretisch besteht die Lösung aus einem DOS Befehl, der ein Skript ferngesteuert auf einem anderen Computer ausführt. So einen Befehl habe ich in DOS selbst leider nicht gefunden. Also habe ich mir das Internet zur Hilfe gerufen. Gefunden habe ich PsTools, genauer gesagt “psexec“, was sich unter diesen Tools befindet.

Dieses Tool macht genau das was ich brauche. Es führt ein Batchfile ferngesteuert auf einem anderen Computer aus. In meinem Fall wäre dies das Update-Script auf meinem heimischen Server.

Unter Verwendung dieses Tools war es mir nun möglich, das “Megaupdatebatchscript” zu schreiben, mit dessen Hilfe sich durch einen Klick der www-root aktualisiert. Das Megaupdatebatchscript enthält also nun einmal den Commit Befehl (ich benutze hier TortoiseSVN, um bei jedem Commit auch komfortabel einen Kommentar zu den Änderungen schreiben zu können) und einen Aufruf von “psexec”, welcher für die Ausführung des sich auf dem Server befindlichem Batchfiles mit dem SVN-update Befehl sorgt.

Das sieht bei mir dann so aus:

TortoiseProc.exe /command:commit /path:”C:/aptana_workspaces/patrick/patrickburke.de/” /closeonend:1

psexec -u “volker racho” -p “” \\volker c:\megaupdatebatchscript.cmd

Nähere Informationen zur ersten Zeile gibt es in den Docs von TortoiseSVN. Wie man psexec benutzt ist auf der Projekt Seite erklärt.

Die Geschwindigkeit

Schneller geworden ist es aber unterm Strich doch nicht. Ich habe nämlich vergessen zu berücksichtigen, dass psexec schließlich auch eine Verbindung zum Server braucht, was irgendwie ziemlich lange dauert.

Aber hey, jetzt hab ich ein Versionskontrollsystem installiert.

Mir ist gerade eine Idee gekommen, die ich auf digg.com noch nicht gesehen hab.

Wie wäre es, wenn User genauso wie Kommentare digged bzw. buried werden könnten. Jeder Benutzer könnte einen eigenen Grenzwert festlegen, ob die Submissions bei ihm angezeigt wird oder nicht, abhängig davon wie oft der Submitter digged oder buried wurde. Eben wie bei den Kommentaren. Eine Benutzer Kontrolle in einem vollkommen Benutzer-basierendem System.

Das funktioniert zwar nur solange es weniger Poweruser als “normale” User gibt, aber davon ist auszugehen, da diese Submission mehr als 19 tausend diggs bekommen hat.

Wenn ihr das für total bescheuert findet würde ich das gerne wissen

Cheers,

Patrick

Ihr könnt meine Posts jetzt auch in Englisch genießen!

Okay, die meisten.

Cheers,

Patrick

UPDATE: Okay, lag wohl doch nicht an WordPress. Scheinbar hatte FileZilla keine Lust ALLE Dateien zu übertragen…

Valerio Proietti, Gründer von MooTools, hat gestern im Blog des Frameworks auf den Ajaxian Artikel zur Integration von John Resigs Selector Engine Sizzle in Dojo geantwortet. Genau genommen ist es eine Reaktion auf eine Mail von Resig an einen der MooTools Entwickler. Resig hatte in der Mail zum Ausdruck gebracht, dass er sich freuen würde, wenn MooTools sich der Sizzle-Sache anschließen würde, also wenn man die Hauseigene Selector Engine mit der von John Resig ersetzen würde.

Als ich zurerst von dem Projekt Sizzle hörte, konnte ich es kaum abwarten bis es endlich in MooTools Einzug hält. Doch Valerio hat mit seinem Artikel meine Meinung geändert. Und zwar absolut.

Beispielsweise führt er als Argument an, dass sich so eine Entwicklung eher negativ auf den “Markt” der JavaScript Frameworks auswirken würde. Wenn nun jeder anfangen würde, Teile seines Frameworks auszulagern, würde es irgendwann kaum noch Unterschiede zwischen ihnen geben. So wäre MooTools vielleicht nur noch ein Name, ein jQuery oder ein Dojo das MooTools heißt. Und da hat der Römer gar nicht mal so Unrecht würde ich sagen.

Jetzt aber mal zum technischen Teil.

Valerio hat in dem Artikel außerdem ganz klar zwischen Frameworks und Engines unterschieden. Dabei führt er an, dass man sie nicht mittels SlickSpeed vergleichen könne. Z.B. berücksichtigt MooTools ein geändertes DOM nach dem bereits Queries ausgeführt wurden, Sizzle hingegen legt einen Cache an, der das Ergebnis in SlickSpeed durchschnittlich fünf mal schneller erscheinen läßt.

Der MooTools Gründer wollte aber einen fairen Vergleich zwischen MooTools und Sizzle. Zu diesem Zweck hat er sich eine MooTools Version erstellt, die vom Prinzip her wie Sizzle funktioniert. Mit querySelectorAll und keiner Erweiterung der Ergebnis Nodes. Fair eben. Engine vs. Engine, nicht Framework vs. Engine. Und da hat die MooTools Engine klar die Nase vorn, in allen Browsern.

Lest euch auch den Artikel von Valerio durch, ist ganz interessant.

Spontan fühlte ich mich dazu verpflichtet, diesen Link weiter zu verbreiten; fühlte mich dazu verpflichtet, dem Unrecht im Webdesign entgegenzutreten und dem Ende des Martyriums für Firefox, Opera, Safari und deren standardphilen Freunde einen Schritt näher zu kommen.

UPDATE: Guckt euch den Quellcode an; der beste Chuck Norris Spruch den ich je gesehen hab…

Eigentlich bin ich kein allzu großer Fan von PEAR. Nicht zuletzt auch weil ich es schöner finde, wenn man sein Zeug selbst geschrieben hat. Allerdings hatte ich doch Schwierigkeiten etwas angemessenes zu schreiben und dachte, dass es sich jetzt noch lohnen würde umzusteigen. Gedacht getan hab ich PEAR::Config heruntergeladen und versucht es in meine Scripte einzubinden.

Ihr müsst wissen: Ich hab mir zwar einige Sachen zum Thema PEAR durchgelesen, doch selbst ausprobiert hab ich es noch nie. Zu den Sachen die ich gelesen habe zählt übrigens nicht, wie man PEAR in seinen Scripten nutzt.

Ich habe dann die Config Dateien auf meinen Lokalen Server hochgeladen und in die index.php eingebunden. Beim Ausführen der index.php hat sich dann die Config Klasse beschwert, es würde eine bestimmte Klasse oder eine Datei (ich weiß schon gar nicht mehr was…) fehlen. Zu diesem Zeitpunkt wußte ich noch nicht, dass XAMPP, das auf meinem Server läuft, bereits PEAR::Config vorinstalliert hat. Ich bin dann “kurz” das Hauptverzeichnis durchgegangen und hab geguckt, wo sich das Ding befinden könnte. Die Suche erweiterte sich dann von ganz alleine auf das gesamte XAMPP Verzeichnis.

Fündig geworden bin ich nicht direkt, aber ich habe den Ordner “pear” im Verzeichnis von XAMPP gefunden. Dort war wiederum ein Ordner namens “config”. Und in diesem Ordner, man glaubt es kaum, waren die gleichen Dateien wie die, die ich selbst Heruntergeladen hatte. Oder jedenfalls Dateien mit dem gleichen Namen.

Ich hatte herausgefunden, dass XAMPP bereits PEAR::Config vorinstalliert hat.

Nun bin ich einfach mal davon ausgegangen, dass dieses ominöse “pear” Verzeichnis Teil des include path von PHP ist, und hab ganz stumpf über “include ‘Config.php’” versucht die Config Klasse einzubinden. Es funktionierte nicht. Weiß der Herrgott warum. War mir auch scheißegal.

In Rage über diesen Mist kopierte ich dann einfach mal ein paar Sachen hin und her, bis es funktionierte (Warum ich jetzt schon in Rage war? Weil ich für das Einbinden einige Minuten eingeplant hatte, ich befasste mich nun allerdings schon den gesamten Nachmittag damit, Anleitungen durchzugehen und Tutorials zu suchen, die irgendwie doch alle nicht funktionierten…). Jetzt musste ich nur noch die Bedienung der Klasse meistern, aber da schreib ich ein anderes Mal drüber, is’ auch so’ne story…

Nun kam der Tag an dem ich mir bei HostEurope diesen Webspace bestellte. Nach einer kleinen Wartezeit konnte ich dann auch auf den FTP Server zugreifen und meine bereits geschriebenen Scripte hochladen.

Ich habe mir dabei nur geringfügige Gedanken bezüglich der Verfügbarkeit von PEAR gemacht, zu groß war die Wut – man könnte sagen es hat bleibende Schäden, ja ein Trauma hinterlassen – als das ich da noch eine Sekunde drüber nachdenken wollte.

Naja, PEAR::Config ist nicht auf den HostEurope Servern installiert. Versuche, PEAR über den Webinstaller nachzuinstallieren (2) schlugen fehl. An diesem Punkt habe ich überlegt, ob ich nicht einfach nur zu blöd für diesen ganzen Birnen krempel bin. Bei der Suche nach einer Alternative fiel mir dann die Konfigurations Klasse von Smarty quasi in den Schoss (Die nennt sich Config_File, ich hab hier eine kleine Dokumentation gefunden). Die ist allerdings noch PHP4 und nur auf das Auslesen von Konfigurationsdateien ausgelegt, ich hätte also den Teil selbst noch dazu schreiben müssen, der die Dateien schreibt.

Jetzt bin ich wieder da, wo ich anfing. Beim Schreiben einer eigenen kleinen Config-Klasse, dieses Mal auf JSON Basis. Vielleicht bleib ich auch einfach bei MySQL…

Was ich nicht ganz verstehe ist, dass die PEAR Leute doch wollen, dass man deren Packages/Klassen benutzt (davon ist ja auszugehen, sonst würden sie sich die Mühe nicht erst machen, würde ich sagen ), aber warum machen die es einem dann so schwer? Ich sage nicht, dass mir keine Fehler unterlaufen sind, aber ich denke die Installation von PEAR ist doch ein wenig sehr umständlich.

Warum nicht einfach wie bei Smarty: Runterladen, Einbinden, Hochladen und es läuft. Und wenn ein Package von einem anderen Abhängig ist, wird es dem Benutzer mitgeteilt und er lädt die auch herunter. Und wenn es am Ende zehn Packages sind, Hauptsache man kann sie über ganz simples Einbinden zum Laufen bringen. Finde ich jedenfalls.