Pythoneering

http://www.jacobian.org/writing/2007/nov/13/book-update/

(Damn, need to wipe that drool off my keyboard…)

Eclipse Europa became available to the world on 29 June, and I’ve spent a few happy hours exploring what it can do.

My standard Eclipse set-up consists of the Eclipse SDK, DTP and the Derby plugin for database-related stuff, WTP for web-related stuff, Subversive for version control and PyDev for Python programming. Installation of Europa has upgraded the main SDK to version 3.3, DTP to version 1.5 and WTP to version 2.0.

So, what do I think of it so far? Overall, it looks more like an evolution than a revolution, with a large number of small additions and changes. None of these are particularly dramatic in their impact, but the cumulative effect is rather pleasing. Features I particularly like include

• Streamlined workspace switching
• The new minimize/maximize behaviour, which allows more flexible use of screen real estate
• The ability to toggle display of invisible whitespace (handy for Python code)
• Grouping of referenced JAR files under a single node in Package Explorer - much tidier!
• The ability to hide the Console view and have it reappear whenever the program writes to the standard output or standard error streams

I haven’t had much opportunity to examine the changes in WTP yet, but DTP certainly seems to have improved significantly. There is now good support for HSQLDB and PostgreSQL, and query results can be displayed in either tabular or textual formats. One particularly nice new feature is a wizard for creating tables. To be precise, it generates the SQL DDL commands to create a table, and these can then be executed in the normal way, or saved to a file for future use.

I’ve encountered two problems, one minor, the other less so. The minor issue is with the Welcome screen. On my system (Ubuntu ‘Edgy’ Linux, AMD 64), I don’t get the nice graphical version, just this:

Perhaps the Welcome screen is constructed using HTML and CSS, and there’s some problem with the CSS? In any case, there doesn’t seem to be any problem with the 32-bit Linux version, which displays the Welcome screen just fine on my PC at work.

The more serious issue (on my home PC, at least) is stability. Eclipse 3.2.2 was rock-solid for me, but 3.3 has locked up a few times already. I’m going to experiment with increasing memory allocation to see if that solves the problem.

Whilst scanning The Register today, I came across an advert for a book review that began “Calling all Rails developers that want to learn Ruby!” Maybe I’m just old-fashioned, but I would have thought it would be advisable to learn Ruby before trying to use Rails?

After Adrian’s announcement that a Django book was in the pipeline, I just had to place my advance order with Amazon (like many other Djangonauts, I suspect). Since then, news on the book’s progress has been hard to come by. Not any more, though, with the appearance of www.djangobook.com.

This site will allow the Django community to participate in the production of Adrian and Jacob’s book, in much the same way that Bruce Eckel has allowed readers to comment on his material as it is written. Of course, the Django book site is a much more impressive piece of work than Eckel’s system, showing off Adrian and Jacob’s ‘leet web dev skills to the full. It is Django-powered (natch) and distinctively styled, with a neat mechanism for viewing and adding comments and an Atom feed so that we can all keep track of new chapters as they appear. Excellent stuff.

The Django project’s installation of Trac seems to be suffering from an ever-worsening spam problem. I checked the project timeline for 27 October and saw 32 tickets reopened by spammers, compared with 2 legitimate new tickets reporting defects, and 2 changesets. How difficult would it be, I wonder, to prevent this with a captcha-based system of some sort?

Googling suggests that there’s been some discussion of captchas within the Trac project, but that incorporation of such a system into Trac won’t be possible until the 0.11 release. The 0.10 release, however, allows the use of the SpamFilter plugin, which supports regex filtering, IP blacklisting and Akismet. Is Django’s Trac site using this to the full extent possible (or using it at all)?

I suppose the other solution would be to restrict the Trac site to registered users only. Personally, I wouldn’t have a problem with that.

This is exceptionally cool, and a real testament to Python’s flexibility.

It’s that time of the year again, when our final-year students begin their project work. In the run-up to project selection, it was tremendously encouraging to see how many of them were keen on using Python in general, and the Django framework in particular. And it now looks like two or maybe three of my four students will be making significant use of Django. Java doesn’t go unrepresented either, with one student planning on doing interesting things with Eclipse and version control.

Anyway, I hope all of my guys get stuck in and do some good work. Projects that go well can be as rewarding for the supervisor as they are for the student!

Having only recently decided to get a personal Django-based project off the ground, I now find myself with an opportunity to use Django for a project at work. I think that RunLog is going to have to take a backseat while I concentrate on something a little more serious.

For a long while now, I’ve been merely tinkering with Django. I’ve tracked its development closely and with great interest - even contributed some unit tests for template tags - but my use of the framework has been limited to experimentation.

I’ve finally decided to bite the bullet and do something more concrete and useful. I do a lot of running in my spare time and I’m fairly serious about it. By “serious”, I mean that I’m a member of a running club and compete in races every now and then. Runners like myself frequently log the details of their training and racing: where they ran, how far they went, how long it took, the effort involved, etc. I first started doing this on paper years ago, then moved to an Excel spreadsheet with an elaborate set of macros to compute mileage per week or month and sundry other statistics. Of course, it is far more sensible to do this in a database, with a front-end to provide the necessary business logic and user interface.

Hence, we have RunLog: a Django application for logging and analysing training runs and races. A first prototype is nearly finished and, if everything works as expected, I’ll stick it online for others to try. Drop me a line if you are a runner and would be interested in evaluating or contributing to this project.

I’ve recently been thinking about why I like Django, and why I’ve ended up spending time with it rather than with something else like TurboGears. It may be largely accidental, in that I came across Django before I’d heard of TurboGears. In fact, my prior experiences with CherryPy lead me to suspect that I’d have been pretty happy with TurboGears, had I discovered it sooner. But Django snared me first.

So why do I stick with Django for my experimentation with web frameworks? Here, in no particular order, is a list of the things it has that I particularly like:

• A well-designed, easily-navigable, unfussy website, providing access to some excellent tutorials and other documentation
• A simple, compact template language that forces business logic into the view code, where it belongs
• A rich set of generic views that allow useful functionality to be delivered with a minimum of code
• An attractive and highly capable administrative interface to the underlying database, generated for free from the data models

All pretty compelling, as far as I’m concerned. I wouldn’t rule out switching to another framework, but it would have to provide all of the above, and improve on some of it, to tempt me away from Django.