ActiveBlog

Rails Revisited in Komodo 4.1
by

, April 18, 2007

While the last two major releases of Komodo (3.5 and 4.0) were pushed the state-of-the-art for dynamic language IDEs, I'll be the first to admit that they could have been better when considered more narrowly as Rails IDEs. We shipped...

While the last two major releases of Komodo (3.5 and 4.0) were
pushed the state-of-the-art for dynamic language IDEs,
I'll be the first to admit that they could have been better
when considered more narrowly as Rails IDEs. We shipped a
full-featured but slow Ruby debugger in 3.5, and reasonably complete
code-completion in 4.0. And while some folks said they were
pleased, we knew we could do better, given the time.

So I finally got the time, and can now say we've improved the whole
Rails development a hundred percent or so for version 4.1 (it's
currently in beta as I write this, mid-April 2007, but the new
features I'm talking about here will be released in the next
drop).

In a nutshell here are the main Rails-related features coming down
the pike.

First, the debugger's gone through a complete rewrite. It
uses Kent Sibilev's ruby_debug module on the back-end (the part that
talks to the Ruby interpreter). His module is mostly C code, and
uses a couple of functions added to the Ruby API for version 1.8.3[1]
to greatly speed up interpreter event handling. Most of my
benchmarks showed a speed-up of about 50-60x over the old
debugger. That's an easy factor to relate to. If you tried
to debug Rails apps with the old debugger, and found you had to wait a
minute between hitting the app from your browser and finally hitting a
breakpoint in the controller, the delay is now about a second.

Second, some people accustomed to more heavyweight,
project-oriented IDEs (the ones where you have to choose a
project-type before you can edit a file) were asking where the Rails
support is in Komodo. Good question.

With version 4.1, enhanced Rails support is one click away.
Pull down the menu item for <File|New|New Project From
Template...>, select the Ruby on Rails template, give
your project a home and a name, and Komodo will do much of the
rest. It will run rails in the new directory, and
create a new project populated with a host of useful commands that
deal with database setup, the various generators, as well as run
server
and debug server commands for testing the
application.

The commands all sit on top of a small Rails-oriented library
(written in JavaScript), that should make it easier for third-party
developers to customize, add new commands, and share them with
others.

As an example, the Rails macro library knows how to process the
config/database.yml YAML file. It currently only supports MySQL,
but that can be easily extended as well.

Our eventual goal with the new project-based command system is to
make the command-line obsolete for building Rails apps. While I
could have spent all my time building more commands, and working on a
Rails app to test them out, I had to spend some time on the
code-completion side of Komodo. After adding some more
Rails-awareness to it, Komodo is now doing better completion on model
objects. For example, we use the habitual_readers
app[2] for some of our testing. I created an instance of the
Book object, typed ".", and among the 200 or so names in the
list (Rails sure is deep...), I found author,
title, isbn, and summary).
It's always a tough call whether to cull generic names from a
completion list.

Time to get back to work.

[1]. No one is still using Ruby 1.8.2, right? Or 1.8.3 for that matter, I hope.

[2]. Downloaded from the paper referenced at http://teamaskins.net/archive/2006/11/13/rails_vs_django_a_comparison.

Subscribe to ActiveState Blogs by Email

Share this post: