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.

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.

Ich kenne das aus der eigenen Erfahrung. Vor allem, wenn man an sein Ziel kommen will, der Bug eigentlich nur nervt, dann ist man sehr oft dabei “intuitive Abkürzungen” zu nehmen. Das das sehr gefährlich ist und nur teilweise zum Erfolg führt, hat mich die eigene Coding-Praxis gelehrt. Denn so gut wie meine Fehleranalyse, war dann auch mein Code. Sprich, wenn die Probleme nur intuitiv bekannt sind, dann kann der erarbeitete Bugfix ebenfalls nur intuitiv richtig sein. Dass damit bereits die Grundlage für den nächsten Bug/-fix gelegt ist, erschliesst sich sicherlich jeden.

Bei der Arbeit als Projektmanager habe ich dabei zwei Szenarien erlebt: a) den Entwickler, der mit einer Software arbeitet (Open Source, Closed Source) welche Ihm nur zu einem bestimmten Prozentsatz bekannt ist. Zusätzlich erschwert wird das Thema, wenn die Sprache/Entwicklungsumgebung nicht 100%ige Nachvollziehbarkeit aller vom Code ausgeführten Aktionen sicherstellt. Hier habe ich Intuition von Entwicklern sehr zu schätzen gelernt. Wo bei es hier gigantische Unterschiede gibt, grundsätzlich gilt, wie im Wikipedia-Artikel nachlesbar: je mehr Arbeitserfahrung , desto besser die auf Intuition basierenden Ergebnisse.

b) Das zweite Szenario, ist z.B. die Arbeit mit Werkzeugen wie Python o.ä. Hier ist gewährleistet, dass jeder einzelne Schritt des Codes nachvollzogen und geprüft werden kann. Hier ist es immer besser, sich ausschliesslich rational dem Problem zu nähern und dieses Schritt für Schritt einzugrenzen. In der Regel ist man schneller, als mit Anzahl x intuitiven Versuchen den Fehler zu identifizieren.

Ein weiteres Problem ist mir vor allem bei der Arbeit mit Scriptsprachen aufgefallen. Die vermeintliche unmittelbare Überprüfbarkeit des Ergebnisses verleitet (bin of genug selbst Opfer gewurden) sich auf ein Try-and-Error-Coding zu verlassen. Wenn diese zusätzlich auf durch Intuition basierden Bugfixes verlässt, ist die Gefahr gross, das der Fehler nur oberflächlich behoben, aber nicht entgültig entfernt wird.

Grundsätzlich bin ich daher ein grosser Freund von Entwicklungssystemen (Sprache, IDE, Tools) welche grosse Transparenz bei der Softwareentwicklung sicherstellen. PHP (hier vor allem das Zend Studio) liefert hier eine recht gute Grundlage. Python ist allerdings hier deutlich besser, da die Sprache an sich besser lesbar und inhaltlich stringenter aufgebaut ist.

Python bietet darüber hinaus deutlich mehr Tools zur Nachvollziehbarkeit des Codes, als PHP. Das kann aber aus meiner Sicht auch ein Nachteil sein. Denn die Arbeitsweise des Softwareentwicklers (v.a. das rationale Analysieren vs. der bewusste Einsatz intuitiver Fähigkeiten) sind sicherlich deutlich entscheidender für das schnelle Finden der korrekten Fehlerursache. Die Tools können das nur unterstützen.

• » Assign Categories and a Category-Filter to persons
• » Add a comment field to each person
• » Sort companies alphabetically
• » Assign Priority to a person

Download Tschitschereengreen CRM v0.2

For an update:

• » Backup your person_person table with -c -t parameters /w mysqldump
• » Remove person_person table
• » Execute a “dbsync”
• » Insert data back into person_person table
• » Enable user access to the modules Category and Priority and add some of them

I simply used the Django-Admin interface, created a nice model and adjusted the Interface.

The CRM is capable of managing Company and Person Objects as well as tracking passed communication and the integration of a followup-flag which indicates what kind of action should follow at which date.

I attached this to this blog post. Feel free to use it: Download

The duration of development was 4h.

The installation took some time, because we were using Trac on the same machine and had to convert our existing SQLite Trac DBs. Furthermore we were setting up Apache with the conf files included with reviewboard. And after some permission adjustments and log-based debugging the whole system was up and running.

Reviewboard allows your developers to upload all changes as diff files according with ticket information and a comment. The reviewer then can check the change and approve it – the changes are commited by the system upon approval. Very nice are the in place comments, where you can discuss the code just aside the code you’re talking about.

Especially the pre-commit-review is very nice and avoids lots of overhead for merging and checking already commited code.