code_swarm - Python from Michael Ogawa on Vimeo.

I so want to run this over my current project.

I was well aware that Adrian Holovaty is a very big name in the Python world. He's one of the two original developers of Django (my personal favorite web-app development framework) about which he's written the book. He's since used it to power some very cool mashups; chicagocrime.org and everyblock.com, amongst others.

What I didn't know is that he's also well known and regarded by forward-looking journalists. Emily Bell's introduction to his talk at the Guardian set me straight.

Adrian's talk was inspiring, both to the few techies in attendance and to most of the journalists, who made up the bulk of the audience. His central idea is that we should ensure that the information that the journalists have collected is stored in a structured way wherever possible. It's hard, skilled work gathering that valuable information, but full use is not being made of it. If it were stored in a structured fashion (rather than just in the text of a story; in a "blob" as Adrian put it) it could be made use of in many different ways.

A great example of this is Faces of the Fallen. The information here is gathered by the journalists, but it can be explored in many different ways; by age, birthplace, all sorts of things.

Another interesting strand to Adrian's talk was the automated collection of data. The Washington Post runs a congressional voting record site, almost all the data for which is collected automatically. everyblock.com is another example of this kind of thing.

Explorability is crucial. Think how often you get stuck in the Wikipedia, 'cos there are just so many interesting links to follow. You go in to read one article, and find yourself with half a dozen tabs open all containing apparently unrelated corners of the 'pedia that you've stumbled upon, all of which you want to read. Don't you want your site to be like that?

Jemima Kiss has written up Adrian's talk better than I ever could here: Future of Journalism: Adrian Holovaty's vision for data-friendly journalists. Well, she is a pro.

Then, after work, Adrian, Julia and I headed off to Le QuecumBar for some disappointingly inauthentic Gypsy Jazz.

Last week was mayhem. I don't think I've ever been so busy, and I've not really caught up on my sleep even now. I was far to busy to blog about it at the time, and now my boss Julia has beaten me to it: Better late than never.

Her own blog at the Guardian; I'm so envious. ;-)

A couple of interesting things came up. The third party supplier of our comments system uses a non-relational data store, so I now have first hand experience of the problems that can be encountered. I'm not impressed. To my original list of capability gaps that going non-relational gives you I'd now add one more point; ad-hoc data fixing. We were able to update our side of the data as and when needed, which proved vital.

For example, one new but crucial date field had been missed out of the migration process, and so hadn't been populated properly. We were able to populate it with a new value calculated from a couple of other date fields in a matter of minutes, on tens of thousands of articles. I love the smell of SQL in the morning.

On the other hand, where a date value had been populated incorrectly on the non-relation data store, we had no choice but to do a complete new import, which took 24 hours. Sigh. Hence the delay.

Another problem we discovered on the night was a bug that was causing IE to die. Really die. It turned out that the bug had already been fixed, but that the fix hadn't been back-ported to the release that we were launching on. We needed a very last minute merge and deploy, so I got to demonstrate the speed and usability advantage of the Subversion command line interface in the hands of someone who has the hang of it. Marvelous.

Subversion 1.5 looks awesome. Svnmerge is now built-in, and refactoring won't cause quite so many conflicts now file moving works properly. I can't wait.

But I'll have to. It's not just a matter of waiting for the Subversion 1.5 release itself, I'll also have to wait for Subclipse, Textmate's Subversion bundle and plug-in, the team's Windows victims will have to wait for a new Tortoise, the list goes on.

The good news; the new Guardian Sport and Football sites were launched successfully, and seem to be working fine. The bad news; 24 hour licensing notwithstanding, we couldn't find anywhere to serve us a beer at two in the morning. Grrr.

Update: More on the new sites here; Our new look.

One of the most interesting things about the GAE to me is the non-relational data store. I've blogged only recently about my doubts about that approach.

A friend of mine from the big G go back to me about this. "To answer your question about what's wrong with a real database, the datastore is all about scalability. The API trades off flexibility with access paths and transaction boundaries for the ability to store terrifyingly huge volumes of data, while serving a bazillion concurrent accesses.

Compared to an RDBMS, I find this style of data storage requires a bit more thought and design up front. However, almost every RDBMS based app I've ever written has required me to go back and optimise my schema and queries any way, so overall, schema-related work is about the same. Not having SQL does make running arbitrary reports and so forth more difficult."

Hmmmm. Now, coming from Google, this bears thinking about. Scalability as an issue I can see. We do have to put in a lot of work to keep guardian.co.uk performant, and it's almost all at the database, fiddling with schema and queries level. Much to think about...

Other people's thoughts on this; Google Datastore and the shift from a RDBMS and Google AppEngine, BigTable and why RDBMS mentality is harmful.

More on the GAE:

• Google App Engine for developers
• Analysis: Google App Engine alluring, will be hard to escape
• Google App Engine: The good, the bad, and the ugly?

I've had some pushback from Felix over my relational databases aren't dead yet post. He points to db4o.

Now, I've not used db4o, but I've tried out ZODB, and very good it is too. especially with a dynamic language it's really nice to be able to tag arbitrary attributes onto your objects, and to be able to persist and retrieve them complete.

But still, I've be wary of using one for a real project. Performance aside, there are things that you just can't do as easily with an ODBMS as with an RDBMS. I'm thinking of things like:

• Report writing
• Data loading
• Data exploration (especially during debugging)

Also, I find it hard to imagine that an ODBMS can be optimized to the same extent as something as notionally simple as a relational database can be.

All this is leaving aside things that don't yet exist AFAIK but which are probably just a small matter of programming - management tools, clustering, that kind of thing.

No, I'll be sticking with the RDBMS for the foreseeable.

Who will write tomorrow's code? Perhaps no one will need to, thanks to Proj-o-matic!

Seriously, there's a good point here. When I was a kid I had a ZX81. You couldn't play any worthwhile games on it, so the only real fun you could have with it was to program it, if you were so inclined. (Lord, did I dream of getting a QL. I mean, 128K and 2 built-in microdrives? Wow! Never could afford one, though.)

Programming requires a certain way of looking at a problem, a certain approach to breaking it down into automatable chunks. I firmly believe that this way of thinking can only be developed by exercising it, and that it's most easily learned as a child, while your thought processes are still developing. I hold this belief with no evidence whatsoever. Hey, it's my blog! So sue me. ;-)

These days, more kids have a console than a general purpose computer. Most of those that do have a general purpose computer are running Windows on it, so they don't get built-in development tools. Of course, you can simply download something for a general purpose computer, and even for a console there might be solutions for anyone who's really keen. But either way it's much easier just to fire up Call of Duty and blast stuff. So, what's going to happen?

