Andrew Binstock says:

Ever-dependable O'Reilly just released Ruby Programming Language, which is without a doubt the definitive Ruby reference. Not only is it co-authored by Yukihiro "Matz" Matusmoto, the inventor of Ruby, but it is superbly well edited, so that every page is full of useful information presented clearly. And at more than 400 pages, that's a lot of information. Couple this book with The Ruby Cookbook, which I reviewed on this blog, and you have probably the best 1-2 combination for learning and using Ruby.

I haven't seen the book myself, but I trust Andrew's judgment. I certainly agree on the value of The Ruby Cookbook.

Ruby 1.9, which involves a number of significant upgrades, is now available. This is development code, probably not ready for use in upcoming sprints / development cyclese, but I will be downloading it if for no other reason than to experiment with its Fibers implementation.

From SapphireSteel, the makers of IronRuby, comes the first peek at an IronRuby visual design surface.

Kurt Schrader wonders if he's the first person to hit a point in a Rails app where he wonders if he's "finally hit the point where the cost of maintaining our code in Ruby is higher than the savings by writing it in Ruby in the first place?"

He says that:

• He misses the refactoring tools of IDEA, and
• Although it may have taken longer to reach, he feels he's on "the same old curve to all of the standard problems you run into when programming a webapp in any language."

Of course, he's not the first person to see such problems. As I write about in a forthcoming column in SD Times, basically as soon as you start getting into professional-level complexity in Ruby, you start seeing that it's no silver bullet. A great language, yes, but not a silver bullet.

Rails, too, is a very nice framework / DSL, but has huge shortcomings -- contorting it to work with the naming not-quite-conventions of legacy databases is enough to make me consider it a "new projects only" tool.

Of course, refactoring IDEs have not been around for very long and it's undoubtedly the case that people are striving to build refactoring Ruby IDEs. The challenge is making refactorings bullet-proof in a language with a dynamic type system. You can't have a "press the button" refactoring that works 95% of the time. This is a mistake that even today's refactoring IDEs make: the "review these changes" dialog they pop up. They're about as useful as "Are you sure you want to delete that?" in file dialogs. No one actually considers the question, they just hit "OK" and see if it breaks.

John Lam details the first public availability of IronRuby. Couple reasons why I'm interested in this:

• It's Ruby
• It's the CLR
• It's a second data point for how to code for the DLR

I don't think I'm going to be able to resist the temptation to write a compiler for the DLR. I know I should resist, but I spend so many cycles thinking about programming languages and the DLR seems to have so much promise to language implementors.

Argh, I can't believe I have such a busy week in front of me.

The Ruby language contains the built-in module ObjectSpace, which provides programmatic access to the entire world of living objects. For instance, in Ruby you can write:

ObjectSpace::each_object(Class) do |c|
  p c if c < Test::Unit::TestCase
end

which will iterate over every instance of Class in the system and do something (in this case, print it out if it is a subclass of TestCase).

John Lam has mentioned to me that ObjectSpace is a particular challenge to IronRuby, as the obvious way to implement ObjectSpace is to hook into the garbage collector, which is not something that is allowed in the world of the CLR. Or in the world of the JVM, as Ola Bini discusses in this interesting post. Implementing ObjectSpace on the managed platforms (using WeakReferences) involves a huge performance hit (Bini talks of measuring several dozen percentage points worth of penalty). He additionally shows some code that works around the obvious ObjectSpace use-case.

Scott Hanselman weighed in on the Ruby buzz, saying that no language is all things to all people at all times.  I agree, but think that there are a couple things about Ruby that don't require us to get into language design philosophies. Let me quickly state that these things are not unique to Ruby, but may take the appearance of The Mansion of Bliss to those with backgrounds in more statically-defined languages. ("The Mansion of Bliss" was, I learned on my flight to Panama last night, a phrase used in the early 19th century to mean "tits.")

The first thing that I like about Ruby is that it has an interactive console / REPL loop. For instance, let's say you're trying to divvy up a bunch of data into bins, but don't know the exact cut you want. With Ruby, you can instantiate a database connection, retrieve this table's data, that table's data, apply this filter, that filter, etc., interactively. Of course you can do this with a static language, but every time you make a step of progress, you have to recompile, start the system, retrieve the data, stitch up the joins, and then check to see if your new filter moves you a step forward (which is the much-to-be-admired test-driven way, but sometimes keeping that line green takes a lot of time off the clock). Or, I imagine, you could do it in an interactive SQL Explorer, if your SQL is better than mine.

The other thing I quite like about Ruby is that while everything's an object, there's an implicit receiver. So if you have:

