Should IronRuby be called NSignificant?

Update:  You’re more than welcome to read my angry rant below.  However, I felt it would be more responsible if I summed up a few points right here at the very beginning:

1. Dynamic languages are awesome for things like web development, scripting, and embedded customization engines for bigger applications.
2. IMO, Ruby is more sought after for its web frameworks, scripting/automation (think Rake), and unit testing frameworks than its potential as an embedded language (unlike Python and Lua).
3. John Lam’s open source Ruby extension, RubyCLR, enabled CRuby to use .NET types pretty effectively.  In other words, I can have a Rails application using .NET code on the server-side if necessary.  Or, I could use rspec to unit test my .NET libraries.  Both could be done while leveraging the existing Ruby implementation and .NET Framework.
4. When John Lam started work on IronRuby, RubyCLR was left to a community that let it fall by the wayside.  In the meantime, IronRuby has not been nearly as impressive as IronPython.  There, I said it.

Now, feel free to read the original rant below.

 

Harsh, right?  I think so.  But, it is time I voice my concerns about the Microsoft’s adaption of the Ruby language.  My intent is to put it all out there, and see how the community feels.  At the end of the day, my opinion is my own.  However, the voice of the community could cause change – of my opinion or otherwise.

What’s beef?

Let me start by saying that I am a .NET developer.  I have specialized in Microsoft technologies over my eleven year career thus far.  In addition to being a member of our local .NET user group, TriNUG, I am also a member of the local Ruby user group Raleigh.rb.  I do not speak for these organizations, but I wanted to point out my involvement with both technical communities.

In addition, my background is web-heavy with a few years of desktop development in there as well.  That is to say that Rails was my introduction to the Ruby language.  From the perspective of a web developer that dug Javascript before Prototype, JQuery and MooTools, Rails whet my appetite for more Ruby-like development in my paying job.  I was amongst the early .NET developers that thought, “Wow, it would be great if we could use a language like Ruby with the CLR!”

In my excitement, I went out and learned about great projects like RubyCLR, John Lam’s old Ruby/CLR bridge, and Ruby.NET, the ruby compiler started by Queensland University of Technology. 

Both projects had great merit.  The former allows a developer to call .NET assemblies and use .NET types from Ruby (and vice-versa though painful), while the latter aimed to be a full implementation of the Ruby language atop the CLR.

I think those two projects could have adequately fulfilled my dream.  More on that later.

Back to my beef.  My beef is that Microsoft killed at least one of these projects.

First, they brilliantly (sans sarcasm) hired John Lam, the developer of RubyCLR.  That was an excellent decision on Microsoft’s behalf.  Initially, I hoped John Lam would continue his work on RubyCLR or a RubyCLR-like project with Microsoft’s resources.  Unfortunately, that was not in their plans.  Instead, IronRuby was started and RubyCLR died.

Secondly, the Ruby.NET project went seemingly inactive (though Open Source) after IronRuby started gaining steam.  It now seems to be stuck at version 0.9 which was working with Ruby 1.8.2.

My beef is that these are two projects the .NET community needs.  IronRuby will become more necessary as Microsoft convince us of such.  But, IronRuby is seemingly being developed at the expense of two very good projects.

Why RubyCLR and Ruby.NET over IronRuby?

Let’s talk web.  As a web developer, my opinion is that dynamic languages are better suited for the web than static languages.  In fact, I may be alone in this, I assert Classic ASP with ActiveScripting fits the web development paradigm better than ASP.NET (not including MVC).  My assertion is based on the ability to make a change and instantly review it by refreshing the page.  This rapid feedback cycle is key to making web development most productive.

Fans of ASP.NET and static languages could make a strong argument for performance.  Simply put, dynamic languages do not perform as well as static languages.  However, this point is less poignant when talking about the web.  Dynamic languages are “good enough” for web development.  In fact, bottlenecks in web applications are usually discovered at the point of disk i/o or data access. 