"The notion of "best practices" is widely misunderstood in IT. It is not organizational best practices that most improve the output, it's best engineering practices. And those are accepted first by the "rockstar" types and least understood, why, most often resisted, by the management and subsistence engineers. Where do you think that 10-20x gap comes from, lightning-fast typing skill?"

Via Titus.

The Death of the Relational Database (via Media Influencer).

Sigh. I've been hearing about the death of the RDBMS for nearly twenty years. And the recurring problem with this thesis is not that the RDBMS is perfect, but that everything else is worse. Until someone comes up with an idea for a persistance mechanism that's better then an RDBMS across large parts of the problem space that the RDBMS solves, this is just idle hand-waving.

It's been a busy weekend, but it's mostly done now. We did UK, World, The Guardian, The Observer and Audio this time, along with a few bits and pieces. The biggies.

Next up for re-launch, Sport. And given the storm-in-a-teacup over the removal of the football link from the front page, and you imagine what it'll be like when the entire sport site changes?

Thanks to Jay for pointing out this rant, via reddit.

Now, I'm sorry they guy can't get a job, but if this is his attitude, I can't say I'm surprised. He's burned his bridges with ThoughtWorks, for a start. ;-)

Disclaimer - I work for ThoughtWorks. But I can say that with perfect honestly that his impression of TW doesn't mesh with mine. Thing is, he seems to think that what TW sells is platform expertise. It's not. We primarily sell smart people. (Oh, and me, too.) A smart person will pick up a new platform quickly. If that's not possible with Rails, that that's Rail's problem - not that I believe that to be the case. Yes, you do need a cadre of people with platform experience for a project to succeed, but not the whole team. (Perhaps he'd have better luck job hunting if he didn't restrict himself exclusively to Rails?)

He says that TW leaves bad code bases behind. Again, in my limited experience, that's not true at all. TWers seem to care deeply about what they do. Anyone else out there who doesn't work for TW who has any experiences they'd care to hare?

Also, his dismissal of TDD and agile practices such as pair programming suggests to me that he's not really tried them. We at TW have a lot of experience in these areas, and it all works just fine for us. If he claims to have improved productivity by dropping them, then he's clearly not comparing like-for-like. Done properly, I fervently believe that these practices improve productivity in the long term (if not in the short term).

I do wish we used more Django and less Rails, though. ;-)

What if powerful languages and idioms only work for small teams? (via Small teams and big jobs) is interesting. We are running a really large Agile project here at GU; what, 60 odd people? Mention any of the road bumps you hit, and people tell you your team's too large.

That's no good. The team, and the project, are the size they need to be. Splitting them arbitrarily might be possible, but it would carry huge costs of its own. The challenge is to make agile work with a big team. And on the whole, I think we are.

Interestingly, despite the fact that we've made agile methodologies scale up, some people here are still nervous about whether agile languages can do the same. Plus ca change...

The story is this. We have to make a change to one of our data migration scripts. It's already doing some really nasty string manipulation, and we are about to make it far far worse. Frankly, I don't have a hope of making the change unless we can simplify things a bit first, so I was hoping to break some of our string manipulation out into functions.

In order to do that, we wanted to develop these functions out of the context of the migration script, so we could play with, uh, I mean test them. ;-)

Problem is, the finest minds in Herbal Hill haven't been able to write a function that Oracle is happy with. We have removed all the complex stuff, and are trying to write and run the simplest function that we can think of, but we get no joy. Running the broken_function.sql, we get this:

ORA-06550: line 11, column 13:
PLS-00231: function 'FOO' may not be used in SQL
ORA-06550: line 11, column 13:
PL/SQL: ORA-00904: : invalid identifier
ORA-06550: line 11, column 6:
PL/SQL: SQL Statement ignored
06550. 00000 - "line %s, column %s:\n%s"
*Cause: Usually a PL/SQL compilation error.
*Action:

Any clues?

So, Annabel was complaining that she couldn't see a log of just her Subversion revisions along with details of the files that have changed from the command line. Shock horror - something you can do from Tortoise that you can't easily do from the shell!

