programmierung

Geschäftsmodell von Open Source ...

... allein das zu hören macht mir schon Pickel. Diese absolute Unfähigkeit von Interessenverbänden aus der Wirtschaft sich eine Motivation ohne Geschäftsmodell vorstellen zu können - traurig.

Tailor - Versionsvermittler

Tailor ist ein Python Script das Changesets zwischen verschiedenen Versionssystemen austauschen kann. Im Prinzip kann man damit auch Repositories in anderen Versionssystemen spiegeln.

Trac on Darcs

Ich liebe ja bekanntermaßen Trac als Projektwerkzeug - und bin mit Subversion als Versionierung (oder neuerdings mit SVK als auf Subversion aufsetzendem Versionswerkzeug) ganz zufrieden. Aber darcs hat mich auch begeistert, weils so schön unbürokratisch ist - und jetzt gibts auch Trac auf Darcs - eine gepatchte Version, die eben mit darcs statt Subversion zusammenarbeitet. Ich glaub, ich werd mir das mal näher angucken ...

Der gleiche Patch erlaubt auch ein Bazaar-NG Backend für Trac - was ganz besonders interessant ist, weil sowohl Trac als auch Bazaar-NG in Python geschrieben sind. Ich glaube auch den Teil sollte ich mir mal angucken.

Und gerade wurde ich im IRC noch darauf hingewiesen, das SCons auch Python ist - ein ziemlich netter Ersatz für das doch schon arg in die Jahre gekommene Make.

Klingt schon fast nach Developer-Nirvana das ganze

Falls mal jemand so wie ich einem Kollegen ohne SQL-Erfahrung bezüglich Oracle aufs Pferd helfen soll: Oracle/SQL Tutorial. Ganz nett gemacht.

SVK - Subversion distributed

SVK ist ein verteiltes Versionssystem mit einer Besonderheit: es kann Trees anderer Versionssysteme (unter anderem SVN) spiegeln und darauf dann Arbeitskopien definieren. Man kann also ein Subversion-Repository eines Projektes spiegeln, einen eigenen lokalen Branch anlegen, darin arbeiten und die Änderungen lokal versionieren. Wenn dann der eigene Branch soweit ist, kann man einen Commit gegen das Ursprungsrepository machen, oder sich einfach einen Diff ziehen und dem Entwickler zuschicken. Sehr nette Sache, ganz besonders wegen der guten Integration mit Subversion.

Für vim: snippetsEmu emuliert die Snippet-Funktion von TextMate, nur halt mit vim Makros.

Wie man in Python Accent-Zeichen in ihr Basiszeichen umwandelt. Ziemlich banaler Ansatz, aber für viele Zwecke völlig ausreichend. Für richtige Lösungen gibts dann PyICU ...

Keine Ahnung ob ich das schon mal hatte, aber Caching Tutorial for Web Authors and Webmasters sieht nach einer brauchbaren Beschreibung der Caching-Direktiven in HTTP aus, mit Erläuterungen für Anwendungsprogrammierer.

Django i18n status

I worked a bit more on the i18n stuff in django today and finally switched my gallery to the i18n branch. You can now see the strings on that site with either english or german settings. Other languages get english output (so if you are in Germany and still see english strings - check the language settings in your browser, wether German is defined with higher priority than English).

The code works quite nice and I think I will give it a week or so to settle and than start to put finishing touches to it - like adding much more translation hooks to the django source.

Ajax mal anders

Subway's new Ajax framework hat einen interessanten Ansatz: per inspect wird Python-Source aus einer Methode geholt und dann nach JavaScript übersetzt. Natürlich wird dabei nur ein Subset von Python unterstützt, aber die Idee ist recht interessant - Python-Syntax für JavaScript.

Natürlich werden die semantischen Unterschiede zwischen Pythons und JavaScripts Interpreterablauf einen früher oder später beissen, aber für einfachere Sachen (und viele Ajax-Sachen sind tatsächlich recht banaler Code auf JavaScript-Seite) kann man so ohne JavaScript-Source aufbauen.

Das ganze würde natürlich wesentlich eleganter ausfallen, wenn Python eine vernüntige Makrosprache integriert hätte - bzw. wenn man in Python Makros in der Art bauen könnte, wie man es in Common Lisp kann. Damit wäre die Definition des Subsets und die Erstellung des JavaScripts daraus wesentlich eleganter machbar. Eventuell könnte hier P hillip J. Ebys Arbeit an Konfigurationssprachen helfen - es ist ja im Prinzip der Ansatz einer Makro-Einrichtung für Python.

