Launching External Tools from Eclipse

Eclipse has an option for starting any external process you want, displaying the
output of the process in the Console view. By configuring our processes as external
tools, we can launch them, stop them, and monitor their output from the IDE
without having to go to the command line, and without having to retype the same
arguments every time.

External tools can be a good way of controlling servers such as memcached, nginx,
sphinx, or mongrel cluster, but they can be used for any process you would start
from a command line.

As an example, we will explain how you could use External Tools for launching
a Mongrel server with some extra parameters. It is not really necessary to use an
external process for this, since the Rails Shell view will let us pass any extra options
that we want to a Mongrel server. This example is just provided for educational
purposes, having the advantage that you don’t need to install any extra servers to try
how to use the External Tools option.

To create a new External Tool, you have to open the Run menu and then select the
‘External Tools’ submenu and then again the External Tools option. This will bring
up a dialog for managing your external tools. From here you can add any new
processes or change the settings for the existing ones.

In a fresh Eclipse configuration you shouldn’t have any external tools, so the first
step will be creating one. We want to launch a process (program), so select the icon
Program in the left pane of the dialog, and either right-click on it to bring up the
context menu, or select directly the New Launch Configuration icon at this dialog’s
toolbar.

Now we have to enter the information about the process we want to launch. First
you have to provide a meaningful name for this External Tool. In our example we
can use mongrel with timeout. Next, we have to enter the location of the program
to launch. When we start a Mongrel server, what we are really doing is launching a
Ruby script, so we will have to select the location of our Ruby interpreter here.

For the working directory, you can select the path of any of your projects or, even
better, you can use the Variables… button. Eclipse provides some useful variables
you can use. In our case, we will select the project_loc variable, which is the absolute
path to the currently selected project. By using a variable instead of the path of a
given project, you will be able to launch the same External Tool for different projects
without having to write a different configuration for each of them.

Finally, we have to provide the necessary arguments for the process we are going
to launch. In the case of Mongrel we will first need to specify the full path to the
mongrel_rails Ruby script (which will typically be in your Ruby bin directory),
and then the selected command line for starting the server. In my example I will be
using the following arguments:

\dev\ruby186\bin\mongrel_rails start –port 3100 -o 1

We are telling mongrel to start a server at port 3100 with a timeout of 1 second. By
using the Servers View you would not be able to set the timeout (which anyway is
OK for practically every development scenario).

After setting these properties, you can select the Apply button and then Run, at the
bottom of the dialog box. Mongrel will start, presenting the output in the Console
view as if you had started it from the Servers view. If there are any errors, you can
check them in that view and correct the configuration accordingly. If you want to
stop your process, use the stop button in the Console view.

Once you have configured the process, you can directly launch it from the Run
menu under the External Tools option. The name of your process will appear as
one more option of this menu. You can also use the External Tools icon at the
workbench toolbar.

For configuring Mongrel, we only need to set the options at the main tab of the
External Tools dialog, but if you are going to use the External Tools dialog for
configuring other processes, you might find interesting the options tabs we didn’t
use in our example.

These tabs have options for logging the output to a file, hiding the console output,
setting the character encoding for your process, setting environment variables, or
even refreshing your workspace after the process finishes (in case it might create files
or modify the existing files).

Rails Console

Coming from a background of languages like C++ or Java, one of the things I first
loved about Ruby/Rails was the IRB-based console in which I could execute code
and have immediate results. After two years working with Rails, that’s still one of
my favorite features of this development environment, allowing me to develop much
faster by being able to try things on the fl y in a trial-and-error manner.

Fortunately RadRails provides an integrated Rails console so we can launch it
without going to the command line. To open the Rails console, there is an icon
representing a system shell on the workbench toolbar. That icon will open by
default the console in the development environment. Should you want to start in
production or test environments, you can click on the arrow by that icon and select
the appropriate environment.

The Rails console works exactly as from the command line with one single limitation.
RadRails internally uses the Console view of Eclipse for displaying the Rails console,
and the Eclipse console uses the arrow keys for moving the cursor up and down the
output area, so you cannot move through the console’s command history with the up
and down arrow keys.

At the time of writing this chapter, there are plans to make the cursors work as
expected in this view, so it’s likely they will behave like that by the time you are
reading it. If not, you can get similar results; you can select the previous commands
and just copy and paste.

Rails Plugins View

You know how it is with software development these days. For almost anything you
want to do, there is someone who has programmed it already (well, at least to some
extent). One of the tasks when starting a new project is choosing which components
to incorporate. In Rails, one of the most common ways of adding software
components to a project is by using plugins.

Plugins are a perfect way both for adding functionality from external sources to
our projects and for encapsulating our own libraries either for internal reuse or for
making them freely available.

RadRails provides a convenient way of installing/removing plugins to your project.
The Rails Plugins view is displayed by default in the Rails perspective, so you don’t
need to explicitly open it from the Window menu.

