Und ja, ich bin begeistert. Endlich ne ordentliche WebUi für .po Files. Zwar muss man nach dem Ändern immer noch den Webserver neu starten, aber das kann man auch alle 24h automatisieren.

Ja nein, funzt super. Fühlt sich gut an und löst so einige Schmerzen in meinem Kopf!

Rosetta gives a webgui for translating. po files

Die Vortragsthemen klingen durchweg interessant. Neben Ausblicken auf die zukünftigen Entwicklungen und Features stellen Best Practices aus dem professionellem Entwickleralltag (Testing, Performanceoptimierung, Deployment) einen zweiten Schwerpunkt dar. Auch neue Datenbankkonzepte und -technologien, wie NoSQL und CouchDB werden heiß gehandelt. Jirka sprach gestern bereits zum Thema „Django at the Enterprise“ über die Integration von Django-Projekten in andere Plattformen, wie in Java EE-basierte  Systemlandschaften mittels Jython. Die Beherrschung dieses Themas insbesondere in Bezug auf Performance ebnet den Weg für Django-basierte Portalentwicklung in großen Unternehmen, a.k.a. the clients with the deep pockets.

Bis Freitag dauert die DjangoCon noch an, davon werden die letzten zwei Tage im Sprint verbracht. Sportsgeist bewiesen die Organisatoren auch bei der zeitlichen Planung der Fachkonferenz, denn der erste Veranstaltungstag, Pfingstmontag (24.05.), ist in Deutschland nach wie vor ein gesetzlicher Feiertag. Manchmal möchte das Pony auch in der Freizeit ausgeritten werden.

Als erstes Testszenario für die Optimierung verwendeten wir eine normale Datenbankabfrage über den Django Object Relational Mapper (ORM).

len(Foo.objects.all())

Zum Profiling der Abfrage nutzten wir die Python-Bordwerkzeuge profile und pstats. Nach einem ersten Profiling zeigte sich die deepcopy()-Funktion mit 6218 Aufrufen und über einer halben Sekunde kumulierter Laufzeit als erster Ansatzpunkt.

In zwei internen Funktionen wurden Dictionaries in try/except-Statements verwendet. Laut den Python-Tipps zum Umgang mit Dictionaries ist dies ein sinnvolles Vorgehen, falls zu beschreibende Schlüssel erwartungsgemäß schon im Dictionary vorhanden sind. Hier jedoch wird das Dictionary mit neuen Werten gefüllt, daher war das Auftreten von Exceptions eher die Regel als die Ausnahme. Zu prüfen, ob ein Schlüssel schon vorhanden ist, ist in diesem Fall also effizienter (und mehr pythonic).

Dieser Fall stellt sich am Beispiel der Funktion _keep_alive() aus Lib/copy.py wie folgt dar:

try:
    memo[id(memo)].append(x)
except KeyError:
    memo[id(memo)]=[x]

Diese Konstruktion wird umgeschrieben zu

if id(memo) in memo:
    memo[id(memo)].append(x)
else:
    memo[id(memo)]=[x]

Weiter fällt auf, dass id(memo) in jedem Zweig der if/else-Anweisung doppelt angefasst werden muss. Aus diesem Grund bietet sich die Auslagerung des Ausdruckes in eine gemeinsame Referenz an. Die zeitliche Einsparung ist vergleichsweise gering, jedoch preisgünstig, weil man ohnehin schon den Code anfasst.

id_memo = id(memo)
if id_memo in memo:
    memo[id_memo].append(x)
else:
    memo[id_memo] = [x]

Wirkung dieser einfachen Maßnahmen: Eine Laufzeitreduzierung von 0.36 auf 0.08 sec in _keep_alive() und von 0.3 auf 0.1 sec in _deepcopy_tuple(), in der eine ähnliche try/except-Konstruktion vorhanden war.

Als nächsten Ansatzpunkt für Optimierungen fielen uns JSON-Felder ins Auge, insbesondere deren Konvertierung beim Datenbankzugriff. Mehr dazu im nächsten Blogeintrag.

Bei Jython handelt es sich um eine Umsetzung von Python in Java, welche als Bindeglied zwischen diesen Sprachen dient. In diesem Zusammenhang erweist sich die Erweiterung django-jython als sehr nützlich für das Deployment und den Datenbankzugriff von Django-Projekten. Mit django-jython kann ein Projekt einschließlich zugehöriger Bibliotheken über einen Django Management Command in eine .war-Datei kompiliert werden. Für das Deployment wird diese Datei nur noch dem Anwendungsserver – hier Apache Tomcat – übergeben.

