Amazon senkt die Preise rückwirkend zum 1. Februar für seinen Cloud-Speicherdienst Amazon Simple Storage Service (S3) um bis zu 13,6 Prozent pro GByte. Mehr Infos im Amazon Web Services Blog.

Und meine Experimente mit statischen Webseiten, die auf S3 gehostet werden, werden dadurch noch interessanter (zu­min­dest für mich). [Golem.de]

• Hier kann man mit der Tropfenschachtel seltsame Dinge anstellen: Automatisiere Deine Dropbox.
• Für ultra-hardcore Pythonistas: PBS »is a unique subprocess wrapper that maps your system programs to Python functions dynamically. PBS helps you write shell scripts in Python by giving you the good features of Bash (easy command calling, easy piping) with all the power and flexibility of Python.«
• Wenn es schon ein Windowsrechner sein muß, dann sollte man sich auch mal die Sicherheitsempfehlungen für Privatanwender des Bundesamts für Sicherheit in der Informationstechnik (BSI) zu Gemüte führen (unter Vorbehalt, als Nicht-Windows-Nutzer kann ich die Qualität der Empfehlungen nicht wirklich beurteilen).
• ShareLaTeX ist eine Art EtherPad für LaTeX, mit dem mehrere Autoren in Echtzeit an einem Dokument arbeiten und es auch mit einem Klick online zu einem PDF-Dokument konvewrtieren können. (Notiz an mich: Testen!)
• Mal wieder etwas für die, denen der Emacs nicht nerdig genug ist: Vim-Tipps.
• Dream Anatomy hatte ich zwar schon einmal, aber da das jetzt über neun Jahre her ist, kann man ruhig wieder auf diese phantastische Sammlung zur Medizingeschichte der U.S. National Library of Medicine hinweisen.
• Server-Monitoring leichtgemacht mit Amon.
• Mal wieder mein Lieblingsthema »Statische Seiten«: Mynt ist ein statisches Weblog-Framework, das in Python geschrieben wurde und auf den ersten Blick einen ziemlich guten Eindruck hinterläßt. Ich glaube, ich sollte dies einmal unbedingt testen!

Wie immer hoffe ich, daß für jeden von Euch etwas dabei ist. [Alle Links: Peter van I. per Email.]

• Übersetzungshilfe: How to read Haskell like Python.
• Bunter Vim (revisited): Vivify ist ein (weiterer) Farbschema-Generator für den Editor für Nerds.
• Für die Freunde des anderen Nerd-Editors: The Ultimate Collection of Emacs Resources.
• JavaScript: Best Practices.
• Online-Journalismus leicht gemacht: New York Times releases code to help journalists collaborate on WordPress, other platforms. Den versprochenen Code gibt es hier.
• Schönere README.md auf Github: Document Up your Readmes.
• Agentenprogrammierung mit der Schlange (ganz einfach): Pyro (MIT-Lizenz) ist eine Python-Bibliothek, die einem die Programmierung im Netzwerk erleichtert/erleichtern soll. (Notiz an mich: Testen!)
• Mal wieder etwas für die Tropfenschachtel: How to Share Your Dropbox Files with Shareable Links.
• Tutorial: Von Null auf ein gehostetes Jekyll-Blog in drei Minuten. Das ist vermutlich der schnellste Weg zum eigenen Jekyll-Blog.
• Interaktive thematische Karten und Geovisualisierung mit Processing: Unfolding ist eine Java-/Processing-Bibliothek, die das unterstützt. (Notiz an mich: Ebenfalls testen!)
• Auf PySchools können die, die es noch nicht können, Python lernen.
• Badass JavaScript ist ein Weblog, das sich ganz dieser Sprache verschrieben hat. Ab in den Feedreader damit.
• Auf Ammon P5 gibt es 25 lebensrettende Processing-Tips. Auch dieses Weblog gehört in meinen Feedreder.

Wie immer hoffe ich, daß für jeden von Euch etwas dabei ist … [Alle Links: Peter van I. per Email.]

Nichts wirklich Neues, aber eine extrem ausgefeilte und nerdige Umgebung, um ein statisches Blog ins Netz zu stellen: Heroku als Hoster, Jekyll als Template Engine und Googles App Engine als CDN. Schon interessant. Und Heroku sollte ich mir auch mal genauer anschauen. [Peter van I. per Email.]

