Tag Archives: development

>The importance of developers working with clients

>

Douglas Crockford says in Peter Seibel‘s excellent Coders At Work:

The place where I found that to be most effective was taking testing, sort of, to the ultimate: going to visit customers. I did some of that early in my career and that was a great experience, having to go live with a customer for a week, helping them to install a new system, and helping them to work out the problems with using it.

It gave me a huge amount of insight into what it’s like to actually use our stuff and what I want to be doing for the benefit of the people who are going to be using my stuff. Going back afterwards, developers who had not had that experience all seemed arrogant to me in a way which was completely inexcusable. The lack of respect they had for the people who used our stuff was appalling and it was basically a consequence of their having never met those people.

In my experience this has been very true. Working directly with customers ON SITE can be very painful initially (and management tend to be very wary of letting developers loose on client sites). But handled correctly it benefits everybody. From a personal point of view I love developing on site. It stops distractions, it speeds up feedback and it puts your mind into a different mode.

Oh, go and order the book now if you haven’t got it already. As a developer (on a good day) I really love the way that different people (brilliant people) have different views on good development. And if you’re not a developer, borrow a copy and leaf through. You’ll learn a little about how they tick.

>Django – Named URLS Gotcha

>A post in two parts.

First of all – thanks to Magus on #django for pointing out one of my errors to me. I’ve been working through Practical Django Projects over the last couple of days and it talks about having named urls. Take a look at these three one liners:


# from urls.links.py

(r'^$', 'archive_index',link_info_dict, 'coltrane_link_archive_index'),

# from urls.py

(r'^weblog/links/', include('coltrane.urls.links')),

# In my template I get the url using

{% url coltrane_link_archive_index %}

We give our view a name (coltrane_link_archive_index), then we call that view with urls.py so it’s context will be /weblog/links – and then in our template we can just use the url tag to call that named url. If the url gets moved, your templates will still work – and of course it saves a lot of tedious typing. Great.

So working through the book, the blog application requires a lot of templates and views and stuff. So I thought I’d just do the main one and get the minor ones working later. But I did check to make sure that links to those views were working and they were not.

Written like this, the problem is obvious, a named view won’t work if the view it’s pointing to doesn’t work. So if your url tag’s don’t function – make sure what they should be taking you to are ok.

But there’s more. Because when I wrote the underlying views it still wasn’t working. And I discovered something interesting. I had a problem last night after restarting the web server – The first time I’d go to a page I’d get


ImproperlyConfigured: Error while importing URLconf 'coltrane.urls.tags': name 'Link' is not defined

For some reason I couldn’t work out why that was happening last night. I have no idea why I could not – it’s blatantly obvious. I wasn’t doing an import of the Link model for my tags url file. But I was ignoring it yesterday because I found that if you just asked for the page again it then displays (not the tags page, I hadn’t written that, but the rest of the site seemed to be working. I put it down to some strange ‘glitch’. It wasn’t.

I’m guessing here somewhat but I think what happens is the first time you load your site up, Django precompiles the regular expressions used for your urls. During that compile if it hits an error you’ll have some urls working (up to where it failed) and some not. The second time you hit the site that doesn’t happen (it thinks the regular expression compilation has completed) and doesn’t raise the error again. But of course all the urls that failed won’t be working (hence why url tag wasn’t working).

On a final note, you’d think by now that I would have learnt that when you have a ‘strange glitch’ there’s something bigger lurking there that you really need to understand.

>Unit Testing

>With apologies to The Monkeys

I thought unit tests were just for fairy tales
Never had the time to do things right
Going live was frantic
Development a drag
Changing all my code got real bad

Then I wrote my tests, now I’m a believer
Without a trace of doubt in my mind
I’m in love – mmmmmmm
I’m a believer, best thing I’ve ever tried

Ahem. Or something. I’ve just made substantial changes to two of our production systems over the last couple of weeks, but thanks to Andy and some stuff we did months ago in a pub, I have tests. They rock. Not saying they’ve nailed everything but certainly they’ve made a big difference.

The first system I changed it was remarkably painless and I felt remarkably confident. The second system was a bit more rushed but the go live had no major issues. The one issue that did crop up I changed on my test system here, ran the unit tests, watched them fail, fixed the code again, ran the tests again, watched them past, svn updated the live system and all was fine. Never felt in much panic and making the fixes was a much more pleasurable experience.

The only problem is – I can now see all the areas I don’t have tests for …