programmierung - 23.6.2005 - 31.7.2005

Einfacher Dateisystem-Browser mit Django schreiben

Dieser Artikel ist mal wieder in Englisch, da er auch für die Leute auf #django interessant sein könnte. Dieser Beitrag zeigt, wie man einen sehr einfachen Dateisystem-Browser mit Django erstellt. Dieser Dateisystem-Browser verhält sich größtenteils wie ein statischer Webserver, der die Verzeichnisnavigation ermöglicht. Die einzige Besonderheit ist, dass Sie das Django-Admin verwenden können, um Dateisysteme zu definieren, die in den Namensraum des Django-Servers eingebunden werden. Dies dient nur zur Demonstration, wie eine Django-Anwendung verschiedene Datenquellen neben der Datenbank nutzen kann. Es ist nicht wirklich dazu gedacht, statischen Inhalt zu servieren (obwohl es mit hinzugefügter Authentifizierung quite nützlich für eingeschränkten statischen Inhalt sein könnte!).

Auch wenn die Anwendung sehr einfache Sicherheitsprüfungen an den übergebenen Dateinamen durchführt, sollten Sie dies nicht auf einem öffentlichen Server ausführen - ich habe keine Sicherheitstests durchgeführt und es könnte buttloads von schlechten Dingen geben, die Ihre privaten Daten der Welt preisgeben könnten. Sie wurden gewarnt. Wir beginnen wie üblich mit der Erstellung der Dateisystem-Anwendung mit dem Befehl django-admin.py startapp filesystems. Machen Sie es einfach so, wie Sie es mit Ihrer Umfrageanwendung im ersten Tutorial gemacht haben. Nur zur Orientierung, so sieht die myproject-Verzeichnis auf meiner Entwicklungsmaschine aus:


.
|-- apps
| |-- filesystems
| | |-- models
| | |-- urls
| | `-- views
| `-- polls
| |-- models
| |-- urls
| `-- views
|-- public_html
| `-- admin_media
| |-- css
| |-- img
| | `-- admin
| `-- js
| `-- admin
|-- settings
| `-- urls
`-- templates
 `-- filesystems

Nach der Erstellung der Infrastruktur beginnen wir mit dem Aufbau des Modells. Das Modell für die Dateisysteme ist sehr einfach - nur ein Name für das Dateisystem und ein Pfad, an dem die Dateien tatsächlich gespeichert sind. Hier ist es also, das Modell:


 from django.core import meta

class Filesystem(meta.Model):

fields = ( meta.CharField('name', 'Name', maxlength=64), meta.CharField('path', 'Path', maxlength=200), )

def repr(self): return self.name

def get_absolute_url(self): return '/files/%s/' % self.name

def isdir(self, path): import os p = os.path.realpath(os.path.join(self.path, path)) if not p.startswith(self.path): raise ValueError(path) return os.path.isdir(p)

def files(self, path=''): import os import mimetypes p = os.path.realpath(os.path.join(self.path, path)) if not p.startswith(self.path): raise ValueError(path) l = os.listdir(p) if path: l.insert(0, '..') return [(f, os.path.isdir(os.path.join(p, f)), mimetypes.guess_type(f)[0] or 'application/octetstream') for f in l]

def file(self, path): import os import mimetypes p = os.path.realpath(os.path.join(self.path, path)) if p.startswith(self.path): (t, e) = mimetypes.guess_type(p) return (p, t or 'application/octetstream') else: raise ValueError(path)

admin = meta.Admin( fields = ( (None, {'fields': ('name', 'path')}), ), list_display = ('name', 'path'), search_fields = ('name', 'path'), ordering = ['name'], )


Wie Sie sehen können, ist das Modell und das Admin eher langweilig. Was interessant ist, sind jedoch die zusätzlichen Methoden `isdir`, `files` und `file`. `isdir` überprüft, ob ein gegebener Pfad unter dem Dateisystem ein Verzeichnis ist oder nicht. `files` gibt die Dateien des angegebenen Pfades unter dem Basispfad des Dateisystems zurück und `file` gibt den echten Dateipfad und den MIME-Typ einer gegebenen Datei unter dem Basispfad des Dateisystems zurück. Alle drei Methoden überprüfen die Gültigkeit des übergebenen Pfades - wenn der resultierende Pfad nicht unter dem Basispfad des Dateisystems liegt, wird eine ValueError ausgelöst. Dies soll sicherstellen, dass niemand `..` im Pfadnamen verwendet, um aus dem definierten Dateisystem-Bereich auszubrechen. Das Modell enthält also spezielle Methoden, die Sie verwenden können, um auf den Inhalt des Dateisystems selbst zuzugreifen, ohne sich Gedanken darüber zu machen, wie dies in Ihren Ansichten zu tun ist. Es ist die Aufgabe des Modells, solche Dinge zu kennen.

Der nächste Teil Ihres kleinen Dateisystem-Browsers wird die URL-Konfiguration sein. Sie ist eher einfach, sie besteht aus der Zeile in `settings/urls/main.py` und dem Modul `myproject.apps.filesystems.urls.filesystems`. Zuerst die Zeile im Haupt-URLs-Modul:

from django.conf.urls.defaults import *

urlpatterns = patterns('', (r'^files/', include('myproject.apps.filesystems.urls.filesystems')), )


Als nächstes das eigene URLs-Modul der Dateisysteme:

from django.conf.urls.defaults import *

urlpatterns = patterns('myproject.apps.filesystems.views.filesystems', (r'^$', 'index'), (r'^(?P.?)/(?P.)$', 'directory'), )


Sie können die Anwendung nun der Haupt-Einstellungsdatei hinzufügen, damit Sie es später nicht vergessen. Suchen Sie einfach nach der Einstellung INSTALLED_APPS und fügen Sie den Dateibrowser hinzu:

INSTALLED_APPS = ( 'myproject.apps.polls', 'myproject.apps.filesystems' )


Ein Teil fehlt noch: die Ansichten. Dieses Modul definiert die extern erreichbaren Methoden, die wir im URL-Mapper definiert haben. Wir benötigen also zwei Methoden, `index` und `directory`. Die zweite funktioniert tatsächlich nicht nur mit Verzeichnissen - wenn sie eine Datei übergeben bekommt, präsentiert sie einfach den Inhalt dieser Datei mit dem richtigen MIME-Typ. Die Ansicht macht Gebrauch von den in dem Modell definierten Methoden, um auf den tatsächlichen Dateisysteminhalt zuzugreifen. Hier ist der Quellcode für das Ansichtsmodul:

from django.core import template_loader from django.core.extensions import DjangoContext as Context from django.core.exceptions import Http404 from django.models.filesystems import filesystems from django.utils.httpwrappers import HttpResponse

def index(request): fslist = filesystems.getlist(orderby=['name']) t = templateloader.gettemplate('filesystems/index') c = Context(request, { 'fslist': fslist, }) return HttpResponse(t.render(c))

def directory(request, filesystem_name, path): import os try: fs = filesystems.getobject(name exact=filesystemname) if fs.isdir(path): files = fs.files(path) tpl = templateloader.gettemplate('filesystems/directory') c = Context(request, { 'dlist': [f for (f, d, t) in files if d], 'flist': [{'name':f, 'type':t} for (f, d, t) in files if not d], 'path': path, 'fs': fs, }) return HttpResponse(tpl.render(c)) else: (f, mimetype) = fs.file(path) return HttpResponse(open(f).read(), mimetype=mimetype) except ValueError: raise Http404 except filesystems.FilesystemDoesNotExist: raise Http404 except IOError: raise Http404


Sehen Sie, wie die Elemente des Verzeichnismusters als Parameter an die Directory-Methode übergeben werden - der Dateisystemname wird verwendet, um das richtige Dateisystem zu finden, und der Pfad wird verwendet, um den Inhalt unter dem Basispfad dieses Dateisystems zuzugreifen. MIME-Typen werden mit dem mimetypes-Modul aus der Python-Distribution ermittelt, übrigens.

Der letzte Teil unseres kleinen Tutorials sind die Vorlagen. Wir benötigen zwei Vorlagen - eine für den Index der definierten Dateisysteme und eine für den Inhalt eines Pfades unter einem Dateisystem. Wir benötigen keine Vorlage für den Dateiinhalt - der Dateiinhalt wird roh geliefert. Zuerst also die Hauptindexvorlage:

{% if fslist %}

definierte Dateisysteme

{% else %}

Entschuldigung, es wurden keine Dateisysteme definiert.

{% endif %}

Die andere Vorlage ist die Verzeichnisvorlage, die den Inhalt eines Pfades unter dem Basispfad des Dateisystems anzeigt:

{% if dlist or flist %}

Dateien in //{{ fs.name }}/{{ path }}

    {% for d in dlist %}
  • {{ d }}
  • {% endfor %} {% for f in flist %}
  • {{ f.name }} ({{ f.type }})
  • {% endfor %}
{% endif %}


Beide Vorlagen müssen irgendwo in Ihrem TEMPLATE-PFAD gespeichert werden. Ich habe einen Pfad im TEMPLATE-PFAD mit dem Namen der Anwendung eingerichtet: `filesystems`. Dort habe ich die Dateien als `index.html` und `directory.html` gespeichert. Natürlich würden Sie normalerweise eine Basisvorlage für die Website erstellen und diese in Ihren normalen Vorlagen erweitern. Und Sie würden eine `404.html` hinzufügen, um 404-Fehler zu behandeln. Aber das bleibt als Übung für den Leser. Nachdem Sie Ihren Entwicklungsserver für Ihr Admin gestartet haben (vergessen Sie nicht, DJANGO SETTINGS MODULE entsprechend einzustellen!), können Sie ein Dateisystem zu Ihrer Datenbank hinzufügen (haben Sie irgendwann zwischenzeitlich `django-admin.py install filesystems` gemacht? Nein? Machen Sie es jetzt, bevor Sie Ihren Server starten). Jetzt stoppen Sie den Admin-Server, ändern Sie Ihr DJANGO SETTINGS MODULE und starten Sie den Haupt-Einstellungsserver. Jetzt können Sie zu [http://localhost:8000/files/](http://localhost:8000/files/) surfen (zumindest wenn Sie Ihre URLs und Ihren Server so eingerichtet haben wie ich) und die Dateien in Ihrem Dateisystem durchsuchen. Das ist alles. War nicht sehr kompliziert, oder? Django ist wirklich einfach zu verwenden.

Wer mit PostgreSQL und Frontier arbeiten will, einfach die PostgreSQL Extension for Frontier installieren. Für Mac und Windows.

Wer glaubte das ISO Zeitangaben einfach nur die YYYY-MM-TT HH:MM:SS.HS ist, vergesst es: International standard date and time notation. War ja klar, ist ja ein ISO Standard ...

Leichen im Keller

Jede Software hat sie - irgendwelche Leichen im Keller die anfangen zu stinken wenn man sie findet. Django leider auch. Und zwar die Behandlung von Unicode. Der automatisch generierte Admin in Django schickt immer XHTML und utf-8 raus an den Browser. Die Browser schicken daher auch utf-8 zurück. Jetzt gibt es aber Browser die bei solchen Sachen dann ein etwas anderes Format für die zu schickenden Daten benutzen - das sogenannte Multipart-Format. Dieses wird verwendet weil es die einzige garantierte Methode in HTTP-POST ist, bei der man einen Zeichensatz mitschicken kann.

Dummerweise parsed Django diese Multipart-POSTs mit dem email Modul von Python. Dieses produziert dann fleissig Unicode-Strings aus den als utf-8 markierten Parts. Was ja auch an und für sich korrekt ist - nur sind im Django-Source überall im Sourcecode str() Aufrufe verstreut. Und die krachen dann natürlich, wenn sie unicode vorgeworfen bekommen in dem Zeichen oberhalb von chr(128) drin sind.

Ich hab mir den Source mal angeguckt, der realistischste Ansatz dürfte sein in Django einfach generell dafür zu sorgen das auch Unicode-Ergebnisse dann wieder nach utf-8 gewandelt werden, so das intern nur normale Python-Strings benutzt werden. Das klappt auch soweit, aber es gibt dann noch Probleme mit manchen Datenbanken die bei Speicherung von utf-8 Inhalten das erkennen und dann beim Lesen der Inhalte wieder Unicode produzieren - SQLite ist so eine Datenbank.

Tja, das wird nicht ganz einfach zu beheben sein. Ich hab mich schon mal dran versucht, das ist ein ziemlich ekliges Thema und leider in Django überhaupt nicht berücksichtigt worden - und daher kracht es an allen Ecken und Enden. Mal gucken ob ich da nicht doch noch was brauchbares hinkriege ...

Was mir auch noch aufgefallen ist: Django schickt den Content-type nur über ein meta-Tag mit http-equiv raus. Das ist ein übler Hack, wesentlich besser wäre es wenn der Content-type korrekt als Header gesetzt wäre, dann kann auch nix schief gehen wenn z.B. Apache einen Default-Charset zufügen will. Und die Browser würden auch wesentlich reproduzierbarer reagieren.

Jedenfalls ist das wieder der typische Fall von amerikanischen Programmierern. Die erzählen einem gerne das man einfach nur auf Unicode und utf-8 wechseln soll wenn man von seinen Zeichensatzkodierungsproblemen berichtet, aber ich habe bisher noch keine Software eines amerikanischen Programmierers gesehen die Unicode korrekt gehandhabt hätte ...

Ansonsten gibts in Django noch so die eine oder andere Klinke - besonders nervig, weil nicht dokumentiert, aber leicht zu lösen: die Standard-Zeitzone in Django ist America/Chicago. Dazu muss man dann nur eine Variable TIME_ZONE mit 'Europe/Berlin' als Wert in sein settings-File schreiben und noch einen kleinen Patch anwenden, damit Django mit dem '-' als Zeitzonentrennzeichen klarkommt. Oh Mann, wenn Amerikaner schon mal Software schreiben ...

Irgendwie steigt im Moment gerade meine Motivation mir doch erstmal Ruby on Rails genauer anzugucken, schliesslich sind das Dänen die damit angefangen haben und die sollten zumindestens solche Sachen richtig hinkriegen (wenn nur nicht dieser nette automatische Administrationsteil von Django wäre - der ist es ja genau auf den ich es abgesehen hätte. Warum hat sowas nur keiner für ROR eingebaut, menno ...)

Update: Ich hab am entsprechenden Ticket zum Unicode-Problem einen Patch angehängt (einfach nach ganz unten scrollen) der erstmal das Problem halbwegs in den Griff bekommt - sofern man kein SQLite einsetzt, da SQLite immer Unicode-Strings zurückliefert und die dann auch wieder Stress machen. Aber zumindestens mit PostgreSQL funktionieren jetzt Umlaute in Django. Die Lösung ist nicht wirklich perfekt, aber zumindestens mit nur wenig Codeänderung reinzubringen. Eine richtige Lösung würde wohl grössere Codeumbauten erfordern.

Ein weiterer Patch hängt am Ticket zum Zeitzonenproblem, mit dem Patch kann man dann auch TIME_ZONE = 'Europe/Berlin' benutzen um die Zeitangaben zum Beispiel in der Änderungshistorie in der richtigen Zeitzone zu bekommen.

In solchen Momenten wünscht man sich commit-Rechte zu Django, um solche recht überschaubaren Patches selber reinstellen zu können

Noch ein Update: Adrian war im Chat gestern und heute und die Probleme mit Unicode sind weitestgehend raus. Nur mit SQLite gibts noch Stress, aber da hab ich den Patch schon fertig. Und die Zeitzonengeschichte ist auch behoben im SVN. Und er hat Unittests begonnen. Sehr sinnvoll, wenn man dann mal auf Dauer das ganze Framework sauber durchtesten kann nach einem Patch ...

Wer wie ich in die Situation kommt das er die Unicode-Strings in PySQLite2 nicht mag und utf8 Bytestrings braucht: PysqliteFactories sind hier die Lösung, nicht Konverter. Denn Konverter müssten auf jede Spielart von varchar registriert werden die in Benutzung ist - die Row Factories hingegen sind da ziemlich agnostisch und praktisch. Und wenn man schon eine eigene Cursor-Klasse benutzt: diese einfach als Cursor Factory auslegen die dann mit self.row_factory der Instanz eine Row Factory verpasst.

Abridged guide to HTTP Caching ist eine Beschreibung der wichtigsten Caching-Header in HTTP und wie sie verwendet werden sollten.

JSAN ist das für JavaScript was CPAN für Perl ist - ein zentrales Verzeichnis und Downloadbereich für JavaScript Sourcen und Paket.

typo ist eine Blogsoftware für Ruby on Rails mit scheinbar schon recht weit ausgebauten Features. Speziell auch mit gutem Caching (produziert statische Seiten) für High-Traffic-Sites, bei denen dann Teile per JavaScript weiter dynamisch gehalten werden. Klingt danach das ich mir das nochmal angucken werde wenn mein ROR-Buch ankommt ...

Django, lighttpd und FCGI, zweiter Versuch

In meinem ersten Versuch mit diesem Zeug habe ich ein Beispiel gegeben, wie man Django-Projekte hinter lighttpd mit einfachen FCGI-Skripten, die in den Server integriert sind, ausführen kann. Ich werde ein wenig mehr über dieses Zeug erzählen, mit einer Möglichkeit, lighttpd und Django zu kombinieren, die viel mehr Flexibilität bei der Verteilung von Django-Anwendungen über Maschinen bietet. Dies ist besonders wichtig, wenn Sie mit hohen Lasten auf Ihren Servern rechnen. Natürlich sollten Sie den Django-Caching-Middleware verwenden, aber es gibt Zeiten, in denen selbst das nicht ausreicht und die einzige Lösung darin besteht, mehr Hardware an das Problem zu werfen.

Aktualisierung: Ich pflege meine Beschreibungen jetzt in meinem Trac-System. Siehe die lighty+FCGI-Beschreibung für Django.

Hinweis: Da Django sehr neue Software ist, habe ich keine Produktionserfahrungen damit. Daher handelt es sich hier eher um einen theoretischen Standpunkt, in den Wissen einfließt, das ich durch den Betrieb von Produktionssystemen für mehrere größere Portale gewonnen habe. Am Ende kommt es nicht so sehr darauf an, welche Software Sie verwenden - es kommt nur darauf an, wie Sie sie über Ihren Server-Farm verteilen können.

Um dieser Dokumentation zu folgen, benötigen Sie die folgenden Pakete und Dateien, die auf Ihrem System installiert sind:

  • [Django][2] selbst - derzeit aus dem SVN geholt. Folgen Sie den Setup-Anweisungen oder verwenden Sie python setup.py install.
  • [Flup][3] - ein Paket mit verschiedenen Möglichkeiten, WSGI-Anwendungen auszuführen. In dieser Dokumentation verwende ich den threaded WSGIServer.
  • [lighttpd][4] selbstverständlich. Sie benötigen mindestens die FastCGI-, die Rewrite- und die Accesslog-Module, diese werden in der Regel mit dem System kompiliert.
  • [Eunuchs][5] - nur erforderlich, wenn Sie Python 2.3 verwenden, da Flup socketpair in den vorkompilierten Servern verwendet und dies erst ab Python 2.4 verfügbar ist.
  • [django-fcgi.py][6] - mein FCGI-Server-Skript, das eines Tages Teil der Django-Distribution sein könnte, aber für den Moment einfach hier herunterladen. Legen Sie dieses Skript irgendwo in Ihren $PATH, z.B. /usr/local/bin und machen Sie es ausführbar.
  • Wenn das oben genannte aus irgendeinem Grund nicht funktioniert (vielleicht unterstützt Ihr System socketpair nicht und kann daher den vorkompilierten Server nicht verwenden), können Sie [django-fcgi-threaded.py][7] - eine Alternative, die den Threading-Server mit all seinen Problemen verwendet. Ich verwende es zum Beispiel auf Mac OS X für die Entwicklung.

Bevor wir beginnen, lassen Sie uns ein wenig über Serverarchitektur, Python und hohe Last sprechen. Die noch bevorzugte Installation von Django erfolgt hinter Apache2 mit mod python2. mod python2 ist eine recht leistungsfähige Erweiterung für Apache, die einen vollständigen Python-Interpreter (oder sogar viele Interpreter mit unterschiedlichen Namensräumen) in den Apache-Prozess integriert. Dies ermöglicht es Python, viele Aspekte des Servers zu steuern. Aber es hat einen Nachteil: Wenn der einzige Zweck darin besteht, Anfragen von Benutzern an die Anwendung weiterzuleiten, ist es eine ziemliche Übertreibung: Jeder Apache-Prozess oder Thread wird einen vollständigen Python-Interpreter mit Stack, Heap und allen geladenen Modulen enthalten. Apache-Prozesse werden auf diese Weise etwas fett.

Ein weiterer Nachteil: Apache ist einer der flexibelsten Server da draußen, aber im Vergleich zu kleinen Servern wie lighttpd ein Ressourcenfresser. Und - aufgrund der Architektur der Apache-Module - wird mod_python die vollständige Anwendung im Sicherheitskontext des Webservers ausführen. Zwei Dinge, die Sie in Produktionsumgebungen nicht oft mögen.

Ein natürlicher Ansatz ist also die Verwendung leichterer HTTP-Server und das Hinterlegen Ihrer Anwendung dahinter - unter Verwendung des HTTP-Servers selbst nur zum Servieren von Medien und unter Verwendung von FastCGI, um Anfragen vom Benutzer an Ihre Anwendung weiterzuleiten. Manchmal stellen Sie diesen kleinen HTTP-Server hinter einen Apache-Front, der nur mod_proxy (entweder direkt oder über mod_rewrite) verwendet, um Anfragen an den Webserver Ihrer Anwendung weiterzuleiten - und glauben Sie es oder nicht, dies ist tatsächlich viel schneller als das Servieren der Anwendung direkt mit Apache!

Die zweite Falle ist Python selbst. Python hat eine recht schöne Threading-Bibliothek. Es wäre also ideal, Ihre Anwendung als Thread-Server zu erstellen - weil Threads viel weniger Ressourcen als Prozesse verbrauchen. Aber das wird Sie beißen, wegen einer speziellen Funktion von Python: der GIL. Der gefürchtete globale Interpreter-Lock. Dies ist kein Problem, wenn Ihre Anwendung zu 100% Python ist - der GIL greift nur, wenn interne Funktionen verwendet werden oder wenn C-Erweiterungen verwendet werden. Schade, dass fast alle DBAPI-Bibliotheken mindestens einige Datenbank-Client-Code verwenden, der eine C-Erweiterung verwendet - Sie starten einen SQL-Befehl und das Threading wird deaktiviert, bis der Aufruf zurückkehrt. Keine mehreren Abfragen laufen ...

Die bessere Option ist also die Verwendung eines Fork-Servers, weil der GIL dann nicht greift. Dies ermöglicht einem Fork-Server, mehrere Prozessoren in Ihrer Maschine effizient zu nutzen - und so auf lange Sicht viel schneller zu sein, trotz des Overheads von Prozessen gegenüber Threads.

Für diese Dokumentation nehme ich einen dreischichtigen Ansatz zur Verteilung der Software: Die Front wird Ihr vertrauenswürdiger Apache sein, der einfach alles an Ihren projektspezifischen lighttpd weiterleitet. Der lighttpd hat Zugriff auf das Dokumentenstammverzeichnis Ihres Projekts und leitet spezielle Anfragen an Ihren FCGI-Server weiter. Der FCGI-Server selbst kann auf einem anderen Rechner laufen, wenn dies für die Lastverteilung erforderlich ist. Er wird einen vorkompilierten Server verwenden, weil es in Python ein Threading-Problem gibt, und er kann Multiprozessor-Maschinen nutzen.

Ich werde nicht viel über die erste Ebene sprechen, weil Sie dies leicht selbst einrichten können. Leiten Sie einfach Dinge an die Maschine weiter, auf der Ihr lighttpd läuft (in meinem Fall läuft der Apache normalerweise auf anderen Maschinen als die Anwendungen). Schauen Sie in der mod_proxy-Dokumentation nach, normalerweise ist es nur ProxyPass und ProxyPassReverse.

Die zweite Ebene ist interessanter. lighttpd ist ein bisschen seltsam in der Konfiguration von FCGI-Dingen - Sie benötigen FCGI-Skripte im Dateisystem und müssen diese mit Ihrem FCGI-Serverprozess verbinden. Die FCGI-Skripte müssen tatsächlich keinen Inhalt enthalten - sie müssen nur im Dateisystem vorhanden sein.

Wir beginnen also mit Ihrem Django-Projektverzeichnis. Legen Sie einfach ein Verzeichnis public_html dort hinein. Das ist der Ort, an dem Sie Ihre Mediendateien ablegen, z.B. das Admin-Media-Verzeichnis. Dieses Verzeichnis wird das Dokumentenstammverzeichnis für Ihren Projekt-Server sein. Stellen Sie sicher, dass Sie nur Dateien dort ablegen, die keine privaten Daten enthalten - private Daten wie Konfigurationen und Module sollten besser an Orten bleiben, die nicht vom Webserver zugänglich sind. Als Nächstes richten Sie eine lighttpd-Konfigurationsdatei ein. Sie werden nur die Rewrite- und die FastCGI-Module verwenden. Keine Notwendigkeit, ein Zugriffsprotokoll zu führen, dies wird von Ihrer ersten Ebene, Ihrem Apache-Server, geschrieben. In meinem Fall befindet sich das Projekt in /home/gb/work/myproject - Sie müssen dies an Ihre eigene Situation anpassen. Speichern Sie den folgenden Inhalt als /home/gb/work/myproject/lighttpd.conf


 server.modules = ( "mod_rewrite", "mod_fastcgi" )
 server.document-root = "/home/gb/work/myproject/public_html"
 server.indexfiles = ( "index.html", "index.htm" )
 server.port = 8000
 server.bind = "127.0.0.1"
 server.errorlog = "/home/gb/work/myproject/error.log"

fastcgi.server = (
"/main.fcgi" => (
"main" => (
"socket" => "/home/gb/work/myproject/main.socket"
 )
 ),
"/admin.fcgi" => (
"admin" => (
"socket" => "/home/gb/work/myproject/admin.socket"
 )
 )
 )

url.rewrite = (
"^(/admin/.*)$" => "/admin.fcgi$1",
"^(/polls/.*)$" => "/main.fcgi$1"
 )

mimetype.assign = (
".pdf" => "application/pdf",
".sig" => "application/pgp-signature",
".spl" => "application/futuresplash",
".class" => "application/octet-stream",
".ps" => "application/postscript",
".torrent" => "application/x-bittorrent",
".dvi" => "application/x-dvi",
".gz" => "application/x-gzip",
".pac" => "application/x-ns-proxy-autoconfig",
".swf" => "application/x-shockwave-flash",
".tar.gz" => "application/x-tgz",
".tgz" => "application/x-tgz",
".tar" => "application/x-tar",
".zip" => "application/zip",
".mp3" => "audio/mpeg",
".m3u" => "audio/x-mpegurl",
".wma" => "audio/x-ms-wma",
".wax" => "audio/x-ms-wax",
".ogg" => "audio/x-wav",
".wav" => "audio/x-wav",
".gif" => "image/gif",
".jpg" => "image/jpeg",
".jpeg" => "image/jpeg",
".png" => "image/png",
".xbm" => "image/x-xbitmap",
".xpm" => "image/x-xpixmap",
".xwd" => "image/x-xwindowdump",
".css" => "text/css",
".html" => "text/html",
".htm" => "text/html",
".js" => "text/javascript",
".asc" => "text/plain",
".c" => "text/plain",
".conf" => "text/plain",
".text" => "text/plain",
".txt" => "text/plain",
".dtd" => "text/xml",
".xml" => "text/xml",
".mpeg" => "video/mpeg",
".mpg" => "video/mpeg",
".mov" => "video/quicktime",
".qt" => "video/quicktime",
".avi" => "video/x-msvideo",
".asf" => "video/x-ms-asf",
".asx" => "video/x-ms-asf",
".wmv" => "video/x-ms-wmv"
 )

Ich binde den lighttpd nur an die localhost-Schnittstelle, weil in meiner Testumgebung der lighttpd auf demselben Host wie der Apache-Server läuft. In Multi-Server-Einstellungen werden Sie den lighttpd-Servern natürlich an die öffentliche Schnittstelle binden. Die FCGI-Skripte kommunizieren in dieser Einstellung über Sockets, weil in dieser Testumgebung ich nur einen Server für alles verwende. Wenn Ihre Maschinen verteilt wären, würden Sie die "host" und "port" Einstellungen anstelle der "socket" Einstellung verwenden, um mit FCGI-Servern auf verschiedenen Maschinen zu verbinden. Und Sie würden mehrere Einträge für die "main" Sache hinzufügen, um die Last der Anwendung auf mehrere Maschinen zu verteilen. Schauen Sie in der lighttpd-Dokumentation nach, welche Optionen Sie haben werden.

Ich richte zwei FCGI-Server für dies ein - einen für die Admin-Einstellungen und einen für die Haupt-Einstellungen. Alle Anwendungen werden durch die Haupt-Einstellungen FCGI weitergeleitet und alle Admin-Anfragen werden an den Admin-Server geleitet. Dies geschieht mit den beiden Rewrite-Regeln - Sie müssen eine Rewrite-Regel für jede Anwendung hinzufügen, die Sie verwenden.

Da lighttpd die FCGI-Skripte benötigt, um sie zu existieren, um den PATH_INFO an das FastCGI weiterzugeben, müssen Sie die folgenden Dateien berühren: /home/gb/work/myprojectg/public_html/admin.fcgi ``/home/gb/work/myprojectg/public_html/main.fcgi

Sie müssen keinen Code enthalten, sie müssen nur im Verzeichnis aufgeführt sein. Ab lighttpd 1.3.16 (zum Zeitpunkt der Abfassung dieser Zeilen nur in svn) können Sie ohne die Stubs für die .fcgi laufen - Sie fügen einfach "check-local" => "disable" zu den beiden FCGI-Einstellungen hinzu. Dann sind die lokalen Dateien nicht mehr erforderlich. Wenn Sie also diese Konfigurationsdatei erweitern möchten, müssen Sie nur einige sehr grundlegende Regeln beachten:

  • jede Einstellungsdatei benötigt ihren eigenen .fcgi-Handler
  • jeder .fcgi muss im Dateisystem berührt werden - dies könnte in einer zukünftigen Version von lighttpd verschwinden, aber für den Moment ist es erforderlich
  • die Lastverteilung erfolgt auf Ebene der .fcgi - fügen Sie mehrere Server oder Sockets hinzu, um die Last auf mehrere FCGI-Server zu verteilen
  • jede Anwendung benötigt eine Rewrite-Regel, die die Anwendung mit dem .fcgi-Handler verbindet

Jetzt müssen wir die FCGI-Server starten. Das ist eigentlich ganz einfach, verwenden Sie einfach das bereitgestellte django-fcgi.py-Skript wie folgt:


 django-fcgi.py --settings=myproject.work.main
 --socket=/home/gb/work/myproject/main.socket
 --minspare=5 --maxspare=10 --maxchildren=100
 --daemon

django-fcgi.py --settings=myproject.work.admin
 --socket=/home/gb/work/myproject/admin.socket
 --maxspare=2 --daemon

Diese beiden Befehle starten zwei FCGI-Serverprozesse, die die angegebenen Sockets zur Kommunikation verwenden. Der Admin-Server wird nur zwei Prozesse verwenden - dies liegt daran, dass der Admin-Server oft nicht der Server mit den vielen Hits ist, das ist der Hauptserver. Daher erhält der Hauptserver eine höhere als Standard-Einstellung für Reserveprozesse und maximale Kindprozesse. Natürlich ist dies nur ein Beispiel - passen Sie es an Ihre Bedürfnisse an.

Der letzte Schritt ist das Starten Ihres lighttpd mit Ihrer Konfigurationsdatei: lighttpd -f /home/gb/work/myproject/lighttpd.conf

Das war's. Wenn Sie jetzt entweder den lighttpd direkt unter http://localhost:8000/polls/ oder durch Ihren Front-Apache zugreifen, sollten Sie die Ausgabe Ihrer Anwendung sehen. Zumindest, wenn alles richtig gelaufen ist und ich nicht zu viele Fehler gemacht habe.

Eunuchs liefert ein paar Funktionen nach die unter Python 2.3 noch nicht verfügbar sind. Speziell socketpair und recvmsg/sendmsg sind da sehr wichtig - für Serverprogrammierung mit preforked Servern zum Beispiel.

Higher-Order Perl ist ein Buch (zur Zeit Papier, aber soll demnächst frei im Netz lesbar sein) das sich mit higher order functions und Perl beschäftigt - könnte ganz interessant sein, Perl bietet da eine ganze Menge Features versteckt unter all den geschweiften Klammern und anderen Sonderzeichen ...

Django mit FCGI und lighttpd ausführen

Diese Dokumentation ist für einen grösseren Kreis als nur .de gedacht, daher das ganze in Neuwestfälisch Englisch. Sorry. Update: I maintain the actually descriptions now in my trac system. See the FCGI+lighty description for Django. There are different ways to run Django on your machine. One way is only for development: use the django-admin.py runserver command as documented in the tutorial. The builtin server isn't good for production use, though. The other option is running it with mod_python. This is currently the preferred method to run Django. This posting is here to document a third way: running Django behind lighttpd with FCGI.

First you need to install the needed packages. Fetch them from their respective download address and install them or use preinstalled packages if your system provides those. You will need the following stuff:

  • [Django][2] selbst - derzeit aus dem SVN. Folgen Sie den Setup-Anweisungen oder verwenden Sie python setup.py install.
  • [Flup][3] - ein Paket mit verschiedenen Möglichkeiten, WSGI-Anwendungen auszuführen. Ich verwende den threaded WSGIServer in dieser Dokumentation.
  • [lighttpd][4] selbstverständlich. Sie benötigen mindestens die FastCGI-, die Rewrite- und die Accesslog-Module, diese sind in der Regel mit dem System kompiliert.

Nach der Installation von ligthttpd müssen Sie eine lighttpd-Konfigurationsdatei erstellen. Die hier angegebene Konfigurationsdatei ist an meine eigenen Pfade angepasst - Sie müssen diese an Ihre eigene Situation anpassen. Diese Konfigurationsdatei aktiviert einen Server auf Port 8000 auf localhost - genau wie der runserver-Befehl dies tun würde. Aber dieser Server ist ein Server für die Produktion mit mehreren FCGI-Prozessen und einer sehr schnellen Medienauslieferung.


 # lighttpd-Konfigurationsdatei
 #
 ############ Optionen, die Sie wirklich beachten müssen ####################

server.modules = ( "mod_rewrite", "mod_fastcgi", "mod_accesslog" )

server.document-root = "/home/gb/public_html/"
 server.indexfiles = ( "index.html", "index.htm", "default.htm" )

 diese Einstellungen binden den Server an dieselbe IP und denselben Port wie runserver

server.errorlog = "/home/gb/log/lighttpd-error.log"
 accesslog.filename = "/home/gb/log/lighttpd-access.log"

fastcgi.server = (
"/myproject-admin.fcgi" => (
"admin" => (
"socket" => "/tmp/myproject-admin.socket",
"bin-path" => "/home/gb/public_html/myproject-admin.fcgi",
"min-procs" => 1,
"max-procs" => 1
 )
 ),
"/myproject.fcgi" => (
"polls" => (
"socket" => "/tmp/myproject.socket",
"bin-path" => "/home/gb/public_html/myproject.fcgi"
 )
 )
 )

url.rewrite = (
"^(/admin/.*)$" => "/myproject-admin.fcgi$1",
"^(/polls/.*)$" => "/myproject.fcgi$1"
 )

Diese Konfigurationsdatei startet nur einen FCGI-Handler für Ihre Admin-Angelegenheiten und die Standardanzahl von Handlern (jeder davon mehrthreadig!) für Ihre eigene Website. Sie können diese Einstellungen mit den üblichen ligthttpd FCGI-Einstellungen feinabstimmen, sogar externe FCGI-Erzeugung und Auslagerung von FCGI-Prozessen auf einen verteilten FCGI-Cluster nutzen! Admin-Medien-Dateien müssen in Ihr lighttpd-Dokumentenverzeichnis.

Die Konfiguration funktioniert, indem alle Standard-URLs so übersetzt werden, dass sie vom FCGI-Skript für jede Einstellungsdatei behandelt werden - um weitere Anwendungen zum System hinzuzufügen, würden Sie nur die Umschreiberegel für die /polls/-Zeile duplizieren und diese in choices oder was auch immer Ihr Modul heißt ändern. Der nächste Schritt wäre die Erstellung der .fcgi-Skripte. Hier sind die beiden, die ich verwende:


 #!/bin/sh
 # dies ist myproject.fcgi - legen Sie es in Ihr Docroot

export DJANGOSETTINGSMODULE=myprojects.settings.main

/home/gb/bin/django-fcgi.py

 #!/bin/sh
 # dies ist myproject-admin.fcgi - legen Sie es in Ihr Docroot

export DJANGOSETTINGSMODULE=myprojects.settings.admin

/home/gb/bin/django-fcgi.py

Diese beiden Dateien nutzen nur ein django-fcgi.py-Skript. Dies ist nicht Teil der Django-Distribution (noch nicht - vielleicht werden sie es einbeziehen) und der Quellcode ist hier gegeben:


 #!/usr/bin/python2.3

def main():
 from flup.server.fcgi import WSGIServer
 from django.core.handlers.wsgi import WSGIHandler
 WSGIServer(WSGIHandler()).run()

if name == 'main':
 main()

Wie Sie sehen, ist es eher einfach. Es verwendet den threaded WSGIServer aus dem fcgi-Modul, aber Sie könnten genauso leicht den geforkten Server verwenden - aber da lighttpd bereits Preforking durchführt, denke ich, dass es nicht viel Sinn hat, auf der FCGI-Ebene zu forken. Dieses Skript sollte sich irgendwo in Ihrem Pfad befinden oder einfach mit vollständig qualifiziertem Pfad wie ich es tue referenziert werden. Jetzt haben Sie alle Teile zusammen. Ich habe meine lighttpd-Konfiguration in /home/gb/etc/lighttpd.conf, die .fcgi-Skripte in /home/gb/public_html und das django-fcgi.py in /home/gb/bin. Dann kann ich das ganze mit /usr/local/sbin/lighttpd -f etc/lighttpd.conf starten. Dies startet den Server, preforkt alle FCGI-Handler und trennt sich vom tty, um ein richtiger Daemon zu werden. Das Schöne daran: Dies wird nicht unter einem speziellen Systemkonto, sondern unter Ihrem normalen Benutzerkonto ausgeführt, sodass Ihre eigenen Dateibeschränkungen gelten. lighttpd+FCGI ist recht leistungsfähig und sollte Ihnen eine sehr schöne und sehr schnelle Option zum Ausführen von Django-Anwendungen bieten. Probleme:

  • Unter hoher Last stürzen einige FCGI-Prozesse ab. Ich habe zunächst die fcgi-Bibliothek verdächtigt, aber nach etwas Herumspielen (Core-Debugging) stellte sich heraus, dass es tatsächlich der psycopg auf meinem System ist, der abstürzt. Sie könnten also mehr Glück haben (es sei denn, Sie laufen auch Debian Sarge)

  • Die Leistung hinter einem Front-Apache ist nicht das, was ich erwartet hätte. Ein lighttpd mit Front-Apache und 5 Backend-FCGI-Prozessen erreicht nur 36 Anfragen pro Sekunde auf meinem Rechner, während django-admin.py runserver 45 Anfragen pro Sekunde erreicht! (immer noch schneller als mod_python über apache2: nur 27 Anfragen pro Sekunde) Updates:

  • Die Trennung der beiden FCGI-Skripte funktionierte nicht richtig. Jetzt passe ich nicht nur auf die .fcgi-Erweiterung, sondern auf den Skriptnamen an, so dass /admin/ wirklich das myproject-admin.fcgi verwendet und /polls/ wirklich das myproject.fcgi verwendet.

  • Ich habe [ein anderes Dokument online][6], das mehr Details zur Lastverteilung enthält

flup: random Python WSGI stuff - eine Sammlung von WSGI-Server-Adaptern für FCGI, SCGI und Apache Jakarta 1.3 Protokolle sowie noch ein paar WSGI-Middlewares zur Authentifizierung, Komprimierung und Fehlerhandling.

Leonardo ist ein CMS mit Blog und Wiki Modulen in Python. Im Moment noch recht schlicht als CGI, soll aber auf WSGI und Paste umgestellt werden und könnte dann ganz interessant als generelle CMS-Komponenten in einer WSGI-Lösung sein.

Python Paste ist ein Meta-Framework - ein Framework zur Erstellung neuer Web-Frameworks auf WSGI-Basis. Viele interessante Middleware-Module und eine Reimplementation von WebWare auf WSGI-Basis.

Seaside ist ein flexibles und sehr interessantes Web-Framework in Smalltalk. Tutorials hatte ich schon mal dazu gelinkt, aber das Framework selber noch nicht - jedenfalls nicht an seiner neuen Adresse. Läuft auf Squeak und Visual Works - und durch deren breite Verfügbarkeit fast auf allem das sich Computer nennen darf und eine TCP/IP-Verbindung zur Aussenwelt hat.

GNU Modula-2 war mir bisher unbekannt. Schön das sich Modula-2 auch in der GNU-Compilerfamilie wiederfindet. Auch wenn Modula-2 für mich nur noch historisches Interesse hat - dynamische Sprachen wie Python sind mir einfach wesentlich lieber. Aber es gab mal Zeiten als ich noch fleissig in Modula-2 programmiert habe.

MochiKit ist eine JavaScript-Bibliothek mit einer ganzen Reihe von Erweiterungen für JavaScript. Vor allem Iteratoren, vernünftige funktionale Konzepte (filter, map, partial application), aber auch eine ganze Reihe neuer Ideen, wie zum Beispiel eine sehr nette AJAX-Integration. Sieht schon ganz nett aus, muss ich mal mit rumspielen.

Und wieder mal Django

Django - das kommende Webframework für Python - hat jetzt SQLite 3 Support. Damit ist eine Installation einer Entwicklungsumgebung für Django-Projekte jetzt extrem simpel geworden: Python 2.3 oder Python 2.4 muss da sein und ansonsten noch SQLite3 und PySQLite2. Auf dem Mac ist also im Prinzip schon alles da, ausser PySQLite2 - letzteres kann man sich aber von www.pysqlite.org holen und einfach mittels sudo python setup.py install installieren. Und schon kann man mit Django loslegen und die Tutorials durcharbeiten. Kein Apache mehr nötig, kein PostgreSQL (zwar die netteste aller SQL-Datenbanken, aber trotzdem für eine Entwicklungsumgebung auf Notebook manchmal einfach Overkill) und vor allem nicht psycopg - dessen Installation leider einen fast vollständigen PostgreSQL-Source-Tree erfordert. Es gibt also keine Ausrede für Pythonistas mehr sich nicht mit Django zu beschäftigen

Apache modauthtkt ist ein Framework für Single-Signon in Apache-basierten Lösungen über Technikgrenzen (CGI, mod_perl und was sonst noch so existiert) hinweg. Müsste ich mir mal angucken, könnte für mich interessant sein.

Jython 2.2 in der Mache

Die Jython Webseiten geben noch nix her, aber in der Mailingliste gabs vor ein paar Tagen eine Info das eine neue Alpha für Jython 2.2 raus ist - und zwar diesmal (war ja schon Ende 2004 mal so weit) eine die funktioniert. Viele Features der neueren Python-Versionen sind drin, auch Generatoren/Iteratoren. Von daher ist es nicht identisch mit Python 2.2, sondern eher ein gutes Stück auf den Weg zu Python 2.3 von den Features her. Da der Entwickler mit OS X arbeitet und dort entwickelt ist es relativ problemlos dort zu installieren.

Zur Installation, da das nirgendwo explizit erwähnt wird:


java -jar [jython .version.elend.langer.name.jar]

Dann kommt ein grafischer Installer der alles auf die Platte kippt. Dann in dem Zielverzeichnis noch zusätzlich folgende Befehle eingeben:


chmod 755 jython
chmod 755 jythonc

Dann sind die beiden (jython ist der Interpreter und jythonc ein Compiler) auch aufrufbar und es kann losgehen. Beim ersten Start von jython wird eine ganze Reihe von Systempaketen aktiviert, also nicht wundern über die vielen Meldungen vom sys-package-mgr.

Wer Jython nicht kennt: das ist eine Reimplementierung von Python auf der Java Virtual Machine. Dadurch lassen sich sehr elegant alle Java-Libraries benutzen und durch die interaktive Shell von Jython lässt sich auch mit Java-Klassen interaktiv spielen. Sehr schön um mal schnell Sachen auszuprobieren. Aber natürlich auch sehr schön um zwar die Portabilität von Java zu haben, aber nicht die kranke Sprache

Und es ist halt einfach witzig so Sachen wie die hier zu machen:


Jython 2.2a1 on java1.4.2_07 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> import java.lang
>>> dir(java.lang.Number)
['byteValue', 'doubleValue', 'floatValue', 'intValue', 'longValue', 'shortValue']
>>> import java
>>> dir(java)
['__name__', 'applet', 'awt', 'beans', 'io', 'lang', 'math', 'net', 'nio', 'rmi', 'security', 'sql', 'text', 'util']
>>> ```

Erste Django Tutorials online

Die Django-Programmierer legen mit den Tutorials los. Das erste Tutorial beschäftigt sich primär mit der Erstellung des Datenbankmodells und des Grundcodes für die zu verwaltenden Objekte und das zweite Tutorial beschäftigt sich mit der automatisch generierten Administrationsoberfläche. Sehr nett, das ganze.

Das System ist natürlich stark auf Content-Erstellung und Verwaltung ausgerichtet - aber trotzdem allgemein genug, so das man es auch für anders gelagerte Inhalte nutzen kann. Die ganze Administration wird automatisch aus dem Objektmodell und einigen Hints erstellt, orientiert sich also immer an den realen Daten im System. Und die Default-Optik ist auch recht ansprechend.

Die Serverintegration geschieht einfach über mod python - also über den Apache. Was ebenfalls ein Vorteil ist, denn mod python bietet sehr hohe Performance schon von Hause aus. Und für heftigere Fälle gibts ja das Caching in Django. Ich muss sagen, was ich bisher von Django sehe gefällt mir ausgesprochen gut.

Ein wichtiger Hinweis fehlt in der Installationsanleitung: Apache2 ist zwingend nötig, und daher auch ModPython in der entsprechenden Version. Mac OS X liefert aber nur Apache 1.3 und viele andere Server haben auch nur den 1.3er Apache zur Verfügung, da hat Django also noch ein echtes Manko.

Wer übrigens auf Debian von Apache zu Apache2 upgraden will: wenn mod perl im Einsatz ist, vergesst es. Das mod perl2 für den Apache2 in der Debian Sarge ist kompletter Schrott - als ob die API-Änderungen in mod perl2 im Vergleich zum alten mod perl nicht schon nervig genug wären. Im Prinzip kriegt man damit keine Perl-Module mehr so einfach zum Laufen.

Update: Übrigens ist gerade im Subversion zu Django eine Menge Aktivität drin um die Pflicht für Apache zu beseitigen. Ein einfacher Entwicklungsserver ist schon drin, man wird also in Zukunft für erste Spielereien keinen Apache mehr benötigen. Und auch das Deployment könnte man damit auf Dauer auch auf andere Beine stellen - z.B. FCGI hinter lighttpd.

Update 2: Das dritte Tutorial ist da und beschäftigt sich mit der Sicht für den Besucher. Die haben ein ganz schön heftiges Tempo im Moment bei Django.

Foundations of Python Network Programming ist ein relativ neues Buch über Netzwerkprogrammierung mit Python. Behandelt alle möglichen Ecken der Netzwerkprogrammierung die man sich denken kann - ziemlich klasse der erste Eindruck. Ich kenn zwar die meisten Sachen schon irgendwoher, aber so kompakt in einem Buch ist das trotzdem nett zum Nachlesen. Zusammen mit Dive Into Python würde ich die beiden als das ideale Gespann zum Python lernen sehen.

HsShellScript ist eine Haskell-Library mit der man Shell-Script-typische Probleme mit Haskell lösen kann. Also Funktionen zur Steuerung von Prozessen und Zugriff auf Systeminformationen etc. Sieht sehr nett aus, lässt sich wegen fehlendem mntent.h aber leider nicht auf OS X compilieren.

mod_haskell ist leider seit Jahren nicht mehr weiter entwickelt worden - es bietet eine Integration von Hugs und ghc in den Apache-Server.

PerlPad ist ein Service für Mac OS X der es ermöglicht in jeden Cocoa-Textfenster Perlcode auszuführen und den Output zu sammeln, oder selektierten Text durch ein Perl-Script zu schicken.

Regular Expressions in Haskell ist eine Implementation von Regular Expressions komplett in Haskell.

Web Authoring System Haskell (WASH) ist eine Sammlung von Haskell-Libraries (genauer gesagt DSLs - domain specific langugages - in Haskell) zur Programmierung von Webanwendungen. Enthalten ist CGI-style Programmierung, HTML-Generierung, Mailhandling und Datenbanktreiber für PostgreSQL.

Django - neues Webframework für Python

Mal wieder ein weiteres Web-Framework für Python, diesmal mit dem markigen Namen Django. Ich bin zwar skeptisch was weitere Webframeworks angeht - gibt schon haufenweise, und ich muss gestehen das ich zu dem einen oder anderen auch was beigetragen habe - aber dieses bietet einige interessante Ansätze.

Zum Einen addressiert es ähnliche Lösungen wie Ruby on Rails - erwähnt Ruby on Rails aber mit keinem Wort. Das ist schon mal positiv, man hat in letzter Zeit fast den Eindruck das die Python-Programmierer wegen ROR in Panik verfallen und meinen alles müsse sich nur noch daran orientieren.

Zum Anderen bietet Django automatisch generierte Backendseiten. Das ist etwas das ich sehr mag und was ich z.B. an Zope so nett finde - man hat gleich einen Weg mit dabei mit dem man mit den eigentlichen Daten rumspielen kann, noch bevor das eigentliche Frontend steht. Sehr praktisch gerade in der ersten Entwicklungsphase.

Auch einige der anderen Ideen sind ganz witzig - zum Beispiel das Mapping von URLs zu Handlern im Python-Code über regular Expressions. Erinnert ein bischen an mod_rewrite im Apache (wobei bei solchen Lösungen immer die Frage der Priorisierung von sich überlappenden regulären Ausdrücken bleibt). Und ein integrierter object-relation-Manager ist auch nicht schlecht, auch wenn man da natürlich auch genausogut auf fertige Lösungen zurückgreifen kann. Und das die Entwickler gleich daran gedacht haben das man effiziente Cache-Systeme braucht und dabei dann auf memcached setzen ist auch nett - viele Projekte sterben irgendwann den Tod der Load, nur weil nicht rechtzeitig an Caching gedacht wurde.

Die Template-Sprache sieht allerdings etwas gewöhnungsbedürftig aus und irgendwie frage ich mich dabei schon warum es davon fast noch mehr geben muss als von Webframeworks

JavaScript-Aktionen über CSS Selektoren zuordnen

Cool stuff: Behaviour ist eine JavaScript Library mit der man JavaScript-Aktionen an CSS Selektoren binden kann. Der Vorteil: die Aktionen verschwinden aus dem HTML-Code - der so deutlich schlanker wird. Und die Aktionen lassen sich durch Änderung der Selektoren jederzeit an neue Gegebenheiten anpassen.

In meinen ersten Anwendungen von Ajax bin ich genau über das Problem gestolpert: die JavaScript-Aktionen müllen den gerade erst mühsam auf semantisches HTML reduzierten Code voll. Genau das was mich vorher an den ganzen Table-Layouts geärgert hat, ärgert mich jetzt an der ganzen JavaScript-Geschichte. Eine saubere Trennung von Code, Semantik und Stil ist also genau das was ich brauche. Eigentlich würde sowas in den HTML-Standard gehören.

Muss ich ganz dringend mal ausprobieren, denn wenn das von der Performanz her brauchbar ist, sollte ich ein paar der letzten Ajax-Aktionen nochmal näher angucken und ändern ...

Keith Devens - Weblog: I hate PHP - August 13, 2003 - der mag auch kein PHP

Kid ist eine recht interessante Python-Library die eine Template-Engine mit Fokus auf wellformed XML implementiert. Das Ergebnis ist ähnlich wie Zope Page Templates - also eine Attributsprache für XML mit Integration von Python. Und fix ist das ganze auch: ein XML-Template hat auf meiner Kiste um die 70 Hits/sec.

n3dst4.com: PHP Annoyances - der mag PHP auch nicht.

Spyce ist ein Webframework in Python mit verdammt guter Performance: eine einfache Seite mit einem Template hinterlegt bringt auf meiner Kiste über 90 Hits pro Sekunde (Spyce über mod_python in den Apache integriert, Memory-Cache). Take that, PHP!

Spyced: Why PHP sucks - eine recht gute Analyse was an PHP eher störend ist.

Why PHP sucks - und noch jemand der kein PHP mag.

Wem Englisch als Sprache für Einsteigerliteratur nicht so liegt, es gibt einen deutschsprachigen Haskell Kurs online zum Durcharbeiten. Sieht ganz leidlich aus - allerdings finde ich das ein bischen wenig erklärt wird.

grössere Haskell-Sourcen

Wer wie ich lieber Sourcen durchwühlt um Sprachen zu lernen, hier ein paar grössere Haskell-Projekte zur Auswahl:

  • [Haskell User-Submitted Libraries][0] ist eine Sammlung von teilweise schon älteren aber trotzdem interessanten Haskell-Projekten. Downloadbar ist ein IRC-Bot und im CVS ist auch noch ein Webserver mit Plugin-Schnittstelle.
  • [Pugs][1] ist eine Perl 6 Implementation in Haskell. [Hatte ich schon mal][2], ist immer noch cool |:-)|
  • [darcs][3] ist ein verteiltes Sourceverwaltungssystem. [Hatte ich auch schon mal][4], ist aber auch immer noch cool.

Helium - Haskell-Lehr-System

Helium ist ein Haskell-Subset-Compiler der speziell für die Lehre entwickelt wurde. Er liefert ausführlichere Fehlermeldungen und analysiert Sourcen weitergehend um diese Meldungen möglich zu machen. Allerdings ist es wirklich nur ein Subset von Haskell - und da Typklassen fehlen, fehlt ein ziemlich wichtiger Teil. Um aber überhaupt erstmal in die funktionale Programmierung reinzuschnuppern ist das ganz brauchbar.

Als Textbücher bieten sich The Craft of Functional Programming und The Haskell School of Expression an. Hab mir beide mal bestellt - meine Haskell-Kenntnisse sind mehr als primitiv und hoffnungslos veraltet (sofern das bei einer doch recht jungen Sprache wie Haskell überhaupt geht ).

Eines der komplizierteren Haskell-Themen sind die Monads - ein Weg um in einer rein funktionalen Sprache mit lazy evaluation trotzdem Dinge wie Seiteneffekte und Sequentialität zu simulieren - einfach weil man zum Beispiel dann doch gelegentlich den Output vor dem Input haben möchte, wenn man Daten vom Benutzer abfragt, oder zum Beispiel sich einen Zustand wegsichern will der später wieder aufgerufen wird. Das Tutorial hilft beim Verständnis des Konzeptes der Monads.

PHP-Serialize für Python

Hurring.com : Code Vault : Python : PHP-Python Serialize : v0.3b ist eine Implementation des PHP serialize() Zeugs in Python. Sehr praktisch für WordPress: in den Optionen werden oft serialisierte Strukturen gespeichert die man so wieder auflösen kann - man kann so z.B. Tools schreiben, die direkt auf der Datenbank aufsetzen, aber in Python geschrieben sind. Der Autor hat das gleiche auch noch mal für Perl gemacht - man kann also zwischen Python, Perl und PHP einfache Datenstrukturen hin und her schieben.

Quengelköppe und Open Source

IT-Entscheider fordern in einem offenen Brief mehr Konzentration auf die ihnen wichtigen Bereiche:

In einem offenen Brief an "die" Open-Source-Community haben IT-Entscheider aus verschiedenen Bereichen dazu aufgefordert, sich mehr an den tatsächlichen Bedürfnissen von Nutzern aus dem Unternehmensbereich zu orientieren.

Ich finds ja immer wieder faszinierend mit welcher Dreistigkeit manche Menschen Forderungen an freiwillige Arbeit stellen, um dann diese für eigene Zwecke zu nutzen. Die einen fordern die Abschaffung der GPL, weil ihnen die Bedingungen nicht passen, die nächsten fordern die Konzentration auf den Desktop, weil sie halt was als Alternative zu Microsoft wollen, andere fordern mehr Konzentration auf Hochleistungsserver, weil ihnen SUN-Maschinen mit Solaris oder IBM-Server mit AIX zu teuer sind.

Komischerweise höre ich aber immer nur in offenen Briefen irgendwelche Forderungen - es wäre aber wesentlich sinnvoller schlicht und einfach das entsprechende Projekt finanziell und mit Manpower zu unterstützen. Aber das wäre ja eigene Leistung, das will man ja gerade vermeiden. Dazu passen dann auch Forderungen nach besserem Support und bessere Dokumentation - beides Sachen, die Firmen ohne weiteres selber auf die Beine stellen könnten. Aber man ist sich da zu fein zu.

Sorry, aber für mich klingen solche offenen Briefe an Open Source Entwickler immer wie quengelige kleine Kinder, die unbedingt ein Eis wollen.

Sorry, Leute, aber so läuft das nicht. Ein grosser Teil der Open Source Community besteht eben noch aus Hackern und begeisterten Amateuren und Fricklern. Das produziert oftmals grosse Scheisse und immer wieder mal geniale Lösungen. Und es produziert eben nur das, wozu die Leute Lust haben - wenn Dokumentation schreiben für jemanden langweilig und nervig ist, wird er seine Freizeit nunmal nicht darauf verwenden.

You have an itch? Scratch it. Yourself.

Objekte und Funktionen mit JavaScript

Da immer mal wieder der OO-Aspekt von JavaScript ignoriert wird, hier mal ein Text über Object Hierarchy and Inheritance in JavaScript.

Ich selbst bin seit meinen ersten Kontakten mit Prototyp-OO-Sprachen wie Self und NewtonScript ein Fan dieser Denkrichtung von OO - das Schubladendenken der klassenbasierten OO Ansätze ist oft einengend, gerade bei der Modellierung von Realwelt-Objekten.

Übrigens hat JavaScript auch noch eine ganze Menge anderer netter Eigenschaften die gerne übersehen werden - allen voran die netten anonymen Funktionen, über die Closures in JavaScript realisiert werden. Und higher-order programming lässt sich damit auch realisieren.

Wenn man jetzt Prototype-OO und Higher-Order-Programming zusammenpackt, kommt unter Umständen sowas wie Prototype heraus - einer Bibliothek für JavaScript mit einer Menge interessanter Erweiterungen wie z.B. eleganter Ajax-Bindings, einfacherer Callback-Konstruktion und noch vielen anderen Spielereien. Eine weitere Möglichkeit könnte sich aus Bob Ippollitos MochiKit ergeben, wenn es denn mal veröffentlicht ist (und es dem Hype standhält).

Prototype erfordert übrigens eine Menge an Vorstellungskraft was damit gemacht werden kann - es gibt nämlich keine Dokumentation

Open-Source-Dummschwätzer

Eric Raymond behauptet die GPL könne dem Erfolg von Open Source schaden:

Eric S. Raymond hat Federico Biancuzzi vom italienischen Linux-Magazin Linux&C während des internationalen Forums für freie Software in Brasilien erklärt, dass die General Public Licence den Fortschritt von Open Source behindern könnte.

Was dahinter steckt ist natürlich nur weiter seine grenzenlose Dummheit und Geltungssucht und der ständige Minderwertigkeitskomplex gegenüber Richard Stallman - denn im Gegensatz zu Eric hat Richard ein Konzept und eine durchgängige Idee. Egal wie man dazu steht was Richard Stallman sagt - man muss anerkennen das er eine Linie hat und die klar verfolgt.

Eric Raymond hingegen fällt über Jubelschreie er sei Millionär und andere dumme Sprüche auf - und dadurch das er andere Open Source Leute wie Bruce Perens bedroht. Und ansonsten ziemlich viel dummes Zeug sabbelt.

Die GPL abzuschaffen wäre eine selten dumme Idee, denn in vielen Bereichen ist es gerade die GPL die die Open Source Projekte schützt - man sehe einfach nur mal auf die aktuellen GPL-Verletzungen. Wären die entsprechenden Sourcen unter BSD-Lizenz, würd sich keiner drum scheren und das Thema wäre erledigt - Firmen würden sich einfach billig bedienen und das wars.

Aber Eric Raymond hat den Unterschied zwischen Freier Software und Freibier eben nie kapiert ...

vcXMLRPC ist eine XML-RPC Implementation in JavaScript. Ganz praktisch für die Integration von JavaScript-Code und ServerCode, wenn man nicht jedes Encoding/Decoding von Hand zusammendengeln will. Allerdings hat das Projekt scheinbar 2001 aufgehört weiterentwickelt zu werden.

PEP 342 -- Coroutines via Enhanced Generators

PEP 342 beschreibt einfache Coroutinen für Python. Coroutinen sind im Prinzip Mini-Threads mit manueller Kontrolle - man kann Code mitten drin einfrieren und mit einem neuen definierten Wert wieder aufstarten. Damit bieten Coroutinen den ersten Schritt zu primitiven Continuations - das einzige was noch fehlt wäre die Möglichkeit eine Coroutine zu kopieren.

Philip J. Eby schreibt über die Implementierung dieses PEP - der übrigens auf den Generatoren und Iteratoren von Python aufbaut.

Also los, Leute, sorgt endlich für die Kopierbarkeit von Generatoren und es ist geschafft

LiveSearch mit WordPress klappt

Ich hab mir gerade mal LiveSearch angeguckt und ein bischen herumgespielt damit. Liess sich mit etwas Hacken in WordPress integrieren. Wenn ihr jetzt in das Suchformular rechts einen Begriff eingebt, kommt nach einer kurzen Verzögerung eine Liste von Suchergebnissen - und zwar die Titel der Postings. Das ganze benutzt die normale WordPress-Suche, das sind also die gleichen Ergebnisse die ihr auch bekämt wenn ihr einfach Enter drücken würdet - nur dank Ajax einfach fixer und als direkte Inline-Liste. Witzige Sache. Sollte mit aktuellen IEs, mit Mozilla-Abkömmlingen und aktuellen Safaris funktionieren.

Was allerdings seltsamerweise bei mir nicht funktioniert, obwohl meines Erachtens der Code identisch ist zu der BitFlux-Seite, sind die Cursor-Tasten zur Bewegung in den Suchergebnissen. Irgendwie findet der nicht die erste Zeile oder sowas - sehr seltsam. Aber der Teil interessiert mich eigentlich eh nicht so doll, von daher störts mich nicht wenn der nicht funktioniert.

Hmm. Safari funktioniert tadellos, aber mein FireFox unter OS X will irgendwie nicht. Sehr seltsam das ganze. Genauer gesagt tuts das mit dem FireFox erst, wenn ich einmal ein Zeichen mit Backspace gelöscht habe oder einmal Space eingebe. Danach läufts sauber. Kann mir das mal jemand erklären? Witzigerweise funktioniert die Cursortastennavigation in den Suchergebnissen mit dem FireFox - wenn man denn mal eine Liste von Ergebnissen hat ...

Update: seltsamerweise funktioniert jetzt im Safari die Cursor-Tasten-Navigation. Irgendwas ist hier sehr strange ...

Microsoft und RSS

Na toll, Microsoft springt auf RSS auf und was machen sie? Klar, eine Erweiterung, die natürlich mit vielen Parsern Probleme machen wird: Simple List Extensions Specification.

Wo die Probleme liegen können? Nunja, Phil Ringnalda hat es ziemlich gut beschrieben. Und wenn ich mir obige Formatbeschreibung von Microsoft angucke ist mir nicht wirklich klar warum sie überhaupt diese Erweiterung brauchen ...

WebObjects 5.3 und Linux?

Apple releases WebObjects 5.3 Update:

Deploys to virtually any J2EE server or the WebObjects J2SE application server

Also los - wer hostet die erste WebObjects-Anwendung unter Linux in einem OpenSource J2EE-Server?

The Hitch Hiker's Guide to the Smalltalk Compiler ist eine schon ältere aber immer noch gute Beschreibung der Compilerklassen in Smalltalk-80 Abkömmlingen wie VisualWorks Smalltalk und Squeak.