Rubynoob - Home

Forms in Ruby on Rails - Part 2

2007-07-12T03:43:00Z

In the previous installment, we learned about two of Rails’ methods that help create forms, form_for and remote_form_for. Those methods dealt with forms primarily based on Model data. Today we’ll turn our attention to form_tag and form_remote_tag which create more generic forms not tied to Model data.

Tutorial after the jump…

As mentioned, form_tag allows you to create forms that aren’t tied to a particular Model in your Rails application. In our super simple example, we’re going to have a form consisting of a single text input control and a submit button. Whatever text is input will be displayed just below the form.

Here’s what our controller method looks like:

def form_tag_test
  @result = params[:text_to_display]
end

When called the first time the params array will be empty and @result will be nil.

Here’s our view:

<html>
  <head>
    <title>Form_Tag Test</title>
  </head>
  <body>
    <% form_tag( :action => :form_tag_test ) do %>
      <%= text_field_tag( :text_to_display, @params[:text_to_display] ) %>
      <%= submit_tag( "Display Text!" ) %>
    <% end %>
    <strong><%= @result %></strong>
  </body>
</html>

Like the other form methods we’ve seen in rails, form_tag wraps code within in a ruby block, but in this case we’re not using a form_builder object. Instead, we’ll use text_field_tag and its FormTagHelper ilk to build our form. Our simple prototype only has a text_field_tag, but you can see documentation on all of your choices here.

The second parameter of text_field_tag is the value in the params collection that the controller can find the entered value. Each XX_field_tag method will send it’s value in a different hash key. In this way, the controller will have access to every value in our form.

form_tag takes a parameter indicating which controller method to execute. In our simple case we’re just going to call the same method again. The documentation for url_for shows how to call other options on form_tag.

Our simple view concludes with a bit of ERb displaying the @result parameter. When the page is first viewed, this parameter will be blank and nothing will be shown.

When we post the form, the form_tag_test method is called in the controller. As we see in the code above, we read the value out of the params collection and put it into the @result variable. Then, when the view is redisplayed, we see the value we entered into the text box in bold type just below our form.

form_remote_tag is the worst named of the lot. If we have form_for and remote_form_for, why on earth don’t we also have remote_form_tag? I suppose even Rails needs to contribute its own bit of perversity into the universe. Of all the methods we’ve talked about so far, though, form_remote_tag is probably my favorite, since by definition it can do all kinds of fun AJAX stuff and it isn’t tied to any model data. We can use form_remote_tag for just about anything.

Here’s our form_remote_tag controller code:

def form_remote_tag_test
end

As you can see, all that it does is render the form_remote_tag_test.rhtml view:

<html>
  <head>
    <title>Form_Remote_Tag Test</title>
    <%= javascript_include_tag :defaults %>
  </head>
  <body>
    <% form_remote_tag :url => { :action => :remote_test }, 
                       :update => :results,
                       :complete => visual_effect(:highlight, 'results') do %>
      <%= text_field_tag( :text_to_display, @params[:text_to_display] ) %>
      <%= submit_tag( "Display Text!" ) %>
    <% end %>
    <div id='results'>
    </div>
  </body>
</html>

This is a bit more interesting than the form_tag view. First, notice that we’re including the default Rails javascripts up there in the head tag. This is important, because without it AJAX won’t work and you’ll usually get some weird output. Also notice that besides the form_remote_tag method call, the rest of our form looks exactly the same. The xx_field_tag methods work exactly the same as they did in form_tag, so we won’t mention them more here.

form_remote_tag looks a good bit like remote_form_for though. In fact, the only real difference is that we don’t need to reference a Model object. This time though we’re calling the remote_test method in the controller:

def remote_test
  @result = params[:text_to_display]
  render :partial => 'form'
end

Here we’re putting the text_to_display value from the params collection (which is the value entered into the text input control) into the @result variable and then we’re rendering the _form.rhtml partial. In form_remote_tag we indicated that we wanted to :update the DOM component called (with the id value of) :results. So, the contents of the _form.rhtml partial goes into the results div.

