thoughts, notes and mooo...
Last weekend I had the opportunity to attend the second Grok sprint. Martijn invited me to join in, as we did work on some grok related issues and testcases already the last couple of weeks.
Grok makes is easier to make use of the great toolset Zope-3 has to offer. It essentially replaces the default configuration and composition system of Zope-3 (based on zcml, an XML language) with another one.
Martijn and I left for Halle, Germany on thursday morning. In Halle we would sprint at Gocept's "headquarters" for one day on friday. We decided to go by train, which would be a seven and a half hour long trip. Time passed by quite quickly actually!
We had diner in Halle and after diner we got back at Theuni's place and I got introduced to the highly addictive game called "Guitar Hero"...
On friday, Christian Theuni, Wolfgang Schnerring, Martijn and I started on making plans for the rest of the sprint weekend and identified two feasible and interesting goals to aim for:
- Make it easy to register local utilities, with being able to easily install and use the Zope catalog as pratical use case.
- Get view-based security to work.
Most of the friday was spent on this planning and figuring out how we would the security and local utility registrations to work. Since my experience with hacking on Grok was still somewhat limited, I took the role of a potential developer of applications with Grok. From that perspective I tried to give feedback on how I would perceive the API that was being designed.
This process of first designing the grok API and how the configuration directives would look like, together with the strong attention to detail in the error reporting of Grok, resembled how user interfaces can be designed to quite some extent. In that sense, Grok is actually an user interface for the application developer to Zope-3's libraries and functionality.
On saturday morning we left for Philipp von Weitershausen's place in Dresden. There we would continue the sprint. Theuni of course brought Guitar Hero there too :-) After a two hour drive to Dresden, we discussed the plans for the rest of the sprint weekend with Philipp.
We then split up in two teams, where Philipp and Theuni would work on the security topic. Martijn, Wolfgang and I would work on the local utility registration with being able to use the catalog as a clear and concrete target to reach.
Since local utilities need to registered for concrete instances of objects in Zope (unlike global utilities that get registered as soon as Zope is started), quite some infrastructure work needed to be done in Grok where core Grok code was refactored for the second, third or even fourth time.
After doing this refactoring-groundwork, Theuni and Philipp reporting succes on getting the Zope-3 security mechanisms to do what we wanted it to do, and enjoying Philipp's lasagna for diner, we played lots of Guitar Hero doing hilarious imitations of how Grok, the caveman, would play rockstar guitar. Grokstar, the dude man! :-)
On sunday we continued working on the same topics in the same teams, until Wolfgang had to leave at the end of the afternoon. We presented the teams' achievements to eachother and concluded that getting the catalog to work, using the local utility infrastructure that now was built, should be fairly easy.
And it is! With just a few lines you can now setup one or more catalog instances, including what indexes to use, for you application.
(It was a bit sad to realise Wolfgang had worked so hard on all the different test cases to cover for the local utility registrations, but had to leave just before we enjoyed actually using it and see it in action)
I think I can say that we went to diner with quite a satisfied feeling, having achieved quite something in this three days! We enjoyed the food, wine and beer and played more Guitar Hero. And then some more :-)
The trip back home yesterday, going from Dresden now, took more than nine hours... This was a bit tiring, but I'm glad I went to this sprint!
The next sprint is already being planned for somewhere in April. The goal then is to get Grok in a polished, documented and releasable state...
update: the next sprint should be somewhere around April, not March and Martijn wrote a blog entry about the sprint too!
zc.buildout is a system for managing development buildouts. Or in other words (mine): for deploying applications, for production usage or development work.
zc.buildout works by way of recipes where one or more recipes define what should be done and how. E.g. "install Zope-3, create an instance and make sure this and this egg is available on the python path". Usually a recipe needs some more information from the user to know where to install things or where to look for dependencies. This is specified in the buildout.cfg file.
I learnt using zc.buildout mainly by looking at other people's work (e.g. grok).
There you can see the specification for the buildout (in the buildout.cfg file) are part of project's hierarchy. So, you check out the project from, in this case, the Subversion repository and you have the project's sources and the specification to make a buildout for this project. You run the buildout command and voila, you have a running project set up.
This makes sense while developing on this particular project, but when you're deploying an application for production use, you do not necessarily want to checkout the sources for the project, since you probably already tagged the release version, uploaded the eggs for you project to some package index (e.g. the cheeseshop or some custom index) and created a buildout.cfg specifically for the deployment of this application.
For these situations I'm trying the following pattern "in the field":
In my project's hierarchy I add a sub directory called "deploy". This directory contains basically only a buildout.cfg. This buildout.cfg knows where to go and look for all the eggs it needs. Now you only have to get this "deployment" buildout.cfg onto the end user's machine and run it to set up the application.
todo: I need to have a look at http://svn.zope.org/zc.recipe.deployment/