puts 'Hello, world!'

alone in a file or alone in the console, you can do without the likes of:

public static void main(String[] args) { ... }

and, y'know, that's just nice. Object-orientation is the Mansion of Bliss, to be sure, but sometimes there's something to be said for a block of imperative code.

Further, after 10 years trying to remember what combination of decorators with which to read a file, there's something awfully blissful about File.Open("foo.txt"), much less File.open(http://www.knowing.net), which you do for the price of require 'open-uri'

It does make me pine, though, for two other things that it could have:

What if every line of code you ever wrote were available, perhaps organized in some form of browser?

What if as you worked in that interactive shell, you could just shut down the system and return to it later, having the exact objects, in all their complex state, restored to their former glory?

I suppose that such capabilities are impossible or someone would surely have implemented them by now.

I'm dying because I've just had a long talk with two of Microsoft's heavy hitters on the Dynamic Languages Runtime (DLR) team and have much to discuss, yet I am in a frenzy preparing for a business trip and cannot yet take the time to do the discussion any kind of justice.

The single-most important quote, I think, was the statement that "no one will take [our implementations] seriously until we can run-- / We aren't done until we can run--" [Django | Rails]. That was contrasted with important libraries that were heavily dependent themselves upon C-based libraries (Zope, in particular). It was also contrasted with libraries that rely on unusual language quirks or implementation details; the touchpoint on that was Ruby's ... shoot, I thought Lam said "objectspaces" but I don't see that in the standard library ... maybe he said "ObjectSpaces-like ability to traverse the entire in-memory object graph" (Anyone know what lib that would be?) ... Anyway, the point was that this was an example of something that would be very difficult to implement within the constraints of the CLR.

I'll update this entry when I can report in more detail...

Because I use primary_key_prefix_type = :table_name this did the trick for me. Basically, I just set up a hash mapping primary key column names ("InvoiceID" and the like) to the name of the appropriate controller ("invoice_admin"). When outputting a column, if the name of the column is contained in that hash, output a link. All I had to do was write a script to generate the hash and a template for the show.rhtml and Bob was my uncle...

# Methods added to this helper will be available to all templates in the application.

module ApplicationHelper

    #lazy initializer for mapping between the names of FK fields and the appropriate controller

    #:return: => nil

    def initialize_identity_columns

        @identityColumns = { 

           'InvoiceID' =>  'invoice_admin' 

           # ... etc ... 

        } 

    end

    #called within show.rhtml (probably) ala 

    # <% for column in LineItem.content_columns %>

    # <%= show_column_with_auto_hyperlink(@line_item, column) %>

    #<% end %>

    #:return: => String

    #:arg: currentObj => ActiveRecord::Base

    #:arg: column => ActiveRecord::ConnectionAdapters::Column

    def show_column_with_auto_hyperlink(currentObj, column)

      if @identityColumns == nil

        initialize_identity_columns()

      end

      html = "<p><b>#{column.human_name}:</b> #{currentObj.send(column.name)}&nbsp;"

      optionalLink = nil     

      if @identityColumns[column.name] != nil 

          html += link_to("Show", { :controller => @identityColumns[column.name], :action => "show", :id => currentObj.send(column.name) })

      end

      html += "</p>"

      return html

    end

end

I'll be listening to this podcast ASAP.

That Microsoft was going to increase support for dynamic languages is no surprise: they've been talking about that since (at least) PDC '03 and various hires and initiatives have clearly been in the works. I haven't seen the DLR yet, but my big question is: what version / runtime / patch level of the CLR  and libraries becomes the lowest-common denominator for Silverlight (i.e., cross-platform, in the browser)? Because for better or worse, that becomes the platform for dynamic languages in the .NET world.

I am surprised by the IronRuby announcement (and officially bestow the He-Man Programming Award to John Lam). I really thought we were going to see some form of Ruby#:Ruby::C#:Java. Although I'm happy (Ruby is now my #1 administrative programming language), I was actually hoping to see a new language. Ruby's a fine language, but it doesn't have a good story for concurrence, it has a boring model of XML (unlike VB), it has some unattractive Perl-isms. Most importantly, I think MS does a good job when they have the flexibility to evolve the language and, simultaneously, can devote the resources to developing the compilers, libraries, and toolsets.

Scott Guthrie just announced IronRuby! Yeehaw!!!!!!

--

Silverlight binding; demoing on Mac

--

Dynamic Language Runtime announced

--

