Das Perl Template Toolkit (TT2) ist in der Version 2.24 auf dem Weg zum CPAN. Wer ungeduldig ist, kann sich die neue Version auch hier herunterladen (tar.gz, 500 KB). Neu sind ein paar neue Textoperationen und es gibt auch ein paar Bugfixes.

Denn bei all meiner (wiedererwachten) Begeisterung für RubyFrontier. Für komplexere Aufgaben ist TT2 sicher das bessere Werkzeug, das ich nicht aus den Augen verloren habe — auch wenn der Einstieg erst einmal schwieriger ist. [TT2 Mailingliste]

Andy Wardley hat vor ein paar Tagen die Version 2.23 des Perl Template Toolkits (TT2) hochgeladen. Es ist ein Wartungs-Release mit ein paar Bugfixes und ohne neue Features. Aber es zeigt, daß die Software doch noch aktiv weiterentwickelt wird. Und das freut mich …

Außerdem wurde die Dokumentation komplett neu überar­beitet und kann hier heruntergeladen werden.

• bbPress, die Forum-Software der Schöpfer von WordPress, die aus Eurem Blog oder Eurer BuddyPress-Installation ein soziales Netzwerk baut, hat einen gewaltigen Sprung nach vorne gemacht und die Version 2.0 erreicht.
• Vier Borkmarklets für Markdown-User.
• Browserspiele: Ben Firshman hat einen NES Emulator in JavaScript geschrieben.
• SlideShare, die Sharing-Site für PowerPoint-Präsentationen hat Flash rausgeschmissen und ein komplettes Rebuild in HTML5 gewagt.
• Python and Django on Heroku, ein Quickstart.
• Mit Custom Maps für Android könnt Ihr eure eigenen Karten mit Euch nehmen.
• Google JS Test ist ein Test-Framework für JavaScript. Hier gibt es eine Einführung dazu: Introducing Google JS Test.
• Ruby im Browser interatkiv ausprobieren. Warum? Weil es geht!
• Noch mehr Programmiersprachen im Browser. Und alle Interpreter sind in JavaScript geschrieben.
• Hier räumt jemand mit den Mythen über die Einrückungen in Python auf.
• Traurig: BerliOS, die SourceForge-Alternative der Fraunhofer-Gesellschaft, schließt zum 31. Dezember 2011 ihre Pforten.
• GNU TeXmacs ist so etwas wie ein Mathematica-Notebook in LaTeX und läuft auch unter MacOS X. Notiz an mich: Testen!
• Auf Try Flask kann man das Python-Microframework Flask online ausprobieren, ohne sich Flask auf der eigenen Maschine installieren zu müssen.
• Mit großen Datenmengen umgehen: mincemeat.py ist ein MapReduce-Framework für Python.
• Wenn die Schlange mit dem Router quatscht: Miranda ist ein in Python geschriebener UPnP-Client.
• Mou (beta) will der fehlende Markdown-Editor für Web-Entwickler auf MacOS X sein. Läuft aber erst ab dem Löwen, daher kann ich das leider nicht testen.
• BlazeBlogger ist ein weiteres Static Site Framework in Perl. Die Software ist gut dokumentiert. Noch ein Testkandidat …
• Markdown für den Emacs (ebenfalls testen!)
• Ich komme mit dem Testen gar nicht mehr nach: Pyll ist ein weiteres Static Site Framework, diesmal in Python geschrieben.
• Und wer statische Seiten mit Haskell herausrendern will, könnte yst mal ausprobieren. Nutzt YAML als Markup-Sprache. (Nein, das versuche ich erst gar nicht, selber zu testen).
• Twitter selbst gemacht: Pidiblog ist ein einfaches aber flexibles, in PHP geschriebenes Microblogging-System, das einfach zu installieren ist und ohne Datenbankanbindung läuft.
• Publizieren mit der Tropfenschachtel (und EC2): Dropbox is my publish button (nutzt ebenfalls Markdown als Auszeichnungssprache).

