Common Rails Tasks

Installing a Rails Plug-in

Now that Subversion is installed, we can use it to install Rails plug-ins. For this example, I've chosen a plug-in that I use on every project called annotate_models (see Figure 36). This plug-in, written by Dave Thomas, adds a rake task that automatically comments your models and fixtures with the current database schema.

Open a command prompt and navigate to a current Rails project.

Execute the command:

ruby scriptplugin install
http://svn.pragprog.com/Public/plugins/annotate_models
Installing the Annotate Models plug-in

Figure 36. Installing the Annotate Models plug-in

This command should complete successfully, installing a few files to your application.

To use this particular plug-in, simply run the command

rake annotate_models

from the root of any of your Rails applications.

Head on over to http://www.agilewebdevelopment.com/plugins to find more plug-ins you can use in your project.

Discovery

Rails has a feature that will "discover" the URLs for many plug-ins so you can simply install them by name rather than passing a long URL. Open a command prompt, navigate to your Rails application folder, and enter the command:

ruby script/plugin discover

You'll need to accept each new repository as they are discovered. Once the repositories have been indexed, you can install plug-ins by name:

ruby scriptplugin install annotate_models
ruby scriptplugin install acts_as_authenticated

You can list the available plug-ins with:

ruby script/plugin list

Using RCov in Order to Test Code Coverage

RCov is a code-coverage tool for Ruby. Combined with a small Rails plug-in, you can easily see how much of your code is covered by your unit and functional tests. This isn't a catchall by any means, but it can be a real eye-opener to you and your development team.

Test-Driven Development

Test-Driven Development, or TDD, is a design process used by many developers in which you write short pieces of code that prove your application works the way you expect. You've probably heard about unit tests before, and Rails makes them really easy to use because they're basically built right into the framework.

In a true TDD process, you'd actually gather your user stories and then write the unit, functional, and integration tests first. These tests will all fail since there is no actual application to test against. Once you have your test written, you then begin writing the actual pieces of the program, slowly making each of your tests pass. The theory is that once your tests pass, you've fulfilled all the requirements from your user stories.

As your requirements change (and they will!), you'll modify your tests as well. They'll help you know what your changes broke so you'll immediately know what to fix.

It takes a few iterations for this type of methodology to really sink in, but you'll be thankful you used it when some Really Big Change needs to be made to your important project.

I have found that writing your tests first also helps you think about the design of your application and whether or not your ideas actually make sense. It makes you take a second look at your processes before you get too far in your implementation.

You can learn more about test-driven development here: http://www.agiledata.org/essays/tdd.html

Install the RCov gem first:

     gem install rcov --include-dependencies

Choose the highest-numbered version for Windows (see Figure 37).

Installing RCov via RubyGems

Figure 37. Installing RCov via RubyGems

Then from within your Rails application, install Coda Hale's RCov plug-in:

script/plugin install http://svn.codahale.com/rails_rcov

You can now create a coverage report by adding :rcov to the end of your test runs.

    rake test:units:rcov
          rake test:functionals:rcov
          rake test:integration:rcov
          rake test:recent:rcov

This creates a /coverage folder in your application that contains HTML files you can open in your browser.

Installing ZenTest to Continuously Test Your Application

ZenTest provides some really great testing features to Ruby, but the best feature comes from its ability to constantly run your tests automatically whenever you change your code.

Install the gem using:

gem install zentest--include-dependencies

The installation will install a few other required packages (see Figure 38).

Installing Autotest

Figure 38. Installing Autotest

Setting the HOME environment

ZenTest's autotest command requires that you've set your $HOME environment variable. To do this, type the command:

Set HOME=c:

From the root of your Rails environment, run the command:

autotest

This command starts a process that automatically runs any relevant unit or functional tests whenever you change your program code or test code. This is a really useful tool that you can use to remind you to write better tests—it helps me out a lot!

Setting the path system-wide

You could also set the HOME path using the Windows Environment Variables configuration dialog. That way you only need to set it once.

  1. Right-click the My Computer icon.

  2. Select Properties from the context menu.

  3. Choose the Advanced tab.

  4. Select the Environment Variables button.

  5. Choose New under User Variables.

  6. Add the variable name HOME and the variable value c: when prompted.

  7. Press OK to save the value. Press OK on all remaining dialogs.