(If you don't care about seeing a list of the files that have been changed, you can just do svn log | grep -A2 sbrunning | less, but adding the -v option turns the output to gibberish.)

Clearly I wasn't going to to let that stand, so I knocked up a very quick script. Then proceeded to over-engineer the snot out of it. (In my own time I must add.)

You can filter by author or by checkin message, with regexps. You can also reverse the output and see the latest checkin last, which is handy if you are only want to see the most recent checkins and don't want to pipe the output to less.

Get it here: svnlog (syntax highlighed - loving that Django TextMate theme) or svnlog (text). Requires Python 2.5. Works on Mac & Linux, probably on Windows too if you give it a .py suffix.

We are desperately short of both QA and CS people at the moment. I wonder if we could induce them to breed?

Returning None is Evil. I agree. I've always subscribed to the Samurai Principle myself. If you allow nulls to float around you inevitably end up with NPEs. These can be hard to diagnose properly; not only do you not know if null is actually invalid, but if it is, it's often non-trivial to work out where it came from.

Fuzzyman has a new mocking library for Python, which he presents in Mocking, Patching, Stubbing: all that Stuff.

Michael takes issue with Martin Fowler's Mocks Aren't Stubs; specifically where he defines mocks as objects pre-programmed with expectations which form a specification of the calls they are expected to receive. Michael's mocks are not pre-programmed with expectations - his expectations are defined after the test execution.

Now, to me, this is a trivial distinction - the important difference between a stub and a mock is in the existence of expectations. Whether the expectations are defined before or after the text execution is not crucial - it's still a mock.

It does matter in terms or usability, of course. It feels more natural to Michael to define his expectations after the test object is exercised, along with his assertions. For me, I have to say that defining the mock object's behaviors all in one place makes sense, so both the expected method calls and any return values should defined together - and the return values have to be pre-defined. We are using EasyMock here at GU (along with the Hamcrest constraints library) and I like it just fine. But that's more a matter of taste than anything else.

Brunning's 1st Law of Source Control: He who checks in first, merges least.

"Source control ate my files!" is a superb post. Spot on - 9 times out of 10, when someone complains about Subversion (or whatever) screwing things up, it can be traced back to fear of updates or commits, or to someone blatting someone else's changes with a blind merge. This last, especially, can always be traced - there's no hiding the truth when history is an open book.

The other time, it's someone trying to revert a revision from a dirty working copy. I've never yet seen the software get it wrong.

But for the love of God, Darren, start running a continuous integration server already!

Julian and I have been asked to put together some unit and functional test coverage figures. We've not actually been given any time in which to do it, though, so I wouldn't hold your breath.

Looks like some work was put into using Emma to provide these figures, but it's not finished.

Over in the Python world, there's been some discussion over on c.l.py about Ned Batchelder's coverage.py, which looks like a fairly nifty module.

OTOH, I think you have to be a bit careful with metrics such as those provided by these coverage tools. Ned himself points out many of the problems with taking your coverage figures at face value (though Emma's block-level approach fixes some of them).

I'd add one more issue - gaming. People can start to see good coverage figures as an end in and of themselves. If the coverage isn't at, oh, say 80%, the tests must be crap. If they are at 100%, they must be great. It's not just that the figures can be meaningless, they can actually lead people astray.

Now, for an approach to coverage testing that actually makes sure you are testing that your code does the right thing, check out Jester & Pester.

I've never been too intimidated by driving Subversion from the command line, so I've always maintained my branches by hand, keeping note of what had been merged in the check-in messages. But today Graham Tackley recommended I take a look at svnmerge. I must say, I didn't know what I was missing.

It keeps track of merges for you, ensuring that you'll never try to merge the same revision more than once, or miss any out by accident. Makes it easy to block revisions that you don't want to merge, too. Give it a try.

Don't forget - you'll need a decent merge tool, too

I don't think I'll be able to make QCon, London this year - my current employer doesn't really see the point of conferences. Which is a shame, 'cos it could have been designed for us. There are an uncanny number of speakers relevant to us: Jeff Sutherland ('cos we Scrum), Gavin King ('cos we use Hibernate), Rod Johnson ('cos we use Spring), and Alex Russell ('cos we use Dojo), plus movers and shakers like Martin Fowler, Werner Vogels, Kylie, and Dave Thomas. I might be lying about one of those, though.

Never mind - there's always PyCamp!

And who knows - I might win a ticket. ;-)

Right, I'm off to London 2.0, via a spot of CD and book shopping. I'll see a few of you there, no doubt.

For reasons beyond our control we have a week and a half between scrum sprints - the period I have taken to calling the interregnum.

We usually only have a couple of days, which is a bit tight. There are plenty of things to do; a bit of user story definition and estimation, infrastructure maintenance, bug fixing, that kind of thing. But eight days - luxury!

I might get some blogging time in!

If you are going to be doing a lot of merging working with Subversion (or, I'd imagine, CVS), you are going to need good a good merge tool. And believe me, you are going to be doing a lot of merging.

Subversion itself doesn't provide a merge tool - and nor should it. It's a cross-platform command line driven tool, and besides, I suspect that most developers have their own favourite - or need to find one quickly.

If you are working on Windows, you'll probably have Tortoise installed, 'cos it's really good for simple stuff. Tortoise does come with a merge tool, but it's horrid, really nasty. Aside from just how damn ugly the thing is, it's also almost totally incomprehensible. All those colours - what do they mean?

But that's OK. There are alternatives, and they are easy enough to integrate into Tortoise. The first thing I came across was WinMerge. WinMerge is very good for showing diffs, but it doesn't (as yet) do three way merging - so that's out. Another, more powerful alternative is KDiff3. By the time I came across this, I'd already made my happy move to the Mac, so I've not used it myself, but my Windows-victim colleagues report that it works fine.

So the trick is to use the tool with diff in the name for merging, and the tool with merge in the name for diffing. ;-)

Tortoise also provides tools for making and applying patches, but they seem to use fully-qualified path names, so you can't apply patches from one machine to another unless it happens to keep everything in the same place. So, it's best to use Subversion to make your patches with svn patch > whatever.patch to make your patches (or svn st | awk '/^\s?[MAD]/ { print $NF } ' | xargs svn diff > whatever.patch if you've made the same externals mistake that I did), and to use unxutils' patch to apply them.

In the Mac, there's a natural solution - FileMerge, part of the XCode suite. It's very nice to use, if not perfect. (A few more keyboard shortcuts would be nice, for example, Apple, Just 'cos it's GUIfied and beautiful doesn't mean I should be reaching for the mouse all the time.) Integrating it with command line Subversion would be non-trivial but for Bruno De Fraine's lovely Using FileMerge as a diff command for Subversion - he's done all the hard work for you. Thanks for that, Bruno.

Oh, SubClipse also provides a merging tool, but I've never really used it. It's nice to have SubClipse around - the fact that it decorates all your files showing you their status against the repository is nice, and I often use it to add files - quicker than an svd add if you are in the IDE already. But IDE/version control integration is far less crucial than it used to be in the bad old VSS days when you couldn't edit a file without checking it out, so I do most of my Subversion tasks from the command line.

I'd be interested to know what all you *nix types use - especially anything console based.

Have I missed anything cool?

When we set up our Subversion repository, we did it wrong. And by we, I mean me. ;-)

Our application is modular - you can buy one bit, or several, depending on what you want. There's a core module, containing anything that all the other modules can't do without - authentication and authorisation, audit logs, that kind of stuff. Then we have a simple contact management module, a technical accounting module, and so on. (Mostly still to be written.)

Each is a separate web application - a separate WAR file. They communicate via SOAP. (I know, SOAP in this day and age. Still, it was what was required...) And each has its own Java package - uk.co.trisystems.morph.core, uk.co.trisystems.morph.cm, uk.co.trisystems.morph.ta, and so on. But they have a fair amount of code in common, which lives in uk.co.trisystems.morph.common. And that's where we (all right, all right, OK, I) went wrong.

It's not all my fault - I blame VSS. We'd been using it for ages, and in VSS, you do things like this using shared folders. This was our first major project to dump VSS in favour of Subversion, and the closest thing we could find to VSS's shared folders was Subversion's externals. Brain damaged by VSS as I was, that's what we used.

In hindsight, a mistake.

Subversion's externals are really intended not for code shared within your own project, but for genuinely external code - stuff you want to pull in from other projects and so on. Subversion treats externals as 2nd class citizens in a way.

Updating your working copy is not a problem - the usual svn up works fine. But checking your changes back in, that's not so easy. If you've made changes to common code, svn commit leaves them behind. Merging, branching, making patches, just the same - externals are ignored. Fair enough, given what externals are intended for.

It's not so bad for me - bash helps out a lot here. To check all my changes in I do a:

svn st | awk '/^\s?[MAD]/ { print $NF } ' | xargs svn commit -m"Blah blah blah"

(Thanks to Andy for the awk lesson!)

Branching is still a bit of a pain - branching both common and the other apps, and munging the svn:externals property is a fiddle, but I can live with it. But for my Windows-victim colleagues, it's much worse. Padawan Dan has taken to cygwin like a duck to water, but for the rest of the team there's Tortoise.

Tortoise is fine for simple stuff, like updating and looking for conflicts. (Though its conflict resolution doohicky is horrid.) But whenever people try to use it for the slightly more complex jobs such as branching... things just go wrong. And we can never work out what happened. I'm not blaming Tortoise as such - I'm sure that it works fine. But GUIs are just not good for this kind of stuff. You need to be able to work from examples, and with a GUI, it's just too easy to leave some checkbox or other unchecked - and you'll never be able to work out what you did wrong after the fact.

So, what should we have done? Well, I think I know, but this is all a bit suppositional. ;-) What I think we should have done is not to have bothered trying to keep one copy of our common code. Instead, we should have had a copy of the common code in each application, and merged any changes to that common code to the other applications.

Sound right?

Of course, for all this merging, you need good merging tools. But that's another post...

There's a discussion going on at the moment concerning refactoring dynamic languages. For whatever reason, its protagonists don't seem to be aware of Phil Dawes' excellent Bicycle Repair Man.

I'd love to give Bicycle Repair Man a go; it looks fab when Phil demos it. but there's one hurdle to get over first - Emacs. And it's a big one.

I've given Emacs a go a couple of times (most recently Aquamacs), and it seems to make sense to me. It's not totally horrid like that nasty vi thing that just beeps at me all the bloody time. No, it's just that the learning curve is steep, and I have real work to do, work that I can accomplish far more easily at the moment using jEdit.

There are loads of tasks that I can achieve really easily using jEdit that I wouldn't even know where to start looking for in Emacs - line sorting, search and replace across a filtered set of files throughout a directory sub-tree, opening files in archives or FTP repositories, HTMlifying, XML re-indenting. I know Emacs can do all this stuff, but I really don't know where to look for it all, and I need to get stuff done.

There are a couple of other jEdit features that I really like and would miss, too. The File System Browser (which I keep docked and open at all times) is a fabulous tool. I like a mouse driven interface for navigating around the file system, and jEdit's is a very powerful one. Also, the combination of the search bar and the hypersearch panel (which I leave on by default and dock at the bottom respectively) is really powerful too. Are there Emacs analogs of these tools?

Oh yes, and I like buffer tabs too.

And before Andy comes in and starts accusing me of being a weak-minded GUI lover, I'm not. I'm getting on fine with bash on the Mac. I'm starting to use awk and sed to do stuff on the command line that are totally impossible via a GUI. (Oh, and thanks for the help on that, Andy.)

So, should I stick with what I know? After all, it's not like I'm using Notepad here - jEdit's very good. Or should I take the pain and try to switch to Emacs? I'd be able to use Bicycle Repair Man!

All IT systems have roughly equal hassle rates. Should you improve the quality of your software (by means of thorough automated testing and so forth), other components of the system (such as the RDBMS, or the hardware) will take up the slack by failing more frequently.

There goes our crowd for London 2.0.

Update: Just to be clear - London 2.0 isn't off by any means. It's just that I'm concerned that many of our potential attendees will go the the Backstage meetup.

This is getting out of hand. December the 12th now appears to be a combined Python/Django/TurboGears/Ruby/Rails/Java/Spring/Hibernate/the million other things you need to build a Java web app these days/Perl/Catalyst/Maypole/Groovy/Grails Christmas party, and Jez is trying to get the Geek Girls on board too. Though that may be just wishful thinking on his part. ;-)