"Shipping later this week" (I'm sure he means shipping a beta / CTP)

--

Uses Ruby naming scheme when programming .NET libraries (weird. Not sure I like that.)

--

"Switch the console into Python mode, Ruby mode, VB mode" (he means something called "Dynamic VB")

--

www.silverlight.net is the commmunity site

(No sign of DLR / IronRuby / IronPython / Dynamic VB on that site as far as I can see)

--

"Componentize dispatching code, code generation, that sort of thing that compiler vendors do" ... namechecks to Hugunin and Lam ... we shipped this morning the DLR source code" on Codeplex ...

(http://www.codeplex.com/Project/ProjectDirectory.aspx?ProjectSearchText=dynamic%20language%20runtime ? )

I know that sounds like a some kind of Bayesian spam-evader, but apparently Edward Herrmann, a programmer at Colgate-Palmolive, and colleagues hacked their Wii controller to send messages to their Ruby On Rails application, which drove their SAP system (film after the jump). What a geek-tastic transcendance of normal categories.

Thanks to Anthony Beecher for the tip!

My long-time favorite Java editor JetBrains/IntelliJ IDEA has added a Ruby plug-in that supports Rails. My initial reaction is that the vitally important quality of code completion is well below that of both Ruby In Steel and Komodo. Don't be too excited by the presence of the Analyze and Refactor menus either -- they're non-functional (or at least I couldn't get them to work).

The little "ruby" icon beside 'def HeloWorld' navigates to the view for the action -- that's pretty slick. You can generate Rails entities (controllers, etc.) via right-click context menus and you can Rake from within IDEA.

My quick feeling is that the plug-in, while welcome, seems to fall well short of the functionality in Komodo and Ruby In Steel much less the full array of functionality available in IDEA (or even ReSharper).

I wonder if anyone else is working on a Ruby IDE.

It's been a good couple weeks for Ruby IDEs. First, Ruby In Steel was released. Pretty much simultaneously, ActiveState releasedKomodo 4 with support for Ruby.

Komodo is a significantly "weightier" IDE and Ruby is just one of the many languages it supports. It is, I suppose, more akin to Visual Studio itself than to Ruby In Steel, which adds Ruby support to Visual Studio.

I still have much more head-to-head comparison to doing, but I wanted to point out a clear "win" for Komodo: the Ruby shell shown in the bottom pane here is graphical, allowing for a significantly easier cut-and-paste experience than the IRB-in-a-DOS-Box approach:

P.S. What the heck is "IDE_GeneticAlgorithm"? Well, a while back there was a flurry of posts about "the best" customized color schemes for programmers. I thought it would be funny to write a distributed genetic algorithm that "bred" color schemes and evolved them on the Web. The problem is the age-old challenge of creating a decent traversal through colorspace (that isn't along the gray axis). What's a way to encode color in a single number such that like values have like colors?

Here's the Ruby In Steel editing / debugging experience. Intellisense works dynamically -- as soon as you define a function, it becomes available to Intellisense. The debugging experience seems to be the standard VS one (that is, pretty darned good).

REPL functionality is provided by IRB in a console window: not ideal, but convenient. There's quick access to Rails, Rake, and Gems (see the second screenshot).

The install silently guessed wrong on my Ruby install location, which caused my very, very first "puts 2+2" to fail, but it was easy enough to guess that the issue could be fixed under Tools | Options...

So far, so good: more to come as experiences develop. I look forward to putting this head-to-head against Komodo.

Hard on the heels of Ruby In Steel's debut, Komodo 4 was released today. This new version supports Ruby and RoR. via Binstock on Software.

Ruby programmers using Windows should definitely give this a look; this is very high on my "IDEs to look out for" list. It should be noted that this is not a CLR / .NET-based Ruby; it's a plug-in to Visual Studio (Standard Edition and above; unfortunately, VS Express users are out of luck) that targets the standard Ruby interpreter.

Although Scite has it's charms (like loading in a fraction of a second), VS is definitely a superior environment for extended development.

Tim O'Reilly posts his always-intriguing quarterly analysis of the tech book sector.

Joe Gregorio interprets the 53% growth in sales of Ruby-based books as evidence that there is no "next Java" or "next framework." I'm sympathetic with his thesis, but I'm not sure that 53% growth counts as any kind of failure...

I don't do a lot of database work, I believe in rendering unto the DBA that which is the DBA's. But ya got's to pay the bills, so I've been doing some refactoring work on a database. While flirting with RedGate's SQL Dependency Tracker, I finally figured out how to replace my current Visio install wtih Enterprise Architect Edition and that did a good-enough job for me in terms of reverse- and forward-engineering the database.

The next phase was formatting the initial data. This was in the form of about half-a-dozen text dumps (a few in XML, a few in CSV) fro