• Wie man Threads korrekt in Python implementiert, verrät Euch dieses Tutorial: Python threads: communication and stopping.
• WordPress Goes Social: Mit diesem Plugin könnt Ihr ein Forum in Eure WordPress-Umgebung einbauen.
• Eine weitere Blog-Engine für Googles App Engine (und web2py).
• Security Alert: Wi-Fi Protected Setup easily unlocked by security flaw. Schreiben die Geier. Ist also wahr …
• Automatisiere Deine Tropfenschachtel (hier eine kurze Review).
• Don’t Panic! Welcome to The Hitchhiker’s Guide to Python.

Ich möchte mich bei Peter für die Zusammen- und Zuarbeit im letzten Jahr bedanken und hoffe auf noch viele weitere Jahre mit Tips und Links aus den Niederlanden. [Alle Links: Peter van I. per Email.]

1. Das Bucket muß genau so heißen wie die Domain also technisch gesprochen, die gleiche CNAME besitzen, in diesem Fall also jweb.kantel-chaos-team.de.
2. Dann muß man über die AWS Management Console für dieses Bucket festlegen, daß die index.html das Startdokument der Website ist, der Welt den Zugriff darauf explizit erlauben und eine Bucket Policy erstellen.
3. Die Umleitung der Domain muß auf jweb.kantel-chaos-team.de.s3-website-region.amazonaws.com erfolgen. Die genaue Region kopiert man sich am einfachsten von der Management Console, in meinem Fall war es s3-website-us-east-1.

Und schon hat man eine funktionierende (statische) Website in Amazons Cloud. Ob und wenn ja, was ich damit anfangen werde, weiß ich noch nicht. Ich wollte erst einmal nur wissen, ob und wie es geht …

• Amazons CloudFront unterstützt nun auch 20 GB fette Objekte.
• Das Internet vergißt doch: Auf Amazons S3 kann man nun Objekte mit einem Verfallsdatum versehen, nach dem diese gelöscht werden.
• Wie bekommt man Videos aufs Kindle Fire? Das Miro Internet TV Blog weiß es.
• Werkzeug für Datenjournalisten: Google Refine hat die Version 2.5 erreicht. Und wer nicht weiß, was er mit diesem Tool anstellen kann, sollte sich obiges Video anschauen.

So langsam bekomme ich den Rückstau abgearbeitet …

Ich bin ja der Meinung, daß sensible Daten in der Tropfenschachtel nichts verloren haben (die Gefahr, daß sie da wieder herauströpfeln, ist mir zu groß). Wer sich dennoch traut, sollte sie wenigstens verschlüsseln. Eine preisgünstige (99 Cent) Möglichkeit dazu bietet die Safebox (Win und Mac). [Peter van I. per Email.]

• Wer — so wie ich — seine ersten Programmierschritte mit den klassischen programmierbaren Taschenrechnern von HP und deren umgekehrter polnischer Notation unternommen hat, der will natürlich unbedingt mit nonpareil für MacOS X (GPL) spielen. Denn dieses Programm emuliert einige der Klassiker mit einer graphisch sehr aufwendig gestalteten Benutzeroberfläche.
• Wider die Datensilos mit dem Salmon Protocol, dem Versuch eines Standards für (verteilte) Kommentare und Notizen in Echtzeit. Sollte ich mir unbedingt mal genauer anschauen.
• Falcon ist eine Personal Publishing Webanwendung für Blogs, Tweets und Real Time Syndication. Das System befindet sich noch in der Entwicklung, aber eine Demo-Anwendung des Entwicklers kann hier besichtigt werden.
• Noch ein Testkandidat: Nimbus.IO will eine Open-Source-Alternative zu Amazons S3 sein.
• Berp ist eine Python3-Implementierung, die in Haskell geschrieben wurde. Warum? Weil es geht!

Ich hoffe, es ist wieder für jeden von Euch etwas dabei. [Alle Links: Peter van I. per Email.]

Man ist nicht nur auf Googles App Engine eingeschränkt, wenn man Cloud Applikationen in Python schreiben will: Boto (BSD-Lizenz) ist eine Bibliothek mit Python-Funktionen, die den Zugriff auf Amazons Cloud vereinfachen will. Unterstützt wird so ziemlich alles, was Amazon bisher auf die Beine gestellt hat: S3, EC2, der mechanische Türke, SimpleDB, Google Storage (sic!), Elastic Map Reduce, Virtual Private Cloud und vieles, vieles mehr. Es gibt eine äußerst umfangreiche Online-Dokumentation und das Buch »Python and AWS Cookbook — Managing Your Cloud with Python and Boto« (Haben wollen!) von Mitch Garnaat, dem Maintainer von Boto. [Peter van I. per Email.]

Für die Diskussion um statisch herausgeschriebene (gerenderte) Weblogs (baked weblogs) hat mein emailender Dauertipgeber mal wieder ein Menge an Links und Hinweisen gesammelt, die ich hier en bloc abhandle:

• Bei der Diskussion um statische Seiten spielt Markdown immer eine Rolle: Und so wie Multimarkdown ein Superset von Markdown ist, so ist PHP Markdown Extra eine erweiterte Version von PHP Markdown. Alles klar?
• Phrozn (wurde schon einmal in meinen Kommentaren erwähnt) ist ein weiteres Tool, das statische Seiten herausschreibt und in PHP geschrieben wurde.
• Socrates schreibt ebenfalls statische Seiten (vorzugsweise Weblogs) heraus und ist nicht nur für Altphilologen, sondern in Python geschrieben.
• Und auch die Rubynistas ruhten nicht, bis sie ein weiteres Tool zur Generierung statischer Seiten unters Volk gebracht hatten: Mit Middleman wird zum Beispiel auch dieses Weblog (natürlich das des Entwicklers) angetrieben.
• Und für die Liebhaber exotischer Programmiersprachen: Static rendert dieses Weblog (das des Entwicklers) als statische Seiten heraus und ist in Clojure geschrieben.
• Noch einmal für Pythonistas: qsgen nutzt Makos Template Engine, stango treibt dieses Weblog (natürlich wieder das des Entwicklers) an und SWG (ebenfalls mit Mako) besitzt auch ein Entwicklerweblog (Quellen auf Github).
• Noch einmal Ruby: Ace treibt nicht nur das Blog des Entwicklers, sondern dieser hat auch noch den Django-Klon rango entwickelt (manch einer kriegt den Hals nicht voll) und korma besitzt ebenfalls ein Entwicklerblog mit Quellen auf Github
• Und jetzt wieder zurück zur Schlange: Mit den Regenwolken in die Cloud, Luna schreibt ebenfalls statische Seiten und mit pPub (nutzt pygtk und pywebkit) könnt Ihr Eure Ebooks im Epub-Format lesen.
• Und wer statische Seiten herausschreiben will, braucht einen guten Editor: Der Aquamacs ist in der Version 2.4 draußen.
• Und irgendwo müßt Ihr Eure statischen Seiten ja auch ablegen. Daher noch einmal die Cloud: Backblaze’s Basic Cloud Storage is 25 Times Cheaper than Amazon S3. Habe ich noch nicht getestet, daher ohne Gewähr.

Und wer jetzt den Eindruck gewonnen hat, daß jeder Programmierer sich seine Template Engine oder seinen Generator für statische Seiten mindestens einmal selber programmiert haben muß, der hat vermutlich recht. [Alle Links: Peter van I. per Email.]

Das neue Release zielt auf den kommerziellen Einsatz. Heise hat die diesbezüglichen Neuerungen zusammengefaßt. [Google App Engine Blog, The Go Programming Language Blog, Golem.de, heise developer news]

»The Internet is great because it is decentralized. If you centralize it, it stops being the Internet.« — (Dave Winer)

Warum P2P?

Die großen sozialen Netze von Twitter über Facebook bis Google+ kranken an ihrer zentralen Struktur. Dave Winer hatte sie einmal mit Datensilos verglichen, in denen der Nutzer zwar seine Daten hineinsteckt, aber sie nicht mehr hinaus­bekommt. Das heißt, der Nutzer ist nicht mehr Herr seiner Daten, wenn Facebook zum Beispiel beschließt, dichtzumachen, oder Google meint, ihn wegen eines Pseudonyms von Google+ auszuschließen, ist alles weg.

Das ist zum Beispiel auch der Grund, warum mein Hauptpublikationstool immer noch mein (selbstgehostetes) Blog ist. Hier gehören mir meine Daten, ich entscheide, was mit ihnen geschieht und wenn mein Provider dicht macht, habe ich (hoffentlich) noch ein Backup und kann woanders alles relativ problemlos neu aufsetzen.

