Mike Hall and I have finally gotten together and recorded our first episode of The Iron Languages Podcast.

In this episode, we chat about the Dynamic Language Runtime (DLR) and IronRuby in particular.

Some links related to topics we discussed:

• Iron Ruby : http://ironruby.net
• Dynamic Language Runtime (DLR):http://en.wikipedia.org/wiki/Dynamic_Language_Runtime
• Factory Girl: http://github.com/thoughtbot/factory_girl
• Sinatra: http://sinatrarb.com
• Jython: http://www.jython.org
• RailsMentor.org: http://railsmentor.org

Please let us know what you think, how we can improve and what you’d like to hear about. We hope you enjoy the podcast!

On numerous occasions working with C# on .NET, I’ve thought to myself “man, I really wish I had something like Factory Girl here!”. So, last night/this morning, I set out to create a spike solution to determine the feasibility of hosting IronRuby within my C# library, thus allowing me to use Factory Girl to build POCOs for me. The result:

OH YEAH!

Well, at least for the Factory.build method, but that’s all I was interested in for this spike.

I’ve put my code up on github for your perusal. For this particular solution I don’t think you’ll need Visual Studio 2010, but you will certainly need .NET 4 installed, as well as IronRuby. Also note that IronRuby needs to be installed into C:\IronRuby unless you want to edit the app.config and fix up some references.

I’m excited now about the possibilities of utilizing other Ruby libraries in my .NET projects!

A couple of weeks ago, Cory Foy and I had a chat with the Herding Code guys. We talked about the differences between developing on the .NET platform and in Ruby/Rails. It was a great time. Please go give it a listen, and do let me know what you think!

I was interested in IronRuby when it was first announced but had lost hope that it would ever be viable. Will did an awesome job of convincing me that it’s alive and well. Great talk.

– Barry Ezell

Nice! Below are the slides, and here are the (admittedly thin) demos up on Github.

I’m working on getting this contributed to the IronRuby project, as judging from the RubyGems sources, as well as the RubyGems sources distributed with JRuby, this is intended to be distributed by the Ruby implementation, not RubyGems itself.

Also note, this allows one to:

C:\Users\Will>gem up –system

Updating RubyGems
Updating rubygems-update
Successfully installed rubygems-update-1.3.7
Updating RubyGems to 1.3.7
Installing RubyGems 1.3.7
RubyGems 1.3.7 installed

=== 1.3.7 / 2010-05-13

NOTE:

http://rubygems.org is now the default source for downloading gems.

You may have sources set via ~/.gemrc, so you should replace
http://gems.rubyforge.org with http://rubygems.org

http://gems.rubyforge.org will continue to work for the forseeable future.

New features:

* `gem` commands
  * `gem install` and `gem fetch` now report alternate platforms when a
    matching one couldn't be found.
  * `gem contents` --prefix is now the default as specified in --help.  Bug
    #27211 by Mamoru Tasaka.
  * `gem fetch` can fetch of old versions again.  Bug #27960 by Eric Hankins.
  * `gem query` and friends output now lists platforms.  Bug #27856 by Greg
    Hazel.
  * `gem server` now allows specification of multiple gem dirs for
    documentation.  Bug #27573 by Yuki Sonoda.
  * `gem unpack` can unpack gems again.  Bug #27872 by Timothy Jones.
  * `gem unpack` now unpacks remote gems.
  * --user-install is no longer the default.  If you really liked it, see
    Gem::ConfigFile to learn how to set it by default.  (This change was made
    in 1.3.6)

* RubyGems now has platform support for IronRuby.  Patch #27951 by Will Green.

Bug fixes:

* Require rubygems/custom_require if --disable-gem was set.  Bug #27700 by
  Roger Pack.
* RubyGems now protects against exceptions being raised by plugins.
* rubygems/builder now requires user_interaction.  Ruby Bug #1040 by Phillip
  Toland.