Here’s the partial:

<%= @result %>

So, all we’re really doing is writing whatever is in the text box into the results div. This would produce exactly the same result as the form_tag_test except for two things. First, since we’re getting AJAXy with it, the browser doesn’t reload the page. Second, the :complete => visual_effect(:highlight, ‘results’) parameter makes the ‘results’ div glow bright yellow and then fade back to white. It’s a very simple AJAX operation, but I think it illustrates the functionality pretty well.

Since I’ve been writing these tutorials and thinking about forms in Rails a good bit the past few days, the names have kind of grown on me. Other than form_remote_tag they don’t seem too horribly named. I now think of form_for as meaning “make a form for this particular Model object.” form_tag now seems pretty obvious – it creates an html form tag. Perhaps it’s just the lack of clear documentation that lead to my confusion.

My lesson, and maybe yours as well, to learn out of this is that when something is confusing, even if it’s something you’ve been using for a while, it is probably a good idea to break it down into a very simple working prototype. Then you may be able to grasp how it works, why it works, and maybe why the heck it’s named the way it is.

As always, thanks for reading, and please leave a comment if you have any questions at all. I’m no expert, but I’ll be glad to try to help. Please feel free as well to point out any errors I’ve made or rewrite sections of code that may need it.

I think my next topic will be how to integrate Google Checkout into your Ruby on Rails application. Hope to have it up soon!

Forms in Ruby on Rails - Part 1

2007-07-09T05:15:00Z

I was confused for a pretty long time about how to create forms in Ruby on Rails. Since many (most?) Rails applications are tied to databases, it makes sense that many interactions with model data will be done via HTML forms. My problem though, was that there just seemed to be too many choices, and the choices are poorly named.

Tutorial after the jump…

There are four Rails methods to use when we create forms. We can chose from the following:

form_for
remote_form_for
form_tag
form_remote_tag

To my mind, none of these methods really indicate what they do or how to use them. The API documentation doesn’t really help either – at least not in really knowing how to use these methods. It makes sense that the remote methods deal with AJAX but I still can’t tell by looking what they do.

So now let’s go over the basics of each method and how and when to use them. We’re only going to cover the basics since you can get pretty fancy with each. Hopefully, though, if you can understand this article, you can use that as a springboard into figuring out the more advanced stuff.

Here’s the most important morcel of this tutorial. form_for and remote_form_for are both methods to use when you want to present model based data. form_tag and form_remote_tag are more general purpose methods which are not based on a model’s data.

form_for allows you to create forms based on the models you’ve created for your Rails app. Let’s say that we have a model named ‘Visitor’ tied to a database table, visitors, which contains a field named ‘avatar_name’. Our controller method that we’ll use to test form_for can look like this:

def form_for_test
  @visitor = Visitor.find_first
end

So here we’re just grabbing the first row in the visitors table and putting it into the @visitor variable which will be accessible in the form_for_test.rhtml view. Here’s the view:

<html>
  <head>
    <title>Form_For Tester</title>
  </head>
  <body>
    <% form_for :visitor, :url => { :action => 'save', :id => @visitor } do |f| %>
      Avatar Name: <%= f.text_field :avatar_name %>
      <%= submit_tag 'Save' %>
    <% end %>
  </body>
</hmtl>

This is a really trivial form, but I think it illustrates the basic concept. form_for’s first variable is the let’s the form know that it will be using the variable @visitor that we created up in the controller. The :url hash tells us which method on the controller we’ll execute when the submit button is pushed, and the :id parameter allows the controller to pull out the id of the visitor model from the params collection which we’ll see in a moment.

form_for’s contents reside within a ruby block which we see in the ‘do |f|’ bit. Since we’re in the block, we can make calls against the ‘f’ variable, which is defined as a ‘form_builder’ object. This gives us access to methods to define every sort of form element. In this simple example, we’re putting the avatar_name column value into a text_field which maps to an input control. You can see the API document for every other type of control here.