Bei der Entwicklung für unser Projekt stellten wir wesentliche Geschwindigkeitsunterschiede zwischen Python und Jython fest. Das Laden einer Referenzseite mit umfangreichen Datenbankoperationen dauerte mit Python 1.5, mit Jython ganze 11 Sekunden. Somit lag die Notwendigkeit einer Optimierung der Geschwindigkeit auf der Hand. Unsere Maßnahmen und Erkenntnisse auf diesem Weg wollen wir in diesem und nachfolgenden Blogeinträgen weitergeben.

Ausgangspunkt für die Optimierung ist ein System in der Konfiguration Apache Tomcat 6.0.20, Jython 2.5.1 und Django 1.1. Um nicht in der Vergangenheit zu optimieren, wechselten wir Jython von stable auf trunk aus – die letzte veröffentlichte Version stammte vom September 2009. Zunächst wollte unser Django-Projekt nicht auf trunk laufen, Fehlermeldung:

java.lang.NoSuchMethodError: org.python.core.Py.makeClass(Ljava/lang/String;[Lorg/python/core/PyObject;Lorg/python/core/PyCode;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;

Nach Identifikation des verursachenden Commits erwies sich der vermeintliche Bug als eine Änderung im Jython-Compiler. Für die Neukompilierung des Quellcodes mussten alle vorhandenen .class-Dateien gelöscht werden. Leichte Übung.

Die Umstellung von Jython stable auf trunk reduzierte die Laufzeit von besagten 11 auf immerhin 6 Sekunden. Nun konnte es an die eigentliche Optimierung gehen. Mehr dazu im nächsten Blogeintrag.

Chris Kaula brachte der interessierten Runde anhand eines Mini-Blogs die Vorzüge von Django nahe. Wir konnten live verfolgen wie Chris den Blog in kürzester Zeit aufsetzte – fetzt! (:

Zu Gast waren neben 3 Teammitgliedern vier Studierende der TU Dresden. Das Feedback war rundum gut: Wissen teilen, guter Vortrag, Django-Interesse geweckt, gerne wieder –> Ziel erreicht! Und nebenbei wurden noch unsere schönen Räumlichkeiten bestaunt – da freut man sich doch.
Dank an der Stelle an Seto fürs Beamer-Ausleihen!

Die Folien finden sich hier zum Download: 11-2009 Allgmeine Praesentation TTS HTW – Neue Werkzeuge.pdf

Das Fazit: die Präsentation kam sehr gut an. Habe ein nettes Kompliment von einer anwesenden Professorin zum Vortrag erhalten . Darüber hinaus geb es ne Menge Fragen und ich musste nach 50% Inhalten und 75% Zeit den Turbo einschalten. Alles in allem hoffe ich, dass es die Erwartungen erfüllt hat und einen Einblick in aktuelle Trends und die Arbeitsweise von Tschitschereengreen vermittelt hat.

Die vielfältigen Fragen waren sehr spannend und wären es sicher wert tiefere Diskussionen hierzu zu führen. Hier ein paar Beispiele:
* In der sich so schnell verändernden Welt der Webtechnologien: welche Rolle wird Java hier zukünftig spielen? Vor allem jetzt wo Google, das im den Web Toolkits verwendet, wird es da einen neuen Aufschwung geben?
* Was bedeutet diese schnelle Veränderung für die Lehre? Was ist wenn, die heute vermittelte Inhalte in 3-4 Jahren, wenn die Studenten fertig sind, nicht mehr relevant sind? (Grossartige Frage eines Professors/Professorin)
* Wie passen die aktuellen Web-Sprachen mit Java-Enterprise-Applikationen zusammen?
* Was passiert, wenn in Ihrem Unternehmen ein Entwickler ausfällt?
* etc… spannend, spannend die Themen

Zum Abschluss habe ich noch wie versprochen, zwei Veranstaltungen vorgestellt, welche wir weiterführend umsetzen könnten. Das Interesse war vor allem für das Seminar: Code Esthetics am grössten. Die erste Veranstaltung wird daher am 3.12.2009 um 17.00 stattfinden und je nach Bedarf aller 2 Wochen wiederholt.

Django – lessons learned from a project management perspective

As a conclusion in the work shop we agreed, that Django is in Germany not very well known and lots of companies are working with less professional tools like PHP, etc. wasting their own money. Therefore this presentation was focusing on the business aspects of using Django based on our long term experience with large Django projects.

The hint from Sebastian was trying the legacy database access provided by django, which enables you to override naming conventions and to access any already existing db.

This worked very fine, so that we do have admin page for the yoosic system now and are able to create an xml-rpc based function to replace contents of the yoosic site.

Furthermore I’m thinking about a way, where I can use Django or Symfony to start replacing functions in our current nasty-code-wasted yoosic-app while accessing the current yoosic database.

The only possibility I see is using Symfony by remodelling the current MyISAM-DB-Structur in the schema.yml and the generating the model. Afterwards I will be able to create Ajax-Views, which I can access from yoosic to have it replacing current modules…

Do you see a way using Django? I really would like to prefer this!