Wouldn’t it be great if we could optimize our disk i/o and data access code with a static language, but use a dynamic language like Ruby for the bulk of our web applications?  Well, RubyCLR enabled that!  If we focus on unidirectional communication be Ruby and .NET – that is Ruby code calling .NET assemblies, we’ll see that RubyCLR is the bees knees!  Imagine doing your web development in Rails while being able to call .NET assemblies for things like disk i/o (I can’t imagine replacing Ruby’s ActiveRecord with a .NET ORM).

On the flipside, Ruby.NET was in the process of enabling developers that know and love Ruby to use the .NET Framework and all its libraries in a statically typed manner.  This means, not only can I call .NET assemblies from Ruby, but I could write .NET assemblies in Ruby.  How awesome is that? (don’t answer)

I believe Microsoft’s most underestimated contribution to developing in Ruby will be easing Rails deployment on IIS.  That is the key piece to the puzzle and the metaphoric “milkshake that would bring all the boys to the yard.”

If you don’t have something nice to say…

I’ll end by saying a few good things about IronRuby and Microsoft.  As a developer that uses Microsoft’s technologies, I continue to believe that Microsoft will (a) make mistakes and adjust to correct them or (b) continue to be an agent of change that brings the rest of us into the light.

With that said, IronRuby, IronPython, and the DLR are bringing capabilities to .NET development that either didn’t exist before or were a pain in the neck to implement.  I haven’t really wrapped my head around doing web development with IronRuby, yet.  I hope the experience will be as pleasant as doing web development with Ruby.  But, the ability to add scripting to a desktop application utilizing IronPython or IronRuby is very nice.

Now, it’s your turn

I can go on and on about this topic.  Those that have had this conversation with me in-person can attest to that.  But, I’m really interested in how the community feels.  What’s up?

Advertisement

Not really a Fan, but still kind of Groovy

Fan is a very young programming language with some promise.  The features of the language are more pragmatic than theoretical.  This means, Fan, like Python and Ruby, should allow you to be productive in a concise manner.  The syntax of Fan left a lot to be desired.  It is not the prettiest language, but hopefully, syntactic sugar will be added in the future to facilitate Fan’s adoption.The killer feature that Fan promises to deliver is the interoperability with both the Java Virtual Machine and the .NET Runtime.  Currently, one or the other are required to compile Fan source code.  However, Fan currently does not offer much in terms of interoperability with Java and/or any of the CLR languages.  That is disappointing for now, but the language is extremely young.  Powerful features like that take time.

While a more developed Fan will find its niche audience of developers, I wonder about the true utility of such a language.  The JVM already has the well-known scriptingly awesome language known as Groovy.  I do not qualify as a Java developer, but I hold Groovy in high regard because of its performance, language features, and *gulp* use of the JVM.  Java reservations aside, Groovy is a language I look forward to learning.

.NET is not absent of nice scripting languages either.  Boo is one such language, noted for its Python-like syntax. Oh, and did I mention IronPython?  It is also noted for its Python-like syntax, but .NET-like performance.  Perhaps, the most awaited .NET language is IronRuby, a dynamic language with the features of ruby and the power of the .NET Framework.  It is going to be great.

There is one other .NET language that I think deserves mention.  It is called Nemerle.  Nemerle is a static language, much like C#.  However, Nemerle implemented features like type inference long before the release of C# 3.0.  Since the latest release of C#, Nemerles advantages have become less pronounced.  But, it still differentiates itself from C# with features like Macros that allow you to customize the syntax of Nemerle (think domain specific language).

Nemerle is a pretty mature language.  It has some integration with Visual Studio 2005.  Also, the Nemerle compiler is written in Nemerle.  That could be a sign of a pretty usable language.

Nemerle is open-source.  I don’t know if it is actively developed today.  However, I recently came across a blog post that sums up some of the features of Nemerle.  That post was the inspiration for this post actually.  Onur went as far as to call Nemerle “C# glorified.”  I’m not sure I agree with that.