So, we really need another name. Jez suggested London 2.0, which is just so zeitgeist. Me, I'm more London 0.9, but I'll go with it...

Let's just hope the Perl guys don't have a punch up.

Speaking of the London Web Framework Night - I never did write that up, did I?

OK, so, first up, Catalyst. What can I say? Catalyst may or may not be a great web framework, but since I didn't understand a word of the presentation, I'm not in any position to judge. It seemed mainly to consist of a list of CPAN modules that are either part of Catalyst, or can be plugged into it. No code, no working system, no screenshots, no inkling of what's in it for me. Nothing. Awkward, opaque, and unfriendly to all but insiders - much like I imagine Perl to be. (It must be said, the Perl mongers are aware of the problem - see this post, and this one. Message for Simon Wistow re your "Show Leon's Catalyst based web debugger. I'm willing to bet that it would be largely impossible in either of the other two" comment - I give you Ajaxy Exception Catching.)

Next up came Simon's Django presentation. I may have put The Fear into Simon about presenting to so many people, but perhaps I did him a favour - despite his admitted inexperience as a presenter, it was a cracking show. Compelling, funny, enthusiastic, and giving a very good idea as to what Django does, and how it does it. Using it will be pretty much a no-brainer when it comes to putting together a CMS style site. Whether it's the right platform for database driven sites like the kind of thing that I do for my day job is another matter. There's a clear front end/back end division with Django, with editors using its spectacular "magic" admin interface, and users mainly viewing content - though you do get community features like commenting pretty much for free. Perfect for a lot of sites, but would it suit enterprise database apps like banks and insurance houses need - and I write?

Simon demonstrated both the front and back ends of Django using lawrence.com - one of the sites for which Django was developed in the first place. Though the God of Demos made an apprearance at one point giving Simon an SQL exception, he also had a number of "oooh"s, and outright applause at least twice.

Last up was Matt Biddulph giving us a flavour of Rails. Struggling manfully through a stinking cold, Matt gave us the phiosophy of Rails in a very punchy manner. It looks very much a case of "do it our way", but that's often the right approach. Not enough code on show to tempt me away from a Python platform, though. ;-)

Without a doubt, the highlight here was Matt's demo of BBC Programme Catalogue. I have no words for how cool this project is. None.

I missed out on the booze up afterwards - I was feeling a bit fragile after several heavy sessions on the trot - so I'm sorry if I missed any of you. It was a good night nevertheless - a big thank you to Dean Wilson for organising it all.

Me? I'm looking at TurboGears. ;-) I like the concept of tying together best-of-breed components. Getting it running on my Mac was trivial, and the 20 minute Wiki is a superb demo. As soon as I locate some of that copious free time of mine, I'll try throwing together a simple site or two to see how it hangs together.

Not content with a Python/Django/Ruby/Rails meetup, Sam, Jez and I have teamed up to throw a Python/Django/Ruby/Rails/Java Christmas party this year. (For "party", read "bunch of nerdy blokes, many with beards, standing around drinking beer and chatting about computers".) It's at The Old Bank of England, Fleet Street on the evening of December the 12th.

Do leave a comment if you fancy coming - we have a room booked, and but we can change it to a bigger one if we need to. I anticipate a lot of interest, what with combining the Java crowd with the dynamic language people, and possible extra interest due to last week's London Web Frameworks Night.

