I recently wrote about Swirrl's choice of Rails host, Brightbox, on the Swirrl Blog.
You can read what I had to say here.
Wednesday, 12 March 2008
Brightbox Rails Hosting










Please also visit the Swirrl blog
Posted by
Richard Roberts
at
Wednesday, March 12, 2008
0
comments
Thursday, 6 March 2008
Rails on Mac OS X Leopard
We'll get to the instructions for setting up rails on Leopard in a moment, but first a bit of background...
A few days after it was released, I changed over to using Mac OS X 10.5 (Leopard) as my platform for developing rails apps. When I first installed Leopard it took me a little while to figure out the best way to do things, as Leopard comes with lots of rails development features pre-installed.
Recently, after reinstalling my OS, I had to figure some of it out again as I hadn't made enough notes. So this time, I thought I'd document it properly and share it on my blog for the benefit of others (and so I don't forget too!).
As you might remember from this post last year, I'm a fan of using Netbeans for my rails IDE. Since that post, it has come out of beta and is now a fully fledged release (currrently at v6.0.1).
However, I couldn't get its step-through debugger to work with Leopard's installation of rails. I think is is because Netbeans assumes certain relative paths between the ruby interpreter and your gems, which differ in the Leopard standard install.
After being inspired by this post by Robby Russell, I decided to use Macports as my solution. Macports gives you a self contained environment for installing stuff. Everything installed under Macports lives in /opt/local, so if you mess up your Macports environment, you can easily just trash this folder and start again.
Installation Procedure
Here goes... The following instructions walk you through how to set up a development environment with Ruby, Rails, MySQL, Netbeans and Subversion on OS X 10.5 "Leopard".
Xcode
Before doing anything else, we need to install the Xcode tools from the Leopard DVD. Just double click on the installer and away it goes.
Macports
Download the installer from the Macports site, and run it.
(I used the dmg for v1.5.0 for OS X 10.5, but I think v1.6.0 is out now so you might want to try that one).
MySQL
Now, for MySQL, I just downloaded the package from the MySQL site, and installed it.
The problem I've found with this using this package is that the preference pane and automatic startup item don't work quite right, but there are workarounds for this. In particular, this worked for me:
"[...] the working MySQL.prefPane is here
and to get the StartupItem to work (see bug#25008), copy the (if existent)
/usr/local/MySQLCOM directory to /Library/StartupItems/MySQLCOM "
There are also some great free GUI tools available on the MySQL site too. At the time of writing, there isn't a dedicated package for these available for OS X 10.5 -only 10.4, but it works fine.
Set paths
This step is important! Dont skip it.
edit ~/.bash_profile, for example using TextMate:
mate ~/.bash_profile
and add the following line:
export PATH="/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:$PATH"
(As I mentioned before, anything installed in Macports is installed under opt/local)
Save the file, and restart your terminal session to pick up the changes.
Install ruby and rubygems in Macports
sudo port install ruby
sudo port install rb-rubygems
Install all your required gems
For example:
sudo gem install rake
sudo gem install rails
sudo gem install capistrano
sudo gem install termios
sudo gem install mongrel
sudo gem install mongrel_cluster
sudo gem install ruby-debug
sudo gem install ruby-debug-ide
(The ruby-debug and ruby-debug-ide gems above are required if you want step-through debugging to work in Netbeans).
Subversion
I just use the subversion installation that comes with Leopard, as this works fine.
Netbeans
Download Netbeans from here, and run the installer. (For developing rails apps, you just need the 'ruby' bundle).
Debgging in Netbeans
In Netbeans, under Preferences->Ruby, set the ruby interpreter to /opt/local/bin/ruby
The fast debugger radio button should become available - select it.
That's pretty much it. You should now have a fully functioning setup for developing on rails.
Note: I use svn over ssh to access my subversion code repository. Below are some instructions for getting this to work with Netbeans. You can safely ignore all that follows if this doesn't apply to you - Netbeans works fine 'out of the box' with svn over http...
svn+ssh in Netbeans
In order to get the svn+ssh protocol to work with Netbeans, you need to set up a ssh key, and set your mac up to remember it. Here's how to do this
1. Create a pair of keys on your local machine.
From your home directory on your mac, run the following command:
ssh-keygen -t dsa
This will prompt you for a secret passphrase - make sure to use a good passphrase. When this is done you will get two files called id_dsa and id_dsa.pub in your ~/.ssh dir.
2. On your server, ensure that the .ssh directory exists for the user
Log in to your server via ssh
ssh myuser@myserver.net
make a .ssh hidden directory
mkdir ~/.ssh
3. Place your public key on your server
On your mac, run
ssh myuser@myserver.net 'cat >>.ssh/authorized_keys' <~/.ssh/id_dsa.pub
4. Try to log in to the server
ssh myuser@myserver.net
You will be asked for the passphrase
In OS X Leopard, there is a user interface for ssh-agent which will ask you if you want to remember the passphrase, and will store it in your keychain. From then on, you wont need to enter a password or a passphrase for this user.
5. Edit the subversion config
This step is required because, although when you check out from an svn repository in Netbeans, the dialog asks you for a tunnel command, it forgets that when you restart the IDE.
On your mac, edit the ~/.subversion/config file (note: this file wont exist unless you've previously run Netbeans)
mate ~/.subversion/config
Add an entry under the [tunnels] section like this:
ssh = $SVN_SSH ssh -l my_ssh_username
Save the file.
Now, Netbeans will be able to access your svn repository over ssh without needing a password from you.
6. Checkout from your repository
In Netbeans, If you go to the Versioning->Checkout dialog, you will see that the tunnel command is pre-populated for you. Just enter your repository location eg:
svn+ssh://myserver.net/repository
and everything should work fine.










Please also visit the Swirrl blog
Posted by
Richard Roberts
at
Thursday, March 06, 2008
1 comments
Labels: IDE, Leopard, MySQL, NetBeans, OS X, Rails, Ruby, Subversion
Tuesday, 5 February 2008
Handling Errors in Ajax & Rails
A while ago, I was wondering how I should deal with errors that are encountered in rails controllers, while processing an Ajax request. I played around with some alternatives and eventually came up with one that has been working great for a few months, so I thought I'd share it.
You've probably all heard of overriding 'rescue_action_in_public' in your ApplicationController to deal with errors. (See simple example below).
def rescue_action_in_public(exception)
# render the error page.
render :file => "public/error.html"
end
This works great in regular methods, but what if something happens in an ajax request?
If you take no action, then the controller will fail 'silently' (well, some stuff appears in the log, but the user is unaware).
The way I got around this was to add a method to the ApplicationController, similar to that below (irrelevant code stripped out, so apologies if this code has a typo!).
def perform_ajax_action
if block_given?
begin
if (request.xhr?)
yield
else
raise RuntimeError.new('Not in an ajax request!')
end
rescue Exception => error
logger.error("#{Time.now}: Error performing ajax action: #{error.inspect}")
logger.error(error.backtrace.join("\n"))
ajax_aware_redirect_to "/error.html"
end
else
logger.error("perform_ajax_action called with no block!");
ajax_aware_redirect_to "/error.html"
end
end
(You were probably wondering what this 'ajax_aware_redirect_to' business is all about. It's just another method in the ApplicationController which helps with redirecting during ajax processing. It looks a bit like this: Again, irrelevant stuff removed.)
def ajax_aware_redirect_to(options = {}, *parameters_for_method_reference)
if request.xhr?
render :update do |page|
page.redirect_to( options, *parameters_for_method_reference)
end
else
redirect_to( options, *parameters_for_method_reference)
end
end
Now, in order to get this to catch your errors, you need to add an :around_filter to your controller. e.g.
class MyController < ApplicationController
around_filter :my_around_filter, :only => [:my_action]
# controller code here....
def my_around_filter
perform_ajax_action do
# do other useful stuff here if you like.
# in an 'around filter' yield calls the method wrapped in the filter
yield
end
end
end










Please also visit the Swirrl blog
Posted by
Richard Roberts
at
Tuesday, February 05, 2008
2
comments
Tuesday, 25 September 2007
MySQL Temporary Tables and Rails
According to the Rails documentation, all active record classes by default use the same database connection.
As the Agile Web Development With Rails book rightly says, Ruby on rails is not thread safe (2nd Edtn p 649). A Mongrel server uses one thread per request (i.e. multithreaded), but is synchronised around the calls to Dispatcher.dispatch. This means that everything is threaded right before and right after Rails runs. While Rails is running there is only one controller in operation at a time. This is why people typically have to run a small set of Mongrel processes (a “Pack of Mongrels”) to get good concurrency (from Mongrel FAQs).
MySQL temporary tables are only visible inside the connection from which they are created, and they are automatically dropped when the connection is dropped (see the MySQL docs). Along with the above, this means that any rails active record class will be able to see temporary tables created by other active record classes (within the same server process).
However, since only one controller operation is running at a time within each server process (and therefore only one for each connection), I think you can safely do the following in a rails active record model class if you want to use temporary tables:
begin
connection.execute("DROP TEMPORARY TABLE IF EXISTS my_temp_table")
connection.execute("CREATE TEMPORARY TABLE my_temp_table")
# do stuff with temp table here
ensure
# this drop is here to help keep the size of the data base down
# between calls to this method
connection.execute("DROP TEMPORARY TABLE IF EXISTS my_temp_table")
end










Please also visit the Swirrl blog
Posted by
Richard Roberts
at
Tuesday, September 25, 2007
0
comments
Monday, 10 September 2007
NetBeans Intervenes
Regular readers of this blog will know that I'm not averse to trying new IDEs for my rails development.
I recently came across this post by George Cook about an app I hadn't considered.... NetBeans.
George does a great job of explaining NetBeans's virtues, so I won't repeat them all here, but to sum up, it does everything I need a rails IDE to do plus a little bit extra. The most impressive feature for me is the in-IDE fast debugging (more on how to set this up below).
NetBeans does have it's down points. With its default settings it doesn't look as slick as TextMate, but after some fiddling around with the preferences you can rectify this. It does use more memory than TextMate but even on my MacBook with 1GB RAM and lots of other applications open, I still have a little bit free. Besides, compared with something like Microsoft Visual Studio 2005 (which eats RAM for breakfast) NetBeans is a veritable size zero.
There is a ruby-only build of NetBeans available which helps to keep the memory footprint down. The exact version I installed was build 3533, which seems to work fine.
UPDATE (26 Sep 07): Netbeans 6 Beta 1 is now out! Get it from the Sun web-site.
Getting started with NetBeans
Here are few quick pointers to get you going.
To begin, all you have to do is do:
-> File -> New Project
.. and then choose "Ruby on Rails Application with Existing Sources"
and browse for your rails folder.
You need the ruby-debug-ide gem installed (sudo gem install ruby-
debug-ide) to do fast debugging.
Before trying to debug, you need to go to:
-> Preferences -> Ruby -> Platform
... then choose the location of your ruby interpreter (e.g. /usr/local/bin/ruby)
You should then be able to select the Fast Debugger radio button for the
Debugger engine. (If you can't, try restarting NetBeans - this worked for me).










Please also visit the Swirrl blog
Posted by
Richard Roberts
at
Monday, September 10, 2007
3
comments
Wednesday, 5 September 2007
RedBox Rules!
As you might have noticed from previous posts in this blog, I'm somewhat interested in modal dialogs in Ruby On Rails.
Up until now, I've been happily using the Prototype Window Class. However, it's quite a lot of js (a lot of which I don't use), and I've recently found a few small bugs in it. I'm not denying it's an impressive piece of work - it's just that there were a few niggles (Check out the forums).
Anyway, I've been investigating a few other options (namely: SubModal, ThickBox, LivePipe's Control.Modal, LightBox Gone Wild, StickyWin) and then I eventually found RedBox.
Most of the options I considered are variations on the LightBox theme, but RedBox stood out for me because of it's simplicity and ease of use with RoR. It doesn't do anything particularly fancy, but it ticked all my boxes (i.e. easily customisable, works well with Rails, small size of javascript, no obvious bugs).
It really couldn't be simpler to use RedBox with Rails.
To install the RedBox plugin, in Terminal just run:
script/plugin install svn://rubyforge.org/var/svn/ambroseplugins/redbox
...from your Rails project folder. This will stick stuff in your vendor folder. Then, from the vendor/plugins/redbox folder, you can run:
rake update_scripts
...to copy the files to the relevant places in your project. (i.e. the public/javascripts, stylesheets folders etc.).
Now all that's left is to stick the javascript and stylesheet links into your layout:
<%= stylesheet_link_tag 'redbox' %>
<%# we need to include prototype, etc... %>
<%= javascript_include_tag :defaults %>
<%= javascript_include_tag 'redbox' %>
To create a link to a RedBox, you can use the helpers that the author provides, the most useful of which I found to be the 'link_to_remote_redbox' helper. This allows you to launch a RedBox with some content from another page. For example:
<%= link_to_remote_redbox("redbox",
:url => {:controller=>'my_controller', :action=>'my_action',
:id=>'my_id'}) %>
Then, in the resulting RedBox dialog, you need some way of closing the it. To just close is very simple...
<%= link_to_close_redbox "Cancel" %>
It's also pretty easy to get it to do stuff after closing. For example, you could call a rails action, via an ajax call...
<%= link_to_close_redbox "OK", {:onclick => remote_function(
:url => {:controller=>'my_controller', :action=>'my_action',
:id=>'my_id'},
:complete => "$('spinner').hide();",
:before => "$('spinner').show();")
} %>
If you want, the rails action could do some rjs to update some of the main page.
(Of course, you could use a similar technique to submit a form on the dialog too).
One of my additional requirements was to be able to guide the users through a two-step process, within the constrains of the modal dialog (something I found fiddly with other modal dialog solutions). Here's how I did this with RedBox...
<%# to link to another page inside RedBox %>
<%= link_to_remote( 'hello',
:url => url_for(
:controller => "my_controller",
:action => "my_action",
:id => "my_id"),
:update => 'modal_content', # the div used by default for the dialog
:complete => 'RedBox.setWindowPosition();'#make sure it's centered
) %>
Notice how I call the RedBox's setWindowPosition() function once the update is complete. This is because the new page being shown might be a different size to the first one, and although the dialog automatically resizes to fit the content (which is nice), it doesn't automatically recenter itself. (Without this step, the dialog's top-left corner just stays in the same position).










Please also visit the Swirrl blog
Posted by
Richard Roberts
at
Wednesday, September 05, 2007
20
comments
Tuesday, 10 July 2007
More on modal dialogs in rails
Almost a year ago (blimey!), I posted about modal dialogs. For various reasons, the part of the application about which I wrote ended up being done a bit differently to how I described. I've recently had a lot more time to work on rails and the other day, I came across a different reason to use modal windows.
The Xilinus Prototype Window Library is now at version 1.3, and has some nice additions since I last used it. There is also a link to a rails helper for launching windows and dialogs, which although doesn't fully support all of the options, is a good point to build from.
Now, to finally answer Michael Kovacs's question from that original post, I found it handy to make use of the callbacks (onOK & onCancel for dialogs and closeCallback for windows) when dealing with ajax.
For example, suppose you want the user to impart some information in one of your modal dialogs. And then you would like to save this information and cause an update to a portion of the page from which you launched the dialog, as a result of what the user did...
One solution is, in the callback function, to interrogate the contents of the dialog for what the user entered (using prototype, say) and then call a remote_function to save the info to a database. This remote_function could then use rjs to update the original page.
The erb in your view to launch the dialog might look a bit like this...
<%=
url = (url_for :controller => 'my_controller', :action => 'dialog_action')
link_to_prototype_dialog(
"link text here",
{
#content
:url=>url,
:options=>{:method=>'get'}
},
'confirm', #dialog-kind
{
# dialog options
:className=>"alphacube",
:width=>680,
:height=>220,
:onOk="function(win)
{
val1 = $F('val1');
val2 = $F('val2');" +
remote_function(
:url => {:controller=>'my_controller', :action=>'do_something'},
:with => "'val1=' + val1 + '&val2=' + val2",
:complete => "$('spinner').hide();",
:before => "$('spinner').show();") +
";
return true; // remember to return true to allow the dialog to close
}"
}
%>
Note that in order to get this to work properly I had to tweak the rails helper to slightly to correctly format the generated javascript, but you get the general idea.
UPDATE: you might also want to try RedBox modal dialogs.










Please also visit the Swirrl blog
Posted by
Richard Roberts
at
Tuesday, July 10, 2007
0
comments
Wednesday, 6 June 2007
diagrams for your rails apps
RailRoad lets you generate diagrams of your rails app.
Documentation often gets left to get out of date. With a tool such as this, you can just keep changing the code, automatically generating diagrams along the way.
The link above tells you how to set up a rake task to do just this, meaning that you'll never have to look at a redundant diagram again (or manually update one either)!










Please also visit the Swirrl blog
Posted by
Richard Roberts
at
Wednesday, June 06, 2007
0
comments
Friday, 16 March 2007
Visibility in ruby
Back in January, I made this post about ruby instance variables in derived classes.
I recently came across this post by Jamis Buck (one of the core Rails guys) with some more info about method visibility in ruby. Basically, he explains that private and protected methods are visible by all derived classes.
This seems a bit free and easy, coming from a C-sharp view point. In rails, this means, for example, that the controllers can't call the models' private methods and vice-versa. But all controllers can access all of the application controller's methods, so it's hard to hide it's inner workings from the other controllers if you want to.










Please also visit the Swirrl blog
Posted by
Richard Roberts
at
Friday, March 16, 2007
0
comments
Saturday, 10 March 2007
Radrails and Aptana
Earlier this month, I wrote about the demise of Radrails.
Well, Aptana have stepped in to save the day. It's not clear exactly what will become of Radrails in its current form, but anything's got to be better than all of that great work just petering out into obscurity.
Here's what the Radrails site had to say about it all.










Please also visit the Swirrl blog
Posted by
Richard Roberts
at
Saturday, March 10, 2007
0
comments
Sunday, 4 March 2007
TextMate for rails
With the seemingly indefinite postponement of Radrails 0.8, I decided to go on the hunt for another Ruby on Rails IDE.
After scouring the web, I found that many people seem to favour TextMate, and according to this page the core Rails team use it for development, so I thought I'd give it a whirl.
I must say I am impressed. It features Subversion integration, and some built in support for developing Ruby on Rails applications. The only thing it doesn't have is a step-through ruby debugger, but there is a TextMate ruby-debug bundle which allows you to set breakpoints from within TextMate. (My previous blog post explains more about ruby-debug.)
Note that in order to get the Subversion integration to work, you need a Subversion client installed. There are now new instructions on Hivelogic.com for setting up rails on OS X which now feature how to install one.
TextMate is not free, but it is cheap at only 39 Euros.










Please also visit the Swirrl blog
Posted by
Richard Roberts
at
Sunday, March 04, 2007
0
comments
Labels: debug, IDE, Rails, Subversion, TextMate
Fast Ruby debugging
Last September I described how to use Radrails for debugging rails apps. I mentioned in that post that it was slow and unresponsive, but bearable.
Today I discovered another way of debugging Ruby On Rails apps, but this time in a much speedier fashion.
Ruby-debug allows you to quickly debug your ruby on rails code. The debugger itself is not integrated into an IDE, but the command line interface is intuitive and adequate.
There is an excellent tutorial on the DataNoise website for how to use ruby-debug. Using this, I was able to get debugging literally within a few minutes.










Please also visit the Swirrl blog
Posted by
Richard Roberts
at
Sunday, March 04, 2007
1 comments
Thursday, 1 March 2007
Where are Kyle and Matt?
The development of Radrails seems to have slowed to a crawl recently, which is a shame as I was eagerly awaiting features promised for version 0.8!
According to posts on the radrails community pages, it looks like the main members of the Radrails team are spending their time on other more profitable ventures.
All the same, for me Radrails is still the best value rails IDE. Some other IDEs have similar features but you have to pay for the privilege.
Where did the Radrails team go
Has Radrails disappeared off the face of the earth










Please also visit the Swirrl blog
Posted by
Richard Roberts
at
Thursday, March 01, 2007
0
comments
Friday, 26 January 2007
Setting up rails on OS X (including radrails)
Hello. This post documents how to get rails going on Mac OS X (I'm using 10.4.8, by the way).
Well, basically I followed these brilliant instructions on Hivelogic.com (except I used ruby 1.8.5 instead of 1.8.4) and it just worked! The only little quirk was getting the lightTPD web server to work properly. I had to tweak the paths on the first line of the dispatch.cgi, dispatch.fcgi and dispatch.rb files (in the public folder of my rails project) as they were pointing to a windows-style path.
Radrails pretty much just worked "out of the box" too, but to get radrails to start the lightTPD server properly, I set up a symbolic link like this...
ln -s /usr/local/sbin/lighttpd /usr/bin/lighttpd...as radrails was having trouble finding it initially. (Credit for this last bit goes to Marc from the radrails community). Note that even after this link is setup, the radrails never reports the lightTPD server as 'started' - it just stays as 'starting...', but it does actually seem to start it properly. I also noticed that the lightTPD server starts on the last port you used for it, and it doesn't pay attention to the one that you specify in radrails.
Remember this post from September where I explained how to setup debugging in radrails on Windows XP? Setting up debugging for radrails in OS X is almost exactly the same, but in the interpreter arguments page of the debug dialog you'll want to put something like:
-I"/usr/local/lib/ruby/gems/1.8/gems/rails-1.2.1/bin"
Also, I had trouble getting debugging to work with lightTPD, so I've put the following in the program arguments to force it to use webrick instead.
webrick -p3001
That's it. enjoy!
UPDATES (March 07):
There are now updated instructions on Hivelogic.com.
You might also want to try Textmate and ruby-debug










Please also visit the Swirrl blog
Posted by
Richard Roberts
at
Friday, January 26, 2007
2
comments
Saturday, 23 September 2006
let's get modal
UPDATE 12 July 07: Check out this more recent post for more info on modal dialogs.
In the Ruby On Rails project on which I'm currently working, I felt the need to introduce the concept of a modal dialog box. This is a common requirement in traditional client-applications, in order to restrict a user's actions to a certain area of the screen. However, until the advent of Web 2.0 it has been tricky implement in internet-based applications.
I tried a few different approaches, but finally settled on using the Xilinus Prototype Window javascript libraries to help me out.
A bit of background...
In my project, I orginally had a table which contained links to allow the user to edit the (often complex) contents of some of the table-cells. The links would causethe user to be navigated away from the page, and so after they had finished doing their editing they would have to navigate back. This is all very well, apart from the fact that if we wanted the site to remember other values that the user had entered on the first page, it meant storing hoards of things in the session. I stuck with this approach for a while, but the more functionality I added to the page, the more work I had to put into maintaining state in the session. Something had to change!
My solution
1. First download the Prototype Window libraries from here. (I used version 0.96.2).
2. The download zip-file contains a bunch of folders. Put the window.js file from the javascripts folder into your rails project's public/javascripts folder. (You will also need the prototype.js file, but this should already be there for you if you generated your project from a skeleton). The stylesheets folder in the zip-file contains all the different themes that are demonstrated on the xilinus prototype window samples page. The styles that you want to use need to go into your rails project's public/stylesheets folder. (I made a window subfolder to keep things tidier).
3. So that your views can use the prototype window javascript, put a javascript include tag in the head of the appropriate layouts file. For the sake of this example, put it in the application.rhtml layout file.
<%= javascript_include_tag "prototype", "effects", "window" %>Also put in a stylesheet link to the style of modal dialog log you want.
<%= stylesheet_link_tag "/stylesheets/window/default" %>We're going to use some javascript later, so put a content_for_page_scripts tag in the head of the layout too.
<script type="text/javascript"><%=@content_for_page_scripts %></script>
4. In the view from which you wish to launch the modal dialog, we need some javascript. Write a function, and put it inside a content_for page_scripts block. Here, the function launches a modal dialog containing the web page at the url passed in.
<% content_for("page_scripts") do -%>
function show_Array_Window(myUrl)
{
win = new Window('window_id', {title: "Array", width:300, height:500, url:myUrl});
win.setDestroyOnClose();
win.showCenter();
}
<% end -%>
5. Now set up a link for the user to click on, and set the onclick event to the function we just wrote. In the example below, we're building up a table with a link to a different object in each row's cell. (If you just want a permanent link to a single modal dialog, you dont need to go to the trouble of building up a dynamic onclick string).
<table>
<% for i in 0...@my_array.length do %>
<tr>
<td>
<%=
# other code here if you like
"<a href = \"#\" onclick='show_Array_Window(
\"" + url_for(:controller => 'my_controller',
:action => 'my_Action', :id => i) + "\")'>
Go Modal!</a>"
%>
</td>
</tr>
<% end %>
</table>
6. You can now do whatever you want in the page that's shown. In my case, this involved allowing the user to edit the complex data structure that was represented by the object in the table.
... and that's it.
The advantage of using the Xilinus Prototype Window libraries over other modal dialog approaches like lightbox gone wild is that because you just point the dialog to a url, the page that is shown inside can include its own javascript. This allows you to do ajax stuff inside your dialog like it was any other rails page. (I wont go into the whole ajax thing here).










Please also visit the Swirrl blog
Posted by
Richard Roberts
at
Saturday, September 23, 2006
5
comments
Wednesday, 20 September 2006
Update on debugging in RadRails
In my last post I described how to get Rails debugging to work in RadRails. I've had some reaction to my instructions, and on the whole they seem OK.
However, I don't think I made it clear that you need to set the breakpoints before you start the server.
Also, someone said they couldn't get it to work with older versions of Ruby and RadRails - so make sure you're fully up to date!
Any more feedback appreciated.










Please also visit the Swirrl blog
Posted by
Richard Roberts
at
Wednesday, September 20, 2006
0
comments
Tuesday, 19 September 2006
RadRails, all is forgiven!
UPDATE 9 March 2007: If you're using a Mac, you might want to try TextMate with ruby-debug. See these more recent posts:
Fast Ruby Debugging
TextMate for Rails
UPDATE 7 May 2007: Aptana (formerly Radrails) now supports fast debugging. See this recent post: Aptana with fast debugging
UPDATE 12 Sep 2007: NetBeans is another debugging solution I've recently discovered (and one I'd heartily recommend trying).
In August, I made a couple of posts (RoR debugging, Gleaming Steel) regarding Ruby on Rails IDEs and debugging. Since then I've come across something which made me realise I hadn't been giving Radrails its due praise.
While browsing the RadRails community pages for news of any updates, I found a link to this article by Steve Midgley which explains how to set up Eclipse for inline debugging with Rails. Steve was using something called EasyEclipse, but RadRails is based on Eclipse so I gave his instructions a go, and hey-presto!... rails debugging.
It's a bit slow, but no slower than RubyInSteel or Komodo. I think the RadRails team should make more of an effort to publicise their app's ability to debug rails code, as other products make a big deal of this feature. (apparently "fast debugging" is coming in version 0.8 of RadRails).
Steve's instructions, although very informative, are quite "wordy" and somewhat oriented towards EasyEclipse - so I thought I would write my own instructions specifically for RadRails with some screenshots. (click on the screenshots to zoom in).
(I'm using RadRails 0.7.1 with Ruby 1.8.5 and Rails 1.1.6 on Windows XP SP2.). I've also got debugging going in Mac OS X see this post.
1. First, get your installation of RadRails set up properly (here are some good instructions for this).
2. Set a breakpoint somewhere (such as a controller method) by double clicking in the margin.
2. Open your rails project, and have the Rails Navigator View open. Go to the Run menu and choose 'Debug...'
3. You will be presented with the Debug dialog. Make a new configuration for your project and on the File tab, specify the file as script/server.
4. On the Arguments tab, enter -I"[path_to_rails]", like in the example below. (There is no space between the -I and the path). You can also specify program arguments too if you like, such as which port to start on (not shown below).
5. On the Environment tab, select your ruby interpreter.
6. On the Common tab, ensure that the "Allocate Console" checkbox is checked, and the "Launch In background" checkbox is unchecked.
7. Click Apply to apply all your changes. Clicking "Debug" should start the debugger. After a short wait, You should see something like the screenshot below in your RadRails Console window. If not, review the steps above as you've gone wrong somewhere.8. Now open a browser and navigate to the relevant page to trigger your controller method.
9. (This step was updated 20th Nov 2006) Go to the Debug Perspective (Window -> Open perspective... ). You should see execution stopped at your breakpoint. You are now able to step in/out/over. You can inspect variables by highlighting a variable currently in scope, right clicking and choosing inspect. The variable will appear in the Expressions window (I think this shows in the top-right of the Debug Perspective by default).
To debug again later, you can simply go to Run -> Debug History, and choose the name of the debug configuration you set up earlier.
All of this is essentially the same idea as setting up debugging in RubyInSteel or Komodo, so I knew it must be possible somehow, I just couldn't figure out the configuration options - my thanks go out to Steve Midgley!










Please also visit the Swirrl blog
Posted by
Richard Roberts
at
Tuesday, September 19, 2006
34
comments
Monday, 28 August 2006
netstat
Yesterday, I was having problems starting my Ruby on Rails server on port 3000. This morning, I discovered the netstat utility that comes with windows.
netstat -a -bgives you a list of all running programs along with what port they're using and their process id.
This helped me to find out what was hogging port 3000. In my case the offending process was wcescomm.exe, which is to do with the Windows ActiveSync program, and just removing my PDA from it's dock released the port.
If this doesn't solve it for you, you can use taskkill to forcibly terminate a process. For example, to kill off process id 2420:
taskkill /f /pid 2420










Please also visit the Swirrl blog
Posted by
Richard Roberts
at
Monday, August 28, 2006
5
comments
Labels: ActiveSync, ports, Rails
Sunday, 27 August 2006
Errno::EBADF
Sometimes, when trying to start my rails server with the usual command:
ruby script/serverI get the following error:
=> Booting WEBrick...
=> Rails application started on http://0.0.0.0:3000
=> Ctrl-C to shutdown server; call with --help for options
[2006-08-27 15:10:09] INFO WEBrick 1.3.1
[2006-08-27 15:10:09] INFO ruby 1.8.4 (2006-04-14) [i386-mswin32]
[2006-08-27 15:10:09] WARN TCPServer Error: Bad file descriptor - bind(2)
c:/ruby/lib/ruby/1.8/webrick/utils.rb:73:in `initialize': Bad file descriptor - bind(2) (Errno::EBADF)
from c:/ruby/lib/ruby/1.8/webrick/utils.rb:73:in `create_listeners'
from c:/ruby/lib/ruby/1.8/webrick/utils.rb:70:in `create_listeners'
from c:/ruby/lib/ruby/1.8/webrick/server.rb:75:in `listen'
from c:/ruby/lib/ruby/1.8/webrick/server.rb:63:in `initialize'
from c:/ruby/lib/ruby/1.8/webrick/httpserver.rb:24:in `initialize'
from c:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/webrick_server.rb:59:in `dispatch'
from c:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/commands/servers/webrick.rb:59
from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
from c:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:147:in `require'
from c:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/commands/server.rb:30
from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
from script/server:3
I realised that if I started the server on a different port, it worked (although I can't see how the error relates to this) e.g.
ruby script/server -p8000Sometimes even restarting the computer doesn't solve the problem. Something must be running on port 3000 somtimes, but I can't figure out what! At least using a different port for my server lets me continue working.
UPDATE: See my next post for a way to get round this problem.










Please also visit the Swirrl blog
Posted by
Richard Roberts
at
Sunday, August 27, 2006
5
comments
Tuesday, 22 August 2006
Gleaming steel
UPDATE (19 Sept 06): Radrails included debugging all along - check out my latest blog entry.
Last week I posted an entry about RoR IDEs and debugging. Since that was written, I have tried out the latest version (0.75) of the free RubyInSteel plug-in for Microsoft Visual Studio from the chaps at SapphireSteel software.
Using the simple articles in their website's online user guide, I successfully managed to import my rails project, and debug rails server methods. (For the record, I am using VS2005 Professional).
Running the server in debug mode was considerably slower than running it normally, taking 3-4 seconds to load each page, but it was much quicker than running Komodo's debugger. My only complaint is that my rails server seemed to randomly stop a couple of times while debugging.
I also managed to successfully install and use the VisualSvn SVN plug-in for Visual Studio. This is not free but cheap at $19, and I found it much better than ankh, which I had previously tried.
To use VisualSvn, you also need to install the Tortoise SVN client, which is available from the VisualSvn download page. Everything was a dream to set up and use - All I did was install everything and it just worked. (It seems to just go off the .svn folders in the directory structure, as I assume all svn clients do. These folders were already there for me, after using RadRails).
Visual Studio 2005 itself has its down-points, such as being RAM-hungry and a little bit buggy in places, but its a mature, effective editor with lots of good features. I also had almost zero learning curve to overcome before starting to edit my RoR code, with me already being very familiar with this IDE.
I think I will use the VS2005-RubyInSteel-VisualSVN combo as my main environment for a while - at least until RadRails includes rails debugging.
Stay tuned to find out if I still feel the same love after using it in anger for a bit!










Please also visit the Swirrl blog
Posted by
Richard Roberts
at
Tuesday, August 22, 2006
0
comments
Labels: debug, IDE, Rails, RubyInSteel