20 Jan 2006
•
Software Development
After finishing my previous post in response to Stephen O’Grady’s ruby tools question it occurred to me that I might be able to shed some light onto the other options that available. While I use Emacs some of the other developers here do not. I will try to give my impression of the couple of other options we have used.
We tried radrails for a while. It was buggy, but you expect that from from product with a version number that is less than one. In the end we decided not to use it because it is not done and even if it where it has some serious limitations. The not doneness that cause the most problem was the inability to create a “server” (RadRails terminology for shortcut/script that starts the Rails application inside the IDE). RadRails creates one for you when you create the project (if you mutter just the right incantations). But if you need to create a new one you are out of luck. Unfortunately, if you import and existing Rails project (like, say, the one you just checked out of source control) RadRails does not create a “server” for you (or at least I did not figure out how to make it do so). This mean that you cannot start a Rails application inside RadRails if the project preexists the RadRails project.
Additionally, I dislike the idea of having an IDE that exclusive to just Rails. It seems far to limiting. We (will) have a non-trivial part of our system which is not a Rails application (it synchronizes data between the legacy system and the Rails application). It would be unfortunate to have two separate, but equal, IDEs for the two parts of this project.
We have settled on Arachno for our windows based developers who like graphical IDEs. It has less direct support for Ruby on Rails than RadRails, but it seems to actually work quite well. The developers who are using it were, most recently, doing C# in Visual Studio and Arachno is similar enough to that experience that they are quite comfortable in it. (I have not actually used it because the Linux version is ancient, by comparison to the windows version.)
My now ex-boss Donald Marino was a strong proponent of TextMate on Mac. I never really played with it or even watched him use it so I cannot comment on it directly but it is the choice of the Cool Kids.
20 Jan 2006
•
Software Development
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](http://www.dzr-web.com/people/darren/projects/emacs-webdev/)..
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}
19 Jan 2006
•
Software Development
Can someone please explain why adding require 'xmlmarkup' to the beginning of application_helper.rb causes the file to not be loaded? Instead you get this error message in the log, ApplicationController: missing default helper path application_helper, as if the file simply did not exist. And, of course, a failure to render any pages that make use of any of the application helper methods, since they are not available.
I strongly suspect that it is related to the auto-loading magic that Rails has but it is not clear to me exactly how it is related. I do know, now, at least, that it is unnecessary to explicitly require this file in order to use Builder::XmlMarkup, but it seems like it should be allowed. After all, requiring the file seems like the most obvious choice if you know Ruby better than Rails. The non-obviousness of this problem combined with the fact that none of the error messages generated specify the actual problem make this problem a bit annoying.
18 Jan 2006
•
Software Development
Google Talk is now connected to the public XMPP networkVia [Phil Wilson](http://philwilson.org/blog/2006/01/google-talk-flips-switch.html), and that is a Good Thing. Now if I can only get my hosting company to provide an XMPP service so that I can could use my real email address. Until then you can contact me via XMPP at peter.e.williams@gmail.com This is _not_ my primary email address. Please do not send email to this address., should you so desire.
17 Jan 2006
•
Software Development
My current job is in downtown DenverDowntown Denver is quite unlike the other parts of the metro area in which I have worked. The Tech Center and Interlocken both feel a little stifled and boring to me. Longmont feels a bit like a small home town, which is cool, but not in a super productive way.. When I got this job I decided that I would use mass transit[RTD](http://rtd-denver.com) is pretty great, except when it is really cold. A few weeks ago I had to wait for an hour in [0 degree weather](http://www.thedenverchannel.com/news/5482123/detail.html) for the bus. for my commute. It only takes a few more minutes that driving and I really appreciate getting that hour of commute time, round trip, back to do something useful.
My first thought was that I could use that time to catch up on my reading. There are a lot of books in my queue and I just do not get the time to read at homeTime to read is one that I did not anticipate losing when we had [kids](http://www.barelyenough.org/apps/gallery/2006/DSCN3657). With 4 month old and a 2 year old there is free time, but it comes in 5-10 minute blocks. That means that if I try to read with my kids around I just don’t make much progress for the time spent.. My second thought was, “Ooh, if I had a e-book reader I could catch up on my feeds on the bus”. I looked around but all the e-book readers are expensive, low resolution and most of them only support proprietary formats. So I gave up on portable feed reading and have just been catching up on my reading.
I thought of this again today because the guys over at Evilsoft pointed out Sony’s new e-book reader, which is at least high resolution. They also noted that aggregation is a potential market for e-book readers. If I were an e-book reader manufacturer the I would definite be providing an aggregator, or at the very least a non-proprietary format that third party aggregators could use. Sony’s e-book reader is still too expensive, it is the price of a budget PC, but I think this e-book thing will happen sooner or later. I, for one, look forward to reading my subscriptions at near print resolution.