Okay, das war wieder eine Menge Holz. Wie immer hoffe ich, daß für jeden von Euch etwas dabei ist. [Alle Links: Peter van I. per Email.]

• Chronicle ist ein Blog Compiler, geschrieben in Perl. Er nimmt HTML-, Textile- oder Markdown-Dateien entgegen und rendert statische HTML- und RSS-Dateien heraus. Beispiele sind Steve Kemp’s Blog (das ist der ursprüngliche Entwickler von Chronicle) und das Blog von Kai Wasserbäch, der die Weiterentwicklung übernommen hat. Notiz an mich: Testen!
• Schöner Coden: Hier git es einen Style Guide für Ruby-Entwickler.
• Vielleicht interessant für Datenjournalisten: Panda ist eine schnelle, fehlertolerante Python-Bibliothek, die mit großen (semi-) strukturierten Daten umgehen kann.
• Und last but noch least ein schönes und ausführliches Tutorial, wie man Python speziell bei numerischen Aufgaben beschleunigen kann: Performace Python.

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

[Update wg. Chronicle]: Kai Wasserbäch schrieb mir (weil die Kommentar­funk­tion von WordPress ihn aus mir unerfindlichen Gründen nicht haben wollte):

But I basically wrote, that I’m not the upstream author, just the Debian maintainer. Mr. Kemp stays upstream (or to stick with a more common, ie. non-Debian, nomenclature: Mr. Kemp continues to develop Chronicle. I’m just the packager for Debian now (which Mr. Kemp was too before)).

Ich hoffe, damit sind alle Unklarheiten beseitigt.

Das Perl-Skript Perlator (GPL) erzeugt aus speziell formatierten Textdateien und einer in HTML und mit wenigen Steueranweisungen gestalteten Vorlage eine komplette Website.

Es generiert nicht einfach nur mehr oder weniger lose zusammen­hängende HTML-Seiten, es ist auch in der Lage, umgekehrt chronologisch sortierte Ansichten von Nachrichten zu generieren, wie man sie etwa von Blogs her kennt. Außerdem entstehen Newsfeeds in den Formaten RSS 0.9, 1.0 und 2.0, die jeder halbwegs aktuelle Newsreader zu interpretieren weiß. Als Orientierungshilfe für den Google-Searchbot erstellt das Skript eine Sitemap und informiert Google gegebenenfalls über das Vorliegen einer neuen Sitemap.

Sämtliche entstandenen HTML- und XML-Dateien sowie alle dazugehörigen Inhalte wie Bilder, PDFs, Videos et cetera überträgt das Skript automatisch per FTP zum Webserver, und zwar nur die, die sich seit dem letzten Upload geändert haben. Ob sich eine Datei geändert hat, stellt das Skript anhand eines MD5-Hash fest, den es nach jedem Upload aus der Datei errechnet und diesen mit dem gespeicherten vergleicht.

Perlator basiert auf dem Perl Template Toolkit und ist eine Eigententwicklung des Heise-Verlags. Notiz an mich: Unbedingt testen! [Peter van I. per Email.]

PerlDancer will der einfachste Weg sein, um Web-Applikationen in Perl zu erstellen. Klingt verlockend, auch der obige Screencast: Building a blog engine using Perl Dancer. Sollte ich mir vielleicht auch einmal genauer anschauen. [Peter van I. per Email.]

Ich hatte mich die letzten Monate mit meiner Unentschlossenheit, ob nun das Perl Template Toolkit (TT2) oder RubyFrontier mein nächstes Werkzeug für statische Webseiten werden wird, selber ziemlich lahmgelegt. Nachdem ich die letzte Zeit eigentlich verstärkt auf RubyFrontier gesetzt hatte (zum Beispiel in meinem Testbett), habe ich an diesem Wochenende intensiv mit dem Template Toolkit gespielt und nun sind die Würfel gefallen.

Ich habe das Grundgerüst einer Site mit hierarchischer Navigation, Next-Prev-Navigation und einem hierarchischen Krümelpfad. Der Einstieg war nicht leicht, denn das Template Toolkit ist anfangs bedeutend sperriger als RubyFrontier, aber es lohnt sich:

