Europython tuesday morning¶

Tuesday morning talks from the europython conference.

See also the complete write-up overview .

Included here: open source python app for payroll software (including business angle); two zope3/Five talks; talk about SchoolBell (a calendaring zope3 app).

Pinner - Breaking the Rules of Commercial Software Development : Why and How we used Python to Produce a New Deal in Payroll Software.

The world's first business computer was build by a tea and baker shop chain: Joseph Lyons & Co. A payroll system might not seem sexy, but it are those non-sexy systems that are essential to businesses: what if you don't get paid?

The payroll system rules in the UK are changed every year by the government, which is really a good opportunity for open source software. You need an updated version of the program every year, so you're hosed if a commercial vendor goes bankrupt. This point makes open source's longevity terribly interesting. And if you depend on support contracts, yearly changing stuff is also nice.

PayThyme was started as an open source payroll application. Why? They wanted to provide a complete open source business solution. But also multi-platform. Based on open standards. Independent of other systems (like, external commercial databases that need to be upgraded once in a while).

A major income would come from support: in case of startup, importing data. Also day-to-day support. And handling the statutory things you need to do if the company folds.

What's different about PayThyme? No baggage, no legacy systems to be compatible to. And they're using modern programming techniques, a good modern object oriented language (python :-), etc.

How to market it. Difficult for a small company. Initially they supply it as "payroll in a box", which is a turnkey IBM hardware and software solution. It fits in well with the security perceptions of the clients. And it is a nice way to introduce open systems. It comes with support for up to 50 employees, if you've got more employees you need to pay a bit more for support, but the software itself will just work.

Theoretically, other companies could try and cut them out of the loop by providing support. That's ok! If they can do it better than them, PayThyme has already made a huge mistake and probably deserves it.

What they are selling is support and trust, not licences or intellectual property.

There are three main developers, spread out over the country. They use python for the GUI and C for the calculation engine (because that particular expert knew C best). The GUI is made with QT and PYQT. QT designer is a fantastic screen designer. The thyme development environment is all python.

He showed a demo of their development appliction: nice. They have GUI editors for all their file formats. Code generators for generating modules for clients to edit those files, too. So: project automation!

The government provides testcases for testing payroll software for tax issues. They've made a system with which you can automatically test their software on those testcases. This way they can prove their results are correct. Funny thing is that they had to do it automatically because they didn't have the resources to do it by hand...

Martijn Faassen - Five in action

Intro by Paul Everitt: zope 2.8 with the Five framework inside it is the biggest thing to happen to plone in a long time and it came into being because of a lot of work Martijn: so a round of applause!

Zope 2 is in production, but showing its age. Zope 3 is better, but how to make the switch? Five allows you to use zope3 technologies right away in zope2. That prepares you for an eventual zope3 transition. Evolution, not revolution. The important thing: convergence, not divergence. Convergence also for the various zope2 content management systems, as zope3 and five are an opportunity to pool together.

Five is being used for production applications. Nice thing that happened is that it re-engergised the zope2 development. There was actually a zope2 sprint.

What's in Five: interfaces, schema, ZCML zope configuration, adapters and views (including layers, skins), global utilities, add/edit forms, menus, zope3-style macros.

The first big deployment was Oxfam USA. Funny: there was actually a developer that was a newbie to zope and python and he used it productively. On the one hand this is strange as there are quite a lot of high-level concepts like adapters, views, etc. so it might be hard. On the other hand, Five allows you to do a lot of work with just plain python classes, so this was the reason for the newbie's productivity.

He showed a couple of applications that made clear that the convergence happens: developers from silva, cps, plone, etc. are working with it. Five is now the official path for migrating from zope2 to zope3.

What's coming? Code cleanup, improvements in the test infrastructure, the zope3 i18n engine and local utilities. Probably later this year there will be zope3.1 support, also zope3.2. Apparently at the end of the year, zope 2.9 and 3.2 will be released at the same time.

It's easy to use in zope2.8, it's in there! For a lot of things, zope3 style of working is actually much nicer.

Philipp von Weitershausen - 2 + 3 = ?

Paul: Philipp is not the zope3 pope, but at least an archbishop.

Zope3's key feature is the component architecture. So individual components with well-defined responsibilities. No more overloading classes with lots of junk. In zope3, a lot of an application's logic is in wiring things together. The wiring is done in ZCML instead of in code, making it easier to swap out certain components.

You should ask yourself whether your framework (CMF, archetypes, ...) has a migration strategy.

Interfaces are both API definitions and documentation. They define the plugs of components, this way they help you to break down the functionality more easily. And it forces you into a more structured approach.

Security is something that has to do with publishing. Zope2 mixes security declarations with application code. Zope3/Five lets you define security separately in the ZCML files.

Adapters are the most advanced and most difficult to understand part of zope3 and Five. Zope2 expects objects living in the ZODB to provide a lot of functionality (acquisition, size, etc.). This makes it hard to make existing code work with new frameworks. A better approach is to keep the original components as simple as possible. New APIs can be supported through additional components called adapters. So: original thing + adapter (in separate file) = the new combo you want. You say in the ZCML that the adapter provides the extra stuff for the existing thing.

In this way, "browser views" are adapters. They adapt existing things to show a face to the outside world. And, again, you specifiy the template to use in ZCML.

Albertas Agejevas - SchoolBell - calendaring in Zope 3

Paul: a lot of the functionality of zope3 was implemented by the folks from the programmers of Vilnius .

SchoolBell is part of the SchoolTool project, funded by the Shuttleworth foundation . SchoolTool targets the administration part of school software. Open source, GPL. The current code base is totally based on Zope3.

SchoolBell itself is a subset of SchoolTool just for generic calendaring. The goal was to get more programmers contributing to the development, as calendaring is of much more generic appeal. Also: sneaking schooltool into schools by way of calendaring, as it is sometimes difficult to get a foot inside the door.

You can use it as a zope3 component, but with a small tweaking script you can run it as a small calendar server. Of course, it has iCalendar support for exchange with the usual calendar apps. Also there is the possibility to overlap a few calendars in the web view. Also included is resource booking: rooms, projectors.

There was a problem with creating the interface for recurring events, as the official standard allowed such strange kinds of recurring events that it was impossible to make a sane user interface that supported it all. So they borrowed a bit from the mozilla calendar, looking at which parts they implemented.

Two parts are available as small libraries: the core calendering functionality (missing the views, though) and a relationships module (for n:n relations, each identified by URIs). So: schooltool is a suitable calendar app for small groups and it is a set of modules for use in zope3.