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!
chatten, chrome, firefox, free accounts, free invitations, google, google wave, iron, wave, web2
Wieder zum Zend Framework.
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.
acl, dynamic acl, zend, zend framework, zend_acl, zion_acl
Heute stand ich vor dem Problem, jedem der Module einer Zend Application eine eigene layout.phtml zuweisen zu müssen. Zuerst dachte ich, es sei ganz einfach über eine application.ini Zeile á la
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?
layout, per module, zend framework
Hab endlich ein Design gefunden mit dem ich Leben kann. Aber so richtig zufrieden bin ich immer noch nicht. Es heißt übrigens coogee, was man ja auch unten sehen kann.
Es ist ein twitter Widget!
Schande über mich, dass ich es nicht schon eher installiert hab.
design, twitter, widget
Geht wieder nur um eine kleine Website, aber hey: Artikel schreiben kostet ja nichts.
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.
benchmark, chris vincent, php, phpbench, speed
Besser als http://www.ajaxload.info: http://preloaders.net
Die Seite bietet sogar 3 Dimensionale Loader an
ajax, loader
Wenn ich an einer Webseite arbeite mache ich üblicherweise kleine Änderungen, lade die Dateien hoch und teste was ich gemacht habe. Das hat sich so bewährt. Der Nachteil an dieser Vorgehensweise ist allerdings, dass ich immer wieder die frisch geänderten Dateien von meinem Computer aus in den www-root meines heimischen Servers übertragen muss. Und nur die geänderten Dateien, nicht alles.
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.
Den Rest lesen
aptana, psexec, pstools, smartsync, subversion, svn
Digg hat ein Problem: Power User. Diese Typen deren Motivation ich nicht ganz verstehe kontrollieren die Frontpage von Digg. Auf digg selbst hat es bereits einige Vorschläge und Ideen gegeben, wie man die Typen los wird, oder wenigstens die Symptome.
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
digg
Heureka!
Ihr könnt meine Posts jetzt auch in Englisch genießen!
Okay, die meisten.
Cheers,
Patrick
heureka, languages
Hatte einige kleine Probleme mit der neuen Version von Wordpress, hab es jetzt wieder neu installiert und alles scheint zu funktionieren.
UPDATE: Okay, lag wohl doch nicht an WordPress. Scheinbar hatte FileZilla keine Lust ALLE Dateien zu übertragen…
2.7, filezilla, trouble, wordpress