Here’s the ‘save’ method which gets called when we submit the form:

def save
  visitor = Visitor.find(params[:id])
  visitor.update_attributes(params[:visitor])
  redirect_to :action => 'form_for_test'
end

This is a really trivial and simple implementation, but it gets the job done. First we find the visitor we’re updating from the database. We do this by grabbing the :id parameter (which we allowed for with ’:id => @visitor’ back in the view). Next we use some Rails magic. update_attributes grabs the visitor parameter representing the changes we made when we submitted the form and applies them to the model object and saves it to the database. In any rails app beyond a simple learning tool we’d use the fact that update_attributes returns false on failure to handle any errors.

Finally in our simple app we just redirect back to the page we came from. I’d probably rather go to a success page or give the user some indication that the save was successful. We’ll do that now with remote_form_for which allows AJAXy form posting.

Our controller method for our remote_form_for test page looks familiar:

def remote_form_for_test
  @visitor = Visitor.find_first
end

Just the same as the form_for controller method.

The view, however, looks a little different:

<html>
  <head>
    <title>Remote_Form_For Tester</title>
    <%= javascript_include_tag :defaults %>
  </head>
  <body>
    <% remote_form_for :visitor, @visitor, 
                       :url => { :action => 'save_remote', :id => @visitor },
                       :update => 'result',
                       :complete => visual_effect(:highlight, 'result') do |f| %>
      Avatar Name: <%= f.text_field :avatar_name %>
      <%= submit_tag 'Save' %>
    <% end %>
    <div id='result'>
    </div>
  </body>
</hmtl>

remote_form_for works exactly like form_for except we add in support for AJAX. So, we need to add the javascript_include_tag method into our head element. Also, note the additional :update and :complete parameters. :update indicates that after we post the form, we are going to do something with the ‘result’ div. :complete says that after the form has been successfully posted we’re going to do a scriptaculous highlight effect on whatever is in the ‘results’ div.

The possible AJAX parameters we can pass to remote_form_for are explained in the API documentation for the link_to_remote method which you can find here. You can find documentation for using scriptaculous effects with visual_effect here.

When the form posts we’re going to asynchronously call the ‘save_remote’ method in the controller. Here’s what it looks like:

def save_remote
  visitor = Visitor.find(params[:id])
  visitor.update_attributes(params[:visitor])
  @result = 'Saved!'
  render :partial => 'form'
end

The first two lines of this method are the same as the form_for save method we discussed earlier. We’ve added in a @result variable and given it a message about our assumed success. Then we render the _form.rhtml partial which will fit into the ‘results’ div as per the :update parameter in the remote_form_for method back in the view.

The _form.rhtml partial is stupidly simple:

<%= @result %>

So, we’re just putting ‘Saved!’ at the bottom of the form after the form is posted. Since this is done in an AJAX manner, the browser doesn’t load a new page, it just displays the result partial and then immediately performs a scriptaculous highlight effect which turns the div bright yellow and then slowly fades it back to normal.

We could also add a spinning graphic if the process took a while to let users know something is going on. We could have the results div slide down or fade in or perform all sorts of other effects.

That’s it for a quick run-down on form_for and remote_form_for. I’m still not really sure why those names were chosen. model_form might have made more sense. In the next couple of days I’ll conclude this series with a discussion of the more versatile yet even more confusingly named form_tag and form_remote_tag methods.

As usual, if I’ve made a mistake or if you know a better way to do something, please leave a comment. Similarly, if you’re having a problem with forms in Ruby on Rails, please leave a comment and ask. I’m no expert, but I’ll do my best to help. Thanks for reading!

RubyNoob Reborn!

2007-06-28T20:05:00Z

After months and months of neglect, primarily due to the fact that I’ve had tons of problems getting Typo to run properly on Dreamhost, I have finally revived RubyNoob running in Mephisto! RubyNoob is up and running on a slice from SliceHost, being served by Litespeed.

I’m planning on writing up some guides on how I did the transition from Typo and Dreamhost to Mephisto and Slicehost, but first I’d like to thank Paul over at UsefulJaja for creating the incredible tutorials that I followed in setting up my new slice.