When you are installing or removing a plugin, you will be doing it over an existing
Rails project, so there must be a way of telling RadRails to which project you will
be applying the changes. By default, the currently selected project in the Ruby
Explorer will be the target of the changes. To be sure, you can see a label above the
list displaying Current Rails Project: with the name of your project. If you want to
change the project, you can either select a new one in the Ruby Explorer, or you can
use the Select Rails Project icon in this view’s toolbar, as displayed in the above
screenshot. This icon is a nice addition incorporated in Rails 1.0 and will be present
in all the RadRails views in which the changes are applied locally to a single project.

If after selecting your project you cannot see a list of plugin names in this view,
you can use the refresh icon in the toolbar. When you refresh the list, RadRails will
connect to a public plugin repository to compose the list, so allow some seconds until
the list is ready.

At the time of writing this book, there was no way of telling RadRails to add new
plugin sources or to manually install a plugin from an unlisted location. For any of
these operations you will have to go to a command line and perform them manually,
or use the convenient Rails Shell view, explained later in the chapter.

After the plugin list is loaded, you will see the name of the plugin and when
available the rating, license, and home URL. You can use the column headings to
change the sort order of the list. If there is a home URL, you can click on it and the
web page for the plugin will be loaded in the internal browser.

If after examining this information you want to install the plugin, you can use
the Install icon in this view’s toolbar, or you can directly select Install from the
context menu.

When you install a plugin from the command line, you can choose two options
related to the subversion repository management: use externals or perform a
check-out via subversion. If you want to apply any of these options, they can be
toggled from the pull-down menu (the big down arrow in the upper right of
the view).

Using externals will tell subversion to download the code locally, but every time you
check for updates the original plugin repository will be checked. By using checkout,
you will force the plugin install script to install via subversion even if the repository
is accessible directly via HTTP. Take into account that you will need to have
subversion installed in your system if you want to use any of these options.

So far we have been working in the list displayed when opening this view, but if
you look again you will see there are two tabs available in the view: install and
manage. Under manage you will see the list of plugins installed in your project. If
you want to remove any of these plugins, just select it and use the remove icon in the
view’s toolbar.

RubyGems View

Ruby gems are another way of encapsulating software components to reuse
them in different projects. Actually, Rails itself is packaged as a set of several
gems (ActiveRecord, ActionPack, ActionMailer, ActiveResource, ActiveSupport,
and Rails).

Unlike plugins, gems can be used in a Rails project or in a stand-alone Ruby script.
Besides, the gem package manager allows easy installation and management of the
installed gems.

The main disadvantages of gems over plugins are that installing gems typically
requires access as an administrator of the machine, and that they are shared by all
the rails projects in that machine. On the other hand, since Rails plugins are installed
individually in each project, deploying to a different server is easier since everything
is auto-contained. Also, if you want to modify the code of the plugin, you can do so
without interfering with any other projects.

In a real-life Rails application, part of the functionality will be provided by Rails
plugins and part of the functionality will be provided by Ruby gems. This is specially
the case for components that require binary libraries, such as database drivers,
for example.

The first thing you will see when opening the RubyGems view is the list of gems
installed in your system, their versions, and a short description. Don’t worry if you
see in this list several versions of the same gem; that’s perfectly normal. In the same
machine you can have different versions of a gem, like for example Rails 1.2.3 and
Rails 2.0.1. If you cannot see the list of installed gems, you can hit the refresh icon in
this view, also available from the context menu, to force RadRails to update the view.

We will now explain the different icons in this view’s toolbar from left to right. The
first icon, represented with a brush, is the Cleanup Gems option. If you select it, you
will remove the older versions of the gems in your local installation. Only the most
recent version of every gem will be kept. Generally speaking, it’s not a bad idea to
clean up your gems once in a while, but before doing it make sure you don’t have
any application depending on an old version of any gems.

The next icon is the Update All Gems one. As you can imagine, when you select
this option, the gem package manager will check if there are any new versions of
any of your gems, installing them if appropriate. This method is safe since it will not
remove any older versions. It will also try to update rubygems itself, unless you
are running on JRuby, since at this moment doing so tends to break JRuby’s
rubygems installation.

The next icon, labeled Update Gem, will also check for new versions but only for
the currently selected gem. If you don’t select any gem in the view, this icon will
appear disabled.

The next option is refresh, and we already know it’s used for reloading the gem
list information from the local installation. The next option is Remove and it’s no
surprise that using it will remove the currently selected gem for the selected version.
As with the Update Gem option, if no gem is selected this icon will be disabled.

The la st of the options is Install. When you select this icon, a new dialog will pop up.
The first field is the Source URL for the gem you want to install. Gems are usually
hosted at http://rubyforge.org, so you won’t probably need to change the
default location. If for any reason your gem source URL is a different one, you can
enter it in the box and hit the Refresh button.

Refreshing the list of gems can take some seconds, so be patient until RadRails gets
all the information needed. After a while, you will see the list of gems available for
installing. You can filter the results by typing in the Gem Name text box. If you type,
for example, acts_as you will see the list of available gems starting with those letters.