Auf der anderen Seite fehlen (m)einem Blog natürlich viele der netten Dinge, die den Sozialen Netzwerken zueigen sind: Ich kann keine Freundeskreise anlegen, deren Nachrichten verfolgen und kommentieren oder einfach mal einen Knopf drücken, der »Gefällt mir« sagt.

Das war also der Ausgangspunkt meiner Überlegungen: Wie muß ein soziales Netzwerk aussehen, in dem der Nutzer immer und zu jedem Zeitpunkt Herr seiner Daten bleibt, das Kommentare und Like-Buttons ermöglicht und das notfalls sogar auf minimalem Webspace mit statischen Seiten funktioniert?

Webserver auf dem Desktop

Wir waren an solch einer Lösung schon einmal sehr nahe dran. Mit Dave Winers Software Radio Userland feierte schon im Jahre 2000 die Idee eines Webservers auf dem Desktop als Kommadozentrale für alle Webaktivitäten ihren Einstand. Der User bloggte dort und die Software schrieb via FTP (oder XML-RPC) statische Seiten auf einen Webspace der Wahl.

Nun füllt man sein Weblog nicht unbedingt nur von einem Rechner aus. Ich habe zum Beispiel über Jahre den Schockwellenreiter mithilfe von Frontier und einer selbstgeschriebenen, vereinfachten Version von Radio Userland von drei verschiedenen Rechner aus gefüttert. Anfangs hatte ich dazu die Datenbasis (die root-Datenbank) immer auf einem USB-Stick mit mir herumgetragen, nachdem ich aber mehrmals durcheinandergekommen war, weil ich bei der letzten Sitzung vergessen hatte, die aktuelle Version der Datenbank wieder zurück auf den Stick zu überspielen, war mir klar, daß dies keine dauerhafte Lösung sein konnte. Da kam mir die Dropbox gerade recht.

Datenbasis in der Cloud

Denn die Datenbasis in die Cloud – in meinem Falle in die Tropfenschachtel – zu verlegen, bedeutet ja nicht, seine Daten wegzugeben. Sie liegen ja weiterhin, nun aber »ordentlich« synchronisiert, auf meinen Rechnern und sind auch offline nutzbar. Der Sicherheitsaspekt spielt keine besondere Rolle, da es ja sowieso nur Daten sind, die ich für eine Veröffentlichung vorgesehen habe.

Ein Nachteil bei der Dropbox und ähnlichen Lösungen ist sicher, daß Konflikte auftreten können, wenn mehr als ein Nutzer gleichzeitig auf die Daten zugreift. Ich gehe allerdings davon aus, daß die Mehrheit der Nutzer des von mir angedachten sozialen P2P-Netzwerks Einzelnutzer sind. Wenn dies nicht der Fall ist, muß man an Stelle der Dropbox vielleicht ein öffentliches Repositorium wie zum Beispiel GitHub verwenden. Das macht die Sache zwar ein wenig komplizierter, löst aber das Problem der Zugriffskonflikte.

RSS als Nachrichtenstrom

Radio Userland hatte aber noch etwas, was es in die Nähe heutiger sozialer Netze rückt: Es hatte einen integrierten RSS-Feed-Reader, der nicht – wie zum Beispiel Googles Reader – die einkommenden Feeds nach den Quellen gruppierte, sonder sie als fortlaufenden zeitlichen Nachrichtenstrom anzeigte, ähnlich wie heute auch Google+, Facebook oder Twitter.

Das wäre die erste Komponente eines P2P-Netzes. Ich abboniere die RSS-Feeds meiner »Freunde« und wie auf Twitter, Facebook oder Google+ rauschen deren Nachrichten als River of News (Winer) an mir vorbei.

Publishing-Interface

Die drei Hauptseiten des User-Interface

Die zweite Komponente ist natürlich ein Publishing Interface. Das sieht erst einmal kaum anders aus, als die gewohnten Weblog-Eingabmasken. Und das Einzige, was es erst einmal herausschreiben muß, ist nichts anderes als einen RSS oder Atom-Feed, den die Software automatisch auf einen Webspace meiner Wahl der Öffentlichkeit zugänglich macht.

