Post by Peter Cooper on January 29th, 2007

Ruby In Steel Released: Ruby + Visual Studio 2005 == Powerful Ruby IDE

Rubyinsteel-1

SapphireSteel Software has today announced the release of "Ruby In Steel", a powerful Ruby and Ruby on Rails IDE add-on for Microsoft Visual Studio 2005. I'm not a MSVS 2005 user, but from what I can tell, this is very powerful stuff. It integrates Ruby at the deepest levels with Visual Studio, including full Intellisense support, documentation integration, debugging (and even a 'one-click Rails debugger'), variable watching, code snippets, macros, etc. There are lots of great screenshots to check out.

SapphireSteel have a limited-time offer of $199 for the Ruby In Steel Developer package against the usual price tag of $249, although you can also evaluate it for free for 30 days. There is also a free "Personal Edition" that lacks indentation, variable watching, Intellisense, and other features, while still providing a taste of the full suite.

17 Responses to “Ruby In Steel Released: Ruby + Visual Studio 2005 == Powerful Ruby IDE”

  1. #1
    duffman Says:

    lol paying 249$ for this.
    I will just use eclipse with the ruby plug-in or with the free Jruby.

  2. #2
    Peter Cooper Says:

    I'm not on the platform myself, but I do know of people who would pay this for a solid MSVS-backed environment for their language. It's worth it if you get the value from it like with, say, Photoshop.

  3. #3
    jc Says:

    The killer feature I see here is the debugger. VS.NET has a slick debugging interface, and if could use it to step through my Rails web application, consider me thrilled. Finally an application worth booting up Parallels for. Cant wait to install it when I get home.

  4. #4
    cies Says:

    duffman: indeed! what a joke!

    i'm a linux user myself, and therefor i prefer some free(dom) editor for rails. this way you get everything, with full customizability and source included for free...

    then i have some friends that use macs. they pay 130 for OSX and 30 textmate... on my planet 200-250 is a lot for a plugin! talking about "great screenshots", i think those textmate screenshots are way more interesting.

    finally there is my feeling that autocompletion (intellisense?) can never work for a statically typed language. how do you know what type is returned?

  5. #5
    Russ Brooks Says:

    VS 2005's IntelliSense is the best in the biz - far better than the manual Ctrl-Space method in Eclipse. Eclipse's is more of a simple template inserter rather than IntelliSense because it doesn't do inline documentation, intelligent tooltips and type sensing, or right-click "Go to Definition", "Go to Reference", etc.) IntelliSense is worth its weight in gold as far as a time-saving and learning device goes, and Visual Studio's is excellent. Absolutely indispensable.

    Also indispensable is Visual Studio's debugger - also the best I've ever used. Once you feel it work in real-time, you can't believe how you ever lived without it. Since this plug-in interfaces with that, then a certain amount of cost is justified [maybe not $250, but a certain amount].

    I agree that $249 is steep. For PHP development at work, I use a VS plug-in called VS.PHP. It's only $99 and appears to do just about everything this Ruby plug-in does: IntelliSense, type and function awareness, inline docs, etc. This plug-in has paid for itself 100 times over in the amount of time it saves the entire team. I'm sure this Ruby plug-in does the same, if not more, but the manufacturer may want to reassess the price.

    It's good to see a soup-to-nuts Ruby plug-in for VS.

  6. #6
    Doug Bromley Says:

    I can't see this being a major hit considering the huge popularity of other editors and IDE's for Ruby development. TextMate, Eclipse, etc.

    A bit too late and a bit too expensive.

  7. #7
    Peter Cooper Says:

    finally there is my feeling that autocompletion (intellisense?) can never work for a statically typed language. how do you know what type is returned?

    But Ruby isn't a statically typed language, so that criticism isn't valid for this product.

    Anyway, keep up with the comments. I am sure the guys who wrote this tool are reading and your comments may help them with their decisions in the future.

  8. #8
    Huw Collingbourne Says:

    Thanks for the piece about Ruby In Steel. I'd like to correct one misapprehension from a couple of the comments left earlier, however.

    It is not our aim to try to persuade users of TextMate, Eclipse, JRuby or other editors and IDEs to 'convert' to Ruby In Steel. There are already many millions of Visual Studio users who don't want to use any other IDE, and Ruby In Steel aims to provide a professional quality development environment for those users.

    That said, we also have a free edition, Ruby In Steel Personal, which compares well, I think, with other IDEs - for example, it has code colouring and folding for Ruby and RHTML, it has built-in project management, a visual debugger with breakpoints, watch windows, call stack window, trace into/out/over, plus an interactive run and debug console and lots more. I don't think that's too bad for a free product. Naturally, it doesn't have some of the special things (such as hover+drill-down watch variables, the Ruby Code Explorer, the fast 'Cylon' debugger and analytical IntelliSense). Still, we have to make a living too ;-)

    best wishes
    Huw
    SapphireSteel Software

  9. #9
    Noah Says:

    Wow, the features on this look impressive. I really, really wish we could get some real codesense in Textmate. The debugging support sounds great, too, though implementing something like that in the Textmate bundle shouldn't be too hard.

    My main gripe with this is -- why so much visual clutter? I realize this is not SapphireSteel's fault, but rather Microsoft's... but why would someone want such a horrendously cluttered editor? It's fine on a 30" screen, but on a 13" laptop that seems like it would be unusable. I much prefer Textmate's -- or vim's or emacs' -- nearly UI-less design, where you can hunt through a menu for rarely-used commands but quickly memorize keyboard shortcuts for frequently used ones.

    That said, Ruby In Steel looks great; nice job. I'd probably use it if I used Windows. Perhaps it can provide some motivation to make the Textmate Ruby/Rails bundles even more impressive.

    -Noah

  10. #10
    Steve R Says:

    Get the power of intellisense and the simplicity and power of intellij with this plugin. Again Jetbrains is leader in providing a powerful tool for editing code. http://www.jetbrains.net/confluence/display/RUBYDEV/Ruby+Plugin+0.1+Release+Notes

    And with the next release you'll get to see a more integrated experience with this plugin as opposed to the "plugin" you typically expeirnce with platforms like eclipse.

  11. #11
    Huw Collingbourne Says:

    A couple more points to clarify...

    First, the point about the 'impossibility' of doing IntelliSense for Ruby. Let me admit it, this has been the biggest single challenge we have faced in the entire development process of Ruby In Steel. There are certain times when a type literally cannot be inferred. On the other hand, in many cases, the fact that the Ruby interpreter can derive class information demonstrates that, much of the time, that information is there in the code, albeit not at all obvious ;-)

    Ruby In Steel does 'real' IntelliSense: not 'code completion', not drop-down lists of methods arrange alphabetically or by their presence in the current code file. It implements a background 'inference engine' (virtually a Ruby interpreter that analyses code without actually running it). This is constantly in the process of analysing and reanalysing code as it is being written. It takes into accont classes, modules and inheritence, visibility by scope (including not only private and public but also nested modules and mixins), distinguishes between class, instance and singleton methods, shows completion lists for methods, variables, parameters and keywords etc. etc.

    If you create a public method in the main object (that is, enter a 'free standing' method) it even binds this into Ruby's base object (as Ruby itself does) and all descendent classes. We believe this to be the most complete implementation of true IntelliSense for Ruby - but we still aren't satisfied. In particular, while we implement IntelliSense for Rails (both 'standard' and user-defined classes), Rails introduces many very difficult problems and our solutions to these are far ffrom foolproof (many Rails code files don't even specify which other files they 'require'). So, we are continuing to add to and refine our IntelliSense until we can deal with even the most bizarre Ruby and Rails circumstances...

    On the subject of the cluttered-looking Visual Studio workspace. The reason for this is, quite simply, the sheer number of features in that IDE. It really is vast. Very powerful but massive. The good news is that, if you want to make the editor full-screen and hide all the other tools and windows, you can do so by pressing some keys. The end result in shown in this screenshot...

    http://sapphiresteel.com/IMG/png/editing_fullscreen.png

    best wishes

    Huw

  12. #12
    jc Says:

    Thanks for the info Huw! I was curious as to how the ruby intellisense worked.

    I'm sure you guys know exactly what you need, though to me it sounds like it could use a combination approach of using the dynamic type (via the inference engine) mapped to the rdoc for ruby on rails so it can pick up all the "injected" methods that would be impossible to parse out from the rb files. And probably some xml files to fill in the gaps.

    Also.. maybe check into porting the Textmate snippets over. DrNic's already done the hard work. http://drnicwilliams.com/2006/11/06/post-halloween-radrails-trick-all-textmate-snippets-available/

    Now THAT would be a killer feature.

  13. #13
    Huw Collingbourne Says:

    We do actually make quite a bit of use of RDoc. If you hover the mouse over a method or class, you see its RDoc in a tooltip. Optionally, you can put 'type assertions' into comments over a method too. This is useful if the arguments to and return type from a method are indeterminate. e.g. This method gives no clue as to its argument or return types:

    def aMethod( a, b, c )
    doSomethingTo(a, b, c )
    end

    When no class types can be inferred, we default to Object. So, if someone calls a method like the one above, we display a parameter info tooltip saying:

    aMethod(a:Object, b:Object, c:Object) : Object

    This shows that a, b and c are Object instances and the method returns an Object. That's clearly not very satisfactory but, without more information, it is impossible to make any more precise deductions. The programmer has the option in a case like this to add a block of assertions (that is, 'expected' object types) in a comment over the method, like this:

    #:return: => Array
    #:arg: a => String
    #:arg: b => MyObject
    #:arg: c => Array
    def aMethod( a, b, c )
    doSomethingTo(a, b, c )
    end

    Now, the IntelliSense has more to go on. When you enter a call to that method, our parameter info tooltip now shows:

    aMethod(a:String, b:MyObject, c:Array) : Array

    Much of the time, we can infer types without having to resort to type assertions but there are some cases where this is just not possible.

    You can automate the creation type assertion blocks by pressing two hashes (##) over a method name or using fill-in-the-gap snippets. We supply a small library of Ruby snippets but I haven't got around to doing 'translations' of all the Textmate ones yet. We do have a Ruby snippet editor, though (to let you write snippets without any hand-coding) so maybe some enthusiastic user may be tempted to help out with Textmate snippet translations...?

    best wishes

    Huw

  14. #14
    Dejan Dimic Says:

    This become is X superior then Y story, again. We can’t agree about such things. There is no better or worse IDE. There is one that suits our personality and way of doing things and the other one. I personally know people that don’t like chocolate, chicken and prefer IE over FF. I can’t find any real logical explanation for such standings and this diversity is one of nature beauty that makes life a grater adventure.

    Form me as somebody who spends a lot of time on XP and Ubuntu programming in C++, C# and ruby (and naturally rails) the most important thing is freedom of choice.

    My life flows throughout eclipse and VS2005 and for some customers even in VS 6.0.

    Two years back I have played with IronPython that has VS Add-in to. It was very interesting, specially debugging.

    I will try IronRuby free version, naturally, but I am so much hooked on svn and eclipse integration that probably it will be a short trip throughout IronRuby roads.

    It would be nice to see a SharpDevelop (http://www.icsharpcode.net/OpenSource/SD/ ) add-in for Ruby since that is one of my favorites.

    Finally, the price. It is just a meter of perspective. Serbia is country where 250 euros is average monthly pay. Nevertheless, tools are investment as much as an investment in knowledge and should be treated likevice.

    The only resource that you can not regain is time – invest it carefully.

  15. #15
    cies Says:

    (i reread my post: ofcourse i meant dynamically in stead of statically)

    huw, i think i own you an apology. it looks like you implemented the intellisense in the best possible way i can imagine.

    congrats..

    next thing (in my dreams) is to have hooks in (on of the) ruby interpreter itself so it can facilitate all kinds of fancy editor stuff (highlighting, intellisense like features, etc).

  16. #16
    Huw Collingbourne Says:

    Hi cies. No need for the apology ;-) . Believe me, one of the biggest problems we have when trying to explain our IntelliSense is getting across the difference between the system we've developed (and are continuing to develop) and much simpler 'code completion' lists in some other editors.

    When you see a screenshot, any dropdown list of method names looks pretty much like any other. It's only when you use an editor/IDE in earnest that you realise that much of what passes for IntelliSense bears no relationship to the real meaning of the code. Getting a truly analytical IntelliSense system for a language like Ruby is really, really hard work.

    In my view, you should be able to rely upon an IntelliSense system to give you useful information (Is this object in scope? Has this method been mixed in? etc.), not just to show lists of method names that may or may not be relevant.

    best wishes

    Huw

  17. #17
    Sergio Says:

    I'm glad Huw came here to clear out things. It's not uncommon to see developers without VisualStudio experience thinking it's your average IDE or too cluttered or confusing. VS is customizable ad nauseum, from keybindings to color preferences to external tools to custom plugins.
    VS's debugging experience is something that you have to try to realize you'll never want anything less after that. IntelliSense kick's the llama's a$$, 'nuff said.
    Another thing non-VS developers may not be aware is that people have been paying close attention to Ruby In Steel since the betas became available. I still have the beta in my VS and I'm trying to convince the Chief Executive Wife to allow me to acquire the RTM version soon :)
    (I'm not affiliated to any company which products I mentioned)