Anyone want to demo TurboGears? ;-)

Update: Thanks to Dave and Dave, it's now a Python/Django/TurboGears/Ruby/Rails/Java/Perl/Catalyst/Maypole Christmas party. That has to be every web nerd in London, right?

Son of Update - This Time it's Personal: See London 2.0rc1.

Off to the London Web Frameworks Night soon. It's gonna be good, I think. I met Matt on Tuesday at a meal organised by Sam, and the lovely (if slightly obsessive) Simon was there too. He's a little nervous about presenting to so many people. I don't think he was before I pointed out how scary it'll be, but he certainly is now.

Name dropping or what? ;-)

Anyway, I hope the drinking won't be too intense this evening. Tuesday night involved a lot of Kronenbourg Blanc. This is evil stuff - I had a very nasty hangover yesterday moirning. Not that it lasted - we had a new starter, Amy (just turned 18, bless her), and spent the afternoon in the pub. But I could sure do with a quiet evening.

Yeah, yeah, I know.

Anyway, I hope to see a lot of you there.

We finished our first XP iteration last week.

My major observation - watch your estimates. Because the iterations are relativly short, one bad estimate can really fuck you up. One of our stories was initially estimated at 20 bananas, but when we broke it down into tasks, we had nearly 300! Since the first iteration (Acorn) was bound to carry a bit of overhead in terms of infrastructure, we were only intending to schedule 400 bananas for the whole iteration. Doulbling our estimates almost straight away was always going to be a bit of a problem.

(A banana is a an arbitrary unit of time - not an hour, but hopefully not too far from being an hour, either. Establishing what a banana is actually worth - which will take an iteration or two - should give us our velocity.)

Anyway, with a bit of hard graft, we didn't do too badly in the end. We delivered just about everything that we were intending to, bar one missing major function and a few missing system table maintenance functions. Oh yes, and a few missing unit tests, too - bad Simon.

We demoed it to our directors (our internal clients) yesterday. It seemed to go pretty well - everything worked, and after a shakey first five minutes, I even made use of some of the presentation skills I'm supposed to have been taught. I think the directors were more impressed by what we've done than we are!

(In fact, one of the Big Four missed yesterday, so I'll be going through it all again this afternoon with the help of my glamourous assistant, err, I mean my assistant, Tulna.)

Next week, another planning meeting, and round we go again. I'll be keeping a more alert eye on all the estimates this time. ;-)

BTW, here's an XP practice that I'd like to see us put into effect - Beer O'Clock.

It's going to be a busy month for nerdy stuff.

Firstly, there's Jez's London Java meetup on Thursday. Always a good night.

Then, next Monday, we have the London Python/Django/Ruby/Rails meetup. It's looking like we might get a good turnout for that - including my Technical Director! Gulp - I'd better be on my best behavior.

Then again, naaah.

On the 17th, there's the London Web Frameworks Night. Looks fascinating - demos of many of the happening web app frameworks back to back. Given the noise and drunkeness I don't tend to take much detail in during the Python/Django/Ruby/Rails meetups, so it'll be interesting to see more formal demos. Let's hope I'm quick enough to book a seat...

And lastly, there's the Einstein vs. Newton debate at the Royal Society on the 23rd. A different kind of nerdy, but nerdy nevertheless. Not to be missed.

Update: If you want to go to the London Web Frameworks Night, sign up now.

In Making Wrong Code Look Wrong, Joel explains the difference between Systems Hungarian Notation (which is what most people think of when they think of Hungarian Notation, and which is utterly pointless these days, Mark) and Apps Hungarian (which isn't anything like so crap, and might still have some utility from time to time). In fact, I find that I use something similar to Apps Hungarian, though I use suffixes rather than prefixes, and I don't tend to abbreviate.

He's still wrong about exceptions, though, Raymond Chen or no Raymond Chen.

Joel has written some very insightful articles in his time. And as a writer, he's very talented. But then again, he's not right all the time. He doesn't like exceptions. He's not investing time in his toolset.

There's worse to come. He and his people build their FogBugz product using ASP. Well, it's not what I would have done, but clearly they are an MS shop with a considerable investment in MS tools and skills, and if they are happy to run on Windows servers, then it's an understandable decision.

Err, no. It turns out that they do want to be able to run on Linux. So, they have written an ASP to PHP converter. Madness, I tell you, madness. Even if it works.

Deciding upon the platform that you want your software to run on is pretty fundamental. If you want a cross platform application, write it in a cross platform way in the first place.

Congratulations to the Jolt 2005 award winners (PDF). I've read, used or will use a number of the winners:

• Better, Faster, Lighter Java by Bruce A. Tate and Justin Gehtland, Technical Books Jolt Winner
• Hibernate: A Developer's Notebook by James Elliott, Technical Books Productivity Winner
• Subversion, Change and Configuration Management Tools Jolt Winner
• Eclipse 3.0, Languages and Development Environments Jolt Winner
• Python 2.4, Languages and Development Environments Productivity Winner
• Hibernate 2.1, Libraries, Frameworks and Components Jolt Winner

We had planned the project meal to be on January the 31st. The system blew up spectacularly that day.

We fixed that, and re-scheduled the meal for today. Guess what's happened.

Update: Fixed. It was a nyetwork issue. We're off to Haz...

I won't go into much detail yet over yesterdays thirteen hour epic, but it was a narrowly avoided catastrophe.

Suffice it to say that we needed a copy of Lumigent Log Explorer, sharpish. I gave Solution Data a bell at around five. "Can you give me some idea as to the lead time on a copy of Log Explorer, please?"

"I suppose that you'll be needing it now, won't you? You can download it now, and I can get you a key in, oh, an hour or so." Clearly, they know their market!

"Err, yes."

They were as good as their word. So, a big thank you to Andrew Hulley over at Solution Data.

As for Lumigent Log Explorer, well, it works. ;-) It does what it says on the tin, and the interface was good enough that we were able to do what we needed to do, despite the fact that our first exposure to the tool was when we were using it to fix a critical problem. Not pretty, and a bit complex, but then it's not exactly an end user tool. You don't need Log Explorer, but if you do need it, you need it bad.

One other thing. If your backup strategy depends on something as complex and delicate as SQL Server Replication, then it's not a robust backup strategy. ;-)

I've had to make some changes to a very old project of ours. Very old. I've not worked on it since rebuilding my PC, so I've had to rebuild the project's environment from scratch.

Well, I can certainly see that we've learnt a great deal since then. The first problem is that the structure in VSS has nearly no resemblance to the structure in disk. Setting up all the working folders correctly is a nightmare. (OK, using VSS is the first problem :-)

We didn't know about Ant back then, so everything is built using nightmarishly huge batch files. Batch files aren't too flexible, so we have multiple versions of all of these batch files, which we have to build using template versions and a cool little find-and-replace script that I put together in Python. (God, that's nasty, too. I've learnt a lot of Python as well!)

The whole process is insanely complicated. (And I do mean complicated, not complex.) Thank God Tracey was in charge of documenting it. No one has ever accused Tracey of leaving anything out of a document. ;-)

All this is irritating. But the worst thing, by far the worst thing, is that bloody Mark left fistfuls of PAUSE statements all over the place. If I see "Hit any key to continue..." one more bloody time...

Update: It's finished, finally:

Press any key to continue . . .
-----
****************************************************
* FINISHED EVO Development/EVO_Base GET ALL *
****************************************************
Press any key to continue . . .

Seriously. There's a PAUSE, and ECHO or two, then another PAUSE. Daily WTF?

Or it should be common sense: Don't build web apps that only work in IE.

Don't do it deliberately, and don't do it by accident, either. Test with multiple browsers. I use Firefox (which is also my main day-to-day browser) and IE. I'd test with Safari on a Mac, too, if I could talk my management into buying me one, and with a Linux browser or two if I could talk them into allowing me to run a Debian box on the network.

Oh, and don't write web apps that don't work in IE, either. Like it or not, it's still 90% odd of the market, and will remain the number one for the foreseeable future.

"If you decide to go with the same tools and technology as everyone else, you make sure that you won't fail any worse than they do. However, you also ensure that you won't succeed any better."

A client sent me a request to build him a new report. (Using SQL Server. Don't ask.) Most of the request was specific enough, except for where he told me that he wanted me to include "the relevant financial values".

My level of domain knowledge isn't sufficient to know which financial values might or might not be relevant. (That's IT consultant speak for "I don't have the faintest idea how his business works, and I haven't got a scooby which columns to show him".) So I emailed him for clarification.

He came back to me, explaining that he wants to see the "appropriate financial values".

Ah, OK, thanks. I think a phone call is in order.

Made in USA - why americans make good software, and good movies, but bad places to live, and bad cars. By Paul Graham.

Paul himself points out the most obvious counter example, Apple, an island of beautiful design in a sea of cack.

It's just given me the error message:

Server: Msg 170, Level 15, State 1, Line 3
Line 3: Incorrect syntax near '('.

Line three is, of course, a comment. The full script is over fifteen hundred lines long, and has a lot of parenthisies in it. How am I supposed to work out what's wrong?

One for Mark: Hungarian notation: an outdated concept. See, Mark, there's almost nobody left who still thinks that Hungarian doesn't suck.

Another one for the wishlist.

The bloody clients now want major changes to a report which it took me about a week to develop in the first place using The Tool from Hell; StyleReport Pro. Bastards. The changes are probably major enough that I'll need to start again from scratch.

Cool - Joe Celko’s writing for O'Reilly. Joe Celko is the SQL guru's SQL guru - and if you're not an SQL guru, you need to become one. Hierarchical SQL is a nice introduction to handling tree structures.

Pragmatic Programmers Interview: "To get job security, developers need to position themselves as highly effective business-value generators, working with the rest of the company to solve common goals. If you sit in your cube waiting for a spec to be thrown over the wall, then you may be in for a wait -- that spec might be in an envelope on its way to Bangalore."

Well, not all of them, anyway. ;-)

One of our biggest recent projects was a new Java front end to an old 5250 green screen application of ours. The majority of users were more than happy with the pretty new front end, but some were not. These users were finding that the GUI slowed them down.

Mouse considered harmful: "Have you ever watched an experineced heads down data entry clerk do thier job? With a green screen system they rarely look at the keyboard and in most cases ignore the screen. They are responding to audible feed back (key press clicks, console beeps, etc) with thier eyes focused on the data to be input. They remember key sequences (press 1, A, down arrow 2 times, F2 to save) to navigate. A mental model of the screens become engrained in thier head. They "SEE" the application in thier head and that vision is updated realtime. They know the system because it's predictable."

What's more, if the 5250 user gets ahead of the system, it doesn't matter - the 'dumb' terminal will just buffer their keystrokes, and play them back when the application is ready for them. So, they can enter data as fast as they can hit the keys.

I heard a story, probably apocryphal, about a salesman trying to sell what IBM calls a 'refacing' tool, and what the rest of the industry calls either a screen-scraper or a 'lipstick-on-a-pig' tool. He demonstrated how easy it was to slap a new front end on the 5250 app. The head of the data entry department then snipped off his mouse with a pair of scissors, and asked him to enter some data. "It costs us a penny every time one of our data entry people takes their hand off the keyboard," he explained.

Anyway, I've implemented a keystroke buffer for a Java app once before, and I know it's pretty much top of our to-do list for our pretty new front end. Perhaps then we can wean the last of our 5250 users onto it...

Via James Robertson.

The artful logger.

Logging settings changes? What a good idea! When it comes to logging, less is not more; less is, in fact, less - more is more.

We use log4j to log everything in sight, with a DailyRollingFileAppender to keep from taking up too much space. We do get some pretty hefty log files, though, so we use Tail for Windows to keep an eye on them in real-time, or Python (what else!) to trawl through them if we are looking for something in particular.

Via Joe Grossberg.

Oh, shit: EU votes through software patent changes. This is bad.

Update 21st May: The Computer Weekly coverage is good: European Council approves 'controversial' software patent draft directive.

Via perfect.

A rose by any other name might well be bloody confusing. Naming is important. Sam writes about this in The importance of naming. I thought I'd point out Hacknot's fabulous Naming Classes - Do It Once And Do It Right.

The demise of Hara-Kiri computing: A non-specialist might conclude that all the what-if analysis is aimed at ensuring that the system can detect and then recover from errors gracefully. However, in the vast majority of cases, this is not what is motivating the development team. Instead, the name of the error handling game is to detect errors and then *die* with as much grace as possible. The emphasis is on graceful death, hara-kiri style, rather than graceful error detection followed by correction/resumption. Nicely put.

Via Sean McGrath.

OK, sorry about this. Remarkably tedious (if rather useful) post coming up.

Everything you will ever need to know about UK address and postcode formats (in PDF), via the Universal Postal Union (where you can find similar documents for other countries' address formats), found via forta.com.

Why Do Java Developers Like to Make Things So Hard?

"Imagine if the Perl cafe and Javahut were across the street from each other. You walk into Javahut, and ask to sit down. "I'm sorry," says the person at the door. I'm not actually the hostess, I'm a Factory class that can give you a hostess if you tell me what type of seat you want." You say you want a non-smoking seat, and the person calls over a NonSmokingSeatHostess. The hostess takes you to your seat, and asks if you'll want breakfast, lunch, or dinner. You say lunch, and she beckons a LunchWaitress. The LunchWaitress takes your order, brings over your food, but there's no plates to put it on because you forgot to get a CutleryFactory and invoke getPlates, so the Waitress throws a null pointer exception and you get thrown out of the place."

This is so true it hurts.

Still, could be worse. Working with RPGIV, there are no restaurants. Nor are there any supermarkets; you have to grow your own food. And make your own cutlery.

Via Ian Bicking.

I'm getting a spot of Karmic feedback for taking the piss out of Mark for his burger flipping VB6 programming - I'm starting on a six week RPGIV project at a client site next week!

This is bad: in decreasing order of love, my used-at-work programming languages are:

• Python
• Java
• Synon/2
• PL/I
• OS/400 CL
• VBA
• RPGIV
• RPGIII
• JCL

As you can see, RPGIV isn't high on the list. Sigh.

Still, I'll be working with one or two people I know and like, so it isn't all bad.

The world's two worst variable names is a great read. I especially liked this comment.

I'm glad to see that How To Write Unmaintainable Code is having the real-world impact that it deserves.

The worst name I've seen recently in the projects I've been working on has been Skippy, the originator of which shall remain nameless.

Via The Farm.

Building good unit tests is a lot harder than it sounds. Designing Developer Tests is a very nice introduction to the art.

Got a good quotation in it, too: The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair. - Douglas Adams, Mostly Harmless

Defending YAGNI.

One day, I'd like to be able to present an idea as well as Charles does here. One day.

How To Spot A Fake Programmer.

One more: Doesn't (or can't) use Google as their first stop when they have a problem.

Steve McConnell's Code Complete is one of the best books on software construction ever written, IMNSHO. Every standards manual (or as I prefer to call them, coding style guide) I've participated in since I came across Code Complete has been based upon it.

So it's great to hear that there's going to be a second edition. This new edition covers the construction of OO software, which the first edition did not. The draft is on line - looks good.

Via paradox1x.

I friend of mine recently referred to Joel as "A pompous, opinionated windbag". Which raised a laugh, I must say, but it isn't really fair. Joel's writing varies between the insightful and the frankly flaky, it's true, but I think that the former predominates.

In Biculturalism, he sums up the differences between the Windows and Unix cultures with: "Unix culture values code which is useful to other programmers, while Windows culture values code which is useful to non-programmers".

He was prompted to think about this while reading Eric S. Raymond's excellent The Art of UNIX Programming. ESR can be rather flaky himself at times - he's a gun nut, for one thing, and we really don't see his point on this side of the pond. But on technical issues his judgement is superb. We already knew that he likes Python. In The Art of UNIX Programming, we see him give an overview of Python and Java, amongst other languages. He's pretty fair, I'd say, but his preference is clear.

When trying to explain the difference between dynamic typing and weak typing, I used to refer to this page (specifically the Addendum at the bottom). I still will - it's brief, but gets the point across.

For the long version, though, in future I'll refer to What the heck is: A type.

Steve has a job. Good. Let's hope that this means that Kim is right, and things are picking up.

My programming job went offshore, and all I got was this lousy T-shirt.

Via PragDave.

codeja vu: the feeling that you are coding something that you already coded before.

Via James Strachan.

Steve's just about getting to the end of Head First Java now. (Which, BTW, he recommends.) He's going to work through Thinking In Java next, which I recommend.

But I've also advised him not to stick too closely to book learning. The best thing to do, I find, is dive off onto real coding whenever you have an idea for something to write. Do as much as you can, then and when you get stuck, go back to the books until you have another brain wave.

Robocode is great for this, if you are learning Java. You can write a simple robot very quickly, but the sky's the limit - as you work through the books, you'll get ideas for all sorts of clever things that you can do.

Another good source of ideas are Dave Thomas's Code Kata. Not just good for newbies, these coding exercises are good practise for anyone. I see Andy and Ian have been using them. I may have a go myself!

I'll be in training for a couple of days now. JIS for XHTML version 8.

Sigh. Not very exciting.

Joel's The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) and Dan's What the heck is: A string both cover the what, why and how of Unicode. Me, I work in The City, and i18n just isn't an issue. UK English only.

The effbot, as ever, gives you everything you need to know, with added brevity: Some Observations on Working With Non-ASCII Character Sets.

Developers show their independent streak, favoring Web-based apps

Actually, legacy applications in COBOL and RPG rule the enterprise in my experience. But in terms of new enterprise applications, I can certainly believe that web based applications are very popular. The advantages are huge, provided that you don't need any UI that a browser based app can't give you. (And as this DHTML widget shows, a browser can give you more than you might expect.)

Joel is bragging about his new office.

In my office, I'm the lucky one, 'cos I've got the window desk. It only looks out onto an atrium, with a brick wall and another window ten feet away, but at least it's natural light, and I can open the window for some fresh air. Besides, the sill gives me somewhere to put my books. I don't have much room around me, though - Tulna's desk is four feet behind me, and we both have to fit into that gap!

Still, I can hardly claim to be on the 99.9 percentile, I'll freely admit.

Most developers spend a huge amount of time looking at code. Obviously, the quality of your VDU is very important, but it's also important to use a good font.

Obviously, you're going to use a non-proportional font for coding. As a Windows victim user, you get a couple by default. Courier New is just too hideous to contemplate. Lucida Console is better, but both these fonts have one big defect in common - it's hard to distinguish between zeros and upper case letter 'o's. Me, I prefer Andale Mono. (You can download Andale Mono here.)

Ned Batchelder points out Tristan Grimmer's programming fonts. Proggy Clean especially looks really nice for day to day code and text editing. Proggy Tiny, is, well, a bit too tiny for editing with, but it might make a good console font. I'll give them a try.

Update: I've had a look, and I think I'll be sticking with Andale for the moment, though Proggy Clean is almost as nice - it just takes up that tiny bit more room. Some samples: Andale Mono, Proggy Clean, and (for Hans) FixedSys.

(BTW, this code snippet arose because a colleague was struggling using a text editor to open a 1.2 gig log file in order to find all the lines containing a specific exception. A slight variation on this code pulled out the required lines, and took 13 minutes on an oldish PC. Another Python convert, I hope!)

Another update: V S Babu mentions Bitstream Vera in passing. There's a non-proportional font in there which looks pretty nice. An example - Bitstream Vera Sans Mono. But again, I think I'll stick with Andale.