1. Man kann viel mehr als in RubyFrontier mit bordeigenen Mittel erledigen und muß nicht eine externe Programmiersprache bemühen — obwohl das natürlich auch geht. Und da ist mir Perl um einiges lieber (weil ich es schon so lange kenne, vermute ich); mit Ruby bin ich einfach nicht warm geworden.
2. Das Perl Template Toolkit ist um einiges schneller als RubyFrontier, beim letzteren kostet der eigentlich nützliche Glossary-Mechanismus bei großen Sites (mit vielen tausend Seiten) zu viel Zeit.
3. TT2 ist älter und dadurch ausgereifter. Trotzdem wird es noch aktiv weiter entwickelt (TT3 steht (irgendwann) vor der Tür.) Und auf der Mailingliste ist auch mehr los.

Was ich vermisse, sind die Wiki-ähnlichen Links, die RubyFrontier ermöglicht. Aber dazu braucht es eben den oben geschmähten, zeitverschlingenden Glossary-Mechanismus.

Bei meinen Erkundunge half mir das Buch zum Toolkit weiter — ohne geht es glaube ich auch kaum. Leider hat es einige Fehler, zwei davon haben mich sehr lange aufgehalten:

1. Das Verzeichnes images muß im Verzeichnis src liegen und nicht darüber.
2. Die vorherige Seite bekommt man natürlich mit loop.prev und nicht mit loop.last.
3. Und es gibt noch ein paar Flüchtigkeitsfehler dieser Sorte …

Trotzdem hilft einem das Buch, die Philosophie hinter den Toolkit zu verstehen. Man sollte nach einer ersten Lektüre die Beispielanwendung im 11. Kapitel unbedingt einmal komplett selber nachvollziehen — danach ist man schlauer.

Hilfreich ist auch ein Editor, der Projekte verwalten kann. An diesem Wochenende habe ich deswegen TextMate zum ersten Mal so richtig schätzen gelernt.

Und ein Webserver auf dem Desktop ist natürlich extrem nützlich. Ich habe auf meinem Macs MAMP dafür genutzt und TT2 die fertigen Seiten direkt in MAMPs htdoc-Verzeichnis schreiben lassen.

