EuroPython 2010 – Talks of Interest

The provisional timetable of talks for EuroPython 2010 is now available. I must admit, the tutorials look pretty good too, but I’m going to have to give them a miss.

So, what am I thining of attending?

Monday 19th July

• New and Improved – Michael Foord
• Development Process of Python – Ezio Melotti
• Python and Selenium Testing – Raymond Hettinger
• Django and the Semantic Web – Zachary Vose
• A Case for Accessibility – Stuart Bowness
• Open Data and Coding – David Read
• KBUS: A Simple Messaging System – Tony Ibbs

Tuesday 20th July

• Appstats – Guido van Rossum
• Arduino and Python – Michael Sparks
• Realtime Web with Eventlet – Ben Ford
• Intro to Functional Programming – Michele Simionato
• Robust Python Programs – Stefan Schwarzer
• Fun with Databases and Django – Andrew Godwin

…and a clash between…

• Deferred Gratification – Terry Jones
• Pythonic Parallelism with CSP – Russel Winder

Wednesday 21st July

• Taming Twisted with Generators – Raymind Hettinger
• Mobi: A Mobile User Agent Lib – Kit Blake
• Web Collaboration and Python – Paul Boddie
• Custom Runtimes with PyPy – Henrik Vendelbo
• Python for JavaScript Apps – Thomas Herchenroeder
• A Python’s DNA – Erik Groeneveld
• Lighting Strikes Thrice – Harald Armin Massa

Thursday 22nd July

• Building a Python Web App – Stuart Bowness
• NoSQL, what’s the deal? – Mark Ramm
• NoSQL for Dummies – Tobias Ivarsson
• Scaling Python at GeekNet – Mark Ramm
• Realtime Websites with Python – Henrik Vendelbo

Mac Mini G4: The Arch Way

I bought a second hand Mac Mini G4 off a colleague last year, which I was using as a Fedora workstation. Because I’ve been playing with Arch Linux on VirtualBox recently, I decided to take the plunge and replace the Fedora installation with Arch Linux PPC. The aim was to convert this “lowly” 1.2 GHz, 512 MB, 40 GB hard disk box into a home server. Apache, Python, Django, PostgreSQL, MoinMoin, Mercurial etc. you get the idea. Being a rolling release distribution, Arch might seem like an odd choice but it’s a home environment not a production one so the only person affected by software incompatibilities will be me. Likewise, PowerPC isn’t a primary platform for Arch, but then again it isn’t for Fedora anymore. Madness? Well maybe, but it seemed like an interesting way to spend a Saturday.

Despite being a distro for more advanced Linux users, Arch is surprisingly easy to install and set up. The project provides excellent documentation: clear, concise and cross-referenced. The installer is as easy to use as any I’ve found on more newbie-friendly distributions. However, you do need to feel reasonably comfortable with the shell, editing config files and partitioning disks. Then again, it’s unlikely you’ll be trying Arch Linux over something like Fedora or Ubuntu if you don’t.

Being a secondary platform for Arch, and noting that the PPC supplementary notes had been revised recently, I was expecting to have a few problems with the installation. In the end, the only real problem I had was getting Arch’s package manager, pacman, to find a repository server. A quick search on Google yielded the problem straight away, and one that was really obvious in hindsight: an empty Server= declaration at the end of the default config file. A quick commenting out and the problem was fixed.

Networking was picked up without a hitch, I actually did the installation downloading the latest packages via FTP so was definitely pleased about not having to fiddle with drivers and other headaches. The Apple keyboard and Logitech mouse worked just fine. X.org was a breeze to set up – much nicer than it was when I had to mess about with huge XFree86 configs files ten years ago! I have wmii set up as my window manager, although have had a bit of trouble getting it to play nicely with a login manager like XDM or GDM. It’s a permissions problem that I need to investigate, but not a major issue as the machine will be a server so firing up X by default is pointless.

Although there’s a good selection of binary packages for PowerPC, you will likely end up needing to install the Arch Build System (ABS) to build missing packages from scratch. ABS is a joy to use and a classic example of Arch’s elegant, minimalist approach to system maintenance. I started off using it to get mod_wsgi installed and expected it to be a rather awkward experience, so was both surprised and pleased when it proved to be simple and painless. A minor tweak to the PKGBUILD config file to add ppc architecture and voila! The built package can then be installed via pacman and you’re ready to go.

I’m only a day into the experiment, but so far it’s working very well. Arch Linux doesn’t install lots of packages by default, nor does it have dozens of services all installed and running on a base installation. I feel more aware of every component in the system, and I have a lot of control over what specific things I want installed. For the sake of a little bit of extra effort initially, I have a system configured exactly the way I want it and have built a lean, understandable server configuration. That can only be a good thing.

If you’re worried about using Arch on a server environment, due to its rolling release nature, there is a project underway to provide a suitable server distribution with more emphasis on long term support and stability on x86 without sacrificing the Arch way.

Anyway, full marks to the Arch Linux team, and especially the guys who have helped restart the PowerPC support for Arch.

• Arch Linux PPC – http://www.archlinuxppc.org/
• Arch Linux – http://www.archlinux.org/
• Arch Server – http://www.archserver.org/

Coverage.py

I finally had a chance to try coverage.py, a Python code coverage tool which is maintained by Ned Batchelder. I’m liking it a lot: it’s minimal fuss to set up and use, yet very useful indeed.

When you’ve installed coverage, it should be on your path. Taking my work-in-progress PyGame code as an example, I ran coverage on the test suite:

$ coverage run run_tests.py

The test suite runs as normal:

$ coverage run run_tests.py
.................................................
----------------------------------------------------------------------
Ran 49 tests in 0.006s

OK
$

Coverage writes the results to a .coverage file. To view this as a plain text report:

$ coverage report
Name                      Stmts   Exec  Cover
---------------------------------------------
constants                     6      6   100%
domain/__init__               1      1   100%
domain/deployment            27     23    85%
domain/game_date             48     48   100%
domain/unit                  18     14    77%
infrastructure/__init__       1      1   100%
infrastructure/storage       12     12   100%
run_tests                     4      4   100%
tests/__init__                3      3   100%
tests/test_deployment        94     94   100%
tests/test_game_date         64     64   100%
tests/test_unit              57     57   100%
---------------------------------------------
TOTAL                       335    327    97%
$

But for the best results, you can create an HTML report:

$ coverage html
$

This writes HTML to an htmlcov directory, which can be viewed in a browser. The HTML report provides not only the summary listed in the plain text report, but links to pages for each source file. Each source listing is highlighted to indicate where code coverage is present and where code coverage is missing. Simple, but very, very useful. I’ve used the reports to improve the test suite’s coverage, and even identified code that could be removed. As you can see above, domain/deployment.py and domain/unit.py need better code coverage, which is something I’m aware needs to be addressed next as it will help with some upcoming changes.

One caveat is that coverage can only provide code analysis for code touched by your test suite. There are two areas of the code missing from the above report: the first is the source that binds the game together, since it’s not referenced by the test suite. More importantly, I mentioned I don’t have UI tests yet: since no UI code is called by the test suite, it doesn’t show on the report.

Something else to mention is it only tells you tests have touched sections of code – it’s up to you to ensure your test suite properly exercises that code.

Very cool, and thought I’d share in case you hadn’t seen this tool before.

Coverage can be obtained from http://pypi.python.org/pypi/coverage