Donnerstag, 28. April 2005
Mit Firefox CSS-Dateien röntgen
Vor kurzem noch darüber geklagt, bin ich jetzt schon einen Schritt weiteR:
Aardvark ist ein nettes "proof-of-concept" Plugin, was dynamisch CSS-Elemente einer Seite highlighted und Informationen darüber darstellt.
Das ganze funktioniert schon relativ gut, und die "Coming Features"-Liste klingt auch vielversprechend: edit styles and content of the elements.
Passend zu der Extension gibt es auch ein Blog, was ich jetzt direkt mal abzapfen werde.
Ich wusste doch, dass ich mir kein MacOS kaufen muss; "FirefoxOS get's the job done".
(via DrWeb.de)
Aardvark ist ein nettes "proof-of-concept" Plugin, was dynamisch CSS-Elemente einer Seite highlighted und Informationen darüber darstellt.
Das ganze funktioniert schon relativ gut, und die "Coming Features"-Liste klingt auch vielversprechend: edit styles and content of the elements.
Passend zu der Extension gibt es auch ein Blog, was ich jetzt direkt mal abzapfen werde.
Ich wusste doch, dass ich mir kein MacOS kaufen muss; "FirefoxOS get's the job done".
(via DrWeb.de)
Dienstag, 26. April 2005
Bauarbeiten!
Wie bereits angekündigt ist jetzt hier ein experimentelles Plugin zu Gange.
Das ganze erzeugt vollständige Caches der Seiten, die maximale 1 Stunde "haltbar" sind. Vorteil ist, dass alle Content-Seiten für mehrere Zugriffe hintereinander stark optimiert sind.
Nachteil ist, dass Dynamik verloren geht: Die Clickanzahl und Karma-Votes innerhalb der Einträge werden nicht mehr den aktuellen Stand wiedergeben. Das Kommentarformular zur Eingabe eurer Daten wird jetzt per JavaScript statt per serverseitigem PHP vorausgefüllt (anhand eurer Cookie-Daten, falls gesetzt). Und dann eventuell noch Sachen, an die ich nicht gedacht habe.
Ein noch größerer Teil bei der Ladezeitverzögerung machen die GoogleAds aus. Die fliegen hier aber eh bald raus, sobald ich meine erste Auszahlung bekommen habe. Seitdem die Ads laufen (ca. ein Jahr) habe ich knapp 100 Dollar verdient, das sind also etwas weniger als 7 Euro monatlich. Und dafür, dass mich das Seitenaufbau-Geflacker so nervt und die Ads so wenig kontextsensitiv und sinnvoll sind, lohnt sich das absolut GAR nicht.
Aufgrund des Timeouts nach einer Stunde sollte davon eigentlich nicht viel bemerkbar sein. Ich würde mich freuen, wenn ihr mir eure Eindrücke mitteilt: Läuft es schneller/besser/langsamer, fallen euch spezielle "Bugs" auf?
Das ganze erzeugt vollständige Caches der Seiten, die maximale 1 Stunde "haltbar" sind. Vorteil ist, dass alle Content-Seiten für mehrere Zugriffe hintereinander stark optimiert sind.
Nachteil ist, dass Dynamik verloren geht: Die Clickanzahl und Karma-Votes innerhalb der Einträge werden nicht mehr den aktuellen Stand wiedergeben. Das Kommentarformular zur Eingabe eurer Daten wird jetzt per JavaScript statt per serverseitigem PHP vorausgefüllt (anhand eurer Cookie-Daten, falls gesetzt). Und dann eventuell noch Sachen, an die ich nicht gedacht habe.
Ein noch größerer Teil bei der Ladezeitverzögerung machen die GoogleAds aus. Die fliegen hier aber eh bald raus, sobald ich meine erste Auszahlung bekommen habe. Seitdem die Ads laufen (ca. ein Jahr) habe ich knapp 100 Dollar verdient, das sind also etwas weniger als 7 Euro monatlich. Und dafür, dass mich das Seitenaufbau-Geflacker so nervt und die Ads so wenig kontextsensitiv und sinnvoll sind, lohnt sich das absolut GAR nicht.
Aufgrund des Timeouts nach einer Stunde sollte davon eigentlich nicht viel bemerkbar sein. Ich würde mich freuen, wenn ihr mir eure Eindrücke mitteilt: Läuft es schneller/besser/langsamer, fallen euch spezielle "Bugs" auf?
Freitag, 22. April 2005
Serendipity Caching-Plugin
Auf der Bahnfahrt heute dachte ich mir, ein einfaches Voll-HTML-Caching Plugin für Serendipity sollte doch etwas nettes sein.
Das Plugin soll eigentlich nur jede Seite anhand der URL cachen, etwaige GET- und COOKIE-Parameter miteinbeziehen und den Cache bei neuen Kommentaren/Einträgen automatisch purgen und danach beim ersten Request neu erstellen. Ausserdem soll es jede Seite nach maximal 60 Minuten einmal erneut bauen. "Just in Case"-Kompilierung, sozusagen.
Genau das tut mein in 30-Minuten gebasteltes Proof-of-Concept Plugin serendipity_event_cachesimple auch.
Es hat so einige gefährliche Gotchas: Man verliert die "Dynamik" der Seiten. Etwaige dynamische Sidebars, "Quote of the Second" usw. wird so natürlich alles am PHP-Parser vorbeigeschleust. Prinzipbedingt kann Vollseiten-Caching nicht anders funktionieren; einzige Alternative wäre ein modularer Cache. Der wiederrum enthält schon wieder so viel Code und Logik, dass er IMHO zuviel Entwicklungsaufwand für zu geringen Nutzen bietet. Dafür gibt es ja auch bereits das "Erweiterte Eigenschaften"-Plugin, welches jeden Artikeltext nur einmal parst und dann immer den Cache zur Hilfe zieht. Mühsame Smilie-Ersetzungen, BBCode usw. werden nur einmal umgeformt, und sparen so schon eine ganze Menge Performance.
Wer darauf verzichten kann, absolut dynamische Seiten zu haben und dessen Content sich nur selten dynamisch ändert, der dürfte an dem Plugin weitaus mehr Spaß haben und so etwas Slashdot-sicherer machen können.
Das Plugin ist derzeit noch nicht durchweg getestet. Ab nächster Woche werde ich es hier einmal in den Probebetrieb schicken um Probleme zu durchleuchten - dafür wird es dann auch hier etwas Einbußen geben an Dynamik, aber hoffentlich mehr Performance. Selbst das Click-Tracking sollte noch funktionieren, auch wenn die dargestellten Daten dann nur stündlich aktualisiert werden. Über eigene Tests und Weiterentwicklung des Plugins würde ich mich daher sehr freuen.
Das Plugin soll eigentlich nur jede Seite anhand der URL cachen, etwaige GET- und COOKIE-Parameter miteinbeziehen und den Cache bei neuen Kommentaren/Einträgen automatisch purgen und danach beim ersten Request neu erstellen. Ausserdem soll es jede Seite nach maximal 60 Minuten einmal erneut bauen. "Just in Case"-Kompilierung, sozusagen.
Genau das tut mein in 30-Minuten gebasteltes Proof-of-Concept Plugin serendipity_event_cachesimple auch.
Es hat so einige gefährliche Gotchas: Man verliert die "Dynamik" der Seiten. Etwaige dynamische Sidebars, "Quote of the Second" usw. wird so natürlich alles am PHP-Parser vorbeigeschleust. Prinzipbedingt kann Vollseiten-Caching nicht anders funktionieren; einzige Alternative wäre ein modularer Cache. Der wiederrum enthält schon wieder so viel Code und Logik, dass er IMHO zuviel Entwicklungsaufwand für zu geringen Nutzen bietet. Dafür gibt es ja auch bereits das "Erweiterte Eigenschaften"-Plugin, welches jeden Artikeltext nur einmal parst und dann immer den Cache zur Hilfe zieht. Mühsame Smilie-Ersetzungen, BBCode usw. werden nur einmal umgeformt, und sparen so schon eine ganze Menge Performance.
Wer darauf verzichten kann, absolut dynamische Seiten zu haben und dessen Content sich nur selten dynamisch ändert, der dürfte an dem Plugin weitaus mehr Spaß haben und so etwas Slashdot-sicherer machen können.
Das Plugin ist derzeit noch nicht durchweg getestet. Ab nächster Woche werde ich es hier einmal in den Probebetrieb schicken um Probleme zu durchleuchten - dafür wird es dann auch hier etwas Einbußen geben an Dynamik, aber hoffentlich mehr Performance. Selbst das Click-Tracking sollte noch funktionieren, auch wenn die dargestellten Daten dann nur stündlich aktualisiert werden. Über eigene Tests und Weiterentwicklung des Plugins würde ich mich daher sehr freuen.
Mittwoch, 20. April 2005
W3C: XHTML2 und XFORMS Tutorial
Gestern war in St. Augustin ein vom Deutsch-Österreichischen W3C-Büro veranstaltetes Tutorial zu XHTML 2 und XFORMS, gehalten von Steve Pemberton.
Beim zuletzt veranstalteten Vortrag über RDF war ich auch schon dabei, und war davon so angetan, dass ich natürlich auch dieses Mal teilnehmen musste. Das dachten sich wohl auch andere, denn im Gegensatz zu den damals 40 Teilnehmern waren diesmal 100 angemeldet. Darunter auch Tom, Andy und Nadine mit denen ich dort gemeinsam in der großzügig ausgestatteten Konrad-Adenauer-Stiftung aufschlug.
Das Tutorial wurde in Englisch gehalten und dauerte mit 30-minütiger Pause gut 4 Stunden. In dieser Zeit hat Steve, mit typisch britischem Humor, sehr eindrucksvoll und mit praktischem Beispielen so ziemlich alles über XHTML2 und XFORMS erzählt, was man sich vorstellen kann.
Die vollständigen und sehr ausführlichen Unterlagen zu dem Tutorial befinden sich auf W3.org, die ich jedem nur ans Herzen legen kann.
Hier dennoch ein kurzer Abriss, mit meinem eigenen knappen Kommentar:
» Vollständiger ArtikelBeim zuletzt veranstalteten Vortrag über RDF war ich auch schon dabei, und war davon so angetan, dass ich natürlich auch dieses Mal teilnehmen musste. Das dachten sich wohl auch andere, denn im Gegensatz zu den damals 40 Teilnehmern waren diesmal 100 angemeldet. Darunter auch Tom, Andy und Nadine mit denen ich dort gemeinsam in der großzügig ausgestatteten Konrad-Adenauer-Stiftung aufschlug.
Das Tutorial wurde in Englisch gehalten und dauerte mit 30-minütiger Pause gut 4 Stunden. In dieser Zeit hat Steve, mit typisch britischem Humor, sehr eindrucksvoll und mit praktischem Beispielen so ziemlich alles über XHTML2 und XFORMS erzählt, was man sich vorstellen kann.
Die vollständigen und sehr ausführlichen Unterlagen zu dem Tutorial befinden sich auf W3.org, die ich jedem nur ans Herzen legen kann.
Hier dennoch ein kurzer Abriss, mit meinem eigenen knappen Kommentar:
Montag, 18. April 2005
Support
Och, jetzt hab ich's doch verpasst.
Die letzten Tage habe ich immer einen Blick auf meinen s9y.org Forum-Account geworfen um da mein 2000. Posting nicht zu verpassen.
Jetzt ist's also geschehen, meine durschnittlich 3.48 posts pro Tag, die 28% des gesamten Posting-Aufkommens des Forums ausmacht müssen also ohne Jubiläumsposting gefeiert werden. Mal schauen, wie lange ich sowas noch durchhalte, eigentlich ist das ja ein wahrer Zeitkiller.
Die letzten Tage habe ich immer einen Blick auf meinen s9y.org Forum-Account geworfen um da mein 2000. Posting nicht zu verpassen.
Jetzt ist's also geschehen, meine durschnittlich 3.48 posts pro Tag, die 28% des gesamten Posting-Aufkommens des Forums ausmacht müssen also ohne Jubiläumsposting gefeiert werden. Mal schauen, wie lange ich sowas noch durchhalte, eigentlich ist das ja ein wahrer Zeitkiller.
Montag, 11. April 2005
Coming to a blog near you: <link rel="start/up/prev/next" />
Heute habe ich auf Initiative von Sebastian Bergmann ein kleines Plugin für <link rel="start/up/prev/next" /> Meta-Informationen hinzugefügt.
Was sich jetzt etwas technophob anhört, ist eigentlich supitoll: Mit so praktischen Mozilla Tools wie linkToolbar werden diese Metatags auf Seiten nämlich ausgewertet, und so erscheint in den Browsern unten rechts eine nette Vor/Zurück/Hoch/...-Navigation.
Effektiv kann man jetzt von der Detailansicht der Einträge aus vor und zurück blättern, genauso kann man wenn man die Archive durchstöbert die Monate/Tage vor/zurück blättern. Sogar für Kategorien und Autoren kann diese Blätterfunktion genutzt werden.
Ich habe es in meinem Blog mal eingebunden und bin gespannt ob sowas Nutzung finden wird. Theoretisch ermöglichst dies auch das sogenannte "Link Prefetching".
Was sich jetzt etwas technophob anhört, ist eigentlich supitoll: Mit so praktischen Mozilla Tools wie linkToolbar werden diese Metatags auf Seiten nämlich ausgewertet, und so erscheint in den Browsern unten rechts eine nette Vor/Zurück/Hoch/...-Navigation.
Effektiv kann man jetzt von der Detailansicht der Einträge aus vor und zurück blättern, genauso kann man wenn man die Archive durchstöbert die Monate/Tage vor/zurück blättern. Sogar für Kategorien und Autoren kann diese Blätterfunktion genutzt werden.
Ich habe es in meinem Blog mal eingebunden und bin gespannt ob sowas Nutzung finden wird. Theoretisch ermöglichst dies auch das sogenannte "Link Prefetching".