Natürlich ist mehr möglich: Zum einen könnte die Software – wie damals schon Radio Userland – alle oder auch nur einen Teil der Beiträge als Weblog mit statischen Seiten herausschreiben. Aber auch ein automatisches Füttern von Weblog-Software via API oder XML-RPC wäre möglich. Und es wäre dann völlig egal, ob es ein selbstgehostetes WordPress-Blog ist oder ich ein Blog bei einem Bloghoster wie Blogger oder Typepad vollschreibe. Die Originaldaten liegen ja weiterhin auf meinem Desktop, das Blog ist nur ein zusätzlicher Distributionskanal.

Und last but not least kann ich auch die vielgeschmähten sozialen Netzwerke via ihrer APIs damit bedenken. Und ich muß diese ja nicht mit all meinen Ergüssen vollmüllen. So bin ich zum Beispiel Teil einer netten Agility-Community auf Facebook und die Software sollte es so einrichten können, daß alle Beiträge, die mit Agility getagged sind, automatisch als Crossposting auf Facebook landen.

Das setzt natürlich einiges an Konfiguration voraus, die man nicht bei jedem Post vornehmen möchte. Daher sollte es eine Default-Konfiguration geben, in der der Nutzer festlegt, welche Sozialen Netze er bedienen möchte (im Minimalfall schreibt die Software eben nur einen RSS-Feed heraus), welche wie getaggten Beiträge in welchen Netzen landen und so weiter. Aber natürlich sollte der Nutzer die Möglichkeit haben, diese Konfiguration bei jedem Post überschreiben zu können.

Und so schweben mir auch zwei parallele Nutzerschnittstellen für die Postings vor: Eine einfache, die ähnlich den bisherigen sozialen Netzen ein simples und schnelles Posten erlaubt und die – weil der Nutzer das so gewohnt ist – über dem Nachrichtenstrom schwebt.

Und ein mehr elaboriertes Interface, das ähnlich der »Artikel erstellen«-Seite von WordPress, dem Nutzer mehr Möglichkeiten gibt, in die Konfiguration einzugreifen und diese für diesen einen Artikel anzupassen, Tags oder Kategorien zu vergeben und die Publikationspfade zu beeinflussen.

Schließlich sollte es natürlich noch eine Seite geben, die nur meine eigenen Aktivitäten anzeigt, ähnlich der Pinnwand von Facebook. Denn gerade, wenn ich mich entschließe, kein Blog zu führen, sondern »nur« einen RSS- oder Atom-Feed herauszuschreiben und vielleicht auch noch Facebook zu füttern, wäre diese Seite eine Art Blogersatz oder mehr ein Tagebuch meiner Aktivitäten nur für mich.

Und auch über dieser Seite sollte es – wie bei Facebook – die vereinfachte Eingabemaske geben. Denn das ist eines der Dinge, die mich bei Google+ regelmäßig ärgern: Ich kann Eingaben nur von der Startseite aus tätigen, nicht aber von meiner Profilseite.

Kommentare und »Gefällt mir«-Knöpfe

Bleibt nur noch das Problem der Kommentare und des »Like-Buttons«. Doch wenn man die Idee des RSS- oder Atom-Feeds konsequent zu Ende denkt, bietet sich auch dieser hier als Lösung an. Obwohl es sicher möglich ist, bestehende, wenn auch selten genutzte Tags der Feeds umzudefinieren, um das Erwünschte zu erreichen, schlage ich – einfach weil es sauberer ist – eine Namespace-Erweiterung (ähnlich der iTunes-Erweiterungen) vor: Für die Kommentare werden (mindestens) zwei zusätzliche Tags benötigt. Einmal einen <comment_title>-Tag und einen <comment_url>-Tag. Und dann bekommt jeder einzelne Feedbeitrag auf der Startseite einen Kommentar-Knopf, der ein Textfeld öffnet, in dem der Kommentar eingetippt werden kann.

Und erst einmal geht dieser Kommentar dann – wie jeder gewöhnliche Beitrag auch – als RSS-Feed auf die Reise. Nur, daß er die beiden vorgeschlagenen zusätzlichen Tags enthält. Was der jeweilige Reader nach Erhalt damit anstellt, bleibt ihm überlassen: Entwender er reiht sie – ähnlich Twitter – wie jeden anderen Beitrag auch in den Zeitstrom ein oder er behandelt sie wie Facebook oder Google+, das heißt, die Kommentare werden als Threads den jeweiligen Beiträgen zugeordnet.