However, I believe Groovy is definitely “Java glorified.”   Maybe Nemerle is a little Groovy.

BDD in .NET the way the big kids are doing it

This is an introductory article about using test/unit and test/spec for behavior driven development (BDD) in .NET.

Target audience:

This article is for you if:
1. You are a programmer/developer that uses Microsoft’s .NET Framework
2. You are interested in doing behavior driven development
3. You realize that while .NET has some nice up and coming BDD Frameworks, they still lag behind test/spec and rspec in features and usability.

Assumptions:

This article assumes that the target platform is Windows XP or greater (or lesser, depending on your experiences with Vista). These steps were not tested on Mono (by me), nor did I test on any OS not previously mentioned. I also assume that you are familiar with Ruby and gems. Also, I assume that you are comfortable with changing environment variables within Windows, which may require elevated privileges.

Required software/tools:

1. Ruby programming language
2. DiffUtils
3. RubyCLR (gem)
4. test/spec (gem)
5. zentest (gem)

Installation:

Download the One-Click Installer for Ruby from here. Double-click the executable and follow the wizard. Installation is a breeze with the One-Click Installer.

Second, download the DiffUtils from here. I suggest you download the installer instead of the zipped binaries. I tried the binaries initially, but found a missing dependency (try figuring that out). After downloading the installer, run it and remember the installation path for later use.

To complete the installation, we need to add the installation path to the PATH environment variable. We can do this by hitting the Left Windows key + Page Break. Select the “Advance” tab and click on the “Environment Variables” button. Select the variable named Path in the System Variables list. Click the “Edit” button under the list to bring up the edit dialog. Append a semi-colon and the installation path to the end of the “Variable Value” text box. BEFORE you exit out of the dialogs, click the “New…” button under the User Variables list. Create a variable named “HOME” and set its value to your user directory that has your “My Documents” folder e.g. “C:\Documents And Settings\Curtis”. Press the “Ok” buttons to exit all of the dialogs, and reboot your computer. The last step is very important, so try not to skip it.

Now that we have Ruby and DiffUtils installed, we can install the requisite ruby gems. Installation of the gems is straight-forward. At the command prompt, use a variation of the following command to install each gem:

gem install [gem name] --include-dependencies

I suggest you add the –include-dependencies flag to the gem commands in order to save a few prompts. Once the gems are installed, you’re all set. You don’t need me.

Usage:

I’ll add a few notes about how to use your new setup. This is where all your hard work pays off.

First, create a new C# Class Library solution in Visual Studio. I suggest you change the output directory to “../bin” in order to have MSBuild output your assembly to a “bin” directory in the root path of the solution.

Open your text editor and create a new file called “.autotest” in the root path of your solution. Note: This may be difficult to accomplish in Notepad since the filename is essentially an extension in Windows. I suggest using Notepad++ or Scite (installed with the one-click Ruby installer) instead.

This file is really just a Ruby source file used by the ZenTest gem. Copy the following code into the file and save it:

class Autotest
  #This method tells autotest to run all of the Ruby source files in the 'test'
  #directory whenever a file changes; namely a test file.
  def tests_for_file(filename)
    return Dir["/test/**/*.rb"]
  end
end

#This block tells autotest to run any file in the 'test' folder that starts with
#'test_' and ends with 'rb' whenever a 'dll' file changes in the 'bin' directory
Autotest.add_hook :initialize do |at|
  at.add_mapping(/^bin.*\/.*dll$/) do |filename, _|
    puts "This file changed: " + filename
    at.files_matching(/^test.*\/test_.*rb$/)
  end
end

This assumes the only .rb files in the solution’s path will be files intended to test the .NET assembly that is being created.

Next, create a new file in your text editor. Call it “test_mydotnetlib.rb” or something cheesier. But, be sure to prefix it with “test_” and save it into a folder called “test” under your solution’s path. The following steps will detail how to actually create a file to test your code.

