Tuesday, June 09, 2009
When all you need is a rake, why would you grab a tractor?
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:
- 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.
- Extract the binaries to c:\rubywork\ruby
- Download RubyGems (1.3.4)
- Extract RubyGems to c:\rubywork\gems
- To install RubyGems, at a command prompt in c:\rubywork\gems, run
..\ruby\bin\ruby setup.rb
- Download Rake (0.8.7)
- Extract Rake to c:\rubywork\rake
- To install Rake, at a command prompt in c:\rubywork\rake, run
..\ruby\bin\ruby install.rb
Next, to update Erik's script:
- Download allinoneruby.tar.gz (0.2.11), the internals of AllInOneRuby
- Extract allinoneruby.tar.gz to c:\rubywork\oneruby\allinoneruby
- Download Erik's tar2rubyscript.rb (0.4.8) to c:\rubywork\oneruby
- Edit c:\rubywork\oneruby\allinoneruby\init.rb and modify line 188 to read:
f.puts " $0 = script"
- Edit c:\rubywork\oneruby\tar2rubyscript.rb and modify line 623 to read:
$0 = File.expand_path("./init.rb")
- At a command prompt in c:\rubywork\oneruby, run
..\ruby\bin\ruby tar2rubyscript.rb allinoneruby/
which will create a partially flawed allinoneruby.rb
- Edit c:\rubywork\oneruby\allinoneruby.rb and modify line 605 to read:
$0 = File.expand_path("./init.rb")
- 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!
Saturday, October 04, 2008
I attended
Pablo's Days of TDD yesterday and today. I didn't attend really for my personal benefit since I already understand and believe in the concepts of TDD. Rather, I came to see what the Los Techies guys had put together and who else attended.
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.
Monday, September 08, 2008
My business partner,
John Teague, is speaking at the
Alamo Coders in San Antonio on Tuesday, September 9, on jQuery.
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!
Friday, August 22, 2008
A potential client is considering a major rewrite of one of their most important applications. Now, at first I’m seeing a few dollar signs for a new project, but then I come back to earth and start thinking again later that evening. Strangely, my business partner, John, starts an IM conversation with me about software rewrites even though I hadn’t yet told him about the conversation I had with the client.
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.
Sunday, August 17, 2008
I'm finally making the leap. However, it took a lot of prodding from multiple individuals to get to this point. This is my first blog post. ...