Im zweiten Fall können die Kommentare dann natürlich auch beim nächsten Herausschreiben des Blogs auf diesem angezeigt werden – und das, ohne daß auf dem Server des Hosters irgendein Skript oder ähnliches laufen müßte.

Analog kann mit dem »Gefällt mir«-Knopf verfahren werden. Auch beim Einsatz dieses Elements müssen (mindestens) zwei zusätzliche Tags für den Feed bereitgestellt werden: Einmal einen <like_url>- und dann natürlich auch einen <like_title>-Tag. Und ob der lesende Server dann stolz die Anzahl der »Likes« zählt und anzeigt oder ob er es einfach ignoriert, bleibt wieder ihm überlassen.

Und ebenso geht das »Teilen« vonstatten: Ein »Share«-Button zu jedem Feedeintrag, ein zusätzlicher <share_url>- und ein <share_title>-Tag im Feed des Nutzers und dann wird der Beitrag erneut im Feed des Nutzers publiziert.

Share und Like in Googles Feedreader

Das alles erfordert ein gewisses Umdenken. Kommentieren, Teilen oder die Zustimmung per Knopfdruck findet nicht mehr auf dem Server des Autors statt, sondern im Feedreader des Lesers. Aber daß dies funktionieren kann, hat uns Googles Feedreader ja vorgemacht.

Auf den Schultern eines Riesen

Natürlich ist dies nicht alles auf meinem Mist gewachsen. Dave Winer, der seine Frontier-Fork, den OPML-Editor, bis an die Schmerzgrenze ausreizt, hat vieles von dem vorgedacht: Es fing ja schon mit Radio Userland an, dann teilte ich seine Bedenken gegenüber den Datensilos der Sozialen Netzwerke. Von ihm stammt der River of News, die Idee, RSS als Publishing-Format zu nutzen (was bei ihm, der sich ja gerne als »the father of RSS« bezeichnen läßt, auch nicht wundert) und mit Radio2 hat er diese Idee – auf Basis des OPML-Editors – auch weitgehend umgesetzt.

Allerdings geht Winer von einer Community aus, die sich weitesgehend um seine Software dreht, den Gedanken eines konsequenten Peer-to-Peer-Netzes hat er nicht zuende gedacht. Dennoch verdanke ich ihm viel und möchte das daher nicht unerwähnt lassen.

Ich bin sicher, daß man mit Winers OPML-Editor sehr schnell einen Prototypen dieser Ideen zusammenbasteln könnte – Winer hat zwar das auf meine Anregung aufgenommene Static Site Framework wieder aus der Standard-Distribution des OPML-Editors entfernt (warum eigentlich?), aber das läßt sich sicher leicht nachrüsten. Aber natürlich geht das mit nahezu jedem anderen Stück Web-Framework auch: Ob Django, Ruby on Rails, irgendeine PHP-Anwendung unter MAMP oder XAMPP oder ein aufgebohrtes DokuWiki … alles, was irgendwie eine Serverumgebung auf dem Desktop realisiert und RSS-Feed herausschreiben kann, eignet sich als Grundlage.

Und unter Umständen kann man – wie ich weiter unten ausgeführt habe – sogar auf die Server-Umgebung verzichten. Das einzige, was benötigt wird, ist ein Stück Software, das mit RSS- und ATOM-Feeds (inklusive der von mir vorgeschlagenen minimalen Ergänzungen) umgehen kann. Was das für eine Software ist und auf welchem Rechner unter welchem Betriebssystem sie läuft, ist zum Funktionieren dieses P2P Social Networks völlig egal.

Zusammenfassung

Die von mir vorgeschlagene Lösung hat den Vorteil, daß sie einmal eine konsequente Trennung von Redaktionsserver (das ist in diesem Fall der Server auf dem Desktop) und Produktionsserver – im Falle der minimalistischsten Lösung ist dies der Server, auf dem der RSS- oder Atom-Feed liegt – vornimmt. Dabei braucht der Redaktionsserver nicht einmal unbedingt ein wirklicher Server zu sein. Ich bin mir sicher, daß Elisp-Bastler es auch schaffen, zum Beispiel den Org-mode des Emacs so aufzubohren, daß er als »Redaktionsserver« einsetzbar ist. Lediglich das Einfahren des RSS-Feeds müßte dann vermutlich manuell vom Nutzer angestoßen werden.

