Of course, if you see one of those cars, chances are you may appear in the photographs they take. My wife remembered a particular location where we saw one last summer, and we've tracked ourselves down, strolling back home from a trip to Broadway Market in Hackney:

View Larger Map

Which actually feels a bit strange. We've been Google-papped. Lucky it was my wife I was out with that day ;)

This is worth knowing if you're testing things that rely on the tests being run in order, such as creating, editing and deleting of records in the database.

For instance:

import unittest
from myapp.models import MyModel

class MyModelTestCase(unittest.TestCase):
def test_create_item(self):
obj = MyModel.objects.create(title="hello")
.... run tests ....

def test_edit_item(self):
obj = MyModel.objects.get(id=1)
obj.title = "goodbye"
obj.save()
.... run tests ....

def test_delete_item(self):
obj = MyModel.objects.get(id=1)
obj.delete()
.... run tests ....


In the above example, when the tests are sorted alphabetically, "test_create_item" is run first, but "test_delete_item" will be run before "test_edit_item", leading to a few unexpected test failures for no apparent reason.

It looks like this is all to do with the "sortTestMethodsUsing" attribute of the TestLoader class, and I daresay there is a way of overriding it in Django, but for now, I'm just happy knowing how my tests are being sorted so I can name them sensibly.

The issue is all about widows - single words that appear on their own when text wraps onto multiple lines. Design-wise, these are bad. So I've been using the rather nifty typogrify extension to Django that makes it very simple to replace the final space in a block of dynamic text with a " " so you don't need to worry about the final word wrapping onto its own line.

Fantastic, very straightforward, on to next thing. But, I simply cannot decide whether I should be doing this for headlines. The homepage of my app has 3 columns of imported feed content, with the most recent headline in quite large type. Depending on the headline content, the widow filter sometimes makes an obvious change to how the headline is rendered. The problem is, the relatively narrow column width means that it can often make the penultimate headline row seem a bit small.

For instance, the following before/after shows a pretty standard headline both with and without widow filtering:

widow

No widow

This one seems pretty cut and dried, the widowless headline looks better and is easier to read. But problems occur with this kind of example:

widow

No widow

To me, its not obvious which one of these headlines is easier to read. If I had a choice, I'd maybe go with the widow version. But this is all dynamic text, so I need to choose whether to run ALL headlines through the widow filter or not.

Currently, I am keeping the widow filter on. But I reserve the right to change my mind about five times a day before this thing is finished.

"We have a dedicated team of seven IT and CAD management personnel across our three offices and in terms of our most significant recent developments we have just launched a new company intranet, which was a major project that we were able to deliver on time and to budget."

"In terms of the motivation behind this initiative, when I joined in August 2007 the company's intranet was looking a bit tired and was being underused but since the overhaul our members of staff have been able to keep track of all of the latest developments and the communication streams within the group are now very much improved."

"One of the other key drivers behind the project was to incorporate a search engine that could help us to tap into the wealth of technical information that we have on the site and the feedback we have had since going live with this has been fantastic."

- Construction Industry News, February 2009, p73

How cool does the Yamaha Tenorion look? Ms. Boots is quite a dab-hand at it too, if her YouTube channel is anything to go by.

I vaguely remember a Shockwave app back in about '99 that used a similar interface to build up beats, but a full hardware sequencer with this interface is clearly a winner. Very happy with the Little Boots EP too.

BTW - Is it a bit weird to name yourself after an insane Roman emperor?

It took a few months, but I finally got freshly-minted versions to complete the jigsaw. I really quite like the new "tails" designs.

I particulary like Drew McLellan's list of things to help smooth the hand-over between design and development:

• Is the layout fixed, or fluid?


• Does each element cope with expanding for larger text and more content?


• Are all the graphics large enough to cope with an area expanding?


• Does each interactive element have a state for with and without JavaScript?


• Does each element have a state for logged in and logged out users?


• How are any custom fonts being displayed? (and does the developer have the font to use?)


• Does each interactive element have error and success messages designed?


• Do all form fields have a label and each form a submit button?


• Is your Photoshop comp document well organised?


• Have you provided flat PDFs of each state?


• Have you provided a colour reference?


• Are we having fun yet?

All good things to think about.

I like the idea of Thanksgiving - a family holiday with no stress over gifts, no dogma and no jingly music.

• Blank company letterhead - and you then write down a list of what you have ordered on it for them. This was required for a limited company (and its omission was why I had to go back)


• Proof of trading with address - I used a company bank statement


• Company debit/credit card


• Driving licence


• PAC code from previous network (if porting an existing number across)

"When you blow something up by a factor of one hundred, it gets weaker by a factor of one hundred. If you try to build a cathedral that way, it just collapses into a pile of rubble." - Alan Kay

Having spent time as both a "Software Engineer" and a Structural Engineer, I am always interested when key industry figures start comparing the two disciplines. Alan Kay's insight into one of the fundamental problems with software reminded me of the arguments over the use of the word "Engineering" for software.

"'Software Engineering' is something of an oxymoron. It's very difficult to have real engineering before you have physics, and there isn't anything even close to a physics for software" - L. Peter Deutsch

The more I think about it, the more I can see what these guys are saying. Within the idiom, software isn't subject to the physical laws that govern structures.

For instance, about a decade ago, I was tasked with building the structural analysis model of the London Eye. As you can imagine, this included a very thorough consideration of the different combinations of force and load acting on the structure in order to calculate how much material was required for it to stand up. We considered over 200 different loadcases for self-weight, wind, people, motion, etc. but in all of them the major force was due to the self-weight of the structure. On average, about 90% of the material in that big wheel is only there to hold itself up.

This introduces some interesting approaches to the engineering solution. In these circumstances, if you have a large force to resist, you cannot just throw more material at it because you are just worsening the problem. Eventually the whole thing will fall down. One wonders what kind of software we would produce if, like London Eye steelwork, 90% of the code written did nothing apart from retain the structural integrity of the software. Without the constraints of gravity, won't we just keep on building and building?

I guess we apply some constraints to ourselves by using application frameworks such as Rails or Django, but the only real physical constraint on sheer volume of code I can see is factors such as disk space, processor speed, RAM, etc. And how many of us push our servers to that extent? Hmmmm.