Shay Friedman, Microsoft IronRuby MVP, joins Mike and I for episode 2 of the Iron Languages Podcast. We’re recording on the afternoon of July 11th. If you have any questions you’d like us to ask Shay, leave a comment here or on the Iron Languages Podcast site: http://ironlanguages.net/next-show-dlr-ironruby-and-ironshay
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:
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!
Recently at work, I’ve been using TDD to drive out the design for some WPF View Models. Part of what I’m doing is filtering a collection based on various properties of the elements in the collection. Of course, I’ve needed to build up that collection first. I’d come up with a very limited method using Action<T> to set properties when the builder method was called. While this worked for my needs, I got to thinking about a library I’ve used a couple of times on Rails projects: Factory Girl.
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!
Just a quicky here…
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!
Last night, I gave a talk at the Tampa Ruby Brigade about IronRuby, targeted at the developer who already knows and loves Ruby. About 10 people turned out, including the regional Microsoft Developer Evangelist, Joe Healy (nice to see Microsoft reaching out to other development communities!). The crowd was predominantly Mac users, and I had some concerns that the talk might not be well received. Boy, was I worried over nothing! This quote about sums up the reaction:
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.
After reading this article on getting around the invalid exec_format “ir”, no %s issue when trying to update RubyGems in IronRuby, I came up with a better solution (rather than essentially swallowing the exception) to the problem. Stick the following file in: %IronRubyInstallDir%\lib\ruby\site_ruby\1.8\rubygems\defaults\ironruby.rb
1 2 3 4 5 6 7 8 9 10 11 12 | module Gem def self.default_exec_format exec_format = ConfigMap[:ruby_install_name].sub('ir', '%s') rescue '%s' unless exec_format =~ /%s/ then raise Gem::Exception, "[BUG] invalid exec_format #{exec_format.inspect}, no %s" end exec_format end end |
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:
1 | ir -S gem install bundler |
I’m now a published contributor to a major open source project!
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.
Tonight, I released version 0.0.2 of iron-term-ansicolor. As you may recall, iron-term-ansicolor makes use of the term-ansicolor library and the .Net base class library to provide colored console output for IronRuby. Users of RSpec and Cucumber on IronRuby should now have much cleaner colored output, thanks to Danny Coates, who found a better way to parse the ANSI control codes out so that the appropriate calls to Console.ForegroundColor and Console.BackgroundColor.
Installation is a simple
1 | igem install iron-term-ansicolor |
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.
1 | sudo apt-get install build-essential libpcre3 libxml2-dev libxslt1-dev sqlite3 libsqlite3-dev –y |
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 |
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 |
1 | echo "gem: --no-rdoc --no-ri" >> ~/.gemrc |
1 | sudo gem i rails sqlite3-ruby ZenTest rspec cucumber factory_girl |
1 | echo "export AUTOFEATURE=true" >> ~/.profile |
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
…you might want to install the following:
1 | git clone git://github.com/lvv/git-prompt.git && echo ". ~/git-prompt/git-prompt.sh" >> ~/.profile |
1 | sudo gem i test_notifier && echo "require 'test_notifier/autotest'" >> ~/.autotest |
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 |
I spent most of last week at work improving our build process, so I thought I’d share with you, and my future self, how I accomplished this.
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.
