Rails

There are 57 posts filed in Rails (this is page 5 of 6).

Avoiding the SUDO police with Capistrano

Turns out that by default, Capistrano is using sudo to delete everything (can I stop for a second and say that, for once, this is a bad default! At least on a shared hosted environment).

So anyway, I take a look at capistrano/recipes/standard.rb in my gems directory, and finds that there are the following 2 lines (conveniently placed at the beginning of the file):

set :use_sudo, true
set(:run_method) { use_sudo ? :sudo : :run }

Not a problem, let’s try to set :use_sudo to false in my confi/deploy.rb

set :use_sudo, false

Just to be sure, let’s do a dry run and check out what are the commands issued in this case to check that sudo is not called:

cap -P cleanup

Uh Ho again!

*** no old releases to clean up

:( oops. not only are my old releases not gone, but now I can’t rerun the script. Forutunately, the previous call to Capistrano had a log and I was able to log in to my host and run that massive rm -rf by hand.

Now, I was able to deploy an other release, and check whether setting :use_sudo works or not.

* executing “rm -rf …

It works! Phew!

And now I can rest assured that the SUDO police won’t take me away :)

Note: turns out “cap -P cleanup” is not too useful because it needs to get the list of what’s available on the server.

Debugging in Rails

In my own experience, here’s what a good debugger needs:

  1. breakpoints (with conditions even better)
  2. stepping
  3. object list (locals, globals, objects)
  4. watches
  5. resetting the current instructions
  6. modify objects

4, 5 or 6 are really icing on the cake, but help separate the men from the boys. Although these can help save a tremendous amount of time, especially when a certain situation is really hard to reproduce because you get several shot at reproducing and fixing the problem in real time.

Best examples I have used (and abused): Steve Jasick’s “The Debugger”, and yes, Visual C++ (before the .net and C# days). Eclipse and the java debugger is not too bad either.

So why is this such an unpopular subject with such a limited support with Ruby and with Rails? Enquiring mind wants to know!

Best usable option in practice: breakpoint.

It meets requirements 1 through 3. Hey, you can even do conditional breakpoints!

Just insert a “breakpoint” call where you want to stop, and then run you app normally.

While you do that, run script/breakpointer to catch the breakpoint (assumes you are on the same machine).

There, you can check out any ruby expression like you can do in irb.

Some useful commands to help find out what’s there:

  • local_variables (list of all your local variables (whether initialized yet or no)
  • instance_variables (same as self, without the values)
  • caller (shows the stack trace, not terribly readable but the information is there)
  • methods (list all the method of the class you stopped in)

Just need to tough it up and get on with it till someone comes up with a better alternative. This brings back some fond memories of long ago when command line debuggers where all the rage, and all you had too. But I’m starting to date myself here so I’ll just shut up and set a few breakpoints to relax.

A word to the wise: do me a favor, and remove your breakpoints before deploying on your production environment. This could save you from ridicule. Not that this ever happened to me, right!

I’m very hopeful that the guys are RadRails will find a solution to get it to work faster and more reliably.

RadRails 0.6.1 released

a few bug fixes and a few improvemens. Especially switching between view and controller now suppors RHTML, RXML and RJS.

If you’ve created test scripts with 0.6, be sure to delete the scripts and regenerate them. See details on radais.org

Download 0.6.1

I recommand you use the site update as I explained in the 0.6 announcement. This greatly simplifies updates.

Adding the Ruby builder to your RadRails project

To add the ruby validator to your project, open your .project file (at the root of your project).

And add:

<buildCommand>
    <name>org.rubypeople.rdt.core.rubybuilder</name>
    <arguments>
    </arguments>
</buildCommand>

inside the

element.

Refresh eclipse, and wait for it to rebuild everything. Then your files will be checked for correct ruby syntax everytime you save. You will see a little marker everytime there is an error.

Here’s the complete .project file:

<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
    <name>typo</name>
    <comment></comment>
    <projects>
    </projects>
    <buildSpec>
            <buildCommand>
                    <name>org.rubypeople.rdt.core.rubybuilder</name>
                    <arguments>
                    </arguments>
            </buildCommand>
    </buildSpec>
    <natures>
            <nature>org.radrails.rails.ui.railsnature</nature>
    </natures>
</projectDescription>

Switching the nature of a project to RadRails

Open your .project file, and replace the element with

<natures>
    <nature>org.radrails.rails.ui.railsnature</nature>
</natures>

Here’s how my project looks like

<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
    <name>typo</name>
    <comment></comment>
    <projects>
    </projects>
    <buildSpec>
    </buildSpec>
    <natures>
        <nature>org.radrails.rails.ui.railsnature</nature>
    </natures>
</projectDescription>

Then either refresh your project or restart eclipse/RadRails. The Project icons should now have the little decorator with the Rails logo.

RadRails 0.6 released

Kyle just announced the release of RadRails 0.6 (thank you Kyle).

If you are not familiar with RadRails, RadRails is an eclipse based Rails IDE, with syntax checking, testing, WEBrick and LightTPD support, debugging.

Highlights:

  • rhtml editor
  • Keyboard shortcut to switch between the view and its controller (Ctrl+Shift+V)
  • Integrated testing support (Yeahh!)
  • Preliminary LightTPD support

Read the Announcement.

Download

Tonight I upgraded and everything went smoothly using the site updates method (Help Mennu -> Software Updates… -> Find and Install…).

Love the shortcut to switch between view and controller. One of those little things that help a great deal :)

Best practices

glu.ttono.us has posted an excellent summary of his take on Rails best practices.

And I think I need to do some reading, that the second time in as many days that someone mentions Refactoring by Martin Fowler, and this has me intrigued.

My top favorites:

  • testing of course
  • I second Luke. Selenium and Selenium on Rails is a better approach for functional (and user type testing). I’m not saying this should replace it. Use both techniques.
  • DRY (Don’t Repeat Yourself)

Fixture variables not created

Given a fixture contacts.yml which contains:

patrick:
id: 1
name: patrick
email: patrick@tes.com

pre 1.0 solutions:

@contacts[&#8220;patrick&#8221;]  #using hash
@patrick              #using variable

solution 1: 

contacts(:patrick)    #using accessor

solution 2:

@loaded_fixtures[&#8220;contacts&#8221;][&#8220;patrick&#8221;] #direct access (not recommended)

solution 3:

Edit the test/test_helper.rb and set 

  self.use_instantiated_fixtures  = true

this way the fixture variables are created like they used to.

You can get more details from the man himself (Mike Clark’s Weblog).