As I’m writing this, the new RubyNoob is using the plain generic Mephisto theme. I’m planning on slowly evolving my own theme over the next few months. I’m hardly a web designer or expert in CSS, but it’s time that I learn and what I’d like to do isn’t really anything spectacular or complicated.

Since my last useful posts I’ve learned a lot of stuff about Ruby on Rails. I’ve added a full e-commerce solution to JoyLi.net by integrating it with Google Checkout. That was a great experience and I’ll be writing about that as well.

If you’re reading this, you’ve found your way to the new RubyNoob (or your RSS subscription actually figured out what happened and I’m amazed) and I’d like to thank you for stopping by. Let’s hope I keep the ball rolling from here on out!

Note: all comments since the migration have been given the date of the migration, sometime in June 2007. Please ignore all the comment dates.

Rails + Errors + FastGI == Bad

2007-01-24T13:05:00Z

One way to generate a lot of “500 – Application Failed” errors in Ruby on Rails applications running on Dreamhost is by throwing a lot of errors. Right now my newly downloaded Typo (supposedly the most recent stable version) is throwing some errors and this is, in part, causing RubyNoob to keep going down.

I’m investigating this to see what I can figure out. My advice is, if you’re running Rails on Dreamhost and you keep getting application failure errors, the first place to look is your production.log file. Make sure to clear up all errors first.

I’ll talk about what else you can do once I get RubyNoob a bit more stable.

Windows is Evil

2007-01-24T09:05:00Z

Simple lesson for other Ruby on Rails noobs – editting dispatch.fcgi in Windows and then uploading to your website may be hazardous for your site!!

Although I haven’t had other issues with doing so, after totally destroying RubyNoob over the past few days, I’m always going to do any editting of dispatch.fcgi through my Dreamhost shell! Apparently some invisible characters can get into your file and keep your site from starting up.

I’ve also updated to the latest and greatest typo, but in the process I’ve lost the comments for the 4 or 5 most recent posts – and that sucks. I’ll see what I can do to resurrect them – or at least the ones worth bringing back.

I have an interesting article coming soon about Dreamhost and Ruby on Rails and Applications failing to start. I’m going to try to make the changes I’ll be mentioning and we’ll see if RubyNoob becomes more stable.

Introducing JoyLi.Net

2007-01-23T20:33:00Z

In conjunction with my wife Lindsay, and our development company, Blue Cockatoo Creative (website in progress), we’re proud to annouce the release of our first, full-fledged Ruby On Rails website, JoyLi.net.

Lindsay created the graphics and the general web design, while I stitched the pages together, created the database and did general rails magic. There’s no real Ajax on the site, though we did include a bit of groovy javascript.

Lindsay talked me into using ThickBox and JQuery instead of the standard Prototype and Scriptaculous libraries which have built-in support in Rails. Her argument was that we’d save time by not forcing users to download those other libraries and I relented, though after we finished I think we both agreed to just use what ships with Rails in the future. If someone goes ahead and fully integrates JQuery into rails, though, we’d stick with it.

Here’s a couple of teaser images:

JoyLi.net took us about 90 hours worth of total effort. It uses mysql and is currently running on FastCGI on Dreamhost. So far we don’t seem to be experiencing the horrible 500 errors that many people get with Dreamhost. I think I may have found a solution to those problems, and I’ll blog about that soon.

For fun, watch the home page for more than 15 seconds or so. Javascript is fun!

Please leave a comment and let me know what you think!

How To Deploy your first rails app to Dreamhost using Capistrano in Windows

2006-09-22T06:29:00Z

Credit: This tutorial owes its existence to the wonderful Dreamhost/Capistrano wiki article.

The primary thrust of this tutorial will be to help you deploy your first rails app using Capistrano from a Windows environment. Although I’m specifically addressing deploying to Dreamhost, you may be able to modify things to work with your own host. Rails apps on Dreamhost usually run on Fast-CGI, so this tutorial covers that as well. You may need to find more information in order to get your app up and running on Lighttpd or Mongrel.