All test files will require a few standard declarations in order to work properly:

require 'rubyclr'
require 'test/unit'
require 'test/spec'

include Test::Unit

#includes the .NET assembly intended for testing
reference_file 'C:\Dotnet\src\MySolution\bin\MyCustomLibrary.dll'

There are two points to note about the above line: First, the whole path to the output of your class library project should be specified. Secondly, this line points to a ‘bin’ directory located under the Solution’s path. This isn’t the default path of output for Visual Studio, so if you skipped the step above where I suggested you change the output path of your class library project, now is the time to correct that.

Now, we can begin writing our actual tests. Add the following to your test file and save it:

describe "MyCustomLibrary" do
  before(:each) do
    @speaker = MyCustomLibrary::Speaker.new
  end

  it "should say hello" do
    @speaker.sayHello.should.equal 'hello'
  end
end

At this point, we can start up Autotest. Open a command window and change directories to the root of your Visual Studio solution. Type “.autotest” and hit enter. Autotest will run the test that you just saved. It should show that you have 1 failed test. That’s great!

Create a Speaker class in your .NET project. Implement the sayHello method so that it returns the string “hello”. Build your project, and watch Autotest re-test your code again. This time the test should pass.

Sweet! This is just the tip of the iceberg of what can be done with RubyCLR.

This solution works because of the creativity and hard work of some great developers. I’m going to run the credits before the end, just to make sure you stick around to acknowledge their efforts:

Credits:
John Lam (RubyCLR) and the person or people continuing to develop it
Christian Neukirchen (test/spec)
Nathaniel Talbott (test/unit) and the person or people that continue to develop it
ZenSpider (ZenTest)
Paul Eggert (DiffUtils)
Venkat Subramaniam (for his inspiring presentation on DNRTV.com)
And, of course, Matz and the rest of the Ruby team

I also appreciate the efforts of all others involved whether directly or indirectly.

Now, back to the code…

Wuby = Ruby Web Framework for Classic ASP Developers

Remember the days when you could just create a page for your web site that contained valid HTML and some server-side stuff between the <% %> symbols?  PHPers know what I’m talking about.  They still do it, except they use those other ASP-like symbols.  Now, ASP.NET allows us to do a little of that, but its frowned upon as poor coding practices if you use it too much.  Ruby on Rails allows it too, but only in the context of the views.  Since the views are display only, there is a pretty good balance of server-side code and browser-speak (HTML, Css, and JS).

We ASP.NETers can appreciate the MVC framework as well as the ASP.NET way of creating web applications.  But, oh how I feel nostalgic when I want to create a very simple page that needs a little bit of server-side treatment to work.  Between you and me, I sometimes revert back to classic ASP for this very reason.  Shh, don’t tell anyone.

Well, the good news is Wuby!  Wuby has finally been released into the wild for your enjoyment.  Wuby is a web server and hash-based database engine that allows web developers to use Ruby on the server-side to create sites using the <% %> delimiters.  Yay for us!

Here’s a link: www.rubyology.com/wuby.zip

Check Rubyology.com for screencasts on how to use this framework.  Alternatively, you can check back here as I plan to create a screencast myself in the near future.

The Significance of Prototype.js and REST

One of my boys sent me a link to an article on Joelonsoftware.com entitled “Strategy Letter VI.” It is a great article that compares the strategy that IBM employed when they were trying to keep Lotus 1-2-3 relevant in the 80s to the challenge web-based software companies faced with keeping their applications relevant today.

Usually, I take Joel’s words with a grain of salt because (ironically) I have interpreted many of his public writings and actions as desperate attempts to stay relevant. However, this article offers true value to the reader. He offered knowledgeable insight that got me thinking about two things that have swept across the web and propelled web development forward by leaps and bounds: Prototype.js and REST architecture.