Ich persönlich würde daher bei Python eher einen Ansatz verfolgen bei dem durch Python-Code-Ablauf (also nicht Parsen und Compilieren) JavaScript generiert wird - denn viele Ajax-Funktionalitäten sind recht standardisierte Abläufe. Es wird in der Regel der DOM-Tree manipuliert, nach festen Vorgaben, mit Daten die über JSON angeliefert werden. Das meiste liesse sich gut standardisieren. Allerdings hab ich da noch keinen konkreten Code parat, bisher ist Ajax bei mir immer noch direkter JavaScript-Code - allerdings mit Hilfe von MochiKit.

Mal schauen was sich im Ajax-Python-Land noch so tut. CrackAjax ist zumindestens mal ein weiterer Ansatz, der möglicherweise andere inspiriert das ganze etwas besser auszubauen.

Pragmatic Ajax wird ein Buch (derzeit noch im Beta-Stadium - man kann aber schon vorbestellen und kriegt dann die Betas als PDF) über Ajax und die ganzen Sachen rundrum. Die Pragmatic Bookshelf Bücher sind meist recht pragmatisch (ach) und angenehm zu lesen, könnte sich also lohnen.

WSGI and WSGI Middleware is Easy beschreibt wie man mit WSGI Middleware arbeitet und was das eigentlich ist.

RobotFlow basiert auf FlowDesigner - sowas wie Open Source LabView - und ist eine grafische Robot-Programmier-Plattform, vergleichbar zu RoboLab. Leider aber noch kein LegOS Backend (oder wenigstens eins für den Lego Mindstorms Bytecode) für RobotFlow

OpenMCL 1.0 ist raus - nach einer doch recht langen Zeit endlich mal ein anständiger Versionssprung

Python Paste Power

Python Paste Power ist ein sehr interessanter Artikel über Python Paste, das Metaframework von Ian Bicking. Es macht die Anwendung und Verteilung von Web-Anwendungen in Python sehr viel einfacher (jedenfalls wenn das Framework mit dem man die Anwendung bauen will Paste Support hat).

IRC Logger update

The IRC logger is working fine, but I wasn't happy with the dependence on muh - so I wrote my own little logger bot in python, based on irclib. Does work fine and does only what I want it to do - logging. I allways feel a bit queasy when IRC bots have command structures and stuff like that and I actually don't need any of those ...

So now the project is mostly complete - just use the django admin to add channels to your database, point the logger bot to some IRC host and see how it joins channels and starts logging.

Oh, there are still things to do - for example the bot needs to rescan the list of channels so it notices newly added channels and leaves deleted channels (and maybe I should add channel activation/deactivation so I can switch off channels for some time without losing the archives), but for now it just logs #django and for that it's good enough.

37signals mal wieder

Diesmal Writeboard son Teil zum gemeinsamen Editieren von Texten über das Web. Im Prinzip vielleicht sowas wie SubEthaEdit für ganz arme. Aus der FAQ:

Is this some sort of wiki?

No way. Not at all. Nope. Wikis are icky. Writeboard is about writing and editing solo or with others. It's all about the words. Wikis are about way more than that which is why they are generally pretty confusing to most folks.

Ja, klar, Wikis are icky. Und schwer zu verstehen. Logisch. Mag für jemanden zutreffen der Todolisten-Programme für genialer als geschnittenes Weissbrot hält. Sorry, aber langsam wirds einfach nur noch lächerlich was aus dem Laden kommt. Banalprogramme werden nicht intelligenter dadurch, das man sie in Bonbonfarbe packt ...

Retrocomputing - MIT CADR Lisp Machines

Yeeeehaaaa! Der Sourcecode der MIT CADR Lisp Machines - dem Vorläufer der meisten High-End-Lispmaschinen - ist unter einer BSD-Lizenz freigegeben worden!

Das dürfte hoffentlich dem CADR Lisp Emulator weiteren Auftrieb geben. In letzter Zeit wars ja etwas ruhig um den Emulator geworden.

Wenn jetzt sich endlich Symbolics dazu durchringen könnte ihre OpenGenera-Plattform auf OS X zu portieren, wäre ich noch glücklicher

Und noch ein paar weiter Neuigkeiten zum Emulator - es gibt den ersten Support für ChaosNet, inclusive einem Fileserver für Linux. Und das im Link angesprochene Lispmachine-Board fänd ich ziemlich cool ...

IRC logger for #django

There now is a IRC logger for #django on freenode.net. Ever since the loglibrary broke down, I thought about rolling my own. So I started to build the stuff needed for an IRC logger. The interface itself is written with django, of course

As allways, the source is available in my trac instance. It's currently only running in #django, but it can easily be extended to other channels. And it stores log lines in a database, so I will be able to add searching and stuff like that. It already has a calendar view on the logs.

The logging itself is done with muh - a nice IRC proxy that allows logging to named pipes. Then there is a script fetch.py that pulls the lines from the named pipe and stores them in the database. The last part is the django-based viewer for those logs.

Update: the logging is now done with a dedicated IRC logger written in python. It's in the source tree as loggerbot.py.