Ich werde das Gelernte erst einmal in einem Buchprojekt einsetzen (mehr dazu, sobald ich mehr habe). Ich hoffe, dabei so viel über TT2 zu lernen, daß ich im Anschluß daran den Schockwellenreiter damit statisch umsetzen kann (momentan ist mir allerdings noch völlig schleierhaft, wie ich aus den Blogposts möglichst automatisch die Archivseiten und den RSS-Feed generiere (aber das weiß ich auch bei RubyFrontier (noch) nicht).

Wenn ich mich jetzt noch entscheiden könnte, ob ich die dynamischen Teile mit Googles App Engine oder mit Django generiere, wäre ich noch weiter. Still diggin’!

• Für die Freunde der roten Eisenbahn, die auch Jünger des angebissenen Apfels sind: Setting up PostgreSQL for Ruby on Rails development on MacOS X.
• Unicode und kein Ende: Why does modern Perl avoid UTF-8 by default? Gute Frage, nächste Frage.
• Heroku, der preisgekrönte Ruby Platform as a Service (PaaS) Anbieter, kann jetzt noch mehr (sagt er).
• Wer — aus welchen Gründen auch immer — Google Map Maker (und nicht OpenStreetMap) unterstützen möchte/muß, findet jetzt ein Help-Center auf Googles Seiten. In Deutschland geht Googles Map Maker sowieso (noch) nicht, dabei ist — zumindest in Berlin, wo ich das nachprüfen kann — Googles Kartenmaterial so schlecht (im Vergleich zu den OSM-Karten, aber auch Yahoo! Maps), daß sie Hilfe dringend benötigen könnten.
• Auch Googles App Marketplace scheint nicht ganz problemfrei zu laufen: Malware from Google Market menaces Android users. Schreiben die Geier vom Register …
• Schlanke Edelsteine: SlimGems, a drop-in replacement for RubyGems. Mhmmm, ich weiß nicht …
• Der Versuch eines Neuanfangs: jQAPI – Alternative jQuery Documentation — für jQuery 1.6.
• Und das Beste zum Schluß: Look Ma, no Flash! Das kleine Online-Büchlein »20 Dinge, die ich über Browser und das Web gelernt habe« mag zwar etwas zu sehr nach Chrome glänzen (das Projekt ist aus dem Hause Google), aber es ist eine wunderschöne Demonstration, was man alles mit HTML5 anstellen kann. Und es funzte bei mir auch im Safari und im Firefox. Jetzt fehlt für Nachahmer nur noch ein Making Of.

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

• HTML2PDF (Apache-Lizenz) ist ein HTML/CSS-Konverter nach PDF, der in Python geschrieben wurde.
• HTML2TeX ist ein Ruby-Programm, das (Überraschung! ) HTML nach LaTeX konvertiert.
• Das gleiche erledigt HTML to LaTeX (GPL), ein in C geschriebenes Kommandozeilen-Tool (Quellcode).
• Natürlich geht das auch in Perl mit HTML2LaTeX.
• Pandoc wurde auch schon in meinen Kommentaren gelobt. Einziger Nachteil: Das Teil benötigt eine Haskell-Umgebung.

So viel zu testen, so wenig Zeit … [Peter van I. per Email.]

• Perl-Guru chromatic hat ein Buch geschrieben: Modern Perl, und das steht unter einer CC-Lizenz (by-nc-nd), so daß Ihr es alle kostenlos runterladen dürft. Eine Ebook-Version ist in Vorbereitung. Wer den Autor unterstützen möchte oder das Buch aus anderen Gründen zwischen zwei Pappedeckel gepresst braucht, kann es auch bei Amazon kaufen.
• Der beste Editor der Welt ist in der Version 9.6.1 draußen. Es ist ein Bugfix-Release ohne neue wesentliche Features.
• Spaß mit Automator und AppleScript: S3 upload Snow Leopard service. Ein einfacher Weg, Dateien quasi nebenher auf Amazons S3 hochzuladen.
• Wie man Yahoo!s Röhren mit Googles App Engine verheiratet: Running Yahoo! Pipes on Google App Engine. Ich will mich in der nächsten Zeit sowieso mal intensiver mit Googles Cloud auseinandersetzen — da wäre das doch ein schönes Beispielprojekt.
• Wem seine Dropbox noch nicht genug Speicherplatz bietet: SugarSync funktioniert ähnlich und bietet in der freien Version noch einmal 5 GB Online-Storage.
• Last but not least noch ein Bugfix-Update: Auch der VLC Media Player erfreut uns mit einer neuen Version (VLC 1.1.5).

Das wäre ja wieder so viel zum Spielen und ich habe immer noch viel zu wenig Zeit. Aber vielleicht ist der eine oder andere Link für den einen oder anderen von Euch da draußen nützlich. [Peter van I. per Email.]

• Verschärfter Flash-Alarm und lange Ladezeiten — aber trotzdem ist Sounds of Hamburg einen Besuch wert. Und vielleicht werdet Ihr dabie selber kreativ.
• Es gibt Neues von Amazons S3: Neben Reduced Redundancy Storage (RRS) ist auch Versionierung möglich. Damit woll eine größere Daten- und Ausfall­sicherheit erreicht werden.
• Meine Studenten hatten es für einige Mashups häufiger genutzt, ich aber noch nicht: Googles Panoramio ist ein Platz für georefernzierte Photos. Interessant ist auch die Analyse auf diesen Seiten.
• Wiederholung! RSS Replay.
• Bei O’Reilly: Damian Conway über die Zukunft von Perl.
• Für Umsteiger auf Python 3 (bekanntlich warte ich selber ja noch ab): WSGI on Python 3.
• Mit Googles App Engine wollte ich ja auch schon lange mal spielen und Django steht auch auf meiner Liste der zu erlernenden Spielzeuge. Vielleicht kann ich das ja kombinieren: Django 1.2 on Google App Engine.

Ich schaffe das alles nicht, aber vielleicht kann einer von Euch da draußen mit den Tips etwas anfangen. [Alle Links: Peter van I. per Email.]

If you’re using Python 3.0 stop reading right now! The way all this works has changed!

Da hat man sich einen Wolf programmiert, damit alles halbwegs funktioniert und dann kommen die Nerds mit ihren neuen Versionen und der ganze Schlamassel beginnt von vorne. Wir Anwender brauchen nicht ständig neue Features, sondern auf Jahre — wenn nicht gar Jahrzehnte — stabile Versionen, auf die wir bauen können (C, COBOL, FORTRAN und mittlerweile sogar Java machen doch vor, daß das geht). Ich hoffe inbrünstig, daß Python 3 genau so erfolglos wie Zope 3 werden wird und daß wir so weiterhin stabile 2.x-Versionen bekommen und nicht unseren ganzen Code umschreiben müssen. Wer unbedingt spielen will, der erfinde doch einfach eine neue Sprache. Akademische Papiere sind voll davon. (Ich hoffe übrigens aus den gleichen Gründen, daß Perl 6 ein totgeborenes Kind bleiben wird.) [Peter van I. per Email.]

[Update] (wegen einiger Reaktionen in meinen Kommentaren will ich meinen Standpunkt konkretisieren): Im Gegensatz zu C oder FORTRAN liefern Skriptsprachen keine Binaries, sondern sind auf eine Runtime nicht nur auf dem Entwicklungs-, sondern auch auf dem Zielrechner angewiesen (insofern hinkt der Vergleich oben natürlich etwas). Und häufig sind Skripter keine ausgebildeten Programmierer, sondern kommen aus anderen Jobs und wollen sich mit ihren Skripten »nur« ihre Arbeit erleichtern (was gut und ihr gutes Recht ist). Und daher ist Abwärtskompatibilität meiner Meinung nach ein absolutes Muß.

Denn ich stehe mittlerweile vor einem Chaos, das ich kaum noch bewältigen kann. Mein Klientel verlangt mittlerweile Python 2.5, Python 2.6 (bald auch Python 2.7) und Python 3.0/3.1 auf den Institutsrechnern, damit die unterschiedlichen Skripte unterschiedlicher Herkunft sauber laufen (so läuft zum Beispiel das Natural Language Toolkit »nur« mit Python 2.5 stabil).

Und natürlich wissen sie schon nach kurzer Zeit nicht mehr, welches Python wie aufgerufen werden muß (/usr/local/python für Python 2.6, /usr/local/bin/python für Python 2.5 etc. — und das hängt auch noch davon ab, ob MacOS X 10.4, 10.5 oder 10.6 installiert ist) und welches Python für welche Aufgaben zuständig ist …

Das Chaos habe ich auch bei anderen Programmen: MacOS X 10.4 ist zum Beispiel auf vielen Rechnern noch installiert, weil nur da noch ein Mac OS 9 (in der Classic-Umgebung) startet, unter der dann FrameMaker läuft (ein von Adobe für den Mac seit 2004 nicht mehr weiterentwickeltes DTP-Programm). Nun kann man sagen, sollen die Wissenschaftler doch umsteigen. Aber was sollen sie machen, wenn sie noch Dutzende unpublizierter Artikel oder gar Bücher in FrameMaker geschrieben aus den letzten — sagen wir mal — 10 Jahren auf ihrer Festplatte haben? Wissenschaftliche Arbeiten dauern eben manchmal Jahre — in manchen Fällen auch Jahrzehnte.

Daher mein Aufschrei nach Kontinuität. Denn das Gleiche gilt auch für die für solche Arbeiten verwendeten Skripte.

Meine Konsequenz habe ich gezogen. »Mein« Python (hier aus reinem Selbstschutz penibel dokumentiert) ist immer noch Python 2.5 und erst, wenn all die dort aufgeführten Pakete sauber unter Python 3.x laufen, werde ich — vielleicht — umsteigen. Und ich empfehle allen meinen Kollegen, es mir gleichzutun.

Denn das diese Kontinuität über Jahrzehnte möglich ist, haben doch Donald Knuth mit TeX und Leslie Lamport mit LaTeX bewiesen. Waum nimmt sich niemand ein Beipiel daran?

Daher schmerzt es zu erfahren, daß UserLand Software zum 31. Dezember dieses Jahres seine Pforten für immer schließt. Nicht nur, weil ein weiterer Web-Pionier das Zeitliche gesegnet hat, sondern auch und gerade für die unentwegten Radio UserLand- und Manila-Nutzer, die ihren Hoster verlieren.

Und in der Community werden eifrig (und auch ein wenig verzweifelt) die Alternativen diskutiert. Klar ist, daß Open Source Frontier seit Jahren nicht wirklich weiterentwickelt wurde und so kommen für die einen Matt Neuburgs Ruby-Spielzeuge rb-appscript und RubyFrontier in Frage, während andere auf Django und Python setzen.

Mein derzeitiger Favorit für die Generierung großer Mengen statischer Seiten ist das Perl Template Toolkit. Doch obwohl ein sehr mächtiges Werkzeug, fehlt mir doch manchmal die Eleganz, die dem Vererbungsmechanismus von Frontier, aber auch Zope zu eigen war. Aber es sieht so aus, als ob es momentan keine Alternative dazu gäbe …

Trotzdem habe ich beschlossen, mir in den nächsten Tagen Django intensiver anzuschauen. Schon allein, weil das Teil auch mit der Google App Engine harmoniert und daher für die Programmierung von Googles Wellen nützlich sein kann. Und weil ich nach Strategien suche, wie große Sammlungen schnell und komfortabel ins Netz gestellt werden können, ohne daß der Nutzer gleich ein Informatikstudium absolviert haben muß. Mehr darüber in den nächsten Tagen.

Andersherum geht es natürlich auch, wie dieses Weblog zeigt (ab in den Feedreader damit). [O'Reilly Blog]

Hier denke ich weniger an eine Blog Engine als an einen Ersatz für das alte Frontier Static Site Tool, das ja bekanntlich leider schon lange nicht mehr gepflegt wird und mit dem ich viele Webauftritte realisiert hatte (unter anderem über Jahre auch den Schockwellenreiter). Wie gesagt, das Teil ist so ohne weiteres nicht gerade eine Blog-Engine — obwohl man sie sicher dazu aufbohren könnte —, aber ich denke dabei auch eher an Sites wie die Nigeria-Connection oder auch an die vielen Sammlungs-Seiten am Institut.

Der Nachteil dieses Toolkits ist, daß es lokal auf dem Desktop installiert sein muß. Aber bei meinen bisherigen Test habe ich die Daten auf der Dropbox abgelegt und konnte auf sie ohne Probleme von meinem Desktop zu Hause, von meinem Laptop unterwegs und von meinem Desktop am Institut zugreifen — eine funktionierende Internet-Verbindung vorausgesetzt.

Natürlich ist Dropbox nicht gerade ideal, wenn mehrere Personen die Daten bearbeiten und publizieren wollen, aber mit einem Versionsverwaltungssystem wie Git oder Subversion könnte man Konflikte vermeiden und die Daten zentral zur Verfügung stellen. Und das Perl Template Toolkit greift auf Textdateien zu, die irgendiwe (zum Beispiel auch via Skript) zur Verfügung gestellt werden — ideal für große Sammlungen.

Das Perl Template Toolkit muß natürlich auch nicht auf allen Rechnern installiert sein. Es wird ja nur dort gebraucht, wo die Berechtigung zum Publizieren vorhanden ist. Das heißt: Viele stellen mit ihren gewohnten (Textverarbeitungs-) Werkzeugen mithilfe eines CVS die Daten zur Verfügung und ein Redaktionsserver stellt diese als statische Seiten ins Netz. Einfacher kann ein CMS nicht funktionieren …