UPDATE: Thanks to Chris_M from the comments for letting me in on another preperatory step. Before using Capistrano, please download the subversion command line stuff from here.

You’re also going to want to be doing this using the latest edge version of Rails. If you’re reading this after Rails 1.2 is available, you may not need edge.

First, let’s install capistrano:


     gem install capistrano

The next thing you’ll need to do is to set up a simple rails app. Create a rails app:


     rails CapTest

Now, in order to play with Capistrano to see if your deployment works, our app will just display an index.rhtml page. First let’s create a controller:


     script/generate controller whatever

Now create an index.rthml file under app/views/whatever. Let’s just make it look like this:


  <html>
    <head>
      <title>CAPTest</title>
    </head>
    <body>
      <p>
      It is now <%= Time.now %>. <br />
      </p>
    </body>
  </html>

In this way, we can make sure that rails is running. Once we get the app up to Dreamhost and running, we’ll add another couple of lines to this simple file as we deploy a few times to see the Capistrano magic.

We’re almost done with setup. Now, let’s change our route so that when we visit our site we’ll go straight to our test page. Open config/routes.rb and make sure it has a line like this:


    map.connect '', :controller => "whatever"

In order to get the whatever controller’s index page to work like this, though, you need to delete the index.rhtml found in your app’s public folder.

Now, let’s test the app with a WEBrick/Mongrel (depending on your version of Rails) server.


    ruby script/server

Just go to http://localhost:3000/ in your browser and you should see our test page showing the current time. Now, over to Dreamhost.

Our next step will be to set up a Subversion repository on Dreamhost and get our CapTest application into it. This is a very important step; we won’t be able to utilize Capistrano without it. So, go look at my handy-dandy Windows+Subversion+Tortoise+Dreamhost tutorial and come back when you get stuff set up.

Ok, now you should have a CapTest rails app that’s synched up with a subversion repository up at Dreamhost. Take a look at your app in explorer:

All of your folders should have green check marks like mine. If any don’t, right click on the topmost folder and choose SVN Commit… That will allow you to resynch whatever’s out of synch.

Now let’s create a subdomain to stick all this stuff up at Dreamhost. Just go into Manage Domains and create a new subdomain (something like captest.yourdomainname.com) and make sure that the FastCGI open is checked and be sure to append /current/public, instead of the default directory suggested. IMPORTANT: After DNS allows access to your newapp.yourdomain.com/current/public folder, you must manually delete the ”/current/public” that DH creates. This is so that later in this tutuorial, ‘cap deploy’ can create a symlink to /current, allowing capistrano and subversion to live happily together. Thanks to topfunky.com for the troubleshooting tip!

The next step is to modify your app according to the instructions under the config/environment section of the Capistrano/Dreamhost tutorial. When you deploy your app it needs to be in Production mode already. One strategy for managing your development work vs the production files is to synch up the important production files first and then modify them for development work – just remember to not synch the development versions! There’s probably a better way to handle this that I haven’t thought of. If you know a better strategy, please leave a comment below.

Now can we start playing with Capistrano. First, let’s Capistranoize our application. Open a command window at the toplevel of your app and type:


    cap --apply-to .

This will create two files in your app. A config/deploy.rb and a lib/tasks/capistrano.rake. Use tortoise to synch them up with your repository.