Prototype.js is the Godfather of Javascript Libraries (RIP James Brown). A large percent of the leading js libraries such as Mochikit, Scriptaculous, Mootools, JQuery, and YUI are either dependent on Prototype or HEAVILY influenced by it. Sam Stephenson, the creator of Prototype, showed the rest of the web that js didn’t have to be stressful. His library gave us an extremely helpful API for easily forging our own js solutions. But, this plain text file also showed the intermediate web developer how to take js and OOP it up; that is, use object-oriented techniques to deliver some advanced cross browser functionality. It was functional and educational at the same time – two attributes stressed out web junkies love.

Similarly, non-groundbreaking but super important, is the emergent REST architecture. REST is an architecture for interfacing with web applications. This increases the interoperability of your web app with other web apps out in the real world. It gives Amazon’s web services a predictable interface so that I, the burned out programmer, can think-less by reusing their chunks of functionality in a very familiar way.

REST does not require you to share your application with other web apps. In fact, the benefits of REST can be reaped by internal applications as well. REST can be a great approach to simplifying any application and making it more maintainable by using a well known architecture. Think of it as REST and relaxation.

Both of these technologies are inherent in Ruby on Rails, the hot young web framework that has all the ladies talking. So, it is no surprise that the management buzzword of the year, Web 2.0, is usually reserved for some RoR application that offers a fairly trivial service, but tons of ways of interacting with it.

In fact, when I think about what Prototype and REST did for AJAX calls, it becomes hard to imagine the term Web 2.0 without them. However, be mindful that the term Web 2.0 only means your web application is relevant today.

Fix for serving static files with Mongrel using Camping

Last night, at our Ruby hack night, I had some assistance debugging a known issue with Why’s magic framework, Camping. Ok, let me be honest; Nathaniel fixed the issue while I sat and observed.

The issue occurs when you try to serve static content like images and style sheets using Mongrel. You can use Why’s example to spin up a controller to handle the static content using X-SendFile like this:


module Camping::Controllers
  class Static < R '/static/(.+)'
    MIME_TYPES = {'.css' => 'text/css', '.js' => 'text/javascript', '.jpg' => 'image/jpeg'}
    PATH = File.expand_path(File.dirname(__FILE__))
    def get(path)
      @headers['Content-Type'] = MIME_TYPES[path[/\.\w+$/, 0]] || "text/plain"
      unless path.include? ".." # prevent directory traversal attacks
        @headers['X-Sendfile'] = "#{PATH}/static/#{path}"
      else
        @status = "403"
        "403 - Invalid path"
      end
    end
  end
end


This code should allow Mongrel to serve any file under the “static” directory. This works as expected on non-Win32 platforms.

To correct this issue on Windows, a change has to be made to the Camping handler in Mongrel. Here is a diff that depicts the fix:


--- camping.rb.orig 2007-10-04 20:36:01.000000000 -0400
+++ camping.rb 2007-10-04 21:31:42.000000000 -0400
@@ -38,7 +38,7 @@
@@file_only_methods = ["GET","HEAD"]



def initialize(klass)
- @files = Mongrel::DirHandler.new("/",false)
+ @files = Mongrel::DirHandler.new(File.dirname(klass.instance_eval{@script}),false)
@guard = Mutex.new
@klass = klass
end


This change will impact the “path” parameter that is passed into the controller. Subsequently, the controller should be modified to take advantage of this change:


module Camping::Controllers
  class Static < R '/static/(.+)'
    MIME_TYPES = {'.css' => 'text/css', '.js' => 'text/javascript', '.jpg' => 'image/jpeg'}
    def get(path)
      @headers['Content-Type'] = MIME_TYPES[path[/\.\w+$/, 0]] || "text/plain"
      unless path.include? ".." # prevent directory traversal attacks
        @headers['X-Sendfile'] = path
      else
        @status = "403"
        "403 - Invalid path"
      end
    end
  end
end


As you may have guessed, this will break the contract with non-Win32 platforms, which is why I have not suggested this change to the Mongrel group. But, I hope you find it useful.