In a new Pyramid project we used deform to render forms. We did not really like it. (The reasons might be detailed in another post.)
To see if other form libraries do better I gave yafowil a try at our gocept Developer Punsch 3: yafowil comes with written documentation. To get a form in our Pyramid application I had to find out some things which are not so clearly documented:
Let the project depend on yafowil.webob via setup.py as it contains the necessary WebOb integration.
Import the loader from yafowil like below, to allow yafowil to register all its known components (even all the packages in the yafowil.wiget namespace). Otherwise I got strange errors. (The loader symbol is not needed at all in the rest of the code of the form.)
from yafowil import loader
To get a value displayed in the rendered form use value keyword parameter in the factory like this:
value can be a plain value or a function which gets the widget and the runtime data of the widget as parameters.
Some widgets need JavaScript-Libraries. The integration with Pyramid or Fanstatic is not part of the framework. yafowil.base.Factory.resources_for could be a starting point. (I did not do this yet, so it might be wrong.)
Conclusion: yafowil looks like an interesting framework and after getting a starting point it should be useable in Pyramid, too. Maybe this post can help to ease it a bit.
Gestatten, Stefan Walluhn mein Name – neustes Mitglied der gocept Crew. Seit vielen Jahren bin ich im Unix/Linux-Umfeld als Systemadministrator und Programmierer tätig. Bisher habe ich in erster Linie für kulturellen Zusammenhängen gearbeitet. Über lange Zeit betreute ich die IT des freien Radio Corax in Halle (Saale). Ebenfalls in Halle war ich an der Gründung des Vereins Terminal.21 e.V. beteiligt, der sich zum Ziel gesetzt hat, moderne Technologien für soziale und kulturelle Projekte verfügbar zu machen. Im Rahmen des Vereins gebe ich Schulungen und Workshops zu IT-Themen. Gemeinsam betreiben wir eine mobile IT-Ausstattung zu Festivals und Großevents. Im Jahr 2011 eröffnete Terminal.21 einen lokalen Hackerspace und versucht seither, die IT-Szene der Stadt zu vernetzen.
Seit Mitte November verstärke ich das Team von gocept. Zusammen mit den „alten Hasen“ kümmere ich mich als Administrator um Server und Netzwerk. Gemeinsam sorgen wir für einen stabilen Betrieb der Dienste, finden auftretende Fehler und erdenken solide Lösungen.
Gleich nach meinem Einstieg hatte ich die Gelegenheit, mit allen gocept Mitarbeitern zum Sprint an die Ostsee zu fahren. Zum einen konnte ich das Team auf sehr angenehme Weise kennenlernen, zum anderen hatten wir Zeit in Ruhe gemeinsam zu arbeiten. Während die Entwickler mit verschiedenen JavaScript-Bibliotheken experimentierten haben sich die Admins Ceph, ein verteiltes Dateisystem, angesehen und dessen Einsatz bei gocept evaluiert. Neben ersten Aufgaben im Tagesgeschäft erwartet mich mit Ceph ein größeres Projekt. Ich bleibe gespannt und freue mich auf eine weiterhin interessante Tätigkeit als Administrator bei gocept.
Heute neigt sich unser diesjähriger Sprint dem Ende. Am Dienstag sind wir gen Norden auf die Insel Rügen gefahren, um uns für 3 Tage intensiv darüber zu unterhalten, wie wir in Zukunft Software entwickeln wollen. Der Fokus lag dabei auf der Client-Seite, also dem Teil der Anwendung, der im Browser ausgeführt wird. Hier wollen wir weitere Erfahrung sammeln und Konzepte suchen, wie man wart- und testbaren, strukturierten Code schreibt.
Im Vorfeld haben wir uns auf drei JavaScript Frameworks/Bibliotheken geeinigt, die wir uns dann am Mittwoch in drei Gruppen à zwei Personen intensiv angeschaut haben: Ember, Obviel und Backbone. Neben Dokumentation lesen und Tutorials ausprobieren haben wir auch gegen einen selbst-gestrickten “Spielserver” programmiert, um durch die praktische Erfahrung ein Gefühl für die Konzepte hinter dem Framework zu bekommen und einschätzen zu können, inwieweit sich das Framework in unserem Alltag einsetzen lässt.
Ember hat uns für den Einsatz bei “Grüne Wiese”-Projekten begeistert. Durch die strikte Trennung von Model, View und Controller (MVC) schreibt man nicht nur automatisch saubereren, sondern auch testbaren Code. Das Objekt-Modell bringt automatisierte, bidirektionale Aktualisierung zwischen Model und View mit, und für die Speicherung auf dem Server gibt es ein kleines, gut integriertes REST-Plugin. Der Aufwand, eine funktionierende CRUD-Anwendung, die Änderungen automatisch an den Server propagiert, zu entwickeln, ist mit Ember erstaunlich gering. Auch wie Ember es erlaubt, seine Klassen zu beerben, ist uns positiv aufgefallen. Leider haben wir es nicht geschafft, zwei Ember-Anwendungen auf einer Seite zu laden. Auch ist die Dokumentation noch recht dünn, was daran liegen dürfte, dass Ember noch ein junges Produkt ist.
Obviel ist streng genommen unser eigenes “Kind”, denn erste Ideen dazu entstanden im Jahre 2008 bei gocept. Obviel ist ein Client-seitiges Web-Framework für jQuery mit einem einfachen, aber genialen Prinzip: für ein JavaScript-Objekt rendert man einen View in einem Element. Dreh- und Angelpunkt bei Obviel sind die Interfaces, die definieren, wie ein View Objekte, die das Interface implementieren, rendert. Entwickler, die mit der Komponenten-Architektur von Zope vertraut sind, werden keine Probleme haben, Obviel zu verstehen. Weiterhin lässt sich Obviel problemlos in bestehende Projekte integrieren, es enthält Unterstützung für Internationalisierung (i18n), Forms mit Validierung, verschiedene Template-Engines, Subviews, …
Backbone unterstützt den Entwickler bei der Strukturierung seiner Webanwendungen durch in Code gegossene Konventionen. Es wirkt sehr fokussiert, denn es tut nicht wirklich viel, aber das Wenige tut es sehr sinnvoll. Backbone ist, im Gegensatz zu Ember, sehr gut dokumentiert, löst aber im Moment keines unserer Probleme. Da Backbone insbesondere keine Unterstützung für data binding bietet, haben wir noch Knockout und Rivets ins Spiel gebracht. Für ersteres steht mit Knockback der „Glue-Code“, um die Frameworks miteinander zu verheiraten, schon zur Verfügung, für letzteres mussten wir ihn uns aus der Dokumentation und dem Issue-Tracker des Projekts zusammensuchen.
Ein Fazit zu ziehen fällt uns nicht leicht: Ember behalten wir für das nächste “Grüne Wiese”-Projekt auf jeden Fall im Auge. Da uns Backbone und Knockout/Rivets nicht überzeugen konnten, haben wir uns noch spontan AngularJS angeschaut – aber auch hier ist im Moment die Ernüchterung groß: Persistieren von Daten ist ein ungelöstes Problem, die Watcher auf dem Model (data binding) feuern nur unregelmäßig oder viel zu oft. Nach längerem Probieren haben wir herausgefunden, dass wir eine eigene Direktive schreiben müssen, die sich um die Persistierung kümmert.
Bleibt also Obviel, das wir an der einen oder anderen Stelle in unseren Projekten schon verwenden. Es wird wohl auch in Zukunft unser Werkzeug, um bestehenden JavaScript-Code zu verbessern oder neue Frontend-Einheiten zu bauen.
Creating a single-source build environment with zc.buildout that works for both Python 2 and 3 is a bit of a hassle. This blog post shows how to do it for a minimal demo project.
During the sprints at PyCon DE 2012, we tried to make the upcoming 1.0 release of the nagiosplugin library compatible with both Python 2.7 and Python 3.2. Going for a single code base (without preprocessing steps like 3to2) was no too hard. The only thing left was a single-source zc.buildout setup suited for both Python 2.7 and 3.2. It worked out at last, but currently it needs two buildout configurations. This is a little bit kludgy. I hope that things will improve in the near future so that a single-source build environment with zc.buildout will be possible.
In the following, I will demonstrate the steps with a simple demo project called MultiVersion. It contains nothing more than a single class that is supposed to run under both Python 2 and 3. There is also a unit test to verify that the code works. We use zope.testrunner to run the unit tests. The code’s functionality is irrelevant for the examples, so I left it out. You can download the full source if you are interested.
1. Use a recent enough virtualenv
Older versions of virtualenv are generally not suited since they ship with obsolete releases of distribute and pip. Check if the virtualenv included in your GNU/Linux distribution is too old. Anything below 1.8 reduces the chance of success, so better install a current virtualenv locally then. Likewise, our bootstrap.py must be recent enough to support both Python 2 and 3. The standard bootstrap.py from python-distribute.org does currently not work with Python 3.
Now we are ready to create a virtualenv in a fresh source checkout.
Python 3.2:
$ virtualenv -p python3.2 .
Running virtualenv with interpreter /usr/bin/python3.2
New python executable in ./bin/python3.2
Installing distribute.....done.
Installing pip.....done.
Python 2.7:
$ virtualenv -p python2.7 .
Running virtualenv with interpreter /usr/bin/python2.7
New python executable in ./bin/python2.7
Not overwriting existing python script ./bin/python (you must use ./bin/python2.7)
Installing setuptools.....done.
Installing pip.....done.
2. Running buildout with Python 3.2
I will discuss the steps for Python 3.2 first, since main development will concentrate on newer Python versions. After that, I will describe the necessary steps to make the build environment backward compatible.
To run zc.buildout, we need a buildout.cfg file. I prefer to pin package versions in all projects to ensure reliable builds. As of writing this blog post, there is just an alpha release of zc.buildout that supports Python 3.2. Unfortunately, this version of zc.buildout supports Python 3.2 only, so don’t try this with Python 3.3.
In my experience, it is best to pin distutils to exactly the same version that is included in virtualenv’s support files. While differing versions are possible, they may trigger hard to find bugs since it is not always clear which version is used is which step.
I use the Python interpreter from my virtualenv’s bin directory while creating the buildout executable. This saves me from using activate/deactivate scripts which are slightly cumbersome in my opinion.
$ bin/test
Running zope.testrunner.layer.UnitTests tests:
Set up zope.testrunner.layer.UnitTests in 0.000 seconds.
Ran 1 tests with 0 failures and 0 errors in 0.002 seconds.
Tearing down left over layers:
Tear down zope.testrunner.layer.UnitTests in 0.000 seconds.
3. Running buildout with Python 2.7
Unfortunately, the current zc.buildout alpha release does not work with anything except Python 3.2. Running bootstrap.py fails:
$ bin/python2.7 bootstrap.py
Getting distribution for 'zc.buildout==2.0.0a2'.
While:
Bootstrapping.
Getting distribution for 'zc.buildout==2.0.0a2'.
Error: Couldn't find a distribution for 'zc.buildout==2.0.0a2'.
There is no single zc.buildout distribution that fits both Python 2.7 and 3.2. To get around this, I need to create a special-case buildout.cfg that changes version pinnings for incompatible packages. Besides zc.buildout, zc.recipe.egg needs different versions for Python 2.7 and 3.2 as well.
We now have a build environment that builds single-source code for both Python 2.7 and 3.2 using zc.buildout. Of course, this technique could be extended to support even more versions. But I hope that the incompatible packages will be updated in the near future so that the need for special-case buildout.cfg files will go away. What seems to be most missing: a release of zc.buildout that supports all major Python versions.
TL;DR
Use a current virtualenv version.
Use a compatible bootstrap.py.
Pin your package versions.
Versions for some packages (including zc.buildout) must be special-cased.
Acknowledgements
I would like to thank Andrei Chirila and Michael Howitz for a great sprint session.
Nachdem wir dieses Jahr bereits zwei “Developer-BBQs” veranstaltet haben, laden wir am Freitag, 7.12.2012 ab 14:00 Uhr ein weiteres Mal in unser Büro ein. Jahreszeitenbedingt unter dem Titel “Developer-Punsch”!
Die Veranstaltung richtet sich wie immer an alle (Web-)Entwickler und Sysadmins, die wie wir gerne mal über den Tellerrand schauen. In einem an Open Space angelehnten Format möchten wir uns vorher gesammelten Themen widmen, die auch gerne mitgebracht werden können [1].
Wir würden uns freuen, zahlreiche Interessierte aus der Region und auch darüber hinaus empfangen zu dürfen.
Ab ca. 19 Uhr wird es etwas zu Essen geben und der Punsch wird serviert.
Um Anmeldung per Mail (mail@gocept.com) oder auf dem Etherpad [1] wird gebeten.
P.S.: Since we are addressing local audience we are keeping this post in German. Basically we want developers and admins in our area to meet up, exchange ideas, and enjoy hot punch.
We have been busy in the last months to improve the presentation of our hosting and operations services a lot – and if you attended the Plone Conference in Arnhem, you may have noticed some bits and pieces already: T-Shirts, nice graphics, a new logo, etc.
When pondering how to name our product we quickly decided that just using the old “gocept.net” domain wasn’t good enough. As we are also ambivalent about the whole “cloud hype” we were looking for something else: something specific, something with technology, something where people who know their trade do awesome stuff, something not for the fearsome but for people with visions and grand ideas.
What we found was this:
We call it the “Flying Circus” – for fearless man doing exactly what is needed to boost the performance, security, and reliability of your web application!
All this is just getting started and we will show a lot more at the PyConDE next week. Or, if you can not make it there, register for more information on flyingcircus.io!
Most of gocept is headed towards the German PyCon next week! We’re excited and look forward to meeting people, exchanging ideas and learning new things.
We have prepared several talks to share some of the experiences we gained over the last year:
For the 4th time the barcamp “Mitteldeutschland” is taking place in Jena. gocept is taking the opportunity to sponsor the barcamp – with pie!
If you are going to the barcamp – meet us at “our” pie bar on Saturday. We would be happy to exchange ideas, learn, share, hang around and have some cookies and pie.
Unser erstes BBQ (Rückblick BBQ 1) war inhaltlich und kulinarisch ein voller Erfolg, und soll nun am Freitag, 14. September ab 14 Uhr seine Fortsetzung finden.
Also, alle (Web-)Entwickler und Sysadmins die wie wir gerne mal über den Tellerrand schauen, sind herzlich eingeladen. In einem an Open Space angelehnten Format möchten wir uns vorher gesammelten Themen widmen, die auch gerne mitgebracht werden können [1].
Ein paar Themenvorschläge haben wir schon gesammelt:
Wartbarer und testbarer JS-Code
Resource-Inclusion, Server vs. Client
CSS-Präprozessoren (SASS, …)
Logging und ubiquituous graphing
Layouttests; hilft needle, sikuli?
Python 3
Automatisiertes Deployment mit “batou”
„Ist django der neue Trend?“
Meteor
ipv6
Wir würden uns freuen, zahlreiche Interessierte aus der Region und auch darüber hinaus in unserem schönen Garten empfangen zu dürfen. (Oder je nach Wetter in unseren Büroräumen.)
Auch dieses Mal wird es ab ca. 19 Uhr wieder leckere Speisen vom Grill geben.
Um Anmeldung per Mail (mail@gocept.com) oder auf dem Etherpad [1] wird gebeten.
P.S.: Since we are addressing local audience we are keeping this post in German. Basically we want developers and admins in our area to meet up, exchange ideas, and enjoy BBQ and beer.
