Month: February 2005

So, lets start building our development tree. Feel free to join in. 🙂

The first thing you need is a Source Control environment. This may sound simple, but even at this stage I have seen some strange things happen on projects.

Here are some ‘must haves’:

• Your source control server must be fast. Your developers are often going to be waiting for your source control to do things, so don’t scrimp on hardware. Specifically:
  • Do use decent, modern, hardware.
  • Don’t use network shares to store files – in my experience it will slow your source control by about 10x. Instead invest in some locally redundant disks (RAID 5 is OK, RAID 0+1 is better), and a backup strategy.
  • Don’t put your Source Control server on the other side of the world from your team. Keep it local, and make sure your network isn’t getting bogged down. Obviously with distributed teams this may not be possible, but if your team isn’t distributed, don’t distribute your hardware.
• Don’t be tight on hard disk space. Get about as much as you think you might need in 3-5 years. Disk space really is cheap and having lots of it means that people can worry about producing software, and not about whether they are going over quota.
• Give developers write access to the code they need to work on. If you trust them to write code, you should trust them to be able to edit their own work without having to go through slow processes. Other team’s code may be a different matter.
• Put each development tree in its own folder under source control – don’t try and ‘save’ work or space by merging them. It really will save you headaches and time. See the ‘hard disk space’ point.
• Make sure new source control clients can be set up fast and correctly. Document what needs to be done for each project on a Wiki. If your Source Control Client setup takes over 10 minutes, or is more than a page of manual work, change it. If necessary throw away your current Source Control software and start again.
• Make sure basic source control operations are quick, simple and well understood. All developers should be easily able to do all of the following operations – if they don’t know how or if these processes are cumbersome or slow to execute, then change them (again, if necessary consider changing your Source Control software)
  • Check out from nothing
  • Get updates
  • Find differences between server and local versions
  • Revert local versions
  • Commit changes
• Your Source Control system must be consistently trustworthy – if developers are losing changes or files are becoming corrupted, fix it.
• Your Source Control server should support the following more advanced operations, which developers should be able to perform if necessary:
  • Labelling (tagging)
  • Branching (parallel, independent, development of integratable code lines)
  • Automation (be driven by a process, not just a person)

The above points I believe are all necessary for an effective development project. For an ‘excellent’ project I recommend the following:

• A good source control server can happily accomodate 100 developers. I recommend the following kind of system:
  • UNIX/Linux based – Most good Source Control software is written primarily for a UNIX/Linux environment so don’t support edge cases.
  • At least dual-CPU (I like the idea of one CPU being able to do work, and one doing I/O, but I’m sure that’s rather a simplistic model these days)
  • At least 1GB RAM – if your often-accessed source is already cached you should get a speed up.
  • Don’t run anything else on the machine apart from a Source Control server. If you do (e.g. source control reporting), invest in extra processors and monitor what impact those extra applications are having.
  • Use 1 disk set for applications and checkpoints/journals, and a separate disk set for your actual data.
• If cash is fairly easily available in your organisation, use Perforce. I’ve been using it on an off for 4 years now and it never ceases to amaze me how fast and stable it is. It also requires almost zero maintenance.
• Otherwise use Subversion. It is free, and better than any other SCM system I’ve tried apart from Perforce.
• If you are using Visual SourceSafe, I strongly urge you to migrate away from it. It is renowned for not being scalable and is also prone to file corruption. If you are not experienced with UNIX, or any other SCM tool apart from VSS, I have heard good things about SourceGear Vault.
• Use clean and simple setups for your ‘meta’ trees. In Perforce, putting all projects in one ‘depot’ is perfectly reasonable, and use similar ideas for other tools.

If after reading all of this you are thinking ‘Nice ideas, but we don’t have the time or money to do any of this’, then think how much it would really cost you to (say) invest in a new Linux server and Subversion, and how much money you are losing through lack of productivity. Its also a lot simpler than you think. Why not try out Subversion for half a day with a good book?

In the next part we’ll start looking at some code – stay tuned!

In the last few weeks I’ve setup 2 brand new .Development Trees for .NET projects. What do I mean by development tree?

• It is a directory structure
• containing:
  • source files
  • tools and dependencies
  • references to external tools and dependencies
• checked into source control
• that is atomically integratable
• to produce a set of artifacts

A good development tree should:

• be easily integratable on new environments
• require little maintainance
• but be easily maintainable when it does require maintenance
• support, but not hamper, developer productivity
• have consistent behaviour

This is all a bit wooly, but will do for an intial stab. I might come back and refine these points later.

Anyway, I’ve setup quite a few development trees in my time, in Java and .NET. In this series of blog entries I hope to develop a good ‘boilerplate’ development tree structure for .NET projects that other people can use.

If you find it interesting, please email me with your comments.

Update

Please see the separate page in my articles section for this.

I’ve recently started using NVelocity. Its a brilliantly simple and powerful templating engine that’s been ported from the Java world.

I was going to explain how it works, and how to use it in your app, but its easier just to show you a test and an implementation.

[TestFixture]

public class MyVelocityTransformerTest

{

[Test]

public void ShouldUseVelocityToMergeContextContentsWithTemplate()

{

Hashtable contextContents = new Hashtable();

contextContents["foo"] = "bar";

MyVelocityTransformer transformer = new MyVelocityTransformer();

Assert.AreEqual("foo is bar", transformer.Transform("testTransform.vm", contextContents));

}

}

public class MyVelocityTransformer

{

public string Transform(string transformerFileName, Hashtable transformable)

{

VelocityEngine engine = new VelocityEngine();

engine.SetProperty(RuntimeConstants_Fields.RUNTIME_LOG_LOGSYSTEM_CLASS, "NVelocity.Runtime.Log.NullLogSystem");

engine.SetProperty(RuntimeConstants_Fields.FILE_RESOURCE_LOADER_PATH, "templates");

engine.SetProperty(RuntimeConstants_Fields.RESOURCE_MANAGER_CLASS, "NVelocity.Runtime.Resource.ResourceManagerImpl");

engine.Init();

string output = "";

using(TextWriter writer = new StringWriter())

{

engine.MergeTemplate(transformerFileName, new VelocityContext(transformable), writer);

output = writer.ToString();

}

return output;

}

}

This assumes that a file called ‘templates\testTransform’ exists with the following contents:

foo is $foo

The benefit to NVelocity is it makes generating string content much cleaner than any other method I’ve seen. Times when you would want to use it include code generation, HTML generation, etc.

The velocity template language is rich enough to make it more powerful that using (say) string.Format() – the #if and #foreach directives are especially useful.

As with all tools and libraries, NVelocity should be used where appropriate. I’ve seen Java projects with hideously complex, un-unittested templates which are incredibally fragile and hard to debug. My advice is to keep your templates relatively small, and only use directives to just go below the surface of the objects in your context. If necessary, introduce presentation objects and create them in normal, unit testable, code.