Installing the RMagick Library to Manipulate Images

RMagick is a very powerful library used to manipulate images. It's a Ruby interface for the popular ImageMagick program. This is one of the more difficult things to get working in Windows, but some really great people have made the installation a little simpler recently.

Visit http://rubyforge.org/frs/?group_id=12&release_id=8170 to grab RMagick for Windows. You'll need to grab the version for Ruby 1.8.5, which at the time of this writing is RMagick-1.14.1_IM-6.3.0-7-Q8.zip (see Figure 39). One thing you'll notice quite frequently about Ruby and Rails on the Windows platform is that updates to libraries take quite a long time.

Grabbing the correct version of RMagick for your version of Ruby

Figure 39. Grabbing the correct version of RMagick for your version of Ruby

Unzip the files to a temporary location like c: emp using the utility of your choice. You'll see a folder containing the ImageMagick program that RMagick uses to do its conversions (see Figure 40).

RMagick contains a few temporary files that need to be installed

Figure 40. RMagick contains a few temporary files that need to be installed

Double-click the installer for ImageMagick to start the installation process. You can choose to accept all the defaults for this setup and everything will work just fine. You might want to look at the options in Figure 41. If you plan to use ImageMagick from within VBScript, Perl, C, or C++, then you might want to check the appropriate options for those languages.

Additional tasks in the ImageMagick setup

Figure 41. Additional tasks in the ImageMagick setup

Once the installation has completed, you need to open a command prompt and change to the folder that contains the files you unzipped:

cd	empRMagick-1.14.1_IM-6.3.0-7-Q8

Now, run the gem command to install RMagick:

gem install rmagick-1.14.1-win32.gem --local

The installation should be completely successful. You should not encounter any errors as long as you have installed ImageMagick first.

You can test RMagick with the following bit of code in a Ruby console. Start irb from the command prompt and enter the following script:

gem 'rmagick'

If you receive => true as your response, then everything is properly configured.

RMagick Is Great, but Huge

RMagick is a powerful library that can transform and convert all sorts of images. It's very common to see RMagick used on lots of web hosts but it's important to note that it can be a real memory pig, especially when you throw large images at it. So be sure to use it with care. A similar project with a smaller footprint is called MiniMagick, but it's not in very wide use at the time of this writing.

You can learn more about MiniMagick at http://rubyforge.org/projects/mini-magick/.

Another option might be ImageScience, which can be found here: http://seattlerb.rubyforge.org/ImageScience.html.

Deploying with Capistrano on Windows

Capistrano is a great tool that helps you automate the deployment process of your Rails application. It runs on your local machine and allows you to run commands on one or more remote machines. You create a simple "recipe" that you then execute locally to upload your application, update your database, and restart your application server.

This section will show you how to set up Capistrano on your Windows machine to deploy an application to a Linux or Unix machine.

Unfortunately, you can't use Capistrano to deploy to a server running Windows, but many shared hosts and dedicated hosts support Capistrano deployment. If you plan to deploy on a Linux- or Unix-based server, this is the route to take.

Installing Capistrano

Capistrano is packaged as a gem, and so you install Capistrano by opening a command window and typing:

     gem install Capistrano -include-dependencies

The installation may also ask you to install some dependencies that you will need to allow (see Figure 42).

Installing Capistrano

Figure 42. Installing Capistrano

Once you get Capistrano installed, you need to apply some configuration settings to an existing application. I'm going to use a simple guestbook application I wrote as a demonstration:

svn export http://svn.napcsweb.com/public/guestbook guestbook
cd guestbook

Go into the root of your Rails application and type:

cap --apply-to ./

You should get a response similar to the one shown in Figure 43.

Capistrano's --apply-to command creates a default recipe

Figure 43. Capistrano's --apply-to command creates a default recipe

This step creates a sample deployment recipe and installs the rake tasks that you will use to deploy your application.

You'll need to open the deployment recipe located in config/deploy.rb. This file defines how Capistrano deploys your application to production. Here's a sample recipe I used for a simple project:

set :application, "guestbook"
set :repository,
"http://svn.napcsweb.com/public/guestbook/"
set :deploy_to, "/app/#{application}"
set :checkout, "export"
set :user, "brian"
set :spinner_user, "brian"
role :web, "mywebserver.mycompany.com"
role :app, "mywebserver.mycompany.com"
role :db, "mydb.mycompany.com", :primary=>true
ssh_options[:port] = 1525

In this case, I have an application called "guestbook" which is located on a public Subversion repository that I maintain. I want to deploy it to the folder /app/ /guestbook on my application server, and you'll see that I can access the application variable I set in the first line of the file when I specify the deploy_to path.

In order to prevent Subversion from putting a bunch of hidden files and metadata on our production server, I tell it to do an export when it checks out the code.

I also have to specify my username because Windows is going to use my currently logged-in username as the default user account for my servers. Even if they match, Windows occasionally displays the username using uppercase letters which might not match the username you have on your Linux server.

Next, I specify the servers I want to use. In this case, they are all on one machine.

Finally, because my SSH server runs on a nonstandard port for security reasons, I have to tell Capistrano what port number to use for the connection.

To do an initial deployment, type:

cap -a setup

This sets up the directory structure on the server. Capistrano uses a /shared/ folder for common parts, but then uses a /releases/ folder for each release of your software. Each time you deploy, a new release is placed into the /releases/ folder and your application server is pointed to the new folder, usually by a symbolic link.

Finally, deploy your application to the server with:

cap -a deploy

If all goes well, you'll see a new version of your application in the /app/guestbook/current folder on your remote server. The default deployment recipe will attempt to fire off some scripts to restart your web application too, but it won't be able to complete those if you're not running Apache. However, it's easy enough to modify the recipes, and the default recipe should give you some insight into how everything works.

This chapter is just an introduction to Capistrano. Once you start using it, you will quickly come to rely on it as part of your toolkit.

Using SQLite with Rails

SQLite is my favorite database to use when I am prototyping an application. Sometimes you just get excited about a new program and you don't want to have to stop to create a database and grant permissions to users, or sometimes you just don't have access to MySQL.

Rails works really well with SQLite, a file-based database. It will even create your SQLite databases for you when you run your first migration, saving you a few steps.

Download the SQLite3 DLL file for Windows and place it somewhere on your path. I tend to place it in c: ubyin because I only use it for Ruby projects, but you can place it anywhere you like, as long as it's in a folder on the system path.

Visit http://www.sqlite.org/download.html. There are two versions of SQLite, version 2 and version 3. We're interested in version 3. Look for a file that has a name similar to sqlitedll-3_3_X.zip. At the time of this writing, the current version is sqlitedll-3_3_13.zip. Download and unzip this file to your path.

Next, install the SQLite3 gem:

gem install sqlite3-ruby

You'll need to ensure you select the version for Windows that has the highest version number (it's usually the second choice; see Figure 44).

Installing SQLite3 gems

Figure 44. Installing SQLite3 gems

To test this out, create a new Rails application and specify SQLite3 as your database:

rails my_sqlite_test_app -d sqlite3

This will create a database.yml file configured for SQLite3 (see Figure 45). You shouldn't have to change a single thing in this file if you don't want to.

Rails creates a database.yml file that "just works"

Figure 45. Rails creates a database.yml file that "just works"

Use the new scaffold_resource generator to build a model, view, and controller for Products (see Figure 46):

ruby scriptgenerate scaffold_resource product
title:string description:body price:decimal
created_at:datetime updated_at:datetime
The new generator creates the model, controller, views, and a ready-to-run migration.

Figure 46. The new generator creates the model, controller, views, and a ready-to-run migration.

This new generator creates a migration for you as well. Run rake db:migrate and Rails will create your SQLite database and create the tables (see Figure 47).

Migrations create the database for you when you use SQLite3

Figure 47. Migrations create the database for you when you use SQLite3

Now that's a quick way to prototype an application!

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset