My Ruby Development Environment

Recently, Stephen O’Grady asked what is included in my Ruby tool set so I will attempt to answer that question, and describe why I choose these toolsI speak of this in the present tense because the set of tools I use is always evolving. Everyday I choose afresh the tools I am going to use..

Text Editor/IDE

A text editor or IDE is probably a software developers most important tool. I use the One True IDE (say that with lots of reverb for full effect), by which I mean Emacs, of course. (Several of my current and former colleagues are now throwing things at me, or wishing they were near enough to do so. Hi Charlie.) I choose Emacs as my primary development environment for a number of reasons, some technical some personal.

The most important reason I choose Emacs is that as ruby development environments go Emacs, with ruby-mode and the other related modes, is the most powerful and complete set of tools for doing Ruby development. I disagree with Mr. O’Grady’s characterization of the Emacs extensions as “simple”. They are, in fact, quite sophisticated, though certainly not the most sophisticated set I have seen. That fact, combined with the wide availability of other high quality Emacs modes for editing XML, HTML, CSS and Javascript it makes an extremely powerful and general purpose development environmentIf you are setting up an environment for doing web development Darren Brierton has done a great writeup..

Emacs is not without it’s downsides, however. The primary disadvantage of Emacs is that the learning curve is quite steep. The non-graphical nature of Emacs is a bit intimidating for many people and it does mean that it is difficult to be productive in Emacs until you have learned quite a bit. Graphical IDEs make it relatively easy to be somewhat productive right away and more powerful uses of the tool can be learned more slowly.

Personally, I find this learn slowly approach a disadvantage of graphical IDEs. Because the allow you to learn slowly the make you less productive over a longer period of time. For example, keyboard short-cuts radically improve your productivity. However, because I can do any action with the mouse in a graphical IDE I rarely learn the short-cuts. In Emacs you learn the short-cuts because you are either typing the command long-hand (in which case it informs you that you could have just typed “C-c l”, or whatever) or you are typing the short-cut so learning the short-cut feels more practical.

Another important factor in my decision to use Emacs is that none of the other Ruby IDEs support IRB. It is impossible to over value IRB. I consider any development environment that does not support IRB to be shamefully incomplete. So incomplete, in fact, that I will generally not use it beyond the point that I realize it does not support one of the most important tool in a rubyist’s arsenal.

IRB

IRB is basically just an interactive shell on top of the normal Ruby interpreter. IRB is a bit like try ruby! except with your application code available. It can be used integrated with your IDE if you are lucky enough to use an IDE that supports it or you can use it stand alone. Programmers who new to dynamic languages tend to not utilize IRB very much because it is a foreign concept, but it is so powerful that no rubyist should be with out it.

IRB allows you to greatly improve your productivity by continuously performing micro-spikes. These micro-spikes can be used to understand the behavior of third party (or your own) objects or to test potential approaches to solving a problem. IRB can also be extremely useful when testing because you can directly manipulate the objects in your application. For example, if you have some bug that only shows up when your application is in a state that is difficult, or time consuming, to get to you can often use IRB to directly manipulate your application into that state, by-passing the complicated set of actions it would take to achieve that state manually.

Browser

Most of the software I am currently developing is web based. When doing web application development your choice of browser is almost as important as your choice of editor/IDE. I use Firefox exclusively, except when I am testing for browser compatibility. The primary advantage of Firefox, in my mind, is the wide availability of extensions that support web development. I should point out, that until my current job my focus has been on the server side of web applications so my knowledge of client side (browser) programming is somewhat more limited, but I am learning fast. I use the following extensions to Firefox

  • Web Developer

    An absolutely brilliant set of tools that allow inspection and manipulation of web pages in the browser. Of particular use to me lately is the CSS editor which allows you edit and apply CSS rules to the current web page without reloading it.

  • View Rendered Source Chart

    A replacement for the standard view source functionality what provides nicer styling and visually groups the members of a block. It is especially nice when doing Rails development because it collapses the large block of generated JavaScript that Rails inserts at the beginning of forms. This make the forms much easier to read.

  • JavaScript Console

    While not technically an extension (I think) this is a valuable tool that presents the errors generated by the JavaScript on a page and allows for ad-hoc bits of JavaScript to be executed on demand.

  • JavaScript Debugger

    I have heard that this does not work well on Firefox 1.5 but I have not had need of it since I upgraded so I cannot comment from experience. Theoretically, it allows relatively easy debugging of the JavaScript on a web page.

Conclusion

So there you have it. Those combined with the standard Unix tools (ie, find, grep, less, sed, curl, etc) are what I use to do Ruby (and Rails) development. I also find my self writing quite a few small scripts in Ruby if I need some behavior that is fairly simple but too complex to achieve with just one line in bash.

Hope this is what you were looking for Steve.

{Update: Fixed link to Steve’s post}

3 thoughts on “My Ruby Development Environment

  1. Interesting point of view. I myself have always considered editting a separate task from “spiking” or “irb”. That’s why I use screen. If you use screen, then you can edit in one virtual console and run irb in another, and test in another. I don’t see what the advantage of emacs is over anybody who knows screen. That is not to say you shouldn’t use emacs… only that the particular advantage you claim, of being able to run irb, doesn’t really make sense to me. Have you tried screen?

  2. Rudi, I have not tried screen (though I am aware of it’s existence). I did not mean to imply that IRB is not useful unless integrated. It certainly is. However, being able to edit code and then load it into IRB (by the file, class or method) with a single keystroke is worth something.

Comments are closed.