There's a debate going on right now on python-dev about what kind of changes are acceptable in micro releases. (Micro releases are where you go from x.y.z to x.y.z+1 - for example, from 2.2.1 to 2.2.2.)

At one point, Fred Drake said "We might not be able to remove a core dump since it would allow code to run that was not run before, thereby changing the behavior of the code".

No one would rely on something like a core dump, right? Well, perhaps, but I was reminded of one of my nastiest ever iSeries hacks, which was very nearly as bad. Scarily enough, this was (and is) used in production code.

Steve is looking for sample programmer aptitude tests. Any suggestions?

This one is funny, but Steve is looking for real ones.

Configuring Automatic Log Ons for Windows NT.

You probably shoudn't do this. But it's nice to know how. ;-)

I nearly used this hack. I was automating a process involving an application which only seemed to work properly if you rebooted before using it!

In the end, though, soving a bunch more RAM into the box seems to have done the trick.

The secret life of GetWindowText, via Joel.

I've been fiddling with GetWindowText myself recently. This explains a lot.

Oliver Steele's excellent post, Test versus Type, explores at some length the argument that test driven development makes static typing unnecessary at best, positively injurious at worst.

I leave with you with a quotation from Quinn Dunkan:

"The static people talk about rigorously enforced interfaces, correctness proofs, contracts, etc. The dynamic people talk about rigorously enforced testing and say that types only catch a small portion of possible errors. The static people retort that they don't trust tests to cover everything or not have bugs and why write tests for stuff the compiler should test for you, so you shouldn't rely on only tests, and besides static types don't catch a small portion, but a large portion of errors. The dynamic people say no program or test is perfect and static typing is not worth the cost in language complexity and design difficulty for the gain in eliminating a few tests that would have been easy to write anyway, since static types catch a small portion of errors, not a large portion. The static people say static types don't add that much language complexity, and it's not design "difficulty" but an essential part of the process, and they catch a large portion, not a small portion. The dynamic people say they add enormous complexity, and they catch a small portion, and point out that the static people have bad breath. The static people assert that the dynamic people must be too stupid to cope with a real language and rigorous requirements, and are ugly besides.

This is when both sides start throwing rocks."

Via Ted Leung.

Mark is stuck building a VB6 project at the moment. I took the piss out of him for a while, but by now I'm feeling really sorry for him.

He's currently having problems with 'event cascading', whatever that is.

"Right, I'm going to delete and re-write all the routines which are giving me gyp," he's just said. Well, shouted, mostly.

In Open Source Flying, Matthew Langham contends that the way the air travel industry has changed over the years may be a good model for the way the IT industry is changing.

In the old days, if you wanted to fly, you went to your national carrier and payed whatever they demanded, and that was that. Just as now, 99% of businesses go to one of the big vendors (Microsoft, IBM, Sun, etc.) for their software.

These days, there are a number of low cost carriers fighting over you. The national carriers are still there, offering high price, high standard, high convenience travel, but they no longer own the skies.

Will the big vendors lose out? I can't say I see any sign of it yet, but it would be nice if he were correct. ;-)

Via Daily Python-URL.

NullBlogException posted a list of Meetings and events in London.

I think I'll give one or more of these a bash. The Python booze-ups just ain't happening.

Nice little windows utility - AR RAM Disk.

If you develop software, you probably have steps in your build process where you create a lot of temporary files. (For example, a typical Ant build process will compile a lot of Java into class files, then put them together into a jar file). Creating all these transient files would be quicker on a RAM disk, and would fragment your disk less.

If, that is, you have the RAM for it.

Via John Lipsky.

Corporate Pimps - Dealing with Technical Recruiters

Because recruiters are universally maligned, their clients have no more respect for their opinions than you do.

The recruiter has no technical knowledge. The skills you’ve spent years acquiring are just empty keywords and acronyms to them.

All so true it hurts. The only good thing about the downturn in the technical job market is that the Recruitment Consultants (as they label themselves in the UK) are getting it in the neck even worse than we are.

Anyway, some good tips here.

Via Alan Green.

Bruce Eckel, The Ideal Programmer.

An interesting, if unfocused, semi-rant about the poor quality of the average coder.

Some interesting numbers: 5% of the programmers are 20 times more productive than the other 95%. The majority (probably that other 95%) of programmers don't read books on programming. Now, I'd love to take this at face value - after all, I read a lot of books on programming. But most books probably don't make people into better programmers, just better informed programmers. In fact, it's often the complete opposite. The code examples in most tech books irritate me greatly, for example - they get across the narrow technical point that they are attempting to illustrate, but apart from that, they are often good examples of how not to code.

There are, however, a very few books which can make one a better programmer, I think. Code Complete and The Pragmatic Programmer, for example, should be mandatory reading for anyone who makes a living cutting code. Other good examples might be the GoF book, or Bitter Java.

How many people in our profession really love what they do? Not many - 95% (the same 95% again?) are in it for the cash - indoor work, with no heavy lifting. There do exist, though, programmers who do not love what they do, but do nevertheless approach it in a professional manner. I know - I work with some of them. But the couldn't-care-less brigade are always present, too...

The company for which I work is not yet 'agile'. We are introducing test-first throughout our development process, though, and other we are looking at and discussing the other XP core practices.

One if the aspects of XP which seems to be putting some people off the idea is the absence of a specific design stage. Demystifying Extreme Programming: Just-in-time design demonstrates the just-in-time design concept.

Interesting. In Closed source versus open source in a model of software bug dynamics, Damien Challet and Yann Le Du of the University of Oxford show that open source software has less defects than closed source, other circumstances being equal.

I'll have to try this on on El Presidente - "It's your fault that the software I wrote is crap. You insisted that it be closed..."

Via Azeem Azhar.

A post over at c.l.py steered me towards this - Building user interfaces for object-oriented systems.

It has some interesting, if perhaps somewhat controversial, things to say on the nature of object orientation.

You may have read in a book somewhere that an object is a data structure of some sort combined with a set of functions, called methods, that manipulate that data structure. Balderdash! Poppycock! First and foremost, an object is a collection of capabilities. Very true, this. The important thing about an object is what is does, not what it has. The latter is an implementation matter.

Classes are irrelevant -- they're just a convenience provided for the compiler. Also true. This was pointed out to me while looking at JavaScript recently. Its rather, uh, idiosyncratic OO model does away with 'classes' as such. Instead, you just define a construction function, and add methods to its prototype. Look, Ma, no classes. (I don't really like this approach much - it makes subclassing rather clumsy if nothing else. But it does work after a fashion.)

All data is private. Period. (This rule applies to all implementation details, not just the data.) get and set functions are evil. (They're just elaborate ways to make the data public.) I like Python's approach here. No data is really private (see