* Gem::Dependency support #version_requirements= with a warning.  Fix for old
  Rails versions.  Bug #27868 by Wei Jen Lu.
* Gem::PackageTask depends on the package dir like the other rake package
  tasks so dependencies can be hooked up correctly.

------------------------------------------------------------------------------

RubyGems installed the following executables:

C:/Ruby/bin/gem

C:\Users\Will>

Sure, it’s a small contribution (having Ruby Gems recognize IronRuby as a platform), but an important one none the less. This allows us to create gems specifically for the .NET platform, similar to the way JRuby has JVM-specific gems.

Installation is a simple

Cucumber has made use of iron-term-ansicolor on IronRuby since the first release of this library. I’m not sure what it would take to include automatic support for RSpec, but I’m sure it would probably be as simple as it was to add it to Cucumber.

The source is available on github. Please report any issues using the issue tracker there.

Enjoy!

I now believe that if you’re serious about creating Rails apps, you aren’t doing it on Windows. Or, you are a masochist.

That’s a quote from me. I’m done trying to do serious Ruby & Rails development on Windows. As of January 1st, 2010, I have not found a Ruby implementation on Windows that is fast enough to support the TDD/BDD workflow that Corey Haines exhibits in his Number to LCD code kata. On top of that, I wasted 2 days on trying to get Selenium and Cucumber to work together in Windows. I was venting about this on Twitter when Cory Foy made a suggestion:

@hotgazpacho You know, I don’t know why you don’t just run a VM with Linux on it for Rails dev. That’s what I have on my Windows box.

I didn’t know why either. My first concern was memory consumption (my personal notebook only has 2 GB of RAM in it), but both Cory and Robert Dempsey allayed my fears:

@hotgazpacho 2GB should be plenty. The Linux VM should only need 512. Would help to run the VM on an external drive if you’ve got one

@cory_foy @hotgazpacho I run linux ubuntu vm’s (vmware) on my MBP and 512 is more than enough if you don’t use a heavy IDE. Runs very well

So, I went ahead and set up Ubuntu 9.10 in a VirtualBox virtual machine (VirtualBox is a free virtualization product from Sun, similar to VMWare Workstation or Microsoft Virtual PC). The results were astounding! On a Rails app I was working on, all the RSpec examples and Cucumber features ran in less than the time it took for the MingW Ruby interpreter to start up. WOW! We’re talking orders of magnitude faster, and all in less memory than it takes to boot Windows. I’m sold.

Here’s how I set up the VM:

1. Install VirtualBox
2. Create a new VB VM for Ubuntu
   The Ubuntu Community wiki has pretty good documentation (for Ubuntu host, but UI is pretty much identical on Windows)
3. Make sure the system is up-to-date (it won’t be). Let update manager run & reboot
4. Install Virtual Box additions & reboot
5. Install pre-requirements for building stuff (note: I may be missing some stuff. If I am, Ruby Enterprise Edition installer will let you know and tell you what is missing):

   1	sudo apt-get install build-essential libpcre3 libxml2-dev libxslt1-dev sqlite3 libsqlite3-dev –y

6. Ruby Enterprise Edition (cause this is what I run on my production server)

   1	wget -c http://rubyforge.org/frs/download.php/66162/ruby-enterprise-1.8.7-2009.10.tar.gz        <br />tar xzvf ruby-enterprise-1.8.7-2009.10.tar.gz         <br />sudo ./ruby-enterprise-1.8.7-2009.10/installer

7. Add Ruby Enterprise Edition bin path to "secure path" for sudo

   1	sudo visudo

   Change line starting with Defaults to the following:

   1	Defaults env_reset, secure_path=/opt/ruby-enterprise-1.8.7-2009.10/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

8. Install gmate, which makes gEdit behave like TextMate. Instructions are on the gmate github page.
9. Make gem not install rdoc and ri by default.

   1	echo "gem: --no-rdoc --no-ri" >> ~/.gemrc