I could make use of generic views in Django, only that I needed to parameterize them. I did that with a wrapper function that moves stuff from the keywords of a view function to the extra_lookup args and extra context keywords of generic views. You can see the code in the repository.

The rest is just standard Django stuff: generic templates (that make use of the cool regroup tag) and some custom tags for the calendar and the user colorization. A bit of model hackery and that's it, actually. Nice and simple. Took only a few hours to bang together, and that includes playing with muh and named pipes ...

TwistedDAV ist ein WebDAV Server in Python, der unter Twisted läuft. Sehr interessant wenn man etwas auf DAV aufbauen möchte - bisher gabs da nur den Zope-Source als Beispiel und Basis.

How-to get decimal.py if I have Python 2.3.x beschreibt, wie man Zahlen in Dezimaldarstellung (entgegen den dusseligen binären Floats mit ihren nervigen Rundungsproblemen) für Python 2.3 bekommt. Ab 2.4 ist das ja ein Standardmodul.

i18n and django

Jacob did set up branch commit rights for me and a branch for i18n stuff. So I worked today on the ideas in the patch on ticket 65 by nesh. I did write the stuff mostly from scratch because I wanted some things a bit differently and now it is available for testing.

So first on how you can use the i18n stuff with your django checkout. You need to have a current svn trunk checkout and go to the root of your checkout and issue the following command:

svn switch http://code.djangoproject.com/svn/django/branches/i18n/

After that you should have a tree with my patches applied. I currently only translated very little stuff to make the patch and changes as small as possible, but I already added a german translation file with stuf for the admin index and the isAlphaNumeric validator. I think I will add some more stuff to the translations soon.

The patch only addresses the translation part - other things like date formatting, number formatting, timezone handling should go into different patches to make each one of them as small as possible. The translation object (that's the beast that is responsible for turning strings into their new form) is built on request. This gives us the chance to look at various places that might help in deciding what language to present to the user. The code starts by looking into the session for a django_language variable. If that isn't found, it looks into the cookies for a django_lanaguage cookie. If that isn't found, too, it digs at the HTTP headers. It looks for the Http-accept-language header and splits that up by languages and sorts them by preference. It will use the first language (ordered by preference, highest preferences first) found in the django messagefile repository. If none of those languages can be found, it will ultimately fall back to the default translation object that is defined by the LANGUAGE_CODE setting in your settings file.Message files can be stored in three different places: the django project message files are stored in the django.conf package in a locale subdirectory. This is much like the admin_media and admin template directories. The locale subdirectory is structured as is typical with locale storage: one subdirectory per language and a LC MESSAGES directory in there. The language domain for django message files is allways django . The next place where django looks for message files is in the project - if you have a locale directory in your project, you can store additional message files there. The third place is the application - you can have a locale directory besides your apps views directory. All locale directories are structured the same.

A translation object for a given language is actually a concatenation of four translation objects: first the application translation object. This will have a fallback to the project translation. That in turn will fallback to the global translation object which will fallback to the translation object for the default language. That way higher levels can override translations from lower levels and applications can provide their own translations.

The application for the translations is actually discovered by module introspection - it uses the view func to call on a URL to discover what application carries this view func and uses that to look for local translations. There are two tools provided to manage translations: make-messages.py and compile-messages.py. Both tools can be called in either the root of the django svn tree or in the project directory or the application directory. make-messages.py will scan the current directory and everything below that for strings to translate and will create a django.po file in the locale directory for the given language. compile-messages.py will just turn all .po files into .mo files. Adding translations is easy. In python code you just surround strings (only string constants!) with ('...') or ("..."). That will mark those strings for translation so that make-messages.py can pull them out and write them to the .po files. And it will translate the string on runtime, using the current translation object as discovered from the request. In templates there is the template tag {% i18n ('....') %} - same syntax as with python code, only you need to wrap it as a template tag. Those strings will be pulled from the .html files into the .po, too. The i18n tag supports string interpolation from the context: {% i18n ('blah %(blubb) s blubber') %} would first translate the string and then interpolate the context variable blubb into the translated result.

A hint: when writing strings to translate, don't use positional parameters for interpolation (the %s stuff) but use named parameters (%(blah) s) instead. That way people building translations can reorder the string without breaking your code - some languages have different orders from english.

Using the translations is easy, too: you just need to set your default language in the LANGUAGE_CODE setting and add the django.middleware.locale.LocaleMiddleware to your middleware setting. You need to put it to the top - especially in the admin it should come before the AdminUserRequired middleware - but it needs to be after the SessionMiddleware, if you use that.

That's it for a start, play with it and tell me when something goes wrong. Best place to tell is on the ticket in the django trac.

Open Dylan

Open Dylan ist ex-Harleqin-Dylan, ex-Functional Developer - eine integrierte Umgebung für Dylan-Programmierung und eine Library von diversen Klassen für verschiedenste Zwecke - vor einiger zeit open-sourced und jetzt als erste Beta zum Download für Linux und Windows verfügbar.

Mir wärs ja noch lieber wenn Apple das Apple Dylan freigeben würde, denn dessen Entwicklungsumgebung war wirklich um Welten weiter als alles was sonst so auf dem Markt ist, aber das wird wohl nie kommen - eher wirds von Open Dylan eine OS X Version geben. Auch ganz nett.

Routes für Python

Sehr interessant: Ben Bangert hat Routes für Python portiert. Routes ist der Kern des Mappings von URLs auf Funktionen und zurück der in Ruby on Rails benutzt wird. Also ein allgemeiner Mechanismus mit dem aus einer URL ein Python-Objekt und aus einem Python-Objekt seine URL ermittelt werden kann - flexibel konfigurierbar.

Könnte auch als Element in Django interessant sein, als Alternative zum derzeitigen URL Pattern System. Das derzeitige System liefert ja recht elegant aus einer URL die aufzurufende Funktion - aber leider gibt es nicht diesen gleichen Weg zurück vom Objekt oder der Funktion zurück zur URL.

Ausserdem könnte Routes auch innerhalb von WSGI-Projekten interessant sein - es löst elegant einen kleinen Teilbereich und das so abstrakt, das es gut mit Sachen wie Python Paste(Ian Bickings Meta-Framework für WSGI-Anwendungen) harmonieren müsste.

Warum ich so bei Rails meine Zweifel habe

könnte klar werden, wenn man sich den Artikel hier durchliest: Choose a single layer of cleverness (Loud Thinking) - ja, genau, seine Meinung ist, raus mit Referentieller Integrität, Stored Procedures und Triggern aus der Datenbank, weil er die alle in seinem Code halten will. Wie wärs mit "das Kind mit dem Bade ausschütten"?

Das ist sowas von peinlich, das ich schon fast nicht mehr weiss ob ich nicht drüber lachen sollte - aber eines werd ich sicherlich nicht: meine Karten auf so ein Pferd setzen ...

Hemdsärmelige Ansätze mit einfachen, pfiffigen Lösungen die auch mal gegen Konventionen verstossen sind ok (und wichtig - sonst würden wir alle bei Java und J2EE landen ...) - aber wenn die Programmierung nur noch aus aneinandertackern von halbgaren Lösungen besteht, dann halt ich mich da lieber raus. Da könnte ich ja auch gleich PHP benutzen ...

Weil ichs für ein Firmenprojekt gesucht habe: InformixDB ist ein Python-DBAPI1-Client für die Informix Datenbanken. Funktioniert auch mit Informix SE.

wxWindows Buch

Es gibt ein Buch über wxWindows/wxWidgets: Cross-Platform GUI Programming with wxWidgets - allerdings Schwerpunkt auf den wxWidgets und damit primär für die C++-Programmierer, die wxPython-Bindings sind dort aussen vor. Trotzdem sicherlich interessant wenn man wxWindows in irgendeiner Form benutzt, da die Bindings für andere Sprachen ja immer auf der originalen Bibliothek aufbauen.

Common Scheme

Common Scheme ist eine Implementation eines gemeinsamen Modul-Standards für verschiedene Scheme-Implementationen inklusive eines Paketinstallers der seine Sachen aus dem Netz holen kann. Dazu kommen eine Reihe von ersten Modulen die darüber verteilt werden. Könnte sowas wie CPAN für Scheme werden.

Ähnliche Ansätze gabs schon öfter, aber leider immer nur für einzelne Schemes (z.B. MZScheme hat sowas). Eine Scheme-übergreifende Lösung könnte auf Dauer doch einiges einfacher machen - und Scheme etwas aus der akademischen Ecke holen. Verdient hätte die Sprache es.

Und das beste: Gambit-C und Chicken sind bei den unterstützten Schems dabei

Leider fehlt MZScheme in der Liste der unterstützten Schemes - es wäre schon ziemlich cool seine Programme mit DrScheme zu entwickeln und dann hinterher einfach durch Chicken zu jagen um sie schnell zu bekommen ...

I want one!

Erste Lebenszeichen von Open Genera auf PowerMac - das wäre echt ein Hammer, wenn Open Genera nicht mehr nur auf seltsamen OpenVMS Kisten liefe, sondern auch auf einem PowerMac - da würd ich mir glatt doch noch einen Desktop-Rechner für kaufen

Django Gallery Status

Again news from my gallery project - it's making good progress, even if some of my latest stuff isn't directly visible. I did a lot of reworking in the code and a lot of admin interface changes. Things in the source that might be interesting for other djangonistas:

• I still have a fully filesystem based gallery - but I added a database stored cache. So now when contents is pulled from the filesystem, the code directly checks with it's database cache and updates that accordingly. This led to a heavy rework of the code so that now actually all stuff is driven by model objects - the cache entries are just part of the django model. Makes code much easier and allows the next two changes.
• I added an automatic sitemap for galleries. First versions traversed the filesystem, but now it just uses the database cache to draw a folder hierarchy with thumbnails.
• I added RSS support. The main gallery selection references a RSS feed over all galleries and the folder and image views within a gallery reference a RSS feed only for images within that gallery. This makes use of the RSS framework of Django.
• the view that showed gallery folders and images was reworked to make much more use of django-like stuff: instead of lazy closures that are passed in to the template, I now use custom templates that help to reduce the code of the view drastically (ok, the code is moved to the taglib, but that's much better decoupling than before).

The result: the gallery is much faster, I have RSS up and running and I have automatic sitemaps. The code itself is much easier as it is more model-driven - the former clash between picturefolder model stuff on the one side and FSObject instances on the other side ist gone - and cache maintenance is automatic. And the XMLRPC integration is much faster, too. All in all some very useful internal changes.

Other changes are in the management interface where you now not only have the AJAX-stuff to change object names and hidden state, but can do that from a filemanager, too. That filemanager will be extended for simple management functions like moving, deleting etc., too. It already is able to create new folders.

Parser für Python-ähnliche Konfigfiles

Philip J. Eby hackt mal wieder. Diesmal einen Parser für Konfigurationssprachen deren Syntax an Python angelehnt ist. Besonders interessant: mit dem Parser kann man sehr schön abstrakte Sprachen aufbauen die in Teilen einfach Python für Code benutzen - man kann enthaltene Python-Blöcke nämlich von der Token-Form wieder in sauber formatierten und eingerückten Python-Code umwandeln. Der Parser kennt natürlich all die Randfälle der Sourceformatierung in Python und kommt mit denen auch klar.

Interessant ist das ganze deshalb, weil man mit Python ja leider keine Makrosprache hat und deshalb eigene Syntaxerweiterungen und Sprachen mit domain-spezifischer Syntax und Semantik nicht direkt in Python abbildbar sind - aber man kann über diesen Parser einen Translator für solche DSLs bauen und diese dann wieder in Python wandeln. Dazu dann noch ein bischen Import-Magic und man hätte sowas wie poor-mans-macros für Python ...

MochiKit Tutorial Teil 1

Es ist der erste Teil des MochiKit Tutorial online. Sehr interessante Lektüre - einige der Punkte sind durchaus bedenkenswert. Und MochiKit hat sich bei mir im Echteinsatz auch schon bewehrt - und ja, ich benutze fast ausschließlich JSON dabei.

News from the Gallery project

News from my Django Gallery project: it's coming along nicely. If you want sample code for AJAX with Django or XML-RPC with Django - look into it's source. I implemented parts of the blogger API, metaWeblog API and MoveableType API - just enough so that Photon can post pictures to my gallery. AJAX is used for logged in users to change the title of pictures and folders by just clicking the title and for activating the toolbox on the backside of pictures. Additionally the gallery includes the usual PIL stuff like thumbnailing - I am especially proud of the flipped corner look for folder thumbnails Other stuff worth looking into might be the usage of lazy evaluation to push stuff into the template without precalculating it - it's only calculated when the template actually uses it. And interesting might be the abstraction of the filesystem based content - only the base path is stored in the database model, the rest of the gallery is in the filesystem (and can so be easily managed with FTP, SSH or directly on the unix shell).

Additionally you might look into it for handling of authentication - user registration isn't yet done, but will follow some day. As will comments and RSS - but I have to write that, first. And I am starting to write documentation - docstrings in the code and documentation pages in the wiki.

JavaScript + CSS Box-Modell Rätsel

Also ich hab da so eine HTML-Table. In der sind alle TDs mittels text-align: center zentriert von ihrem Inhalt her. In diesen TDs hab ich zwei DIVs, die übereinander angezeigt werden. Die obere enthält ein IMG, die untere einfach nur einen Text. Beide Inhalte werden auch brav zentriert. Jetzt tausche ich per JavaScript DOM Funktionen die obere DIV mit dem IMG drin gegen eine andere DIV aus, die nur zwei DIVs enthält, die wiederum Text enthalten. Die Texte in den inneren DIVs der neuen DIV sind brav zentriert. Nur die DIV selber, in der die inneren DIVs liegen, ist bezogen auf die umfassende TD nicht mehr zentriert. Das Problem ist mit Safari und Camino reproduzierbar - irgendwie geht die Eigenschaft "Inhalt zentriert ausrichten" flöten für die neu zugefügten Element. Ich hab schon alle möglichen CSS Attribute durchgeguckt und mit allem möglichen rumprobiert (z.B. gucken ob die alte DIV mit dem IMG drin oder das IMG selber einen Wert für left hinterlegt hat), aber irgendwie will das ums Verrecken nicht funktionieren.

Der Hintergrund für das ganze: per Klick auf ein Icon soll ein IMG komplett gegen eine gleichgrosse DIV ausgetauscht werden, in der ein paar Schalter drin sind mit denen Eigenschaften des IMG geändert werden können. Im Prinzip sowas ähnliches wie die Widgets bei Dashboard machen - Konfiguration auf der "Rückseite" eines Bildes.

Im Moment übernehme ich nur die Höhe des Bildes, damit passt die vertikale Ausrichtung perfekt. Nur halt bei der horizontalen Ausrichtung bleibt jetzt alles dynamisch an der Stelle. Wenn ich zwei Zellen übereinanderstehen habe und beide umschalte auf Konfiguration wird die Tabelle in der Breite verändert. Was dann hässliches Zucken gibt. Aber ich will jetzt nicht die TDs statisch aufspannen, denn dann würde sich das Layout nicht mehr dynamisch an die Browserbreite anpassen.

Achso, das ganze muss auch noch mit dem Safari funktionieren, ist schliesslich mein Hauptbrowser

Upadte: in den Kommentaren stehen Links auf Testseiten mit denen man sich das ganze im Effekt mal angucken kann.

JavaScript und die escape() Funktion

Note to self: escape() in JavaScript ist nur latin-1 tauglich - ein utf-8 String mit Sonderzeichen schickt diese als latin-1 Zeichen über die Leitung. Ziemlich dämlich wenn man mit Ajax ein Formular dengelt und dann daraus einen Wert an eine Funktion im Backend schickt und das eigentlich utf-8 erwartet. encodeURIComponent ist die Antwort, nicht escape.

MochiKit – erste Erfahrungen

Ich hatte ja schon kurz MochiKit – A lightweight Javascript library erwähnt. Jetzt hab ich es bei viele-bunte-bilder.de (seit 2007 offline) benutzt (damit der Besitzer einer Galerie die Bildnamen und Ordnernamen ändern kann). Ziemlich geniale kleine Library für JavaScript. Macht die Arbeit mit JavaScript deutlich angenehmer.

PostgresPy ist eine Sammlung verschiedener Python-Module rund um Postgres. Serverseite und Clientseite.

DjangoGallery - sample app with sample installation

Mal wieder englisch, da auch für #django interessant I have uploaded the source and made available the repository and a trac instance for my django projects. The first one that's there is the DjangoGallery - that's what I am using at viele-bunte-bilder.de. I have written a first take at an installation instruction that shows how to get the gallery running on your own site - you could even integrate it into your own project (although you will have to do some minor source changes - mostly replacing the projectname "gallery" by whatever your project is called).

The application isn't fully done, yet. There are many plans on how to extend it, as it will be my main motiviation to remove all other gallery software I am running (I already replaced PHP Gallery and now I am targeting my old mod_perl stuff and last one will be attacking my Wordpress based gallery), so be warned that it will change over time.

If you find bugs, feel free to file tickets. You can file enhancement wishes, too - but since the main target of this project will be to replace my own other gallery projects, it's doubtfull that I will do much work besides what is needed to reach that goal. At least for now - there's no limit to what can be done to the code after I phased out all PHP and Perl code

Since 2007 these links are non-functional, so I removed them.

Kibot ist ein in Python geschriebener IRC bot. Mit einfacher Pluginschnittstelle, so das man den gut als alround-bot auf einen Channel loslassen könnte.

erste Django-Anwendung life

So, meine erste Django-Anwendung ist life - noch nicht fertig, aber im Moment schon mal so gut, das sie besser ist als das alte PHP-Gemölter das da vorher lief. Und zwar gehts hier um meine Bildergalerie unter viele-bunte-bilder.de. Im Moment gibts zwar die Benutzerregistrierung und alles was damit zusammenhängt - aber das werd ich noch irgendwann mal einbauen. Oder auch nicht. Schaun mer mal.

Auf jeden Fall ist es schon mal ganz nett - ich kann Bilder wieder direkt aus iPhoto hochladen (was der wichtigste Vorteil der alten Galeriesoftware war) und die Sachen liegen im Filesystem, nicht in einer Datenbank - was ebenfalls ein recht wichtiger Punkt war.

Die Software selber ist natürlich verfügbar - wer stöbern will, ich hab eine Trac-Instanz mit meinen Django-Spielereien aufgesetzt.

Seit 2007 ist nix mehr davon online.

ObjectiveCLIPS

Way cool: Objective CLIPS ist eine neue Entwicklungsumgebung für OS X. Aus der Beschreibung:

Using Objective C runtime introspection, CLIPS, and FScript, it is possible to write intelligent Cocoa applications. Any Objective C object can be asserted as a fact in CLIPS, however, CoreData provides an additional meta model along with object persistence.

CLIPS ist eine Expertensystemumgebung die im Prinzip auf einem Lisp-Dialekt aufbaut und die Verwaltung von Regeln und Fakten ermöglicht, sowie das Reasoning darüber. FScript ist eine an Smalltalk angelehnte Scriptsprache die direkt mit den ObjectiveC-Klassen im OS X zusammenarbeitet. Beides zusammen sollte ziemlich coole Sachen ermöglichen, zumal mit CoreData auch einfach Datenbanken und Dokumente erstellt werden können. Und beide Sprachen (CLIPS und FScript) fand ich bei meinen Spielereien damit recht interessant - CLIPS war sogar längere Zeit bei mir als "Lisp-Ersatz" im Einsatz, weil es zwar ein recht altmodisches Lisp ist, aber dafür eben mit mächtigen zusätzlichen Abstraktionsmöglichkeiten ausgestattet ist.

RSS 3 - gleich zweimal

Mal wieder jemand der meint er könne ein tolles neues Format kreieren: RSS 3.0 - und der jemand ist zu blöd vorher mal zu googlen. Denn sonnst wäre er über RSS 3.0 gestolpert und hätte vielleicht mal nachgedacht.

Ach watt, nachdenken zählt nicht zu den üblichen Tätigkeiten von tollen Erfindern von Syndizierungsformaten, hat man ja schon in der Diskussion rund um Atom gemerkt. Ich bin immer noch überzeugt das die ganze Syndizierungsformate nur ein grossangelegter netzpsychologischer Test sind.

Heise hat auch was drüber. Und genauso Rogers Cadenhead - der ja im RSS Advisory Board sitzt.

Writing PlugIns beschreibt wie man iPhoto Exporter Plugins erstellt. Könnte mal ganz interessant sein.

Django hat einen wichtigen Schritt für den Release 1.0 gemacht: anonyme Sessions. Bisher waren ja Sessions bei Django an eine Benutzeranmeldung gekoppelt, aber jetzt gehts auch ohne Registrierung. Wesentlich netter als tausende Cookies beim Benutzer zu erzeugen.

CRUD mit Django

Create, Read, Update, Delete - die Standardfunktionen klassischer Interfaces - kann man mit Django sehr einfach zusammenbauen. Dazu gibt es die Generic Views. Auf Postneo gibts jetzt ein CRUD Tutorial, welches zeigt wie simpel solche Oberflächen mit Django zusammengestellt werden können.

Mal was interessantes in Rails

Endlich mal eine Anwendung in Ruby on Rails die über die üblichen Beispielanwendungen hinaus geht - und nicht einfach ein Weblog oder eine total sinnlose Todo-Listen-Verwaltung oder Artverwandtes ist: VitalSource ist eine iTunes-ähnliche Anwendung für Bücher mit einem entsprechenden Backend und einem ebenfalls auf Rails aufbauenden (aber in der Anwendung integrierten) Frontend:

Apparently their backend applications have been running Rails for a while. But they've recently released their client software, and it runs Rails as well. Except... you won't see it running in a conventional browser. As the picture shows, the Rails app runs embedded within the client executable: in the case of the Mac client it uses WebKit to render the responses from the Rails app.

Mir gingen schon die ganzen Rails-Anwendungen - die irgendwie alle nach Übungsbuchaufgaben klangen - auf den Wecker.

A comparison of Django with Rails ist ein recht guter Vergleich von Rails und Django. Wobei Vergleich bei zwei Systemen die durchaus unterschiedliche Themen adressieren natürlich recht schwierig ist - aber der Artikel versucht zumindestens die beiden Frameworks gegeneinander zu positionieren.

Lebende Daten

Komischer Titel, oder? Naja, mir ist einfach nur was aufgefallen bei der Beschäftigung mit Webframeworks und anderen Anwendungen, speziell im Ruby und Pyhton Umfeld. Und zwar die Art und Weise wie Minidaten gespeichert werden und wie zum Beispiel Konfigurationsdaten gehalten werden.

Im Java-Umfeld gibts da eine Inflation von XML-Mini-Languages - Berge von toten Daten. Tot deshalb, weil diese Daten eben nur im XML-Format leben und nur über XML-Werkzeuge bearbeitet und verändert werden können - habe ich zum Beispiel sich ständig wiederholende oder algorithmisch beschreibbare Konfigurationsblöcke (z.B. einen Berg von sich ziemlich ähnlich sehenden URL-Mustern für ein Webframework), kann ich diese nur über XML-Werkzeuge generieren - z.B. mittels XSLT aus einfacheren Formaten generieren. Oder ich schreib mir kleine Tools dafür.

In Ruby sieht die Situation ähnlich aus - nur das da statt XML dann eben YAML genommen wird. Letztendlich ist das aber auch nicht besser - die Konfiguration ist immer noch ein totes File.

Aber sowohl im Python-Umfeld als auch bei diversen anderen dynamischen Sprachen gibt es eine gute Alternative dazu: nimm einfach ein Modul in deiner Programmiersprache. Denn zum Beispiel Pythonmodule leben - ist die Struktur komplexer, aber teilweise repetitiv - einfach eine kleine Python-Funktion schreiben die bei der dynamischen Erstellung der Config hilft. Soll die Config teilweise aus Datenbankinhalten kommen - einfach eine Python-Funktion schreiben die diese Daten zur Laufzeit aus der DB liest und in die Config einmischt. Lebende Konfigurationdaten eben.

Natürlich kommen so Sicherheitsprobleme mit ins Spiel - wir wollen ja nicht den PHP-Fehler mit dem ewigen eval wiederholen. Was dazu also dringend notwendig wäre, wäre eine saubere Sandbox für solche Module. Leider ist genau da in Python ein massives Loch in der Implementierung. Es gab früher mal die Bytecodehacks, die auch wiederbelebt wurden - aber das sind eben nur Hacks. Auch die Methode mittels eingeschränkter Imports und Proxy-Objekten eine Scheinsandbox aufzubauen wie es Zope macht ist nicht der Weisheit letzter Schluss.

Perl bietet hier - wie bei allen Sicherheitsfeatures in Perl üblich wird das natürlich von fast keinem Projekt verwendet - eine sehr saubere Methode über die safe execution. Man kann bis ins kleinste hinein reglementieren was der Code in einer solchen Sandbox darf - und damit ist eine Konfiguration über Perl-Modul definitiv besser abzusichern als in Sprachen ohne so ein Konzept.

Java selber hat natürlich ein ziemlich ausgefeiltes Sicherheitsmanagement - zwangsweise, es soll ja auch in Browsern mit sehr stark beschränkten Rechten laufen. Dieses Security-Modell ist auch für Anwendungen nutzbar und könnte zum Beispiel für Servlets oder eben auch Java-Configs zum Einsatz kommen - vor allem da man mit Java ja auch problemlos Files zur Laufzeit übersetzen und dynamisch laden kann. Erklär mir jetzt mal einer warum die Java-Leute so fixiert auf XML sind, wo sie doch die besten Grundlagen für sichere lebende Daten haben ...

Das Safe-Modell von PHP ignorieren wir hier mal geflissentlich, denn das ist ein Sekt-oder-Selters-Modell - entweder läuft jeder Code unter safemode, oder garkeiner. Was wir bräuchten wäre aber eine selektive Aktivierung unterschiedlicher Sicherheitsklassen für einen einzelnen Codeblock oder Modulimport (ok, Modulimporte hat PHP auch nicht, nur Includes - ich sag ja, wir ignorieren es einfach mal).

Bisher kann man also bei Python nur dann mit lebenden Konfigurationen arbeiten, wenn man sich sicher ist das die Konfigurationen nur von Usern ohne böse Absichten bearbeitet werden. Django zum Beispiel benutzt nur lebende Konfigurationen - es wäre daher eine ziemlich dumme Idee, würde man z.B. die Konfigurationdateien bei zentral gehosteten Anwendungen über das Web editierbar machen.

Wir brauchen dringend eine saubere Sandbox für Python. Ich glaube sogar das wäre ein wichtigeres Teilprojekt als die diversen syntaktischen Erweiterungen die immer wieder angegangen werden.

wxWindows jetzt auch für Common Lisp

wxCL bietet Common Lisp Libraries für die Nutzung der genialen wxWindows GUI Bibliothek. Sehr schön - ich habe wxWindows in seiner Python-Inkarnation schon zu schätzen gelernt, auch in Scheme (über DrScheme) ist es sehr hilfreich, jetzt dürfen auch Common Lisper. Ich weiss das bei Common Lisp natürlich CLIM (heute oft in der Form von McCLIM) das Toolkit der Wahl ist, zumal es wesentlich mächtiger als wxWindows ist. Aber trotzdem ist es schon nett eine Cross-Plattform GUI Bibliothek zu haben, auch und gerade weil es diese eben für mehr als eine Programmiersprache gibt.

die seltsame Neigung der PHP-Programmierer zu eval

Schwachstellen in PHP-Modulen gefährden (mal wieder) zahlreiche Webapplikationen - und zwar wieder mal XML-RPC. Da wird immer noch eval benutzt - und zwar zur Auswertung von Tags. Bitte was? Sorry, Leute, aber das ist einfach nur noch albern - eval ist euch schon mal um die Ohren geflogen, warum wurden die ganzen Aufrufe nicht damals schon rausgeworfen? Oder wenigstens vernünftig gesichert?

Und da wundern sich Leute wenn ich von PHP-Software nicht allzuviel halte ...