The NHibernate Profiler is a pretty cool tool. If you are using NHibernate and want to see how your application/website uses NHibernate this is what you need.

But, why wait till you use the whole application to start using the profiler. Why not use it when writing  writing tests , while building your mappings and when building your NHibernate queries. It’s really easy to do this.

First, get the NHibernate profiler from www.nhprof.com. Extract the contents to a location. From your test project, add a reference to HibernatingRhinos.NHibernate.Profiler.Appender.dll in the NHProf package.

This is my small test class.

 [TestFixture]
    public class EpisodeTests : BaseTest
    {
        [SetUp]
        public override void SetUp()
        {
            base.SetUp();
            ActiveRecordStarter.Initialize(typeof(Episode).Assembly, new XmlConfigurationSource("activerecord.xml"));
        }

        [Test]
        public void CanPersistTitle()
        {
            Episode episode = new Episode();
            string expectedTitle = "Dr Who and the Daleks";
            episode.Title = expectedTitle;
            episode.Save();
           
            Guid savedEpisodeId = episode.Id;
            episode = ActiveRecordBase<Episode>.Find(savedEpisodeId);

            Assert.That(episode.Title, Is.EqualTo(expectedTitle));

        }
    }

I’m using Castle ActiveRecord (which uses NHibernate behind the scenes) to demonstrate this. To enable NHProf to profile the test, add a static constructor to the super class , BaseTest. In the static constructor, add the following code.

HibernatingRhinos.NHibernate.Profiler.Appender.NHibernateProfiler.Initialize();

Go to where you extracted NHProf and run the profiler exe. Run the test and watch the magic.

NHProf is now profiling your integration tests. You can leave this running in the background while you are working on the tests.

You get immediate feedback NHibernate best practice violations, and you can fix them while writing tests. You don’t have to wait till deployment to profile your code. Although this doesn’t give the whole picture of how your application is using NHibernate , you still can fix many things early. I highly recommend running NHProf while running automated acceptance test scenarios.

BBC Worldwide (my employer) is sponsoring a conference on software craftmanship on the 26th of February 2009. This is about the skills you need to build better software. This is about the refactoring skills, spotting code smells and habits that make you a better developer.

The programme and registration details are at Software Craftmanship 2009 

This conference is not about how to do Agile, or how to get started with TDD or how to get started with a certain technology. The conference is programming language agnostic and the skills can be applied to any programming language.

Typing this from a laptop running Windows 7 Beta. This is an older laptop, which is now idle because it has been replaced by a new Dell Studio laptop. Toshiba Satellite M30, 1.5GB RAM, GeForce Go 5200 with 64MB video ram. The only problem was finding the driver for the GeForce Go 5200. I found the Vista 32 bit drivers for this from here. I’ve got full Aero running, it it’s quite snappy. All the other drivers are the normal Vista 32 bit drivers.

Win7 hasn’t picked up the power management utilities from Toshiba (?), trying to see if the utilities from my other Toshiba laptop will work on this. Looks very good so far. Think I’ll wait for Windows 7 to upgrade my main laptop to a 64 bit OS. I’m still not very happy with the driver support from nVidia, and ATI does not seem to be much different either.

Stumbled across this blog entry by William Pietri. Made a list of some pair programming smells I have observed in the wild

1. Quiet Partner  - only one does all the talking, the other listens quietly, often looks bored and un-interested.

2. God Syndrome – the less experienced of the pair is afraid to ask questions. Not wanting to admit lack of knowledge. The superior of the pair zooms along assuming the other is following along.

3. Constant Arguing – over minor design decisions, egotistic reasons. not coming to conclusions.

4.  “My work is so boring, I don’t you to want to see it, let me slave away in the salt mines”

5. Going too fast – Either of the pair going too fast.” I know what I’m doing, just watch me”, and not bothering to explain.

6. Lack of focus - “Hey look at this other thing I’m doing”.

7. Quiet pair – ignoring partner, partner not interested. “I finished everything when you were having a cuppa”.

Ping Pong pairing

SO questions tagged with pair programming

Pramod Sadalage, has written an article on Behaviour Driven DB development. http://www.methodsandtools.com/archive/archive.php?id=78.

He writes about adding behaviour to the domain model and how that behaviour is translates into database objects, with tests. In the project I'm working on, which driven by a Web UI I use the UI behaviour to build the presenter and  through this add behaviour to the domain model. It's at the last stage that I add the persistance, through Nhibernate.

here is a random thought I had today.

From what I've seen, in the past 2 years, agile practices have spread among the .Net community.  The .Net framework  gives us the power to do TDD and follow other agile principles.  the community is now empowered with a rich API , so that we don't have to worry about how to build things.  We now have to worry about what we can build and how to build it better.

We have been freed from the shackles of VB and classic asp, with a good OO framework, that is getting better. You name the problem and there is a very good .Net based tool to help you solve it. You want mocking , you have Rhino Mocks, you want persistence you have NHibernate, you want testing APIs, you have Nunit, Mbunit and what not. 

The technology and tools to build better software is here, are you using it ? if not what's stopping you ?

Seriously, do yourself a favour and go buy this. Keep it on your desk, have it while pairing, use it to bash sense into someone.

Clean Code: A Handbook of Agile Software Craftsmanship . There’s a pretty good review of the book here http://www.markhneedham.com/blog/2008/09/15/clean-code-book-review/

Related Posts:
Martin Fowler Talk