10. Install Rails, Sqlite, ZenTest, RSpec, Cucumber, & Factory Girl

    1	sudo gem i rails sqlite3-ruby ZenTest rspec cucumber factory_girl

11. Make cucumber feature running part of autospec runs

    1	echo "export AUTOFEATURE=true" >> ~/.profile

One Minor Problem…

There’s only one minor problem with this whole setup. Cory Foy articulated it best:

@hotgazpacho The problem is now you’ll /really/ not be happy doing Rails on Windows. Ever.

This is a problem I can live with

For some additional fun…

…you might want to install the following:

1. git-prompt, bash prompt with GIT, SVN and HG modules

   1	git clone git://github.com/lvv/git-prompt.git && echo ". ~/git-prompt/git-prompt.sh" >> ~/.profile

2. Autotest/Autospec notifications to Ubuntu system notifications (similar to Growl on OS X)

   1	sudo gem i test_notifier && echo "require 'test_notifier/autotest'" >> ~/.autotest

3. Sounds for Autotest events – http://www.fozworks.com/2007/7/28/autotest-sound-effects

   1	sudo apt-get install mpg321 && wget -c http://www.fozworks.com/static/autotest-sound-1_2.zip && gunzip autotest-sound-1_2.zip && echo "require '~/autotest/sound/sound.rb'" >> ~/.autotest && echo "Autotest::Sound.sound_path = '~/autotest/sound/sound_fx/'" >> ~/.autotest

First, Why?

We practice continuous integration (CI) at my office. This means we have a server, specifically TeamCity, monitor our source control repository and perform various builds on a clean system (thus avoiding the “it works on my machine!” syndrome). In addition to performing continuous builds (whenever someone checks code in), we also perform full builds at regular intervals throughout the day. We also perform a more exhaustive nightly build, where in addition to compiling our suite, we also deploy the built suite to our lab server for more processing. This additional processing entails running a program to create database schemas on the 3 database platform we support (SQL Server, Oracle, & Access), perform conversions from one version of the suite to another, and validate the results.

Sounds straight-forward enough, right? Well, there’s one really big wrinkle here: our build servers are physical servers located in Texas, our lab servers (app server and two database servers) are virtual machines located in Florida, and between them is, shall I say, a really crappy network connection. How crappy? Well, if we run the database creation and validation app on our lab app server, the process takes about 45 minutes. If we run the creation and validation app on our build servers, the process takes significantly longer (I’ve been told 4-6 hours). That extended length is not acceptable, as it interferes with our ability to create the MSIs that we use the next day for integration testing and QA.

To get around this, our nightly build process stopped at copying a zip archive of the compiled suite to our lab server. We then relied on a couple of scheduled tasks on the lab server to run batch files to unzip the suite and run the database creation and validation app. This worked, but had a major draw back. If the creation and validation script failed, it sent an email. However, only a very small number of the team received this email. Since the CI server had no knowledge of this process, it could not fail the build, and the majority of the team would go on not knowing that the suite was effectively broken in a way that would only be apparent at run-time, and only if we happened to exercise a certain bit of functionality that relied on the database schema being valid.

In other words, the risk of massive wasted team productivity was very high.

Now, How

As I mentioned before, we use TeamCity as our CI server. We build a suite of applications for Windows clients and servers, so we use MSBuild as our build system. MSBuild has a built-in task called Exec, which allows you to execute any command, and if the command returns a non-zero exit code, it is considered to have failed. This is great, except that it executes the command on the current machine (recall that the build server is in Texas, but we need the database app to run on the server in Florida.

PsExec: A False Start

My first thought for remotely executing commands on a Windows server was to use PsExec from the SysInternals Suite. This worked great, as long as I ran the MSBuild script from my local machine. However, as I discovered after combing the SysInternals forums, PsExec does some funky things with standard in (stdin) and standard error (stderr), such that Java processes (which TeamCity is), seem to hang when calling PsExec. That is, PsExec does not appear to return control to the spawning Java process in the manner that it expects. So, even though the remote processes would execute properly, they would not return control to TeamCity, nor would it provide the exit code of the remote process. As a result, not only would the build fail (we configured TeamCity to fail the build if it ran more than 2 hours), but it would fail for the wrong reason, and continue to mask the real reason from the majority of the team.

This would not do, no sir. So I set out in search of an alternative.

RemCom: A New Hope

After much searching, I came across RemCom, “the open source psexec”. RemCom performed the same function as PsExec, but it did so without funky stdin/stderr redirection. So, I added RemCom to the build process, adjusted the build scripts accordingly, and kicked off a new nightly build in TeamCity. The build finished in about 90 minutes, and it succeeded! Except for one problem: I knew there was still a problem with the databases, so I was expecting it to fail. Sure enough, I checked the logs and found that RemCom had provided all the output of the remote commands (something PsExec never did, btw), including printing the exit code returned. However, it seems that exit code was not being bubbled up to RemCom. So, we had a situation where RemCom was telling us the remote command failed, but RemCom itself was returning a successful exit code, and so MSBuild saw this as successful.

Exec Task: The Empire Strikes Back

It was great that I was getting the output of the remote commands, but now I needed to parse it. Unfortunately, the Exec task that comes with MSBuild simply does not provide you with the ability to capture the output and do anything meaningful with it. So, it was time to look elsewhere.

ExecParse: The Return of the Exit Code

After a little bit of Googling, I came across ExecParse:

A custom MSBuild task that inherits from the Exec MSBuild task. The task adds a parameter to allow parsing of the output using regular expressions, and reporting to the MSBuild logger (and consequently the VS.Net IDE).

Bingo!

I then added a reference to the task library in our build script and followed the simple directions to create a configuration with a simple regular expression to grab the exit code of the remote command from RemCom.

<UsingTask AssemblyFile="ExecParse.dll" TaskName="ExecParse.ExecParse" />
<PropertyGroup>
<DeployServerHost>nasrvfl7004</DeployServerHost>
<DeployServerLocalPath />
  <ExecParseConfiguration>
    <Error>
      <Search>Remote command returned (-?[1-9]\d*)</Search>
      <Message>Remote command failed with error code $1</Message>
    </Error>
  </ExecParseConfiguration>
</PropertyGroup>

<Target Name="CreateDbsOnServer">
<Message Text="Creating databases on Server $(DeployServerHost)..." />
<Error Text="Build and Deploy selected, but the DeployServerHost was not not specified" Condition="'$(DeployServerHost)'==''"></Error>
<Error Text="Build and Deploy selected, but the DeployServerLocalPath was not specified" Condition="'$(DeployServerLocalPath)'==''"></Error>
  <Copy SourceFiles="RemCom.exe;CreateDbsOnServer.bat" DestinationFolder="$(DeployLocation)" />
  <ExecParse
      Command="RemCom.exe \\$(DeployServerHost) /d:$(DeployServerLocalPath) $(DeployServerLocalPath)\CreateDbsOnServer.bat $(DeployServerLocalPath)"
      Configuration="$(ExecParseConfiguration)"
      ErrorCausesFail="true" />
</Target>

That, right there, was the secret sauce. Now, we can execute remote tasks from our CI build, include their output in the build log, and fail the build if those commands fail. NICE!

Going forward, we’re going to investigate including the remote commands into the full builds, as they run reasonably quickly enough. We will probably want to investigate adding another build agent, as this would tie up the build server for 90 minutes, thus preventing the continuous builds from running in a timely manner.

Epilogue

Pavel Sher, presumably from JetBrains, contacted me via Twitter and suggested that I try the latest TeamCity EAP. Pavel tells me that PsExec is working now with this version (would be a 5.0 EAP). Though I am not in a position to go upgrading TeamCity right now, I thought I should include this bit of info, in case someone reading this is.