A Ruby IDE written in Ruby
Despite the fact I’ve been developing it for a couple of years, Ruber is still currently in alpha state. This is mostly my fault, because I have sometimes spent months working very little on it. However, I have been using it for its own development for a long time and I think it works quite well.
Here’s a short list of shortcomings of the current version. A list of planned changes to be made and features to be added is availlable here
Although the KDE ruby bindings are very well done and complete, they do have a drawback: if your ruby code causes the C++ side to fail somehow, you get a long backtrace containing only references to the internals of the bindings, which are completely useless if you are not a korundum developer.
What this means is that these crashes are quite difficult to fix. I’m going to ask help to the KDE bindings developer about this, but I’ve waited to have the source online before doing that so that they can have a look at the program, in case they need it.
Note that, at least with my workflow, these crashes never caused data loss. I only had to start Ruber again.
Every now and then, when starting Ruber, you can get an exception about a to_sym
called on nil. I haven’t as yet figured out what’s causing this, expecially since
starting Ruber again doesn’t cause the issue anymore. Since this is only an inconvenience,
I’ve postponed investigating to after I’ve released the first alpha version of Ruber.
Currently, the Ruber API is not completely stable. In particular, there are two issues on my TODO list which most likely will require incompatible API changes that may affect plugin developers.
At the moment, the only plugins included with Ruber are the ones I needed most
to develop it. This means, for example, that there isn’t a Test::Unit plugin,
because I use RSpec for testing. My TODO list contains a large number of plugins,
but before starting working on them, I wanted to finish some core functionality.
This, of course, shouldn’t stop anyone needing the missing plugins to start developing them. I only ask that anyone intentioned to write, and release to the public, a plugin which is already on the TODO list contact me before starting, so that we can exchange ideas and maybe have the plugin included with future releases of Ruber
Unfortunately, Ruber is not completly documented. Originally, I’d decided to write all documentation before the first public release, but, seeing the large amount of time documentation was taking, I changed my mind.
At the moment, Ruber code may be divided in three categories according to the documentation status: