Ruby

Ruby Cookbook has interesting scripts. Here is one ported to PowerShell. Useful for generating test data.

You can add | Set-Content test.txt after New-RandomWord to save it to a file. Or create a script like Export-ToSql.

Begin {
 $letters = @{
  v=‘aeiou’
  c=‘bcdfghjklmnprstvwyz’
  ‘ ‘=‘ ‘
 }

 Function New-RandomWord ($s) {
  [char[]]$s |
   ForEach {
    $source = $letters.([string]$_)
    $word += $source[(Get-Random $source.Length)]
   }
   $word
  }
}

Process { if($_) {New-RandomWord $_} }

Cross-language implementation of the MVC meta-pattern - PureMVC. Supported languages:

• ActionScript 2
• ActionScript 3
• C#
• ColdFusion
• haXe
• Java
• Perl
• PHP
• Python
• Ruby

From here:

Microsoft Corp. plans to demonstrate integration Friday between its new Silverlight browser plug-in technology for rich Internet applications and the Ruby on Rails Web framework.

Chris Sells wrote about the book Nobody Knows Shoes. Shoes is a tiny toolkit. For making windowy Ruby programs that run on Mac, Windows, Linux and so on. Download it HERE Trivial Shoes App Shoes.app { button(“Press Me”) { alert(“You pressed me”) } } PowerShell Version . .Shoes Shoes app { button “Press Me” { alert “You pressed […]

I recently got to playing with Ruby, something that some colleagues in Lab49 have been big fans for some time.  I've never been a big fan of scripting languages, but have grown more of an appreciation for functional programming over the past several months and thought I would give it a try.

Ruby is a very smart language, and I can certainly see why it has some appeal.  The "don't repeat yourself" and "defaults over configuration" aspects of the language and its framework are really nice for cranking out simple applications.

ORM and Inference of Properties from database

I am a big fan of the objects that automatically get their properties from the database (a Customer object will automatically be linked with the Customers table when pulled through the ORM).  Things like this make it dirt simple to crank out web projects of moderate size without writing tons of redundant code (as is the case with a classic OO approach, using adapters, abstractions, etc).

Even though this is a nice feature, and great for many projects, I am concerned that this is simply not sufficient for larger enterprise apps.  Very often your app layer and database layer should be different, as one does not always properly map to the other.  I suppose that you could achieve this nicely with views, however for large applications, the lack of abstraction seems a little brittle to me.  At the same time, if you did change something in your database, you'd still have to change your abstraction logic, so maybe this isn't all that bad.

Syntax

The syntax of Ruby is very clean and straight forward.  I like the bare bones structure, nothing more than needed is written.  Reading into it a bit more, I found it interesting that various things can be written in several ways, for example:

while i < 3
   print(i)
end

can also be written

print(i) while i < 3

While conceptually this is nice (the latter "reads" better), it is something I have a really hard time accepting.  Yes it is nice not to have to write things like "end", however, syntactical differences like this (and others, such as the optional parenthesis around method parameters) concern me.  While its great that you can develop your own style, and do what feels comfortable to you, it may be very confusing to other developers.  An argument can be made either way, after call you can do this:

if (i < 3) Console.WriteLine(i);

in C#.  Nothing stops you.  At the end of the day, sloppy code is sloppy code, and its really a matter of having a well trained developer, not a strict language.

Naming Conventions

Here's something that threw me off.  Ruby does a very good job of making names intuitive, however some of their names seem to break their own concepts.  First of all, names like to_s are just sloppy.  If you're making a lanugage thats supposed to be readable, why write cryptic names like this?  Also, whats the deal with properties count and length being synonyms?  Why have both?  It seems relatively dangerous to me to have methods that mean the same thing on objects.  A developer who sees count in one place and length in another may think they are different, something that certainly doesn't help code legibility.

Overall, Ruby has been fun to learn (although I'm still a novice), and I can certainly see its value.  I'm not sure if I agree with some of its "friendly" tendencies -- being able to write whatever you feel and have it probably compile is not necessarily good.  Just because code compiles doesn't mean its good code -- some bugs the compiler may catch now become runtime bugs.  On the other hand, things like the ORM make it very easy to build rich apps with little code, something that .NET still comes up short on (just because designers generate LINQ classes doesn't mean that the code isn't there).  Looking forward to playing more!

Last week I attended the Ruby NYC get-together (Doug blogged about it) - the talks from that night including Luke Melia on Ruby.NET and Tatum’s talk on Erlang are up at MotionBox. Worth a watch if you’re into that sort of thing.

Rails has very nice logging behavior built in; one such feature is that it logs the parameters passed in to every request. That is not so great, however, when one of those parameters is a user’s password. Fortunately, you can use the filter_parameter_logging directive; just add it to controllers/application.rb, like this:

filter_parameter_logging “password”

Now any field that matches ‘password’ will be hidden. You can get further details here.

I spent a bit of time banging my head against the behavior of redirect_to in Rails. The problem was, when redirecting to the same action, e.g. redirect_to(:action=>’foo’), the request parameters of the previous request were being passed through. So if the action had orignally been called with :id=>99, the action was called again after the redirect with the same parameter. This was not what I had expected, and it took a bit of digging to understand why.

It basically comes down to the url_for method in .\lib\actioncontroller\base.rb:457. This has some fairly idiosyncratic logic around when it chooses to preserve options from the previous request, and when it drops them. From the comments:

# When generating a new URL, missing values may be filled in from the current request’s parameters. For example,
# url_for :action => ’some_action’ will retain the current controller, as expected. This behavior extends to
# other parameters, including :controller, :id, and any other parameters that are placed into a Route’s
# path.
# Â
# The URL helpers such as url_for have a limited form of memory: when generating a new URL, they can look for
# missing values in the current request’s parameters. Routes attempts to guess when a value should and should not be
# taken from the defaults. There are a few simple rules on how this is performed:
#
# * If the controller name begins with a slash, no defaults are used: url_for :controller => ‘/home’
# * If the controller changes, the action will default to index unless provided
#
# The final rule is applied while the URL is being generated and is best illustrated by an example. Let us consider the
# route given by map.connect ‘people/:last/:first/:action’, :action => ‘bio’, :controller => ‘people’.
#
# Suppose that the current URL is “people/hh/david/contacts”. Let’s consider a few different cases of URLs which are generated
# from this page.
#
# * url_for :action => ‘bio’ — During the generation of this URL, default values will be used for the first and
# last components, and the action shall change. The generated URL will be, “people/hh/david/bio”.
# * url_for :first => ‘davids-little-brother’ This generates the URL ‘people/hh/davids-little-brother’ — note
# that this URL leaves out the assumed action of ‘bio’.
#
# However, you might ask why the action from the current request, ‘contacts’, isn’t carried over into the new URL. The
# answer has to do with the order in which the parameters appear in the generated path. In a nutshell, since the
# value that appears in the slot for :first is not equal to default value for :first we stop using
# defaults. On it’s own, this rule can account for much of the typical Rails URL behavior.

Just something to bear in mind, because the behavior is not always intuitive.

I have been doing some work getting ruby to work with Active Directory, and I found this free tool handy for seeing what is actually going on with the LDAP server: jxplorer

Huw Collingbourne video blogs his Ruby in Steel IDE for Visual Studio by building a blog application in visual studio using Rails and SqlExpress.

Without a command prompt.

The demo is based on David Heinemeier Hansson’s Blog application in Rails.

The Ruby in Steel IDE supports Rails as well as Scaffold, MySql and Sql Server. Intellisense is under development.

Video of building the blog application

Ruby in Steel IDE for Visual Studio 2005