Theuni on Zope

AJAX loading spinner without flickering artifacts

2009-10-16T11:55:00.005+02:00

We were embedding a spinner to give user feedback while loading data from a server which might take a little longer (but can also be pretty quick in most cases).

Implementing the spinner itself isn't that hard, but we found that quick responses from the server caused visual artifacts flickering up because the spinner was only visible for a few milliseconds (probably roughly 30ms).

The solution we chose to implement looks like this:

before triggering the AJAX request, schedule the code that loads the spinner 150ms into the future
if the AJAX request returns and the spinner did not materialize yet, cancel the scheduled code
if the AJAX request returns and the spinner was materialized, schedule the code to hide the spinner 200ms into the future

We also had two smaller variations: if the replacement looks almost identical to what was shown before, don't hide it until the spinner actually shows up. If the replacement looks usually a lot different, then blank the area immediately waiting for the spinner to show up or not.

We implemented this with MochiKit and here is some sample code:

var expansion_element = $('mydivcontainingstuff');

var spinner_loader = MochiKit.Async.callLater(0.15, function() {
   MochiKit.DOM.addElementClass(expansion_element, 'loading');
   MochiKit.DOM.addElementClass(expansion_element, 'loading-spinner');
   spinner_loader = null;
});
d = MochiKit.Async.doSimpleXMLHttpRequest(ajax_url);
d.addCallback(function(result){
   $('mystuffdivcontainingstuff').innerHTML = result.responseText;

   if (spinner_loader != null ) {
       spinner_loader.cancel();
   } else {
       MochiKit.Async.callLater(0.2, function() {
       MochiKit.DOM.removeElementClass(expansion_element, 'loading-spinner');
       MochiKit.DOM.removeElementClass(expansion_element, 'loading');
   });
}

And here's the CSS:

.loading-spinner {
  width: 100px;
  height: 100px;
  margin-left: auto !important;
  margin-right: auto !important;
  background-image: url(ajax-loader.gif);
  background-repeat: no-repeat;
  background-position: 50% 50%;
} 

.loading * {
  display: none;
}

z3c.recipe.tag

2008-12-06T11:18:00.002+01:00

Nachdem Wolfgang diese Woche auf der Suche nach Symboldefinitionen durch sein Egg-Verzeichnis gekrochen ist, haben wir z3c.recipe.tag ausprobiert und waren auch sofort begeistert: Mit diesem Rezept werden Vim- und Emacs-kompatible ctags-Dateien erstellt, die alle Symbole des genannten Eggs und seiner Abhängigkeiten haben. Damit entfällt endlich die Pfad-Sucherei und die händische Prüfung der Versionsnummern.

Python descriptor tutorial

2008-07-08T13:44:00.002+02:00

Raymond Hettinger hat ein Tutorial gegeben, in dem er erklärt wie man mit Hilfe von Deskriptoren den Attributzugriff (lesen, schreiben, löschen) in Python für seine eigenen Zwecke anpassen kann.

Die Folien zum Vortrag sind praktisch orientiert und sollten demächst online verfügbar sein. In der Zwischenzeit kann man sein bestehendes Deskriptor-Tutorial anschauen.

Nebenbei wird erklärt, wie super() funktioniert und wie aus Funktionen Methoden werden.

Update: Die eigentlichen Folien sind inzwischen im Europython-Wiki verfügbar.

How we develop Launchpad at Canonical (and Bazaar too)

2008-07-08T10:28:00.003+02:00

Steve Alexander hat über die Entwicklungsmethoden berichtet, die für Launchpad und Bazaar benutzt werden. Steve und ich haben lustige handgeschrieben Folien gebaut, die wir abfotografiert haben.

Eins der Hauptprobleme mit denen man sich in der Entwicklung bei Canonical, speziell bei den Launchpad- und Bazaar-Teams, beschäftigt ist die Frage wie man "Corporate-Style Development" mit einem völlig verteilten Team unter einen Hut bekommt.

Der von Canonical verfolgte Ansatz lautet dabei: aus Methoden von agilen Prozessen und der Community-getriebenen Open-Source-Entwicklung ein Emulgat zu erzeugen, das sie "Community Agile" nennen.

Um diese Prozessentwicklung intern fortlaufend zu gestalten, verwendet Canonical ebenfalls Elemente des "LEAN"-Prozesses. Dieser stammt ursprünglich aus der Autoproduktion von Toyota und und dem Kaizen: der kontinuierlichen Verbesserung von Produkten, der Organisation und der Prozesse.

Werte

Die konkrete Ausgestaltung der Prozesse berücksichtigt einige feste Elemente, die Canonical als "Werte" bezeichnet. Diese Werte werden mit den Werten "klassischer" agiler Entwicklung kontrastiert dargestellt und beruhen auf den eigenen Erfahrungen:

Wissen und Motivation über Co-Lokation

Canonical möchte die besten Leute zusammenbringen und hat die Erfahrung gemacht, dass es produktiver ist die besten Leute miteinander über große Entfernungen arbeiten zu lassen, statt darauf zu bestehen, dass alle vor Ort arbeiten und dabei weniger gute Entwickler im Team zu haben.

Patches integrieren über Sprintplanung

Canonical entwickelt die meisten Produkte gezielt als Open-Source. Dadurch kommt es zu Code-Spenden, die nicht unbedingt in die eigene Planung passen. Um das Gesamtprodukt für so viele Anwender wie möglich interessant zu machen ist man bestrebt Patches so schnell wie möglich in die Hauptlinie des Codes zu überführen.

Gemeinschaft über In-House-Entwicklung

Software profitiert in verschiedenen Aspekten davon, wenn sich um Sie eine Gemeinschaft bildet, die sie aktiv benutzt, erweitert und entwickelt. Dazu ist es nicht immer notwendig, dass die eigene Software Open-Source ist - extensive Schnittstellen und Plugin-Systeme helfen einer Community ebenfalls, sich zu etablieren und zur Entwicklung einer Software beizutragen.

Im Vergleich zur agilen Entwicklung ist dies eigentlich eine konsequente Fortführung des Kunde-vor-Ort-Prinzips.

Hochwertige Builds

Ebenfalls ein aus der agilen Entwicklung fortgeschriebener Ansatz: Hochwertige Releases.

Selbst bei zusammensitzenden Teams ist defekter Code problematisch. Wenn sich bei stark verteilten Teams ein Fehler einschleicht, kann dieser aufgrund der Zeitunterschiede schnell gesamte Arbeitstage vernichten, während man auf die Fehlerbehebung wartet. Daher müssen alle Tests nach jedem Checkin laufen. Und eigentlich ist man dann sowieso in der Lage nach jedem Checkin ein hochwertiges Release.

LEAN

Eine weite Frage bei LEAN ist auch, wie viel Arbeit verschwendet wird, um vom Beginn der Implementation eines Features zum Kunden zu kommen?

Mit LEAN versucht man hohe Entwicklungsgeschwindigkeit zu erreichen, um Funktionen so schnell wie möglich zum Kunden zu bringen, denn solange eine Funktion in Arbeit ist, verursacht sie nur Kosten: die Spezifikationen können sich ändern, es erfordert Aufmerksamkeit der Entwickler, es fehlt dem Kunden. Je länger dieser Zustand dauert, desto teurer wird die Funktion am Ende.

Ebenfalls ist es Verschwendung, wenn eine Funktion einmal bereitgestellt wurde, und wieder in die Entwicklung muss. Beispielsweise aufgrund fehlender Qualitätssicherung oder zu großer Arbeitspakete.

Canonical versucht Verschwendung durch einige Methoden zu reduzieren:

Feste Release-Zyklen

Launchpad hat einen Release-Zyklus von einem Monat, bei einem Planungshorizont von 4 Monaten. Ubuntu hat einen Release-Zyklus von 6 Monaten. Dadurch wird es einfacher für die verschiedenen Unternehmensbereiche (Marketing, Testing, Entwicklung) miteinander zu kommunizieren.

Gleichmäßige Arbeitsbelastung

Gegenbeispiel: Wenn man einfach nur einen 1-Monatszyklusansetzt, passiert in der dritten Woche folgendes: Qualitätssicherung muss passieren. Dadurch versucht jeder seinen Code noch irgendwie ins Release zu bekommen, was für erhöhten Stress in dieser Woche führt (eigenen Code schreiben, Tests schreiben, anderer Leute Code reviewen, ...).

Um dies zu umgehen, hat Canonical jeden Code-Reviewer einen Tag in der Woche auf Bereitschaft (jeweils an verschiedenen Tagen). Dadurch kann jeder Programmierer den bereitstehenden Reviewer sofort ansprechen und muss nicht auf die Qualitätssicherung in der dritten Woche warten. Durch synchrone Kommunikation (IRC, Voip) wird hier ebenfalls Verschwendung vermieden, da sowohl Reviewer als auch Entwickler Code und Konzepte gerade im Kopf haben und nicht "swappen" müssen.

Weiterhin werden die Arbeitspakete bewußt kleingehalten: jeder Patch darf maximal 500 Zeilen inklusive Diff-Kontext sein. Ist er größer muss er in mehrere kleinere Einheiten zerteilt werden.

Zum Schluss werden Änderungen so schnell wie möglich auf den Trunk gespielt um erneute Konflikte zu und damit Verschwendung zu vermeiden.

Weiterführendes

Steve hat außerdem auf ein Paper von Ian Clatworthy hingewiesen, in dem die Gedanken zur Community-getriebenen Entwicklung noch einmal vertieft dargestellt werden.

Discouraging the use of Python (or: How to keep the snakes off your plane)

2008-07-07T16:04:00.003+02:00

Harald Armin Massa hat typische FUD-Argumente gegen Python in einem unterhaltsamen Vortrag erfasst und deren Gegenargumente aufgezeigt.

Sneaking in Python

Python schleicht sich ja wirklich überall ein: durch Mock-Anwendungen (die nie ersetzt werden), durch kleine Scripting-Tasks, durch Datenbanktransfers und andere Programmiertätigkeiten.

Der geneigte Pointy-Haired-Boss (PHB) weiß, dass er jetzt vorsichtig sein muss, um zu verhindern, dass Python in seiner Abteilung um sich greift ...

Python is dangerous

... weil weniger Code geschrieben werden muss.

Dadurch braucht man weniger Programmierer, die eigene Abteilung wird kleiner, man bekommt ein kleineres Budget, kleineres Büro und einen schlechteren Parkplatz. Man verliert Macht!

Aber ein anständiger PHB weiß: Python ist nur für kleine Anwendungen geeignet. Wir schreiben aber große Anwendungen. Python kann hier nicht benutzt werden!

... weil Python-Code lesbarer ist.

Dadurch können Nicht-Programmierer (oder Programmierer anderer Teams) verstehen was wir tun. Andere können Fehler in unserem Code finden! Die
Urheber der Spezifikationen können unseren Code auf die Spezifikation prüfen!

Für einen PHB ist das natürlich kein Problem: geistige Eigentumsrechte und Geschäftsgeheimnisse müssen gewahrt werden. Code kann nicht einfach weitergegeben werden!

... weil selbst große Unternehmen Python einsetzen.

Früher konnte man als PHB gegen Python argumentieren, indem man auf eine große Firma setzt: Wir sind eine Microsoft-Firma. Wir nehmen nur Software von großen Firmen (MS, Sun, Oracle, IBM, ...). Aber das geht heute leider nicht mehr. Selbst Sun und Microsoft setzen Python ein. Sogar in der Microsoft Knowledgebase wird Beispielcode in Python veröffentlicht.

Aber zum Glück ist Python keine Sprache erster Klasse. Jeder weiß, dass die richtigen Sprachen für .NET nicht IronIrgendwas heißen. Wenn Python eine Sprache erster Klasse wäre, müßte es ja Python# genannt werden!

... weil Python frei ist.

Und zwar nicht nur frei (wie in Freiheit) sondern sogar frei (wie in Freibier). Dadurch hat die eigene Abteilung weniger Ausgaben, ein kleineres Budget und (siehe oben) der eigene Parkplatz ist gefährdet!

Ein erfahrener PHB weiß jedoch, wie wichtig es ist im Team zu arbeiten. Um in einem Team zu arbeiten, braucht man gemeinsame Ziele. Unser Ziel ist: Profit. Das Ziel eines kommerziellen Softwaretool-Herstellers ist: Profit. Das Ziel der Python-Hersteller ist aber nicht Profit. Daher können wir nur mit Werkzeugen eines kommerziellen Herstellers arbeiten.

... weil Python's Entwicklungsprozess sich an der Leistung der Mitglieder orientiert.

Das ist natürlich Diskriminierung und verstößt gegen viele viele Gesetze, denn Personen, die keine Leistung erbringen haben nichts zu sagen!

Merke: Ein guter Pointy-Haired-Boss weiß, wie man Python vermeidet!

ZEORaid-Talk

2008-07-07T14:42:00.003+02:00

Ich habe auf der EuroPython einen Talk über den aktuellen Entwicklungsstand von ZEORaid, unserer Replikationsslösung für die ZODB, gegeben.

Der Vortrag lief recht gut, mit etwa 50 anwesenden Zuhörern. Es gabe einige interessante Nachfragen, speziell zum Problem ZEORaid selbst hochverfügbar zu machen, ohne komplizierte Lösungen (heartbeat et al) hinzuzuziehen.

Die Folien sind ebenfalls verfügbar.

py.test: rapid testing with minimal effort

2008-07-07T11:21:00.001+02:00

Holger Krekel hat ein 1-stündiges Tutorial gegeben um die Verwendung von py.test zu erläutern.

Übersicht

py.test ist projektübergreifend und hält den Test-Tool-Code in einer eigenen Bibliothek
sammelt Python-Tests automatisch auf und führt sie aus
versucht die Boiler-Plate innerhalb eines Projekts klein zu halten
kann projektspezifisch erweitert werden
läuft auf Linux, Windows, OSX und unter Python 2.3-2.5

Grundlagen

Installation als Egg, stellt "py.test" als Executable zur Verfügung
Der "py"-Namensraum hat einen automatischen Lazy-Importer, der alles unterhalb von "py.*" importiert, so dass man nur "py" importieren braucht, der Rest kommt automatisch mit.
Tests werden über Konventionen automatisch gefunden (Klasse mit Namen "Test*" und Methoden mit dem Namen test_*) automatisch gefunden.
Automatisches Auffinden kann über "--collectonly" nachverfolgt werden
um zu sehen wie py.test vorgeht und was es tatsächlich sieht und findet.
Assertions werden über Python's "assert"-Statement formuliert. Exceptions können über eine Helferfunktion "py.test.raises" mit dem "assert"-Statement kombiniert werden.
Fehlerhafte Werte bei einem Fehler werden getraced um zu zeigen wie sie berechnet wurden.
Generative Tests: wenn eine Testmethode ein Generator ist, kann sie Callables und deren Parameter yielden, die dann als eigentlicher Test ausgeführt werden.
stdout/stderr werden umgeleitet und nur im Fehlerfall ausgegeben
--pdb lädt einen pdb nach einem Fehler
-x beendet den Testlauf nach dem ersten Fehler
--looponfailing: führt die fehlgeschlagenen Tests automatisch neu aus, wenn Dateien, die zu diesen Tests gehören verändert werden
setup/teardown: setup_module, setup_class, setup_method, teardown_*
setup_method bekommt das Methodenobjekt reingereicht, setup_module erhält das Modul-Objekt, setup_class erhält die Klasse
doctests werden anhand der Extension ".txt" automatisch gefunden

Erweiterbarkeit

py.test sucht nach "conftest.py"-Dateien, die die Konfiguration von py.test beeinflussen.
Mehrere conftest.py-Dateien können über Verzeichnisebenen miteinander kombiniert werden.
Diverse Elemente (Session, Collection, Module, ...) können beerbt werden, um eigene Funktionalität unterzubringen.
Dazu werden via "conftest.py" dynamisch die konkreten Klassen für Session, Collection, Module, ... nachgeschlagen, die unterhalb eines Verzeichnisses verwendet werden sollen.
Fehlerberichte können in HTMl generiert werden. Dies kann ältere Testläufe beinhalten, so dass man den historischen Verlauf einsehen kann.
Weitere Plugins für Prolog-Tests, JavaScript-Tests (via SpiderMonkey), verteilte Tests um Tests auf anderen Maschinen (mit ggfs. anderen Plattformen) auszuführen, Integration mit klassischen UnitTest
Reporting kann man momentan nicht (einfach) anpassen

Fragen

Ist die py-Import-Magic kompatibel mit py2exe? Antwort: Unbekannt.
Wie schwer wird es sein py.test auf Python 3k auszuführen? Antwort: Unbekannt
Parallele Ausführung: über verteilte Tests. Können sowohl lokal als auch remote verteilt werden inkl. Multi-CPU-Support.
Gruppierung von tests nach Setup ala Layer: Gibt es momentan nichts.

ReportLab Paragraphs Reloaded

2008-07-07T09:37:00.001+02:00

Dinu Gherman gab einen Vortrag über ReportLab. Dabei ist er speziell auf die Implementation von Paragraphen, deren Probleme und einer Reimplementation eingegangen.

ReportLab-Übersicht

Canvas, eine Zeichenfläche, die in etwa einer Seite entspricht. Kann auch als Bilddatei exportiert werden.
Platypus, "Page LAyout TYPography Using Scripts", bietet verschiedene Objekte (Frame, PageTemplate, DocumentTemplate, Content, Flowables) um Typographie und Inhalt einer oder mehrer Seiten zu beschreiben um daraus ein PDF zu erzeugen.
RML, "ReportLab Markup Language", ein Aufsatz für Platypus, der XML in Platypus-Anweisungen übersetzt (kommerziell, eine freie Drittanbieter-Implementation (z3c.rml) ist aber auch verfügbar)

Paragraphen sind Flowables aus der Platypus-Bibliothek, deren Hauptaufgabe die Berechnung von Zeilenumbrüchen ist. Außerdem wenden Paragraphen verschiedene Stile für Schriften, Einzüge und Anstriche an. Innerhalb eines Paragraphen können XML-Tags verwendet werden, um einige Stile auf Wortebene anzuwenden.

Paragraphen können momentan nicht:

eingebettete Bilder (im ReportLab SVN inzwischen doch)
Silbentrennung
Kerning

Außerdem ist der Code für Paragraphen nur sehr schwer verständlich und nicht erweiterbar. Leider ist das Hauptaugenmerk der Entwicklung bisher auf Geschwindigkeit gelegt worden.

"Paragraphs Reloaded"

Ein neues Flowable, genauer: eine Familie von Paragraphen-Klassen, die abgeleitet werden können (und sollen).

Der MinimalParagraph ist ausschließlich für die Berechnung von Zeilenumbrüchen und wenigen Paragraph-Stilen da.

Paragraphen bieten ein Event-Schema, an dem eigener Code in das Layouting eingreifen kann. Beispielsweise an Wort- oder Zeilengrenzen.

Beispiele für Erweiterbarkeit, die Dinu bereits implementiert hat: einzelne Wörter markieren, Silbentrennung, eingebettete Bitmap- und Vektorbilder, Zeilennummerierung.

Beim Vergleich der Code-Komplexität der Original-Implementation fällt auf, dass der bisherige Paraph etwa 1400 Codezeilen hat, während die neue Minimalimplementation mit etwa 200 Zeilen auskommt.

Im Geschwindigkeitsvergleich hat die bisherige Implementation die Nase vorn. Der neue Code braucht etwa 2-5mal länger um einen Vergleichbaren Paragraphen zu zeichnen. Nach Dinus Erfahrung ist das aber immer noch schnell genug für die meisten Aufgaben.

In Zukunft will Dinu weitere Paragraphen-Attribute implementieren, sowie Kerning, eingebettetes XML, generische Callbacks und eventuell RTL-Unterstützung.

Fragen

Frage nach der Verwendung des TeX-Zeilenumbruch-Algorithmus: nicht berücksichtigt. Andrew Kuchling hatte ihn mal teilweise implementiert, ist aber extrem langsam gewesen.

EuroPython 2008

2008-07-07T08:50:00.001+02:00

Die EP 2008 beginnt heute. Eine gute Neuerung des Hotels ist die freie Verfügbarkeit von WLAN auf den Zimmern, nicht nur im Konferenzbereich. Die Registrierung lief bedeutend einfacher als letztes Jahr: zur Anmeldung gehen, eigenes Namensschild und Konferenztüte nehmen, fertig.

Neue Blob-Verzeichnisstrukturen

2008-06-27T08:36:00.001+02:00

Die ZODB unterstützt seit einiger Zeit große Dateien über den eigenen Datentyp "Blob". Bisher wurde für jeden Blob ein Verzeichnis angelegt, in dem sämtliche Revisionen des Blobs gespeichert wurden.

Eine Installation brachte dies an die Grenze, da als Dateisystem ext3 benutzt wurde, und dort die Anzahl der Einträge je Verzeichnis auf 32k begrenzt ist. Da dies auch in anderen Dateisystemen der Fall ist habe ich das Blob-Verzeichnis etwas stärker strukturiert: 8 Ebenen von Verzeichnissen, abgebildet über die Little-Endian-Repräsentation der OID. Das garantiert maximal 256 Einträge je Verzeichnis und balanciert den Baum relativ einfach aus. Die Implementation ist abwärtskompatibel für alle, die bereits Datenbanken im alten Schema haben.

Momentan lebt der Code noch auf einer Branch und ist für ZODB-trunk und ZODB 3.8 verfügbar.

Eine Einschränkung der Branches ist momentan, dass die Datenbankgröße nur ohne den Platz, den Blobs einnehmen berechnet werden kann, da getSize von ZEO in jeder Transaktion einmal aufgerufen wird, und bei der neuen Struktur sehr langsam wird.

Pakete von Drittanbietern konfigurieren

2008-05-22T08:45:00.006+02:00

Ich hatte gestern mit Sebastian das Problem aus einem Python-Paket für Zope 3 (gocept.country) eine ZCML-Konfiguration (konkret: i18n:registerTranslations) relativ zu einem anderen Python-Paket (pycountry) zu spezifizieren.

Leider erlaubt i18n:registerTranslations nur eine relative Pfadangabe zum aktuell konfigurierten Paket. Glücklicherweise gibt es einen generischen Mechanismus in ZCML um Konfigurationsangaben im Kontext beliebiger Python-Pakete auszuführen: das configure-Statement.

Configure-Statements können verschachtelt werden und erlauben die freie Angabe eines Pakets, das für alle darin eingebetteten Anweisungen als Kontext benutzt wird. Das ganze sieht dann folgendermaßen aus:


...
<configure package="pycountry">
  <i18n:registertranslations directory="locales">
</i18n:registertranslations>
...

ZEORaid in Beta

2008-05-02T17:42:00.002+02:00

Seit Mittwoch gibt es ZEORaid 1.0b1, das wir inzwischen auf einem internen Produktionsserver testweise einsetzen. Die initiale Replikation der 1.1 GB grossen ZODB hat etwas weniger als 15 Minuten gedauert und resultiert normalerweise in Byte-genauen Kopien der originalen Datenbank.

Setzt man zwei identisch konfigurierte ZEORaid-Server auf, kann man auch ZEORaid selbst als einzelnen Ausfallpunkt ausschließen, wobei ein paar operative Einschränkungen zu beachten sind.

ZEORaid unterstützt Zope ab Version 2.8, Blobs und alle anderen ZODB-Funktionen ausser "Versions".

PyCon 2008

2008-03-14T20:47:00.004+01:00

PyCon 2008 (diesmal in Chicago) läuft seit einigen Stunden. Fotos gibt es ebenfalls.

psycopg, segfaults, Valgrind

2008-02-15T08:51:00.004+01:00

Diese Woche habe ich einen Segfault in psycopg behoben, der bei einem Zope-Server häufig für Abstürze sorgte. Das interessante: psycopg hat immer wenn ein Client-Encoding angegeben wurde, das keine Binde- oder Unterstriche enthalten hat, ein Byte zu wenig alloziiert. Genaue Fehlerbeschreibung und Patch gibts im Trac.

Schlussendlich hat mir Valgrind sehr geholfen das Problem zu analysieren. Die Aufrufzeile um einen Zope-Server, der im Vordergrund läuft zu überwachen ist:

valgrind --leak-check=yes --trace-children=yes --suppressions=valgrind-python.supp bin/zopectl fg

Die Suppressions-Datei wird im Python-Source-Code mitgeliefert und sorgt dafür, dass Valgrind sich nicht von Python's Memory-Manager für kleine Objekte verwirren lässt.

zc.resourcelibrary und virtual hosting

2008-02-06T08:25:00.000+01:00

zc.resourcelibrary ist ein exzellentes Werkzeug um automatisch Pakete von Ressourcen (CSS, JS, Bilder) gemeinsam zu registrieren und in eine HTML-Seite (via PageTemplate oder View-Klasse) einzubinden. Dabei werden sogar Abhängigkeiten (z.B. "Meine JS-Files benötigen MochiKit") berücksichtigt.

Da die URLs (CSS verweist auf Bilder) in einer Resource-Library statisch sind, muss man ein klein wenig aufpassen, wie man "Virtual-Hosting-kompatibel" bleibt.

Der kleine Trick besteht darin, alle URLs in CSS-Dateien relativ anzugeben. Dadurch wird die (automatisch berechnete) Basis-URL der Resource-Library ebenfalls auf die statisch enthaltenen Verweise angewandt.

Zope ist nicht simpel - und das ist auch gut so

2008-01-24T12:49:00.001+01:00

Dr. Dewar und Dr. Schonberg haben in zwei Artikeln dargestellt, warum Softwareentwicklung mehr ist als "einfach mal was zusammenzustöpseln":

Beide Artikel bestärken meinen Eindruck in Bezug auf die handwerklichen Fähigkeiten, die ich von Software-Entwicklern erwarte und wie diese von Hochschulen durchgängig enttäuscht werden.

Auch die typische Argumentation gegen Zope, dass es nicht "einfach sei", halte ich nicht für ein Problem, sondern für einen Vorteil. Nur weil es nicht simpel ist können wir komplexe und anspruchsvolle Probleme lösen und mehr tun als "zufällig die richtigen Komponenten raussuchen".

Ich möchte damit nicht für sinnnlos komplizierte Systeme argumentieren. Einfachheit darf aber nicht mit Simplizismus verwechselt werden.

Datenbank-Generationen: Am besten immer initialisieren

2007-12-20T15:59:00.000+01:00

Wir merken uns: wenn man in der Zukunft eventuell Datenbankgenerationen in seiner Zope-3-Anwendung/Bibliothek/... benutzen will, dann sofort eine leere Generation anlegen.

Der Grund: Wenn die Generations-Infrastruktur noch nicht initialisiert ist, dann wird, wenn vorhanden, immer die `install`-Methode ausgefuehrt. Diese versetzt die Datenbank aber direkt in die aktuellste Generation.

Hat man keine `install`-Methode und eine neue Datenbank wird die Datenbank ohne irgendetwas zu tun sofort in die aktuellste Generation gehievt.

Im optimalen Fall beginnt man also immer bei 0. Beginnt man aber bei `None`, dann muss man den ersten Migrationsschritt immer noch in der Installation abbilden, was man eigentlich nicht sollte.

Security-Target für Zope 3

2007-11-08T14:50:00.000+01:00

Die Common-Criteria-Zertifizierung von Zope 3 geht wieder voran und wir haben einen konkreten Zeitplan, der die Arbeit bis zur Zertifizierung abdeckt. Als Zertifizierungstermin zielen wir März 2008 an.

Als ersten Schritt habe ich heute eine überarbeitete Version des "Security Target" (ST) zum TÜV geschickt und bin mal gespannt ob wir mit unseren Überarbeitungen jetzt eine finale Version produziert haben. Im Dezember wird es dann mit den anderen Dokumenten wie im ST beschrieben weitergehen.

Buzzword-Compliance

2007-10-26T14:08:00.000+02:00

Mir ist diese Woche bei technorati ein Blog-Eintrag aufgefallen, der einen Wikipedia-Artikel zitierte und das Beispiel des Buzzword-Compliance-Artikels aufführte. Ich will das Beispiel hier nicht selbst wiedergeben, habe aber endlich mal den Artikel bei der Wikipedia aufgeräumt. Die alte Version steht hier, und ich wundere mich immer noch wer das mal formuliert hat ...

Zope auf der Systems 2007

2007-10-16T09:52:00.000+02:00

Die DZUG wird auf einem Gemeinschaftsstand mit gocept und syslab Zope auf der Systems in München vertreten. Neben den Informationsständen gibt es auch 3 Vorträge im Programm.

Details gibt es auf zope.de.

Web-Formulare mit Zope 3

2007-09-10T10:07:00.000+02:00

Wir bei gocept bereiten uns gerade auf einen Sprint vor. In diesem Sprint wollen wir die Probleme und Erfahrungen der letzten Projekte aufarbeiten, die sich um Web-Formulare drehen.

zope.formlib ist momentan das Standardpaket mit dem wir arbeiten und bietet eine prinzipiell solide Grundlage. Vor einer Weile ist z3c.form erschienen, was einige Probleme der formlib zu beseitigen scheint. In der Vorbereitung zum Sprint evaluieren wir z3c.form als Grundlage unserer weiteren Bemühungen; wir wolle auf jeden Fall ein existierendes Projekt weiterentwickeln und nicht noch eine Baustelle aufreißen. Neben Code werden wir als Ergebnis auch die Dokumentation gängiger Patterns anstreben.

Hier eine Liste der Probleme die uns momentan umtreiben:

Interface-Invariants validieren nur gegen Felder, die der Benutzer gerade bearbeitet hat
Der Kontext und Werte von Feldern die im Formular nicht enthalten waren stehen nicht zur Verfügung.
Werte nach der Validierung aber vorm Schreiben auf Attribute zu verarbeiten ist nicht möglich (z.B. um Passwörter zu codieren)
- Im gleichen Zusammenhang: Validatoren scheinen etwas merkwürdig zu sein da sie die Daten modifizieren können (sollen).
- Properties können helfen, sind aber schwierig
- Evt. müsste man Feldern einen Mutator mitgeben
- Noch eine Option: getrennte Interfaces mit Adapter bereitstellen um solche Werte ins Schema einfliessen zu lassen und auf dem Adapter eine Property definieren
Constraint-Validierungen haben ein komisches Interface
- True oder Exception
- Fehlermeldung steht auf der Exception
- Einige Constraints melden nur "Value too long" ohne dem Benutzer ausreichend Information zu geben
Layout-Engine

Eine getrennte Komponente um Formulare im Stil unseres Produktes "Jucon" zu layouten/generieren

Widget-Definitionen

Interfaces der Widgets aus zope.app.form sind nur intern und via Subclassing gemacht
Wie verhält sich z3c.form in dieser Hinsicht?
Anscheinend sind alle Widgets neu definiert.

Formulare mit ergänzenden Inhalten sind unsauber/unflexibel

Z.B. beim Einbinden von Suchergebnissen
Hier können Content-Provider oder Viewlets helfen.
Viewlets sind aber aufwändig zu deklarieren.

Abhängig definierte Felder
- Das typische Master-Slave-Szenario: Wert in Feld A auswählen so dass Feld B mit davon abhängigen Optionen gefüllt wird, natürlich via JavaScript
- z3c.form und z3c.formjs scheint dafür noch keine fertige Lösung zu haben

Stabilisierung von Zope 3.4

2007-08-31T07:44:00.001+02:00

Zope 3.4 befindet sich seit einiger Zeit in der Stabilisierungsphase, wobei unser halbjährlicher Zyklus für den "Big Tree" mal wieder nicht eingehalten werden kann.

Mit Zope 3.4 stehen alle Zope-Pakete jetzt als Python-Eggs zur Verfügung, so dass man sich für seine Anwendung genau die Elemente aussuchen kann, die man benötigt. Zope wurde in etwa 180 kleine Pakete zerteilt, die nun jeweils ihren eigenen kleinen Release-Zyklus erhalten. Dadurch kann bei Egg-basierter Entwicklung auf Fehler und neue Funktionen deutlich flexibler reagiert werden. Ich finde, dass dies ein exzellenter Schritt ist um die Flexibilität von Zope 3 auf einer weiteren Ebene zugänglich zu machen.

Bevor demnächst die Zope 3.4 Release Candidate veröffentlicht werden kann gibt es eine TODO-Liste die alle noch als stabil zu releasenden Eggs auflistet. Mit diesen Eggs wird dann das klassische Release erzeugt. Diskussion zur Stabilisierung findet auf zope3-dev, ungefähr hier statt.

Abhängigkeiten der Zope-Pakete

2007-08-15T14:25:00.000+02:00

In unserem wöchentlichen Workshop bei gocept befassen wir uns seit einer Weile damit die Abhängigkeiten der offiziellen Zope-Pakete aufzuräumen. Einige der Pakete im zope.*-Namensraum haben beispielsweise Abhängigkeiten nach zope.app.*. Diese Abhängigkeiten erschweren die Wiederverwendbarkeit solcher Pakete außerhalb des Zope-Applikationsservers und sind daher unerwünscht.

Wir haben inzwischen alle Pakete analysiert und den Zustand im Zope-3-Wiki dokumentiert. Für Pakete mit ungünstigen Abhängigkeiten suchen wir jetzt Möglichkeiten diese aufzulösen.

Für zope.annotation und zope.location haben wir bereits Lösungen erarbeitet, die momentan hier und hier diskutiert werden. In den nächsten Wochen wird dieses Thema dann hoffentlich für die Pakete des zope.*-Namensraums erledigt.

Update (31.08.2007):
Inzwischen sind nur noch wenige Pakete mit akutem Handlungsbedarf übrig: zope.traversing, zope.viewlet, zope.sendmail haben immernoch Abhängigkeiten nach zope.app.* - viewlet und sendmail werden noch diskutiert.

Weiterhin gibt es noch einen ziemlichen Ausnahmefall: zope.formlib - dort gibt es einige systematische Abhängigkeiten nach zope.app.* die nicht ohne weiteres aufgelöst werden können.

Im Verlauf unserer Bemühungen ist noch einmal das Thema hochgekommen ob die strikte Trennung zope.*/zope.app.* wirklich gewollt ist:
http://mail.zope.org/pipermail/zope3-dev/2007-August/023349.html

Mein Zope-Blog

2007-08-12T00:04:00.000+02:00

Heute traf sich der Vorstand der Deutschsprachigen Zope User Group (DZUG e.V.). Das Protokoll der Sitzung wird in Kürze auf dzug.org verfügbar sein.

Unter anderem möchten wir die Vorgänge der Zope-Entwicklung und der Organisationsarbeit der Zope Foundation und des DZUG e.V. auch Zope-Anwendern nahebringen, die nicht alle E-Mail-Listen im Detail verfolgen können.

Wir hoffen mehr Personen zu motivieren Ihre Wahrnehmung mit anderen in Form eines deutschsprachigen Blogs zu teilen. Diese Blogs werden wir auf zope.de aggregieren.

Ich werde versuchen meinen Teil in diesem Blog beizutragen und über die Entwicklung von und mit Zope berichten. Die Arbeit der Foundation und des DZUG werde ich ebenfalls berücksichtigen.