Zum zweiten – und das ist mir das Wichtigste – behält der Nutzer die volle Kontrolle über seine Beiträge und Dateien. Artikel, Bilder, Videos … all dies liegt und bleibt auf dem Desktop des Nutzers, die jeweiligen Clients erhalten bestenfalls eine Kopie. Natürlich bleibt es dem Nutzer unbenommen, falls zum Beispiel sein Hoster nicht genug oder zu teuren Speicherplatz zur Verfügung stellt, auch Flickr, YouTube, Picasas Web Album oder andere Dienste zu nutzen und seine Multimedia-Dateien darüber einzubinden. Die Software sollte dies ermöglichen, in dem sie zum Beispiel alle Bilder, die in einem dafür vorgesehenen Ordner liegen, zu Flickr hochlädt; aber sie sollte trotzdem eine Kopie der Daten auf dem Desktop behalten.

Und auch das Publizieren in der Cloud bereitet so keine Kopfschmerzen mehr. Warum sollte man nicht anstelle eines »normalen« ISP wie Host Europe oder Strato seine statischen Daten zu Amazon S3 hochladen. Egal, wo es mir nicht mehr gefällt – mit einer Änderung in der Konfigurationsdatei und einem Knopfdruck kann ich mit all meinen Daten umziehen.

Mit diesem Entwurf habe ich einen langen Weg hinter mir. Ging ich bei meinen ersten Überlegungen (2003 in einer Keynote zur Blogtalk in Wien) noch davon aus, daß ein Community-Server und ein Trackback-Ping notwendig seien, um ein P2P Social Network zu schaffen, konnte ich zwar in späteren Überlegungen den Community-Server eliminieren, setzte dafür aber auf XMPP (Jabber) als verbindendes Protokoll. Erst langsam ging mir auf, daß die einfachste Lösung die sicherste Lösung ist und eine Lösung, die nur RSS resp. Atom als verbindendes Protokoll benötigt … einfacher geht es kaum.

Ich glaube nicht, hiermit den Stein der Weisen gefunden zu haben. Aber ich wollte die Idee einfach einmal niederschreiben, und sei es nur, um irgendje­man­den zuvorzukommen, der sich so etwas patentieren lassen und damit Geld verdienen will. Denn Trivialpatente sind ja gerade en voque in dieser seltsamen Zeit.

• Dieses Test-Driven-Django-Tutorial klingt vielversprechend, ist aber noch in einem frühen Entwicklungsstadium.
• Hier hat jemand Spaß mit Mathematik (und mit Python).
• Mit ein paar Tricks (und einem kleinen PHP-Skript) kann man so etwas wie »statische Kommentare« für Jekyll erzeugen. Hier gibt es den Source-Code.
• Im Frühjahr nächsten Jahres soll ein runderneuertes Emacs-Relase (genannt Emacs 24) erscheinen: Man kann aber jetzt schon damit rumspielen: Getting started with Emacs 24. MacOS-X-Nutzer brauchen dafür eine Pretest-Version des Emacs für MacOS X (funzt (noch) nicht mit Aquamacs). Und Emacs Prelude soll die Arbeit mit Emacs 24 noch komfortabler machen.
• ApeJS ist ein kleines und einfaches JavaScript-Framework für Googles App Engine.
• Wer für seine Projekte angepaßte LaTeX-Pakete verteilen muß, der kann dies mit diesem kleinen Python-Skript automatisieren (auchh die Kommetare bachten).

Wie immer hoffe ich, daß für jeden von Euch etwas dabei ist … [Alle Links: Peter van I. per Email.]

Googles Cloud SQL steht vorerst kostenlos zur Verfügung, soll später aber kostenpflichtig werden. Die Preise will Google mindestens 30 Tage vor dem Zeitpunkt veröffentlichen, ab dem sie gelten. [Golem.de, Google App Engine Blog]

Und schließlich hat sich auch Peter Magnusson (Engineering Director der GAE) auf Google+ zu Wort gemeldet und das neue Preismodell verteidigt. Zumindest zeichnet sich langsam Klarheit ab. [Google App Engine Blog]