Isotoma Limited

Recently I've come to love restructured text. It excels at everything it tries to, without being overcomplicated. Our heavy reliance on subversion for version control, sharing and merging means that we need a non-binary format where possible for documentation; that combined with the many tools to convert it to other formats (including our own to convert from ReST to PDF which I promise we will publish soon) and suddenly my previous reliance on GUI-heavy word processors seems strangely unnecessary and over the top.

Another tool we simply couldn't do without is Trac. Once you get the hang of it it literally adds another project member to your team - it really is that powerful. So far we've only found one drawback, which is that the wiki uses a bespoke markup for formatting.

"What we want," thought Doug and I, "is a way to combine the power of Trac with the power of ReST, so that we can have our live documentation in the repository in sync with the wiki"

Obviously we aren't the only people to have had that thought. Like all the best ideas it combines two very powerful things and makes them all the more powerful. That and it's a piece of cake to use. Doc publishing for the lazy Trac user. Like the man says, "using it is adopting it." It really is that simple.

Posted by Andy Theyers at 09:02 PM | Permalink | Comments (0)

A very well intentioned piece over at InfoWorld by Matt Assay ruminating on the lack of a recommendations engine for Open Source software. I was with him for a while, until his last paragraph:

The record labels - bless 'em! - perform the music selection and promotion process reasonably well. Surely a software analog is ready to be born....

Er... Surely that's Microsoft, Oracle, CA, Apple and the like isn't it?

Despite his rather wayward conclusion the initial point is still valid though. Here at Isotoma we are those Open Source Systems Integrators that he talks about and sometimes it's no easier for us to decide on the right software for a particular project than it is for a first time Open Source user.

The traction that a project has, the political environment that the software or component you are interested in operates within, the commitment of the core developers and a myriad of other factors all need to be taken into consideration alongside the more practical functional and technical requirements. Some way of demystifying those non-functional factors for the casual user would really enable users to maintain a positive experience of OSS (outside the likes of the biggest projects like Apache, MySQL etc.).

And with all that said, even the most stable projects can collapse unexpectedly (although, like freedb, they will likely recover).

Posted by Andy Theyers at 11:37 AM | Permalink | Comments (0)

We’ve finally moved in to the new office. Choosing the hottest week of the year was perhaps not the wisest thing, but Doug and family have safely arrived in York and both of us are now firmly ensconced in Tower House on Fishergate. The new address and contact number can be found over on the main site

Posted by Andy Theyers at 11:22 AM | Permalink | Comments (0)

I seem to be spending a lot of time inside Plone's workflow engine at the moment. This time I'm moving items around the portal depending on their workflow state (using workflow for archiving in this particular instance).

It's a fairly common use case and there are a few recipes out there ([1], [2], so I won't replicate them here.

That said, it's not made wholly clear in the first (from Andy McKay's excellent Definitive Guide to Plone) or at all in the second that when raising the state_change.ObjectMoved exception the first object passed is the object affected by the workflow (after the move), while the second is where you want the user redirected to.

So rather than automatically passing new_obj twice you can always pass a different second object (say the original location's parent folder). This makes a lot more sense in my case, for example, where my users are likely to be archiving a number of items simultaneously.

Posted by Andy Theyers at 11:43 AM | Permalink | Comments (0)

There has been some venting on this subject in the past, but here’s a good post by Arnen Rotem-Gal-Oz on the subject, with a summary of the differences.

Posted by Doug Winter at 12:56 PM | Permalink | Comments (0)

Quick recommendation for Firebug. Superb!

Posted by Doug Winter at 02:27 PM | Permalink | Comments (0)

DateIndexes do not behave quite as you expect. They are only calculated to the nearest minute and they display incorrectly in the ZMI, both of which can throw you off the scent. This makes 10:58:58 on the 8th January 2004 a very special time…

For one of our current projects we have a requirement for a portlet very similar to the ‘recent changes’ portlet, but with some AJAXy filtering and sorting. To ensure that I was getting the behaviour I wanted while I was still mucking around I had written a script that auto generated some content to appear in that portlet; my intention being to use that to make sure that my sorting and filtering were behaving as expected.

Unfortunately sorting on the last modified date didn’t work. It just didn’t. I had copied the code to get the content from the recent changes portlet lock, stock and barrel, including the sortorder and sorton parameters, so I was at a loss as to what was going on.

My confusion only grew when I started to browse the modified index. The dates displayed did not reflect the dates that the objects had actually been modified. In fact everything was resolutely stuck in late January 2004.

I started looking at all of our other portals. The values in their modified indexes were the same. All their dates were somewhere in late January 2004 too.

Investigation of the DateIndex in ./Products/PluginIndexes/DateIndex of my Zope installation showed the following reason for both behaviours.

The DateIndex uses an internal representation of dates, rather than a DateTime object. This format is used because a) DateTime objects are large both on disk and in memory and b) they provide too much granularity for most date based searches. Therefore instead of using DateTime objects an integer value representing an approximation of minutes since year zero is used. (Remember that these values only need to be in order and unique. They do not need to accurately represent the date, so this value is perfectly suitable.)

That explains the lack of sorting. Because my content was all created in the same minute (by my script) it had no sort order, as the index is not that granular.

The screwy dates when browsing the index are similarly explained. The dtml that generates the index browser (./Products/PluginIndexes/dtml/browseIndex.dtml) creates a Zope DateTime instance from the DateIndex value (so that nice string representations of the date can be printed to screen), but the DateTime constructor assumes that any integer passed is a UNIX time stamp (seconds since the epoch) rather than a DateIndex internal representation (minutes since year zero).

So don’t panic when your DateIndexes all look screwed, it is only presentation.

(In case you were wondering, 10:58:58 on 8th January 2004 is the time when seconds since the epoch and DateIndex’s minutes since year zero are equal)

Posted by Andy Theyers at 11:42 AM | Permalink | Comments (0)

One of the perennial points of discussion about coding is about which tools to use. I have been an inveterate user of one or another vi clone for almost twenty years, from elvis on RISC OS to vim on Ubuntu. Vim does fulfil many of the roles of an IDE, especially when running on *nix, where you get so many IDE features for free (ctags, make etc).

However, I have finally been seduced by an IDE, Wing. The Zope debugging was the killer feature for me, but the rest of it is excellent. And it even has vi keybindings!

For UML, I use the excellent MagicDraw. A few years ago I tried UML editors exhaustively and I’m certain this is the best of the lot. In particular it supports Robustness Diagrams, something missing from a lot of editors.

This week I was introduced to OxygenXML, and I’m very impressed. One project I am working on uses XSLT and XPath heavily, and Oxygen’s XSLT debugging is truly awesome. I’m using it now for editing KID templates too, and it works really well.

Of course, these are a tad more resource intensive than good old vim. Running MagicDraw, Wing and OxygenXML together would need a shade under 4GB to avoid swapping entirely. None of my machines can take more than 2GB, so there is a little bit of swapping sometimes ;)

Posted by Doug Winter at 11:20 AM | Permalink | Comments (0)