Dutch python meeting summary (from 16 Februari 2011)¶

Tags: pun, django, python, grok, deliverance

Last Wednesday we had a fun PUN meeting in our office in Utrecht at Nelen & Schuurmans. A nice turnout with 30 people all in all.

Jasper Spaans videotaped everything, so that’ll turn up on blip.tv soon. My brother Maurits also made a summary. He missed the first talk (which I have) but he has a summary of my own talk (which I haven’t).

Trac - Christo Butcher¶

Trac is for developers, for making developers’ lives easier. About half of the participants uses trac.

• A core part of trac is its wiki. Interesting since version 0.12: a side-by-side editor: the wiki text format on the left and a live preview on the right.

• The second core part is the issue tracker. Nothing much special compared to other issue trackers, but pretty OK. The tracker is good both for bug tracking and for task/feature management.

• Third: source browsing. For subversion, mercurial and git (the latter two by means of plugins). The main reason Fox IT (where he works) started with Trac is this source browser. Not the tracker or the wiki, but the source browser. Handy: the timeline, for browsing all the changes (code, issues, wiki) in the system. Handy to keep track of things.

Upgrading to 0.12 is really worthwile, btw. Especially when you’re working with mercurial or git: 0.12 supports multiple repositories.

Some examples of trac users: Django (including custom ticket properties), virtualbox (uses it as their main site), sourceforge, twisted, etc.

Trac, like zope, is build around a component architecture. One of the only ones. Trac’s component architecture is available as a separate package, too (“pyutillib”).

The core is small, just component management, configuration and request handling. Around it are standard components like the wiki and issue tracker. Configuration is done by an ini-style configation file with an option for some web-based editing of that file. Trac’s data ends up partially in a database, partly on the filesystem (attachments and so).

Trac has its own template language that you can use separately: genshi.

If you want more? Go visit trac hacks. A huge collection of plugins. Warning: not all of them are up to date or work with the latest versions. Good place to go for inspiration. Hudson integration, LDAP user auth, wiki diagrams, buildbot integration and so on and so on.

Want even more: write your own plugin!. Every plugin is a regular python package/egg. An option is to implement an alternative for one of the (around 30) standard trac interfaces (IRequestHandler, IWikiMacroProvider, etc.). An example of what you can do: a plugin that combines a series of wiki pages and turns it into a single PDF.

A possible trac plugin usage: you can forward/cc e-mails to trac. Email2trac parses emails and updates tickets.

Another plugin: a buildbot, called “bitten”, inside trac itself. All of course nicely integrated into the rest of the trac interface. Nice: source code coverage right in trac’s code browser!

Trac has flaws: everything is home-grown. Templates, database abstraction, request handling. It makes several things harder. Tests are harder to run.

Theming with xdv, paste, fanstatic - Maurits van Rees¶

Maurits’ website is ages old and he’s been meaning to update it for ages, too. For now, just a UI update ought to be enough.

He wants to do the UI update without updating the existing site. For that he uses xdv (or “diazo” as it is called now). XDV takes the original site, the new theme and a “rules” file that maps one to the other.

Paste is used to hook it all up together (“all” is xdv and the theme and the original old plone site and also some resources).

Publish your CHANGES - Jan-Wijbrand Kolman¶

Jan-Wijbrand is the release manager for Grok and he’s also a member fo the “Zope Toolkit” release team. So he has to make sure releases are done properly - and he has to do a lot of them.

He found a quote on twitter: Zope Community and Friends, I love you so much for putting changelogs in your PyPI info. Wish others did likewise. (by @jshell).

Who releases software on pypi? Compare for instance Sphinx’ pypi page (well known) with the relatively small grokcore.component’s one. Pypi is the first impression someone gets from your package. Use it well! Add a proper description and a changelog.

Pypy rocks - Jasper Spaans¶

Pypy is python in python, basically. It is a python implemented in “RPython”: restricted python. You’re not allowed to do all regular things in RPython, which allows you to actually do more things with it like compiling it.

Pypy should be a drop-in replacement for the regular python. The number one big thing: it allows you to use a JIT (just in time) optimizing compiler. Which can make it really fast.

Quite soon, you’ll be able to run it on ARM, which means on android.

At Fox IT they had something that needed ridiculous amounts of processing power. They used a big server, but it didn’t scale well enough. So they tried pypy. They had to fix a couple of problems (like a memory garbage collector that didn’t actually collect the memory…). In the end, not everything worked, but they could work around it with some tricks (amongst others “protobuf”, which he likes a lot).

They managed about 10% more requests/second with the pypy implementation. Nice enough. The biggest drawback: it used 20% more memory.

Geographic information websites for water management - Reinout van Rees¶

See Maurits’ summary

My slides are on slideshare.net.

Python in arcgis - Coen Nengerman¶

Arcgis is a tool for dealing with your mapping data and for doing spatial analysis on that data. (Actually, in practice it is the number one tool).

At Nelen & Schuurmans we use python to extend arcgis. For instance to add some hydrologic analysis possibilities.

Coen then demonstrated arcgis’ build-in python prompt! Neat!

Fanstatic - Jan-Jaap Driessen¶

Fanstatic is a spin-off from grok. It is a way for managing your static resources (javascript, css). It makes it easy to deal with css/jss resources by specifying in your code that you need them. A call like my_resource.need() is basically enough once you’ve set up fanstatic.

Fanstatic, after you’ve told it of your needs, injects the resources via some clever tricks into your page.

What they’re working on: releasing javascript/css resources as python packages. So the resource with a fanstatic wrapper. Python packages means you get to do proper dependency management.

Fanstatic handles the difference between development and production: in development you want everything fresh, in production you want everything cached for 10 years. And it puts the javascript at the bottom of your page and the css at the top, for instance.

Read http://developer.yahoo.com/performance/rules.html, that’s the best source of information.

Upcoming: combining javascript in bundles, lazy loading, CDN, minification, etc.

Fanstatic uses WSGI, so it can be used in many web frameworks.

Web2py - Nico de Groot¶

Web2py is easy to learn (Nico’s background is zope/plone). It is stable, secure and lightweight. Lots of database backends (through DAL). It even runs inside google app engine. The internal structure is pretty much the standard model/view/controller structure. It uses the “rocket” wsgi server (it used to be the twisted server).

Prettig personeel - Jean-Paul Ladage¶

Prettig personeel is an HR package. Employee contracts, vacation registrations, notifications, task lists.

The user interface has lots of ajax interaction, but they wanted to keep the interaction and data validation as close to python as possible.

jquery.pyproxy allows you to add a @jquery decorator to your method and add a bit of jquery code that will be run in your browser. It works in zope/plone/django. It helps a lot to keep validation and so on the python side of things. It works because jquery code actually matches quite well with the python syntax.

In your html code, you bind a “pyproxy” method on certain elements.

Check out http://pypi.python.org/jquery.pyproxy for examples!