the blog
Back to -Blog

Gearing up for Rails

The next release of Steel is due shortly
by Dermot Hogan
Sunday 2 July 2006.

I’m just finishing the next release of Steel. We’ve put quite a lot of work into this one – Rails support, mainly. But underlying that is a whole raft of things which we’ll be using in future versions. Underpinning the Rails work is the extensive use of MSBuild. Now, initially, it wasn’t clear to me how you can build a project that uses an interpreter. For example, in a C++ or C# project you take a source file and produce an output file of some sort – you compile it. But Ruby?

So I had a good look at ‘rake’ the make of the Ruby world. And a very nice tool it is too. You specify a series of transformations from an input to an output. The examples I looked at seemed largely to do with extracting documentation from input files, but I can see how you can do much more.

The problem is of course that rake isn’t that useful for Visual Studio. Visual Studio not only uses MSBuild to construct outputs but incorporates MSBuild XML files into the way projects are laid out in the Solution Explorer. Clearly, the way forward is to incorporate rake type transformations into MSBuild and get MSBuild to do what rake does.

For example, in this version of Steel, when you build a project, the syntax of both Ruby files and Rails files is checked (via a rather nice HTML utility called Tidy). Syntax errors are reported back into the Error pane as you would with a C build. In addition, you can run both before build and after build tasks, so that Watir, for example, could be run to do even more checking. I’ll add more tasks as I think of them.

One of the things I really liked about rake was the way you could apply a Ruby script to a set of inputs. I’ve seen one example of something similar to that somewhere using C#, but it’s not really what C# is for – it’s a bit clumsy to compile it and then execute it in an MSBuild task. But with Ruby it’s easy. All you need to do is add a simple script to a MSBuild property and get your MSBuild task to run it. I don’t think I’ll be able to get that into the upcoming release, but it will be there for the next one.

As I mentioned, we’ve put quite a lot of work into incorporating Rails into Visual Studio. We’ve got RHTML/Ruby color coding functioning (the RHTML looks like the HTML you get in Visual Studio and Ruby looks like Ruby. The RHTML also has collapsible outlining. It certainly makes for nicer looking and more maintainable Rails code. On the database side, we support MySQL and SQLServer (with Oracle to come). If you stick with SQL Server you’ll get a better integration with Visual Studio, though I note that MySQL has signed up for the VSIP program now, so we’ll hopefully be able to improve on the MySQL ODBC connection in the future.

Of course, we’ve fixed a few bugs and improved the general Visual Studio ‘look-and-feel’ as I’ve got more familiar with the VS SDK – this will continue as I get round to implementing them. For example, Show All Files now works – pretty useful for seeing all the other stuff in a Rails project that isn’t in the MSBuild XML, such as log files and the like.

After this release, the next big things look like being code completion and the fast debugger. I should be able to link this into Rails debugging as well. From my limited experience of Rails so far, I’d say that’s the one area over anything else that could do with some help. Rails diagnostic messages aren’t just bad – they’re dire.

Bookmark and Share   Keywords:  development
© SapphireSteel Software 2014