My Universe Logo

My Universe Blog » Entries Tagged as development

Synctory Stepping towards Release

Posted by Jesco Freund at June 19, 2011 8:36 p.m.

Synctory (or libsynctory) is the project I'm currently spending most of my leisure time on. Basically, it implements algorightms similar to librsync. Originally, I developed libsynctory as part of a backup software project, but later decided to continue it as a separate library. The first code was written during my last summer holiday in Denmark, and since then, a lot (of the code) has changed.

Now, after almost one year of rather less steady development, libsynctory is stepping towards release maturity. Today I finally managed to commit a performance test to evaluate how fast libsynctory actually works. Though I immediately discovered a memory leak bug which is not resolved yet, the performance seems to be somewhat satisfactory for a first approach (average runtime in seconds):

+-------------+---------+---------+---------+---------+
|             | small   | big     | huge    | giant   |
+-------------+---------+---------+---------+---------+
| fingerprint |    0.01 |    6.67 |   33.94 |   67.94 |
+-------------+---------+---------+---------+---------+
| diff        |    0.04 |   31.99 |  144.99 |  303.08 |
+-------------+---------+---------+---------+---------+
| synth       |    0.02 |   14.11 |   81.01 |  152.82 |
+-------------+---------+---------+---------+---------+

The test was taken by a constant chunk size (512 bytes) for all four file sizes (0.5 MiB, 0.5 GiB, 2.5 GiB, 5.0 GiB). For me, the results illustrate two main conclusions: First, the algorithms of libsynctory seem to scale linearly with the file size (however I would have been surprised if they didn't), and secondly, bigger files require larger chunk sizes to allow a runtime-friendly processing. Therefore, I think the decision to allow individual chunk size adjustmens was a good one.

The way forward seems to be clear by now – some bugs to fix, some man pages to write, and then I'll hopefully be able to produce a first release of libsynctory. As (almost) always in open source projects, any help is appreciated, particularly I am looking for testers on Linux and OpenSolaris. So if you have some spare time, don't hesitate to contact me!

No comments | Defined tags for this entry: development, open source, synctory

Qt Creator mit CMake

Posted by Jesco Freund at March 27, 2011 5:42 p.m.

Auch C-Programmierer schätzen Komfort – mir jedenfalls geht es so. Warum sollte ich meinen Code mit vi schreiben, wenn es auch bequemer geht? So zahlreich die IDEs mittlerweile auch sind – für meine Bedürfnisse war bisher nur wenig brauchbares darunter. Sicher, Eclipse CDT ist eine passable Entwicklungsumgebung, auch NetBeans ließe sich benutzen. Aber die Java-Schwergewichte (und mittlerweile de-facto-Standards im IDE-Umfeld) sind nicht für Projekte ausgelegt, die CMake als Build System verwenden. Selbiges gilt übrigens auch für Anjuta – hier liegt der Fokus klar auf den GNU Autotools.

Interessanterweise kommen aus der Qt-Ecke zwei IDEs, die mit CMake recht gut zusammen arbeiten. Da wäre zum einen KDevelop 4. Leider ist Version 4 noch etwas wackelig, und auch die Zusammenarbeit mit Versionskontrollsystemen läuft noch nicht so ganz rund – mit Subversion klappt's einigermaßen, mit Git so lala und Mercurial wird derzeit gar nicht unterstützt. Schade eigentlich, denn die CMake-Unterstützung ist wirklich exzellent; die Mouse-Over Dokumentationseinblendungen sind wirklich der Hammer und machen auch CMake-Neulingen den Einstieg sehr leicht.

Im Bewusstsein der meisten C-Programmierer spielt Nokia's Qt Creator eine eher untergeordnete Rolle – dabei kann die recht schlank geratene IDE viel mehr, als nur C++-Code mit Qt zu verleimen. Die Editor-Komponente kann selbstverständlich auch mit „normalen“ ANSI C Code- und Headerdateien umgehen. CMake anstelle von qmake wird ebenfalls unterstützt, auch wenn das nicht auf den ersten Blick ersichtlich ist. Da keine Projekt-Templates für CMake mitgeliefert werden, bleiben zwei Möglichkeiten: Entweder von Hand ein CMake-Projekt im Dateisystem anlegen und dieses einfach öffnen, oder eigene Templates bauen.

Genau letzteres habe ich jetzt getan, damit ich nicht mehr so häufig zwischen Shell und IDE hin- und herhüpfen muss. Wer mag, kann sich die Templates gerne herunterladen. Die Datei muss nach /usr/local/share/qtcreator/templates/wizards/ entpackt werden (unter Linux kann der Prefix verändert sein, dann wäre es /usr/share/…). Beim nächsten Start der IDE steht dann eine neue Kategorie CMake Projects zur Verfügung. 100%ig perfekt sind die Templates noch nicht; das ausführbare Binary findet Qt Creator noch nicht ohne Hilfe – eine Kleinigkeit, die sich IMHO aber verschmerzen lässt.

No comments | Defined tags for this entry: development, IDE, open source, Qt Creator

YAR specification feature freeze

Posted by Jesco Freund at Feb. 5, 2011 12:12 a.m.

Today, I froze the design for the YAR container format. Trunk has been branched to 1.0-STABLE. The compiled 1.0-STABLE documentation is available at docs.yarutils.org.

The current state now incorporates all features considered relevant for the 1.0 release. At a short glance, these are:

  • Recoverable index for both, fast access and robustness
  • Secure hashes (no path to attack symmetric encryption)
  • Electronic signatures

This list is far from being complete – just have a look at the specification or the issue tracker. The next two weeks will be dedicated to finalizing the documentation, i. e. tracking down unclear expressions, typos etc. and filling the index and glossary.

No comments | Defined tags for this entry: backtory, development, open source, yar

First alpha of libsynctory released

Posted by Jesco Freund at Jan. 5, 2011 5:02 p.m.

Some minutes ago, I released the first alpha (ever!) of libsynctory. It is a replacement for librsync, but makes use of different algorithms. Therefore, processing might be slower and fingerprint chunks are definitely larger than the ones produced by librsync. However, libsynctory's fingerprints are much more collision safe, so it is more adequate for environments, where high reliability is estimated more than performance or network load (like e. g. backup applications).

Currently, I consider libsynctory to be “feature-complete”, meaning it offers all the functionality required to serve its intended purpose. It can create a fingerprint of a given file. Using this fingerprint only (and without resorting to the original file), it can calculate the difference between the original file and another file. Using this difference and the original file, the other file can be restored.

However, libsynctory does neither offer any documentation yet (shame on me), nor does it provide a decent interface for error handling (or even backtracing). Furthermore, it has not yet been reviewed for thread safety, so use it with care (if you intend to do so). If you would like to test libsynctory, just grab the source archive from the project page and do the following:

tar -xjvf libsynctory-0.1.0-a1-Source.tar.bz2
cd libsynctory-0.1.0-a1-Source
cmake .
make
sudo make install

This will install the header files into /usr/local/include and the library itself into /usr/local/lib. Within the build directory, you will find some test binaries (in src/test). You can use them for very simple single file operations, just to see how libsynctory works.

No comments | Defined tags for this entry: backtory, C, development, synctory

Python für Webanwendungen 4: Lieferservice

Posted by Jesco Freund at Oct. 29, 2010 9:56 p.m.

Seit dem vorherigen Teil hat es nun ein paar Tage gedauert - aber hier ist er nun, der versprochene letzte Part. Eine funktionierende Webanwendung ist nun vorhanden, aber noch läuft sie nur im Entwicklungsmodus, mit dem CherryPy-eigenen Webserver. Für eine Produktivumgebung ist definitiv ein gestandener Webserver vorzuziehen, der den statischen Content besser und schneller ausliefert, robust und praxiserprobt ist und sich über entsprechende Startmechanismen automatisch als Dienst starten lässt.

Mit WSGI-Anwendungen und FastCGI hatte ich bisher kein Glück – zu instabil lief dieses Konstrukt, wenn es überhaupt ans Laufen kam. Richtig schnell und robust hingegen laufen bei mir diverse WSGI-Anwendungen in Kombination mit dem Apache Webserver und mod_wsgi. Unter FreeBSD beispielsweise lassen sich beide Pakete bequem aus den Ports installieren, auch Debian bringt ein entsprechendes Paket mit.

continue reading Python für Webanwendungen 4: Lieferservice

1 comment | Defined tags for this entry: Apache, CherryPy, code, development, python

Python für Webanwendungen 3: Türsteher

Posted by Jesco Freund at Oct. 26, 2010 11:29 a.m.

Mit ein wenig Phantasie kann die Anwendung aus Teil 2 hübsche HTML-Seiten rendern und verschiedene Themes verwenden. Doch was, wenn eine dieser Ansichten vor unbefugten Augen geschützt werden soll? Sicher, CherryPy bringt eine rudimentäre Authentifizierung über HTTP-Auth mit – keine sehr elegante Lösung. Von einer modernen Webanwendung erwartet man eher ein Login-Formular.

Das wäre mit einem hübschen Template und einer Controller-Methode ja noch fix erledigt. Doch wogegen authentifiziert eine Anwendung eigentlich? Viele Webanwendungen haben die in meinen Augen sehr schlechte Angewohnheit, auf eine eigene Userverwaltung zu bauen. Als Backend kommen häufig Datenbank-Tabellen in einem RDBMS zum Einsatz. Ich finde das äußerst nervig, denn i. d. R. lassen sich diese User-Informationen nicht oder nur mit aufwändigen Hacks von anderen Anwendungen nutzen – mit der Konsequenz, dass User für jede Applikation ein eigenes Login-Handle benötigen.

Sowohl für User als auch Admin ist es viel angenehmer, wenn jedem User (z. B. in einem Unternehmen, einer Organisation, einer Community, …) genau ein Handle zugeordnet ist. Nur ein Passwort, das vergessen werden kann, Änderungen von Attributen (Nickname, Name, Mail-Adresse, …) schlagen in allen Anwendungen durch, und als Admin muss man sich nur mit einer Userdatenbank herumschlagen. LDAP bietet genau diese Möglichkeit: Alle User-Handles an einem Ort zu speichern, und diese mit zusätzlichen Attributen auszustaffieren - je nachdem, was die verschiedenen Anwendungen so benötigen. Auch der Zugriff auf einzelne Anwendungen oder Anwendungsbereiche lässt sich über LDAP-Gruppen regeln.

In diesem Teil geht es daher um die Implementierung eines eigenen Authentifizierungs-Moduls für unsere Webanwendung, das gegen einen LDAP-Verzeichnisdienst authentifiziert. Um das Beispiel erst mal nicht zu komplex gestalten, soll das Modul nur die übergebenen Credentials prüfen, um den Zugang zur Applikation zu erlauben oder zu verwehren. Komplexere Prüfungen (etwa die Zugehörigkeit zu einer bestimmten LDAP-Gruppe) lassen sich dann später leicht einbauen.

continue reading Python für Webanwendungen 3: Türsteher

No comments | Defined tags for this entry: CherryPy, code, development, Genshi, python

Python für Webanwendungen 2: Genshifizierung

Posted by Jesco Freund at Oct. 25, 2010 4:34 p.m.

Die im vorhergehenden Teil vorgestellte Anwendung ist in ihrem Können bisher eher sparsam – keine großartige Anwendungslogik, keine komplexe Steuerung, keine hübsche Darstellung. Genau diesem letzten Askpekt möchte ich mich im zweiten Teil der HowTo-Serie zu Python und Webanwendungen widmen. Für Webanwendungen (fast) unumgänglich ist die Darstellung der Oberfläche mittels (X)HTML. Die finsteren Zeiten, in denen man sich in CGI-Anwendungen das HTML-Dokument noch mittels print() zusammengebaut hat, sind glücklicherweise längst vorbei.

Heute benutzt man dafür Template-Systeme. Grundsätzlich lassen sich Template-Systeme in drei Kategorien einteilen:

  1. Als Platzhalter-Templates bezeichne ich Template-Systeme, die darauf beruhen, in einem (wie auch immer gearteten) Template-Dokument auf bestimmte Weise gekennzeichnete Platzhalter auszutauschen. Die Verarbeitung dieser Templates basiert meist auf Regulären Ausdrücken oder auf einfachen Suchen/Ersetzen-Operationen.
  2. XML-Templates würde ich Templates nennen, die einen eigenen XML-Namensraum definieren und dadurch dem xhtml-Namensraum im selben Dokument nicht in die Quere kommen. Die Verarbeitung erfolgt über einen XML-Parser, Xpath und ggf. XSLT-Transformationen.
  3. Kompilierte Templates kenne ich eigentlich nur aus einem Bereich, und hier stellen sie für mich einen Sonderfall der XML-Templates dar. Das Template wird beim Start der Applikation geladen und in eine Controller-Funktion umgewandelt, die aus den im Template eingebetteten Code-Schnipseln und print()-Anweisungen für die HTML-Dekoration besteht.

Für Python steht eine Reihe von fertigen Template-Systemen aus den Kategorien Platzhalter- und XML-Templates zur Verfügung. Gerade bei arbeitsteiliger Entwicklung bietet sich der Einsatz eines XML-Template Systems an. Auch wenn man sich dadurch zunächst etwas mehr Komplexität einhandelt – die höhere Flexibilität macht das in großen Teilen wieder wett. Aus dieser Überlegung heraus kommt in der Beispielanwendung das Template-System Genshi zum Einsatz.

continue reading Python für Webanwendungen 2: Genshifizierung

No comments | Defined tags for this entry: CherryPy, code, development, Genshi, python

Python für Webanwendungen 1: Projektstruktur

Posted by Jesco Freund at Oct. 25, 2010 1:03 p.m.

Hier nun wie angedroht der erste Teil, in dem ich einmal vorstellen möchte, wie man sich selbst basierend auf CherryPy und Genshi das Grundgerüst für eine Webanwendung aufbaut. Dabei geht es mir jedoch nicht um's Wiederkäuen der Dokumentation (wie etwa des Genshi Tutorials) – die darf jeder schön selber lesen ;-). Vielmehr geht es mir darum, ein Grundgerüst zu beschreiben, das eine belastbare Basis auch für komplexere Anwendungen darstellt. Das kommt IMHO in der angebotenen Dokumentation einfach zu kurz – ein „Hello, World“ mit dem gesamten Code in einer einzigen Python-Datei ist sicherlich kein Best Practice für die Entwicklung von Webanwendungen…

Zunächst einmal möchte ich kurz darauf eingehen, warum ich CherryPy und Genshi gewählt habe. Bei Genshi liegt der Fall relativ einfach: In meinen Augen ist es die derzeit mächtigste und professionellste Framework-unabhängige Template Engine, die für Python zu haben ist. Anders als bei vielen anderen Template-Engines üblich verwendet Genshi einen eigenen XML-Namensraum, so dass Templates während der Entwicklungsphase als ganz normale XHTML-Seiten behandelt werden können – für Designer und HTML-Bastler ein großes Entgegenkommen.

Bei CherryPy liegen die Pro's und Con's dichter beieinander. Auf der einen Seite bringt CherryPy schon Funktionalität mit, die ich eigentlich gar nicht haben will. Auf der anderen Seite ist CherryPy ein aktiv entwickeltes und gepflegtes Projekt, und genau die Dinge, die ich benötige, bringt es ebenfalls mit: WSGI-Fähigkeit, eine einfache Schnittstelle zum Request, URL-Mapping und Sessions. Als zusätzlicher Leckerbissen bringt CherryPy auch noch eine eigene Konfigurations-Engine mit und bietet mit der Tools-Schnittstelle ein zugleich einfaches und mächtiges Werkzeug für eigene Erweiterungen. Eine Alternative wäre gewesen, Flup als WSGI-Basis zu verwenden und URL-Mapping, Sessions und Request-Handling selbst zu implementieren. Die Wahrscheinlichkeit, dabei Bugs und ggf. eine Angriffsfläche gleich mit einzubauen, halte ich jedoch für relativ hoch – daher meine Entscheidung für CherryPy.

continue reading Python für Webanwendungen 1: Projektstruktur

No comments | Defined tags for this entry: CherryPy, code, development, Genshi, python

Python für Webanwendungen: Einführung

Posted by Jesco Freund at Oct. 25, 2010 12:49 p.m.

Django ist derzeit eines der mächtigsten RAD-Frameworks für's Web. Genau wie seine Konkurrenten (Ruby on Rails, Pylons, TurboGears & Co.) ist Django jedoch sehr stark auf Anwendungsfälle fixiert, in denen Datensätze in bzw. aus einem RDBMS angelegt, bearbeitet, angezeigt und gelöscht werden. In anderen Anwendungsfällen dominiert heute Java – wirklich gerechtfertigt ist das aber nicht.

Gerade Python macht es einem Entwickler dank WSGI und einer Vielzahl nützlicher Bibliotheken sehr leicht, sein eigenes Framework zusammenzusetzen. Dabei beziehe ich mich mit „Framework“ auf eine bestimmte Strukturierung der Anwendung, durch die Standard-Aufgaben (wie etwa das Rendern von HTML-Seiten) extrem einfach zu implementieren sind. Da ein ganzes Framework zu viel für einen einzelnen Blog-Eintrag ist, habe ich dieses HowTo in vier Stücke zerhackt:

  1. Aufbau einer Projektstruktur
  2. Integration von Genshi
  3. Authentifizierung gegen LDAP
  4. Deployment in einer Produktivumgebung

Zu guter Letzt noch ein kleiner Hinweis: Meine Code-Beispiele beziehen sich auf Python 2.7 – daher ist bei älteren Versionen (insbesondere <2.6) Vorsicht geboten. Gerade wenn Exceptions ins Spiel kommen, halte ich mich an die neue as-Notation gemäß PEP 3110.

No comments | Defined tags for this entry: CherryPy, code, development, Django, Genshi, python, TurboGears

MVC ohne Java, Python, Ruby & Co

Posted by Jesco Freund at Sept. 15, 2010 10:23 p.m.

MVC kann man auch jenseits der klassischen objektorientierten Programmiersprachen umsetzen. Derzeit bastle ich an einer Implementierung in C – teils als Proof of Concept, teils für einen bestimmten Einsatzzweck – auf jeden Fall aber aus Spaß an der Freude.

Die Idee hinter Stormrose (so habe ich das Projekt getauft) ist relativ einfach: Ein kleiner, schlanker HTTPd nimmt Requests entgegen, ermittelt (ähnlich wie bei Django) anhand der URI den zuständigen Controller, übergibt diesem den Request und lässt vom Controller dann eine Antwort generieren, die zurück an den anfragenden Client übertragen wird.

Controller sind dabei einfache C-Funktionen, die einem bestimmten Schema entsprechen. Zu Demonstrationszwecken habe ich einen „Hello World“ Controller schon mal eingebaut, der – wie nicht anders zu erwarten – nur ein einfaches „Hello, World“ an den Client sendet. Ein Controller für statische Inhalte soll noch hinzukommen, so dass Stormrose theoretisch auch als „normaler“ Webserver einsetzbar wäre. Weitere Controller werden dann im Zuge der Entwicklung einer Stormrose-Applikation erstellt.

Auf Seiten der Views habe ich noch keine Aktiv-Posten zu verbuchen – hier muss ich mir noch etwas sinnvolles ausdenken. Einen (schwergewichtigen) XML-Parser möchte ich aber tunlichst vermeiden – sonst kann man ja gleich JSPs verwenden…

Für das Model gilt im Prinzip ähnliches – hier möchte ich allerdings dem Anwendungsentwickler wirklich komplett freie Hand lassen. Einen ORM-Mechanismus wird es nicht geben – Frameworks mit diesem Dreiklang (ORM, Templates, Glue) gibt es schon zu Hauf. Stormrose ist eher für Applikationen gedacht, die eben nicht hauptsächlich Datensätze aus einem RDBMS bearbeiten.

Damit wird es sicherlich eher ein Nieschendasein führen – wer es sich trotzdem mal ansehen möchte, kann sich den Code jederzeit per Subversion auschecken (https://svn.my-universe.com/stormrose/trunk). Derzeit ist der Code aber noch sehr unreif und befindet sich in ständiger Entwicklung. Momentan taugt er also bloß zum Experimentieren. Sobald die Controller-API stabil ist, werde ich dann auch ein kleines How-To zur Entwicklung einer kleinen Stormrose-Applikation veröffentlichen.

No comments | Defined tags for this entry: C, code, development, programming, Stormrose

Page 1 of 2 next page »