The next step is to modify your deploy.rb file. This file contains the bits of information that are specific to your app and your host. Getting all of this to work properly has been difficult for me, I think primarily because I’m deploying from Windows. Let’s look at my deploy.rb file. You’ll need to change a few things to make it particular to your domain and sub-domain. The comments up to where the Tasks start should be self-explanatory. This is all standard capistrano deployment for Dreamhost accounts. We’ll discuss the tasks below.


    # the name of your subversion application
    set :application, "captest" 
    # use exactly what you see on the Dreamhost subversion control panel
    set :repository, "http://www.icuo.us/captest" 

    # These three should be set to your subdomain name you set up
    # on Dreamhost.  The explanation of all of these is beyond 
    # the scope of this tutorial.
    role :web, "cap.icuo.us" 
    role :app, "cap.icuo.us" 
    role :db,  "cap.icuo.us", :primary => true

    # This is the directory you created when you setup
    # your subdomain on Dreamhost.  Don't include the
    # public/current part...
    set :deploy_to, "/home/tdonaghe/cap.icuo.us" 

    # Dreamhost doesn't allow you to use sudo.
    set :use_sudo, false

    # Do this so subversion doesn't create a .svn in your
    # world-accessible directory.
    set :checkout, "export" 

    # Make sure to set this to your DreamHost user name that
    # you use when you connect to ssh
    set :user, "your_user_name" 

    #      
    # TASKS
    # 
    desc "Tasks to execute after code update" 
    task :after_update_code, :roles => [:app, :db, :web] do
     # fix permissions
     run "chmod +x #{release_path}/script/process/reaper" 
     run "chmod +x #{release_path}/script/process/spawner" 
     run "chmod 755 #{release_path}/public/dispatch.*" 
    end

    desc "Restarting after deployment" 
    task :after_deploy, :roles => [:app, :db, :web] do
     run "touch /home/tdonaghe/cap.icuo.us/current/public/dispatch.fcgi" 
    end

    desc "Restarting after rollback" 
    task :after_rollback, :roles => [:app, :db, :web] do
     run "touch /home/tdonaghe/cap.icuo.us/current/public/dispatch.fcgi" 
    end

During my initial experimentations with Capistrano, I would have a lot of failures when deploying. These failures all stemmed around the executable permissions of the reaper and spawner scripts. I think this is a problem because when you build your rails app in Windows, you don’t have a good way to set the unix style permissions on these files. The first task takes care of this.

This task is called :after_update_code. Capistrano runs various tasks while it’s deploying your code. For each of these tasks you can create custom tasks to run either before or after they run. Just create a new task with the prefix of either “before” or “after” and the task name you’d like to add behavior to. In the :after_update_code case we’re going to run some unix commands after all of the code has been deployed onto the server.

When Capistrano deploys your app, it creates a directory structure something like this:

To get this started, let’s save this deploy.rb file as is and commit it to your subversion repository. Now, in a command line, run “cap setup” in a command window from the top level of your rails app. This will create the necessary starting structure up on the server for your app to be deployed to.

The important thing to notice in the :after_update_code is that your code goes into a 2006XXXX directory under the subdomain/releases directory. The location of this directory is stored in the release_path variable, and that’s what’s used in the after_update_code task. After the deploy step, Capistrano sets a symlink to point our cap.icuo.us/current/public directory to whatever the most recent release/public directory is. After the code update that’s not set yet, so we have to refer to the most recent release path as you see in the :after_update_code task.

So, we set executable permissions on the two process scripts as well as chmod’ing public/dispatch.* to 755 – something else I don’t know how to do in Windows.

Finally, there’s one more step for the deploy process – yet another stepped I figured out through trial and error. At the end of the deploy process you can see the reaper script attempt to restart the server by calling dispatch.fcgi. As you can see, this step fails:

If we let the deployment stop at this point, our web app won’t start and we’ll get a Rails error. I found that if I ssh’d into Dreamhost and opened dispatch.fcgi in nano, made a trivial edit (I think just stick a space after a comment) and then save that I could refresh the webpage and the app would work. I couldn’t though, figure out how to script in calling nano into a task. I finally remembered reading that you could sometimes “touch dispatch.fcgi” to get it to run sometimes. So, I created the :after_deploy task to do exactly that.

With the :after_update_code and :after_deploy tasks in place, you should be able to save your deploy.rb file, commit it to your subversion repository, and then run “cap deploy” in a command window from the top level directory of your rails app. If everything works ok you’ll soon be prompted to enter your ssh password. Then more scripts will run, and hopefully the process will end with no errors.

