Paul Hatcher

Just recovering from flu at the moment and I’m an official Swine Flu statistic.

Not the nicest of bugs, couldn’t keep any food down until the anti-virals kicked in but the funniest thing about the whole episode is the screening questionnaire to see if you qualify for the Tamiflu.

First question is whether you are enquiring on behalf of yourself or someone else, on being told I that I was asking for myself the call centre staff (apologetically) asked

I try to keep the same project structure for all projects, this makes it easy when initiating new projects as you can automate the creation of the core project structure.

We have the usual subversion branches/tags/trunk structure and then within trunk we have

• builds : Contains all continuous integration build files for the project.
• code : All the code for the project, flat directory structure internally with one project per directory.
• database: Database structure, produced using the Red Gate schema compare tool
• docs: Documentation source and any other project documentation
• lib: Holds the library files for the project, typically referenced via svn:externals but might really be here if only used by one project.
• model: Location of any models, I generally use Enterprise Architect for UML modelling so the files go here.

I’ll explain about the builds directory a bit more in the post about continuous integration, but the reason it is here physically is that then keeps everything about the project in one location rather than some bits being held by the CI project.

Finally had sometime to progress the port of Hibernate Search…

We are intending to be feature complete with Hibernate Search 3.0.1 GA and at the moment I would say that we have ported about 80% of the code.

I have also updated the libraries so that we are using Lucene 2.3.1 and NHibernate 2.1

One of the things I’ve been working on over the last couple of years for myself and for clients, is making the development environment as frictionless as possible. By this I mean removing all the little annoyances that get in the way of producing good quality software.

This guiding idea has led me to one guiding principal: keep everything under source control!

For example, one classic problem I’ve encountered is that the build works on the developer’s workstation but not on the build server or vice versa. To solve this, we now put all of our tools, excluding Visual Studio, under source control, this minimizes the differences between the developers’ machines and build environment.

No this isn’t about how Haskell evaluates stuff, but how people design and write code.

There’s a mobile phone ad showing in the UK at the moment about how it’s the impatient people that drive towards new innovation and in software at least I strongly disagree.

On the contrary, lazy programmers rule. I’m a lazy programmer, I can’t bear writing the same code more than a couple of times and when I recognise the second instance I refactor it into a function. Why - basically its about how to keep the essential stuff in your head and good use of patterns.