I have been doing some investigations of build tools lately.  My simple desires for a build tool are:

• smallish size
• no installation
• as much ancillary benefit as possible

I have used NAnt extensively and dabbled in psake recently.  I may post my thoughts on psake later, but at this moment, I want to document what I have done with rake.

My business partner, John Teague, had been pushing me to try Ruby and rake for some time, but I knew the installation had a footprint over 20MB.  Disk space is cheap, but that is still quite an increase over NAnt.  Compound this with how many times it will be downloaded by developers and a Continuous Integration server as part of a build and the size and time adds up.  There is definitely a lot of Ruby development going on, but the size and required installation (Ruby itself plus lots of little “gems”) were real turn-offs.

One evening I started surfing on Ruby and ran across Erik Veenstra’s AllInOneRuby script.  It is a Ruby script that packages your Ruby installation into a single executable.  This is definitely worth a try.  However, I quickly ran into trouble with a run-time error in the script.  The script has not seen an update in two years, so Ruby has apparently moved beyond it.  A lilttle digging and I found the accepted solution to the error.  Nothing like learning a new language by fixing an error in two year source.

This being my first work in Ruby, I am open to constructive criticism.  I will describe the process in two parts.  Specific version numbers are given for reference.  First, the Ruby installation:

1. I downloaded the latest Ruby binaries (1.8.7) rather than use the Windows installer to maintain the “cleanliness” of my workstation for subsequent testing.
2. Extract the binaries to c:\rubywork\ruby
3. Download RubyGems (1.3.4)
4. Extract RubyGems to c:\rubywork\gems
5. To install RubyGems, at a command prompt in c:\rubywork\gems, run
   ..\ruby\bin\ruby setup.rb
6. Download Rake (0.8.7)
7. Extract Rake to c:\rubywork\rake
8. To install Rake, at a command prompt in c:\rubywork\rake, run
   ..\ruby\bin\ruby install.rb

Next, to update Erik’s script:

1. Download allinoneruby.tar.gz (0.2.11), the internals of AllInOneRuby
2. Extract allinoneruby.tar.gz to c:\rubywork\oneruby\allinoneruby
3. Download Erik’s tar2rubyscript.rb (0.4.8) to c:\rubywork\oneruby
4. Edit c:\rubywork\oneruby\allinoneruby\init.rb and modify line 188 to read:
   f.puts “    $0 = script”
5. Edit c:\rubywork\oneruby\tar2rubyscript.rb and modify line 623 to read:
   $0 = File.expand_path(“./init.rb”)
6. At a command prompt in c:\rubywork\oneruby, run
   ..\ruby\bin\ruby tar2rubyscript.rb allinoneruby/
   which will create a partially flawed allinoneruby.rb
7. Edit c:\rubywork\oneruby\allinoneruby.rb and modify line 605 to read:
   $0 = File.expand_path(“./init.rb”)
8. At a command prompt in c:\rubywork\oneruby, run
   ..\ruby\bin\ruby allinoneruby.rb –site
   which creates the desired allinoneruby.exe.

The exe is just over 3MB.  Not bad at all.

Now, to execute rake, we need a couple support files.  Create a file named rake.rb:
require ‘rake’
require ‘rake/tasklib’
Rake.application.run

Then, a file named rakefile:
task :default do
$stderr.puts “Howdy, World”
end

Place these two files together with your allinoneruby.exe and execute:
allinoneruby.exe ruby.rb
and receive a Texan salutation.

Enjoy!

Pablo’s guys were exceptional.  They put together a set of sponsors to provide a venue with plenty of space and large projectors and provide food.  They assembled a lab workbook with step-by-step instructions and lots of screen shots to encourage working along with the presenter.  Another sponsor provided the color printing of the workbook.  Lots of attendees brought their laptops and were actively following.

Obviously, the primary topic was common unit testing concepts using NUnit.  In addition, Resharper hints and tricks are used extensively.  Finally, an introduction to mocking with Rhino.Mocks was covered in the last lab.  I counted eight Los Techies members on hand to answer virtually any question or provide one-on-one help.

Although the turnout was very good, I know there were more people out there that could have benefited.  I encouraged several folks to show up and not a one was there.

Come on folks.  There are tons of opportunities out there for free skills development.  You might have to give up a Saturday or an evening to attend, but it will be worth it to your craft.  In the long run, this translates to increased productivity and career advancement.

Managers, look for these opportunities and encourage your developers to attend.  As your developers improve and advance their careers, this is a positive reflection on you as well.

Then, he is speaking on Object Oriented Design Principles at Houston Techfest on Saturday, September 13.  I will be in attendance as well.

Be sure to check out these sessions in your area!

I hit the net searching for discussion on this topic and found plenty of blogs saying “don’t rewrite, refactor instead.” However, no one really speaks in favor of a rewrite. Here, we list reasons in favor of a rewrite:

• Performance: The existing architecture and code was written in a day when the transaction volume was several orders of magnitude less.
• Turnover: With a twist to the meaning of the term, everyone has heard the stories about this code and has managed to push back on every feature request for years. In that time all of the developers that actually did know that code have left.
• Business has evolved: Similar to the performance reason, the business has evolved to the point that the architecture is challenged to meet the needs.
• Development speed: The code is so rigid that developers cannot deliver features fast enough and the business is unable to take advantage of changing market conditions.

I contend that all of these reasons boil down to just one:

When changing the existing code is more expensive to the business, it is time for a rewrite.

This should absolutely be measurable. Compare the estimated development time of the requested features and the ROI of those features based on time with the estimated development time to rewrite.

I am proposing my client invest in a little time to evaluate the code closer for refactoring options.

As with many others before me, my first post will be more or less an introduction.  I am co-founder and principal consultant for Next Level Technology with John Teague. We are a custom software development and Agile coaching firm in Austin, Texas.  Although our business is new, we will succeed by taking advantage of short iterations, and the frequent communication that accompanies them, to make sure our clients get software that works just as they need.

I’ve been leading teams for over a decade.  I’ve written device drivers and 3D games, shrink wrap software and enterprise software, desktop software and web applications.  I’ve been a developer, technical lead, director, and vice president.  I won’t pretend to be a master of any slice of software development, but I’ve definitely been around the block.  This diversity has afforded me the opportunity to work with many different teams.  Some teams were quite strong; others, well, not so strong.

Most recently, I was the VP of Technology at Callaway Golf Interactive for over 6 years where I lead the teams that developed the ecommerce site for Callaway Golf, specifically www.callawaygolfpreowned.com and shop.callawaygolf.com.  During this time, my day-to-day focus shifted from mostly coding to mostly management.

I believe it was back in 2005, while at CGI, that Eric Hexter introduced me to Agile, something he was just discovering, and a new way of thinking.  Although I instantly saw the benefits from a project management and quality standpoint, it has been a continuous journey ever since.  It is absolutely a new way of approaching a project and working it to success.  Since then, I have become a certified ScrumMaster, lead multiple project cycles, and I even put myself into a team as a coder just for the experience.

My goal for this blog is pass along those useful tidbits of information, or start a topic of conversation.  I have a couple of pet projects going on that will afford me plenty of personal coding experience to share.  In addition, there will be technical leadership thoughts to pass along as I work with other teams as part of NLT.