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.

One of the reasons I started this blog was to write down some of the stuff I’ve learnt over the past couple of years on how to structure my development environment so that it’s easy to use and ties in nicely with things like continuous integration and automated testing.

So this is sort of a “head-up” of the topics I think I will be covering over the coming weeks..

• Tools choice
• Source control
• Project structure
• Binary dependencies
• Continuous Integration

It won’t necessarily be in this order and I may throw some other stuff in if I find the inspiration