launchpadblog

Bjorn Tillenius recently took the role of Launchpad Technical Architect. That, and the release of Launchpad 3.0, seemed like a good opportunity to learn a bit more about his new role.

Matthew: You’ve just taken a new role in the Launchpad team of Launchpad Technical Architect. That sounds like a big job: how is it going so far?

Bjorn: Yes, it’s indeed a big job. There are a lof of things that are in need of attention, so a big part of my work so far have been to talk to people, and get a list of the most pressing tasks written down. But I’ve also managed to do something concrete, like integrating our Windmill (a Javascript integration test framework) test suite into our zope.testing test runner, which we use for all our other tests.

Matthew: Is your role mostly concerned with the code of Launchpad or also the servers etc?

Bjorn: My role is mostly concerned with the code of Launchpad. My main objective is to make it easier to develop Launchpad, which includes designing and refactoring code to make it easier to use. I’m also concerned about ensuring that the quality of the code is high, and that we have good automated tests.

Matthew: What are your top three priorities for your new role?

Bjorn:

1. Make it quicker to develop new pieces of code.
2. Code reuse.
3. Make sure Launchpad code is scalable.

Matthew: What challenges does being a large Python/Zope application throw up?

Bjorn: Complexity. There are a lot of sub-systems that need to interact, and it’s hard to keep track of everything in the code base. If you work on one part of the system, you might not know that another part of the system has already solved part of your problem.

Another big challenge is that Python is big on readability. It should be easy to read and understand your code. This is great, except when you get more users, and realise that the beautiful code you wrote is really slow. Producing code that is both beautiful and fast is hard, and sometimes impossible. You have to make a lot of compromises.

Matthew: What coming technologies look as though they might be interesting for Launchpad?

Bjorn: We’re currently looking into using Grok and memcached.

Grok is interesting, since it allows us to more easily replace our ZCML code with Python code. This makes it easier to both write, and to understand, since ZCML adds another language the developer has to learn, and it adds an indirection which can be hard to follow.

Memcached is interesting, since we currently render a big part of the HTML page on-the-fly, which is quite expensive. Memcached allows us to cache part of the page, so that our pages will render faster.

Matthew: How do you ensure a consistent approach to development and architecture of Launchpad with a distributed team?

Bjorn: Being in a distributed team certainly makes things harder, when it comes to making sure everyone does the same thing. I’d say our biggest asset here is the code review that we require before any code can land in the mainline. With another pair of eyes looking at the code, the chance of spotting areas of improvement increases. Of course, spotting mistakes at this point isn’t ideal, since it’s quite late in the process, the developer has already spent time writing the code. That’s why we also are pro-active, and use mailing lists and IRC to inform the developers about things they should be aware of when coding. We also aim to have a call with another developer, before the code is written, so that there are at least two people thinking about the design.

Most of these discussions are made on public mailing lists, so that all the developers can see and be part of the discussion.

Thanks Bjorn!

This entry was posted by Matthew Revell on Wednesday, September 23rd, 2009 at 10:59 pm and is filed under General. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.