Tim Hoolihan

Rake Breathing New Life to Building Old Projects

I’ve seen lots of examples of rake (the ruby make replacement) being used as a build tool in non-ruby projects. Many of these are still modern platforms, like .Net. For example, StructureMap builds with rake. But I’ve found that even on older platforms, the power of having a full programming language in your build tool is useful.

Recently, I was working through examples in Thinking in C++, and there is the need to build many small one file examples. I started writing a Makefile to simplify this, and decided to try rake instead.

The power of a programming language brings a lot to table when doing repetitive tasks. Check out the following Rakefile which generates a build, run, and clean method for each file listed in an array. And there are aggregate methods which will run or clean all.

exe_name = ["hello","c_in_cpp","file","vector"]

exe_name.each do |f|
  desc "clean #{f}"
  task "clean_#{f}".to_sym do
    sh "rm -rf #{f} #{f}.o"
  end

  desc "build #{f}"
  task "build_#{f}".to_sym => "clean_#{f}" do
    sh "g++ #{f}.cpp -o #{f}"
  end

  desc "run #{f}"
  task "run_#{f}".to_sym => "build_#{f}" do
    sh "./#{f} 2> error.log"
  end
end

desc "run all"
task :default => exe_name.collect{|f| "run_#{f}"}

desc "clean all"
task :clean => exe_name.collect{|f| "clean_#{f}"}

If any of the above is unclear, and you want to see the output, do the following: copy and paste that code into a file named “Rakefile”. Run “rake -T” to lists all available tasks. You won’t be able to actually run the tasks, unless you have the appropriate cpp files in the directory (ie “rake run_hello” requires hello.cpp).

If you want to learn a build tool, and know ruby, or want to learn ruby rather than some specialized build language with no other uses, give rake a shot.

NHibernate and Auto Properties

I’ve been working through the NHibernate with ASP.NET ProblemDesignSolution (Wrox Blox), with some small changes. I’m writing my sample in C# using the .Net framework 3.5. I prefer to use auto-properties.

It’s common that fields have private setters and only nhibernate can map using the backing field (set via reflection).

public String City { get; private set; }

The problem is telling NHibernate how to find the backing field. When you have an explicit field, you end up with something like:

<property access=”field.camelcase-underscore” name=”City” />

But with no backing field, that is a problem. I started looking around on the net and found the following:

StackOverflow discussion without much good info
and a blog post with an interesting response from Ayende Rahien.

Ayende is saying to not worry about the issue, NHibernate will still be able to set via reflection. That’s fine, but it feels a little “magical”, especially to a new developer coming along.

Why not set protected? It’s not unreasonable to expect a maintaining developer to understand that NHibernate sub-classes your class.

public String City { get; protected set; }

Now the mapping stays simple too:

<property name=”City” />

And there is no need to expect a maintaining developer to know that reflection magic is setting the property.