Even if you type the exact name of the gem, you still have to select it from the gem
list so RadRails can refresh the drop-down list with the version numbers. Only after
selecting the name and version number of the gem, can you proceed to install the
gem. If you try to install without selecting a version number, you will receive an
error message and nothing will be installed.

Apart from the output at the Console view, you can that check the gem was properly
installed by checking the RubyGems view, where the installed gem should now
be listed.

Rake Tasks

As happens with many other development environments, in a Rails application
it is usual to launch different processes for manipulating files (cleaning log files,
for example), initializing data, and so on. Usually these processes have dependencies
between them and it’s useful to have a tool to deal with these issues in a
comfortable way.

In languages like C or JAVA this is done with popular tools such as make, ant or
maven. In Ruby, we have the rake utility, which from Ruby 1.9 and in some older
distributions too is packaged together with the standard Ruby installation. If Rake is
not installed in your system, you can install it directly like any other gem.

Rake can launch different processes while keeping track of the dependencies
between them. In Rake, every process you want to launch is called a ‘task’. One
advantage of Rake is that, unlike other platforms in which you need to learn a new
language, the code you use for writing your tasks is pure Ruby code.

It’s no surprise then that Rails provides a smooth integration with Rake tasks and
that in a common Rails application, many management operations are achieved via
such tasks. Out of the box, Rails provides tasks for cleaning up files—logs, cache
or temp files—, for interacting with the database—creating the schema, moving
between migrations, rolling back, etc.—for launching our test suite, or for generating
documentation and managing Rails versions.

Apart from the built-in tasks, it’s common to create different tasks in our projects
for initializing data, running scheduled jobs, getting data from external systems,
interacting with processes such as indexers or cache systems, or any other operations
we need to launch automatically in the background of our application.

If you just want to run a Rake task without any parameters, you can directly
right-click on the name of your project in the Ruby Explorer and select Rake from
the context menu. A menu displaying the available tasks will open for you to select
the one you want to launch.

If you want to pass any parameters to your tasks, or if you want to see their
descriptions, RadRails provides a specialized view. The Rake Tasks view is available
by default in the Rails perspective, so you don’t need to do anything special to open
it, just select its tab to display it.

The drop-down list of this view will show the available tasks for the currently
selected project in the Ruby Explorer view. If you change the selection to a different
project, the task list should reload. If it doesn’t, you can use the refresh icon in the
toolbar. Also, as in the Plugins view, you can use the Select Ruby Project icon
instead of selecting your project from the Ruby Explorer.

When yo u select any of the tasks in the list, a short description will appear in the
big text box at the right of this view. If you want to launch that task without any
parameters, just click on the Go button. If you want to pass any parameters, you can
use the long text box at the top of the view. For example, in the screenshot above, I’m
passing the parameter VERSION=12.

The most common use scenario is launching a task with or without parameters,
but sometimes you want to launch a task and pass extra parameters to the rake
command itself. For example, suppose you want to pass the argument describe
to rake, so it will output in the console the full description of the tasks instead of
executing them, or maybe the trace option for debugging purposes. In those cases,
you must use not this view but the Rails Shell view, explained later in this chapter.

Generators View

There is no question about Rails being a framework oriented to programmer’s
productivity. You can get results much faster than with other tools of the trade. The
reasons for this productivity boost are many.

In the first place we have the underlying language Ruby, which allows us to get
the same things done by writing less code. Not only is the language important, but
the Rails framework itself has been designed with a strong understanding of which
things are important for most web applications, making these tasks very easy to
develop and leaving the least frequently used features out of the framework.

Finally, another interesting productivity mechanism in Rails comes from the code
generators. By using generators you can create code templates for many common
operations. Out of the box, Rails provides generators for controllers, models,
migrations, plugin skeletons, scaffolds, and resources.

You can generate the basic code with these generators and then adapt it to meet your
needs. Even if the generated code is fairly basic and it requires modifications, it’s a
very fast way of setting up your application. As we saw when creating our example
application, by using generators you can get a full maintenance application in a few
minutes. And that already includes the (empty) methods for testing your models
and controllers.

If you don’t like the default generators, you can create your own totally customized
generator for your coding requirements. The good thing about generators is that you
only need to write them once and then, by packaging them as plugins, you can use
them in any other project.

RadRails supports the use of code generators through the Generators view, which is
available directly in the default Rails perspective.

By now this kind of layout should be familiar already. First make sure you have
selected the project in which you want to run the generator, and hit the refresh icon
if the generators list doesn’t get updated.

Now you can select the generator you want to execute from the drop-down list or
you can just type the name in. If you want to pass any parameters to the generator,
you can do so in the long text bar at the top of the view. Notice that this is a
drop-down list, and if you unfold it you will see the history of recently used
parameters, which can be handy sometimes.

The script for running generators accepts some arguments from the command line.
In this view there are some checkboxes so when you select them those arguments
will be passed to the generator. In this way you can just pretend to run the generator
so you can see the output without actually changing anything, skip existing files
without prompting you, or use subversion to persist the changes, for example.