michi bloggt!

Fantastische Neuigkeiten die sich da bereits gestern abend in den CVS Commit Logs abgezeichnet haben:
-> http://dev.helma.org/wiki/New+Skin+Features+in+Helma+1.6/

Author: <% this.creator.name | truncate max="10" | escape %>

Bzgl Filter-Library kann man sich hier schon mal Ideen holen:
* Smarty Modifiers
* Liquid Filters
* Freemarker Builtins

So, die Woche ist mir endgültig die Geduld mit meinem Laptop gerissen. Ich brauch will einen neuen Rechner. Empfehlungen?

Ich tendiere ja aus mir eigentlich unbekannten Gründen zu einem Lenovo. Die Macht des Marketins eben.

Vista wird mir jedenfalls nicht auf das Ding kommen. Eher bleib ich noch bei XP.

Update: Etwas teuer, aber schon mal ein heißer Kandidat: http://www.ba-computer.at/product_info.php?products_id=56665 Vielleicht lässt sich ja das Viste gegen 1GB extra noch tauschen :-)

Update 19.3.: Danke für die Tipps / Infos. Ich hab heut mal 2 GB extra RAM bestellt, und seh mal zu wie das Ding dann läuft. Ansonsten könnte ich mir noch Franz seinen Vorschlag zu Herzen nehmen, und mal zeitweise auf Ubuntu switchen um zu sehen, ob das Arbeiten dort schneller von statten geht. Vielleicht war ich ja doch etwas voreilig meinen ansonsten braven Rechner in die Pension zu schicken. Abgesehen davon hätte ich mich jedenfalls für einen T60 entschieden.

* Amazon Simple Queue Service
* Fun with Amazon's Simple Queue Service (5.1.05)
* ActiveMQ (Apache project, which emerged from the incubator a month ago)

...gibt gas.

-> http://www.lighttpd.net/

Security, speed, compliance, and flexibility--all of these describe LightTPD which is rapidly redefining efficiency of a webserver; as it is designed and optimized for high performance environments.

lighttpd powers several popular Web 2.0 sites like YouTube, wikipedia and meebo. Its high speed io-infrastructure allows them to scale several times better with the same hardware than with alternative webservers.

Bei uns derzeit noch nicht im Einsatz, da
1) der Static-Server bisher kaum ein Flaschenhals war, und
2) die AJP13-Kommunikation zwischen Webserver und Helma mit lighthttpd bisher nicht möglich war.

Die Liste an 'interessanten Modulen' wird aber stetig länger. Die 'Hausaufgaben' wurden (mod_auth, mod_compress, mod_rewrite,..) bzw werden gerade (mod_proxy with ajp13) erledigt. Darüberhinaus gibt es aber eine Menge aktueller, web2.0-relevanter Themen welcher man sich bei lighthttpd sehr engagiert annimmt:
* flv streaming (see also)
* Performance Gain thanks to async io
* Protected Downloads with with mod_secdownload or with mod_trigger_b4_dl
* Upload Progress
* COMET with lighthttpd
(more modules)

Nachtrag: Mmh, den eigenen Benchmarks zu schließen kann lighthttpd gerade mal mit Apache2.2 Event MPM mithalten.

For Rails 2.0 we hope to cultivate these humble beginnings into an automatic cache so that all read queries are only run once per rails request if possible. [src]

Da kann man als alter Helma-User nur schmunzeln. Vor allem "we hope" und "if possible" ist noch extra erheiternd. Man vergleiche hierzu Helma's LRU Object Caching Mechanismus, für die die ihn noch nicht kennen.

Randnotiz: Ich weiß, ich weiß, hier auf twoday.net lahmt es in letzter Zeit. Ein Helma-Cluster-Setup ist aber bereits am Weg. Bis dahin heißt es durchhalten.

Eine super interessante Entwicklung findet hier im Kampf um die User-Identitäten gerade statt.

Als Microsoft seinerzeit Passport (neuerdings als 'Windows Live ID' bekannt) launcierte, genoß M$ bereits nicht gerade den bereits Ruf als Datenschützer um einen globalen, zentralen User-Server erfolgreich etablieren zu können. Die Zahl der integrierenden Services konnte man seit jeher an einer Hand abzählen (wenn man die MS-eigenen Services mal bei Seite lässt)

Die Antwort der Bloggerwelt (bzw von SixApart) auf das Problems des sich ständig Registrieren müssens, lautete Anfang 2004 Typekey. Da dies aber wiederum ein zentrales Service war, bloss dass statt Microsoft eben eine andere (genauso 'vertrauensunwürdige') Firma versuchte, an alle Daten heranzukommen, fand auch Typekey kaum Freunde jenseits der WordpressMovableType-Grenzen.

Das Bedürfnis nach einem dezentralen, demokratischen Authentifizierungs-Mechanismus für das Web war dann (Mitte 2004) bereits so groß, dass ich zusammen mit earl die Idee ausformulierten und SORUA ins Leben riefen. Etwa zeitgleich gab es aber auch eine Reihe von anderen Initiativen: OpenID, Yadis, LID,.. Initiativen die man mittlerweile unter dem Schlagwort Identity 2.0 zusammen fassen kann. Von Anfang an genoß aber OpenID, dank der Unterstützung von LiveJournal, die meiste Aufmerksamkeit.

Seitdem hat sich aber das Internet enorm schnell weiter entwickelt. Die großen Player (allen voran Google und Yahoo) brachten ein Webservice nach dem anderen unter deren Deckmantel heraus. So viele schrecklich nützliche Services, dass kaum jemand der Versuchung widerstehen kann, sich nicht doch einen Account bei Google oder Yahoo anzulegen. Und schlau wie die sind, machen die es jedem anderen Service sehr einfach (siehe Google Account Authentication, bzw Yahoo's BBAuth) mit einem Schlag das eigene Service (potentiell) Millionenen von bestehenden Usern zu öffnen, ohne dass diese sich registrieren müssten. Wer kann denn einer solchen Versuchung noch widerstehen? Es schien fast so, als wären all die ganzen Bedenken welche man zentralen User-Servern gegenüber hegte, plötzlich verschwunden wären.

Gottseidank ist dem aber anscheinend doch nicht so. O'Reilly griff das Thema vor zwei Monaten wieder auf, und publizierte dass bereits 500 Sites OpenID unterstützen. Und nun verkündete Bill Gates höchstpersönlich, dass Microsoft künftig OpenID ebenfalls unterstützen wird. Ein smarter Schachzug vom Herrn Gates, denn das Rennen gegen die zentralen User-Server von Google und Yahoo war einfach nicht mehr zu gewinnen (behaupte ich jetzt mal so).

Es ist also auch höchste Zeit für uns auf das richtige Pferd, sprich OpenID, zu setzen. Sorua wird weiterhin für die überschaubare Zahl an Implementierungen seinen Dienst verrichten, aber die Zukunft gehört eindeutig OpenID. Und ich bin gar nicht mal so unglücklich darüber.

Nachtrag:
* Quick Intro to OpenID (video)
* Six cool things you can build with OpenID
* ruby-openid

-> http://pipes.yahoo.com/
bzw related, aber schon älter:
-> http://www.dappit.com/

Pipes is an interactive feed aggregator and manipulator. Using Pipes, you can create feeds that are more powerful, useful and relevant.

-> cool!

Aber ich hab nach ein zwei Stunden "herumspielen" (sowohl mit Pipes als auch mit Dapper) nicht geschafft auch nur einen einzigen halbwegs vernünftigen UseCase umzusetzen. Und es dürfte anderen nicht ganz unähnlich gehen.

Robert Gaggl from Orf On proudly presents:
-> Jala
Jala is an open-source collection of JavaScript modules for Helma Object Publisher.

Especially the JsDocs are nice to see in action. Also see here for more feedback on Jala.

Eine gute URL eines Objektes soll in etwa folgende Merkmale aufweisen (geordnet nach meiner persönlichen Einschätzung der Wichtigkeit):

1. Sie soll muss permanent sein: Damit man das Objekt mittels dieser URL bis in alle Ewigkeit eindeutig referenzieren kann
2. Sie soll selbstredend sein: Damit man an Hand der URL selbst bereits möglichst gut erkennen kann, was sich dahinter verbirgt. V.a. auch für SEO wichtig.
3. Sie soll kompakt und kurz sein: Damit man die URL (ab)tippen (z.B. vom Gedruckten) kann.
4. Sie soll mehrstufig sein: Damit man Teile der URL (von rechts) entfernen kann, und man erhält weitere Seiten

Leider stehen diese Ziele teilweise in einem Konflikt zu einander.

Hier auf twoday.net folgen wir noch immer dem aus Antville übernommen URL-Aufbau. Dieser Beitrag z.B. ist unter http://michi.knallgrau.at/blog/stories/3279755 erreichbar. Diese URL ist zwar permanent, kompakt und (bedingt) mehrstufig. Aber selbstredend ist sie nicht.

In den gängigen Blog-Systemen hat sich mittlerweile folgendes URL-Schema durchgesetzt: http://.../articles/2006/03/20/flexable-routes-with-path_info Fantastisch. An Hand der URL kann ich bereits ablesen, wie aktuell der Beitrag ist, und worüber er ungefähr handelt. Solcherlei URLs sind definitiv selbstredend und mehrstufig. Aber erfüllen sie auch das oberste Gebot des URL-Designs, zwar den der Permanenz? Üblicherweise wird Usern nämlich auch erlaubt den textlichen Teil der URL ändern zu können. Eine Aktion die absolut tabu sein sollte, denn dadurch verlieren sämtliche Referenzen auf die URL ja ihre Gültigkeit.

Das 37signals-Blog zeigt nun eine mögliche Lösung für dieses Dilemma vor. Die dortigen URLs bestehen sowohl aus der uniquen ID als auch aus einem arbiträren Text. Die folgenden drei Links führen alle zum gleichen Artikel [siehe auch]:
-> http://.../posts/247-calling-all-basecamp-customers-in-nyc-or-chicago
-> http://.../posts/247-was-auch-immer-ich-hier-schreib
-> http://.../posts/247

Ein interessanter Kompromiss. Doch leider geht nun hier die Injektivität, sprich Eindeutigkeit verloren. Denn woran erkennt nun ein Fremdsystem, dass es sich bei obigen URLs um ein und das gleiche Objekt handelt?

Schwierige Angelegeneheit. Weiterhin. Und derweilen bleiben wir eben auch besser bei den numerischen URLs.

Danke an Christopher für den Hinweis auf diesen Vortrag von Steffen Meschkat (Google) über
-> JSON RPC (Cross Site Scripting and Client Side Web Services)

Da ich erst heute die Muse fand, mich mit der Google Maps API genauer zu befassen, war ich mir eigentlich nie wirklich bewusst, dass es da ja eigentlich einiges an Magic benötigt um mittels Browser Codes ein Remote Service (welches unter einer anderen Domain läuft) benutzen zu können. Ajax-Calls lassen sich ja bekanntlich aus Sicherheitsgründen bloss auf die eigene Domain absetzen. Der Trick ist nun, dass man externe Methode aufruft, indem ein dynamisch generierter SCRIPT-Tag nachgeladen wird. Und der Response enthält den Aufruf einer Callback-Methode mitsamt den Return-Werten als Argumente, welche dann im Browser ausgeführt werden kann.

Aber am besten man sieht sich Slide 6 und 9 der PDF Slides des Vortrages an, und dann wird es, denke ich mal, klarer.

Quintessenz: Der Browser kann, wie die Google Maps API ja schon seit längerem demonstriert, problemlos externe Services benutzen. Einer service-orientierten Architektur steht also auch auf client-Seite nichts im Wege.

Some more on JSONP:
-> http://ajaxian.com/archives/jsonp-json-with-padding
-> http://ecmanaut.blogspot.com/...jsonp-recipe-for-visitor-innovation.html
-> http://unclehulka.com/.../2005/12/12/jsonpyoure-joking-right/
-> http://www.xml.com/pub/a/2005/12/21/json-dynamic-script-tag.html?page=2

Another impressive use of JSONP:
-> http://js-kit.com/