Ruby in Steel 1.5 Released, Drops IronRuby Support
SapphireSteel Software, the developers of Ruby in Steel have released version 1.5 of their Visual Studio based IDE for Ruby on Rails. Among many improvements, they also dropped support for IronRuby, as Huw Collingbourne from SapphireSteel explains:
Our plans for future development are affected by the possibility that Microsoft may do their own VS environment for IronRuby. Following [IronRuby Program Manager] Jimmy Schementi's blog entry on the subject, the degree of uncertainly that now exists is (to say the least!) not an encouragement to us to continue developing IronRuby support.
Schementi later wrote on Twitter that they "never "announced" IronRuby VS integration; it's just something we'll have to do if no one else does". Apparently, the "majority of [Ruby in Steel] users continue to use the 'standard' version of Ruby (MRI)", writes Huw, so "this does not affect the continued development of our professional Ruby programming environment, Ruby In Steel".
Ruby in Steel is available in two editions: the all-including Developer and the lower-cost Text edition, which has a slower debugger and lacks IntelliSense code-completion (see the feature list for more information).
Ruby in Steel supports the traditional Ruby as well as JRuby. The most prominent features are certainly their own debugger, the intelligent code-completion and its visual designer for rails. The debugger – called Cylon – provides all the features one could expect: conditional breakpoints, breakpoints on exceptions, call stack, watches, the exploration and manipulation of variables. A screenshot tour can be found on the Ruby in Steel website.
InfoQ talked to Huw Collingbourne to learn more about the new release.
Apart from updating the JCylon debugger for JRuby, we have made a large number of small improvements and bug fixes throughout the system. Most of these have been in response to requests from our users and they generally address some of the finer details of the code editor. To be honest, many of these are pretty obscure. A typical example is that prior to version 1.5, the code coloring was incorrect for a function-call inside a string when the closing bracket was placed on a new line. This, and a number of similar bugs, have now been fixed.
Version 1.5 was always intended to be a 'consolidation' release since all the major features – IntelliSense, debugging, the Visual Rails Workbench and so on – were already in place in the previous version. After the release of Ruby In Steel 1.4 there were no compelling reasons rush out a subsequent version until JRuby 1.4 was released towards the end of 2009. JRuby 1.4 is now a very mature platform and, as an added bonus, it has an excellent installer for Windows. When we tried out JRuby 1.4 we were impressed by just how good it was and so we decided that it would be a great opportunity for us to update our JRuby support with the release of Ruby In Steel 1.5.
InfoQ: What are the plans for the future?
Currently we are completely focused on the launch of Ruby In Steel 1.5, so I don't want to make any announcements or to speculate about future versions just yet. We support Ruby 1.9 in all major respects with the exception of debugging. The default Ruby 1.9 debugger itself is still in a process of development and some potentially significant changes may be made in later releases. We decided it would not be a good use of our resources to develop integrated debugging to support what is, in essence, a transitional technology. Instead, what we have done is to implement the Visual Studio 'build configuration' system to enable people to switch between two or more Ruby interpreters when running and debugging a single project. This means the programmer can pick a named configuration such as 'Release' from a combo box in order to run an application with Ruby 1.9, then switch to another configuration named 'Debug' in order to debug using Ruby 1.8 and a third, named 'JRuby', to run and debug with JRuby.
Download a 60 days trial version of Ruby in Steel from SapphireSteel Software and try it yourself.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015