UPDATE: Noch 13 übrig.

UPDATE: Wie es scheint bekommt nun jeder der schon bei Google Wave registriert ist weitere acht Einladungen. Somit komme ich jetzt auf insgesamt 14 Einladungen, die noch verschickt werden können.

Ich habe vor kurzem eine Google Wave Einladung bekommen. Und nun, da ich die meisten Einladungen an Arbeitskollegen und Freunde verteilt habe und immer noch neun Einladungen übrig sind, dacht ich mir “Machste mal was nobles!”

Da ich persönlich ja gar nicht so auf Gewinnspiele oder Quizfragen etc. stehe mach ich es ganz kurz und schmerzlos: Die ersten neun Leute die diesen Artikel finden und einen Kommentar drunter schreiben bekommen eine Einladung. Die eMail Adresse ist dabei Pflicht, ohne die kann ich euch keine Einladung schicken. Ein Google Konto kann auch nach der Einladung erstellt werden. Aber früher oder später braucht man ein solches.

Google empfiehlt folgende Browser: Internet Explorer 6, Firefox 3.5, Safari 4 und Google Chrome.
Ne scherz, der IE kommt auf sowas natürlich gar nicht klar, weder Version 6 noch 7 noch 8, nur die anderen drei Browser werden von Google empfohlen. Opera (10.01) hat jedoch Probleme mit der Darstellung von Wave. Ich empfehle Iron, die Google-lose Version von Chrome. Warum? Wegen der schnellen JavaScript Engine und der Google-Losigkeit. Das ist kein gelaber, ich selbst hab mir extra Iron installiert, da Firefox zumindest bei der JS Ausführung ein wenig zu langsam ist. Vielleicht hilft auch ein schneller PC, das kann ich mangels letzterem nicht beurteilen.

Aber wenn man zu zweit, jeder mit entsprechender Performance mitttels Wave chattet kann man, und das hab ich erst nicht geglaubt, tatsächlich sehen wie der andere tippt. Vielleicht sollte ich es nochmal erwähnen: Das ist eine Preview Version. Oft bleibt bei alles hängen, Nachrichten kommen erst nach einer gewissen Zeit an, etc.

Nun denn, lasst die Spiele beginnen!

Als ich mir die Dokumentation zu Zend_Acl durchlas war mein erster Gedanke “Mein Gott, ich soll bei jedem Seiten Aufruf die gesamte ACL Struktur laden? Das kann doch nicht euer Ernst sein.”

Natürlich nicht. Erneut Google zur Hilfe gerufen fand ich schnell einen dynamischen ACL Loader im Wiki des Frameworks. Die Lösung! Funktioniert auch super, doch zickte es ein wenig mit Objekte als Resource/Role IDs, selbst dann wenn diese das Zend_Acl_Resource_Interface bzw. das Zend_Acl_Role_Interface implementierten. Also überschrieb ich die entsprechende Methode einfach und fügte so die fehlenden gewünschten Funktionen hinzu.

Blödsinn! Warum? Ganz einfach: Ich hatte sowieso schon eine eigene Version von Zend_Acl::isAllowed() geschrieben (nicht überschrieben, meine Variante gehört zu einem Plugin das für ACL zuständig ist und nicht von Zend_Acl erbt), welche wiederum Zend_Acl::isAllowed() benutzt um festzustellen, ob Peter nun Zugriff hat oder nicht (Ein Name, den ich ständig als Platzhalter benutze, man kann ihn einfach so schnell tippen. Und nein, meine Passwörter enthalten diesen Namen nicht ).

Jedenfalls lade ich nun innerhalb meiner Variante von Zend_Acl::isAllowed() zuerst alle Rollen und Resourcen nach denen gefragt ist (selbstverständlich mit einer Überprüfung ob diese nicht vielleicht schon geladen sind), besorge mir die Berechtigungsdaten aus der Datenbank, verwende entsprechend Zend_Acl::allow() bzw. -::deny() um die Berechtigungen festzulegen und am Schluß Zend_Acl::isAllowed() um nun endlich herauszubekommen wie es um Peters Berechtigungen bestellt ist. Das ACL Objekt sollte statisch deklariert werden um sicherzugehen, dass das Rad nicht ständig neu erfunden wird.

admin.resources.layout.layoutPath = path/to/layout

möglich (wobei “admin” hier der Modulname ist). Doch wie so häufig brachte der Druck auf F5 Ernüchterung, es funktioniert so nicht.

Eine kurze Google Suche ergab, dass man sich einfach ein Front Controller Plugin schreiben kann, das vor dem Dispatchen abhängig vom Modulnamen die entsprechende layout.phtml lädt. Eigentlich genau das was ich wollte, aber es musste doch einen Weg geben ohne zusätzlichen Code dasselbe Ziel zu erreichen.

Also gab ich mich nicht mit diesem Plugin zufrieden und probierte herum, bis mir eine Fehlermeldung die Augen öffnete. Und zwar sucht Zend unter anderem auch im /scripts/views/ Unterverzeichnis eines jeden Moduls nach einer layout.phtml. Also brauchte ich nur die “resources.layout.*” Einstellungen in der Konfiguration entfernen und eine layout.phtml in den eben genannten Verzeichnissen erstellen und – voilà – schon benutzt jedes Modul sein eigenes Layout; krass, oder?

Es ist ein twitter Widget!

Schande über mich, dass ich es nicht schon eher installiert hab.

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…