If you get errors at this point, please leave me a comment and I’ll try to help you out, and hopefully more knowledgeable folks will help as well. If you’re deploying this really simple rails app from Windows to Dreamhost we ought to be able to figure something out. The first thing I’d check is your dispatch.fcgi file. Open it in a text editor like Notepad++ and look at the end-of-line characters. If you have anything other than just LineFeeds (LF) at the end of each line, you’ll need to convert the file to Unix format, commit the file to your repository and try again.

Now try to navigate to your website. If it fails, see the previous paragraph. Let’s be optimistic and assume that everything works ok. Now let’s witness the power of Capistrano! Go into your app/views/whatever folder and edit your index.rhtml file. Just add a line to the end of it. Now save and commit the file to subversion. Run “cap deploy” again. Refresh your webpage. Voila! You should see your new line!

Now, let’s try a different Capistrano method. In your deploy.rb file you should also have a task that runs after a rollback, :after_rollback. This guy just “touches” your dispatch.fcgi file again. This time we can’t use #{release_path} to get to the public folder because by this time, that’s gone. So, we just use the absolute path of your newly rolled back app. Let’s try it out. Do “cap rollback” from the command window. Refresh your browser. You should see the original page we saw after doing the first deploy. Nifty, huh? Now we can just do a “cap deploy” to see our updated page.

That’s deploying and rollback changes to a rails app in a nutshell. There’s about a bajillion more things you can do with Capistrano like deploying apps to multiple servers, etc. There’s tons of info you can find out in GoogleLand. Hopefully this tutorial has helped you get your first pretty trivial rails app deployed out to Dreamhost. The principles should remain the same for more and more complicated websites. So, get to capping and have fun!

Please take a look at the wiki article mentioned at the top of this tutorial for more information and some helpful hints. It’s also very worthwhile to take a look at the Capistrano book up at RubyOnRails.org.

As usual, I’m a noob, so please feel free to correct me whereever I’ve screwed up, enlighten me on things I don’t know, or belittle me just for the hell of it.

How to download files with a Ruby script

2006-08-21T10:23:00Z

For a project that I'm working on, I want to download a set of pictures from flickr once a day. In this way, my Rails app won't need to access the flickr api - it can just grab the pics out of an images directory.

I figured that it would be an awfully easy task to download pictures from the internet using Ruby, and it is, but it was very difficult to find good examples. I googled for an hour or so, and kept coming up empty-handed. Finally, I checked in gmail where I keep mail from the Ruby Language mailing list. I found a relatively straightfoward way to do this.

Let's say that you want to download a picture from flickr, and you know its URL. Here's the ruby script to download the file:


require 'net/http'

Net::HTTP.start("static.flickr.com") { |http|
  resp = http.get("/92/218926700_ecedc5fef7_o.jpg")
  open("fun.jpg", "wb") { |file|
    file.write(resp.body)
   }
}
puts "Yay!!"

The Net::HTTP class contains the magic needed to handle this operation. I don't think this will work at all if you need to pull down a file from an FTP server. For now, we're dealing with http urls. So, just strip off the "http://" portion of the url and everything after that up to the first / goes into the start method.

Now, we get the file. The rest of your image url after what you put in the start method goes into the get method. This grabs the file from flickr.

Now we're going to copy the file down to where the script is running. First, let's create the file we're going to copy the picture into. Using the open method, the first parameter is the name of the file that you're going to plop the picture into. We could have used "218926700_ecedc5fef7_o.jpg" or anything else here. The second parameter of the open method, "wb" indicates that we're opening the file for (w)riting and we're going to be writing (b)inary information. The "b" may not be necessary on non-Windows platforms.

Finally, we're going to write into the new file, the contents or "body" of what we grabbed from flickr. So, this writes in the binary bits of the picture into fun.jpg. Remember that with the way that we created fun.jpg it'll be in the same directory with our ruby script.

This same method will copy down .html files, .css files, .pdf's and just about any other kind of file. In my next RubyNoob entry, I'll write about how to combine this method with a flickr api call to grab an arbitrary number of recent photos from flickr. As usual, I'm still a noob, and there's probably much better ways to do this. If you know a better way, please share in the comment section below.

How to create and use subversion repositories with Windows and Dreamhost

2006-07-22T17:25:00Z

I currently do my development work on a WindowsXP PC running Subversion through Tortoise and I’m currently hosting sites with Dreamhost, a popular site for Ruby on Rails and PHP hosting. This is going to be a tutorial on how to get your rails apps up in a repository on Dreamhost, but you’ll be able to use to coordinate any sort of subversion repository on dreamhost.

First, let’s use the nifty tool that Dreamhost has provided for creating Subversion repositories. Go into your ControlPanel. Drill down into the Goodies menu and choose Subversion. You’ll see a dialog that looks like this:

Use whatever name you’d like and make sure to give it a useful Username and Password. Then you press the create button. On success you’ll see something like this:

In a few minutes you’ll receive an email from Dreamhost declaring that your new repository is now working. So, now let’s fill it with some stuff.

The easiest way to interact with Subversion under WindowsXP is to install the super excellent Tortoise software. This extends your Windows Explorer shell with the full functionality of Tortoise. We’ll look at this as we go through the tutorial. If you haven’t yet, please install Tortoise.

Now we need something to stick into our new Subversion project. Let’s create a new rails application. That’ll create all sorts of stuff. Go into the directory where you have your Rails apps and type something like:


rails SubSample

After that’s done, let’s load up our new repository.

The 20 Coolest Ruby Apps You've Never Heard Of

2006-07-13T12:23:24Z

The 20 Coolest Ruby Apps youâ€™ve never heard ofâ€¦

Actually, I have heard of a few of these. BillMonk is a pretty darned cool idea for the younger, poor college aged crowd. CommunityWalk is another of my favorites, but I didn't realize it was written in Rails.

Blogged with Flock

More fantastic resources

2006-07-09T09:55:00Z

19 Rails Tricks Most Rails Coders Don't Know" RubyInside.com does it again! This is a great list of Rails shortcuts that us mere mortals will probably come to rely on. Thanks guys!

Excellent RJS Reference List

2006-07-05T16:12:40Z

16 RJS Resources and Tutorials for Rails Programmers This is a great list of resources for RJS stuff, not the least of which because it has a link here! And yes, I'm back (again)!

Lightbox Version 2

2006-06-01T23:16:22Z

I realize this is probably really old news, but I'm really excited now to see the second version of lightbox! Check this link. I'm going to delay showing off my little flickr app until I can integrate this new stuff. I've been off procrastinating for a while, but now I'm motivated again.

Still here!

2006-05-30T16:57:16Z

Hi everyone. Just posting because I haven't posted in a while and I don't want people to think I've abandoned RubyNoob! I'm hoping to have an extended version of the famous Flickr example available for download soon!

How to Send Files in Rails

2006-05-19T14:34:21Z

Setting up a link in your Rails app to allow your users to download any file is incredibly easy. Not just incredibly easy - OMGWTHBBQ easy! Stuff like this makes Rails so cool!

First, put the file out on your server. I put my "README.txt" file in a "files" folder like this: "rails/ appname/files/README.txt."

Next, set up a link in one of your pages:

12	<%= link_to 'Get Readme', :action => 'get_readme' %>

Finally, add the "get_readme" action method to your controller:

1234	def get_readme send_file("files/README.txt", :filename => 'yo_readme.txt') end

That's it! Now, whenever a user clicks the "Get Readme" link on your page, the file will be sent to the client. The :filename option simply allows you to suggest a name for the file to your users. I threw it in just to see how it works. I couldn't believe it was this easy, but sure enough, it is. Very cool.

There are other options like the :filename option which allow you to tell the browser what type of file to expect, how to display the file, and whether or not to stream the download. Streaming is turned on by default and allows downloading of very large files. All of these options go into the same line of code. Take a look at the article at this link.

As usual, expect a quick video demonstration of this posted later tonight.