From the beginning, one of the weaknesses of Ruby on Rails has been the complexity of deploying a Rails application. Deployment was not difficult once you had done it once or twice, but it required several extra steps, learning about additional technology (like Mongrel or FastCGI), having a fair amount of server admin skills and a bit of patience. Most significantly, deploying a Rails application was much harder than deploying a PHP application.

With PHP, you can just drop your application files on the server, configure Apache to server up those files and you are done! It is possible to do this thanks to a module for Apache that allows it to serve up PHP files without needing a “handler” in between. This Apache module can be referred to as “mod_php”. This has been one of PHP’s strengths and one of it’s advantages over Rails.

Last week that all changed when Passenger was released by Phusion. Passenger is also referred to as “mod_rails” because, like mod_php (and mod_perl, mod_python, etc.), it is a module that allows Apache to serve up Rails applications without needing a handler like Mongrel or FastCGI. Once Passenger is installed, deploying a Rails application becomes as easy as PHP—simply drop files on the server and configure Apache to serve them.

It is notable that it is nicknamed “mod_rails” and not “mod_ruby”. mod_ruby is a different project whose development seems to have stalled in mid-2006. The difference also indicates that Passenger currently works only with Rails and not with other Ruby frameworks (like Merb or Camping).

Phusion made Passenger very easy to install and set up. Ryan Bates at Railscasts has a demonstration of how easy it is. Notice that he does not launch WEBrick, start up Mongrel or use FastCGI, he just restarts Apache and the application becomes available!

This is the first release of Passenger, so it is very possible that there will be bug fixes and improvements in the near future. There has already been some discussion about how to reduce the memory usage of Passenger (currently twice the memory usage of a single Mongrel instance). It has also been noted that if an application sits idle for a while it takes a little while for it to load again (I find that FastCGI does this too). Fixes, work-arounds and good advice will certainly be surfacing over the next few weeks as developers test it out on a wide range of web applications and server set ups.

One thing is for sure: the Ruby on Rails community is excited at the potential Passenger has for making deployment easier and thereby lowering a key barrier to entry for new developers. PHP took off once it became an Apache standard. Now Rails is poised to do the same.

It’s been a while since my last post. I’ve been busy on a few projects with upcoming deadlines. Harder still, I am working on both a Ruby on Rails and a PHP project at the same time and switching mindsets is challenging. (I can’t count the number of times I type self when I mean $this and vice versa.) It is like traveling between two foreign countries several times a day. I speak French to the German baker and German to the French butcher. (Or, most often, I am speechless in both cases!)

For the PHP project, I need to work with fractions of an inch in a few places. Not as decimals, but as fractions (1/5, 5/12, 3/64, etc.). Fractions are not an uncommon problem for developers. Since there seem to be very few discussions online about the subject, I thought it would be worthwhile to review some of the options. My example code will be in PHP since that’s the “country” I’m in right now, but the Ruby code is easy to extrapolate.

Read the rest of this entry »

This is part of an ongoing series of posts about how to get started writing tests for Ruby on Rails. The series begins with an introduction and overview of the ideas behind testing.

One final post about unit tests and then we will move on to functional testing.

Running All Tests in a Single Test File

Up to now we have run our unit tests by simply asking Ruby to process the file that contains our tests.

When you are first developing unit tests on a single model, this may be the easiest way to do it. It will run all the tests in the WineTest file.

Read the rest of this entry »

This is part of an ongoing series of posts about how to get started writing tests for Ruby on Rails. The series begins with an introduction and overview of the ideas behind testing.

© Celia Perez

At this point in the series, we have covered most aspects of unit testing in Ruby on Rails. We learned the basics both in Ruby and in Rails and discussed how to write meaningful tests. We set up fixtures to make working with sample data easier. We learned to write tests for ActiveRecord objects and their relationships, validations, additional attributes and callbacks.

The only thing we have not done is write tests for the custom methods in our Winery and Wine models (such as: location, find_newest, age, is_antique?). But I feel confident that you have the testing skills to make that an easy task.

To ensure that you have everything you need for writing unit tests on your own, in this section I want to expand on the assertions you can utilize for unit testing.

Read the rest of this entry »

This is part of an ongoing series of posts about how to get started writing tests for Ruby on Rails. The series begins with an introduction and overview of the ideas behind testing.

In previous sections, we learned to unit test the ActiveRecord associations and validations in our classes. Both are extremely common and appear in most Rails models. While less common, attribute definition methods and callbacks are still used somewhat frequently and are worth learning to test.

Hopefully by now your knowledge and confidence about writing tests is growing!

Attribute Definition Methods

When I refer to attribute definition methods, a classification I made up, I am referring to the methods that define and describe attributes in our model. There are two kinds. First, there are methods in the Ruby language that define attribute reader and writer methods: attr, attr_accessor, attr_reader, and attr_writer. Second, there are methods in the Rails framework that limit the access to attributes: attr_accessible, attr_protected, and attr_readonly.

Read the rest of this entry »

This is part of an ongoing series of posts about how to get started writing tests for Ruby on Rails. The series begins with the introduction and overview of the ideas behind testing.

Now that we have unit tests to insure that our models are related properly, we are ready to test our the validations in our models.

There are two approaches to testing your validations. It will be useful to examine both techniques because it will help you to write better tests overall. First, we need to write tests that confirm the code we have in place is working properly—as we have done thus far. Second, we need to think about special cases that we might not have coded into our validations already. This is where writing tests can really improve your code, and validations are a great place to see it in action.

Read the rest of this entry »

Sun Microsystems has purchased MySQL for $1 billion dollars. That sounds like a lot of money but. considering the popularity of MySQL, I think it was a bargain for Sun.

What does the purchase mean for developers? Nothing yet.

It’s as if your favorite restaurant just got a new head chef but the menu is the same. Some of the dishes may change slightly over time—you might not notice. Someday the chef may decide to make more radical changes, even revise the whole menu. Changes to the kitchen operations and to the food may improve the quality and service of the restaurant, or it could hurt it. But for the near future, you can still order your favorite dish, pretty much the way you’ve always had it.

This is part of an ongoing series of posts about how to get started writing tests for Ruby on Rails. The series begins with the introduction and overview of the ideas behind testing.

Unit Testing ActiveRecord

In the unit tests we wrote previously, we tested everything in the class. The rule of thumb was that everything needs to be tested. That has not changed now that we are working with ActiveRecord—each method still needs a test.

But what testing should be done on the basic database CRUD (Create, Read, Update, Delete)? After all, that is what is most different about classes that inherit from ActiveRecord, right? It may surprise you to learn that we do not need to test basic CRUD.

Why not? ActiveRecord handles all of our database activity for us. It knows how to connect to the database, how to create, find, read, update, delete, use conditions and sort. That is the reason why we are using a framework like Rails to begin with: because we can inherit all that ActiveRecord goodness without having to rewrite it ourselves. We can trust that ActiveRecord will do its job correctly.

photo by Tomás Castelazo

That is not blind trust—ActiveRecord has its own unit tests that the core Rails team uses to insure that it works properly. Therefore we can assume that everything our class inherits from ActiveRecord is solid and tested. It was unit tested before we installed it. We just need to focus on our code in the subclass.

The corollary to “Test Everything” is: “If it is code you added, it is code you need to test.”

Read the rest of this entry »

This is part of an ongoing series of posts about how to get started writing tests for Ruby on Rails. The series begins with the introduction and overview of the ideas behind testing.

Fixtures

In the most general terms, a test fixture is an environment for running tests which is in a fixed state (i.e. it is ‘fixed’). While the term is primarily associated with software development, it applies to any testing environment.

Think back to our car battery example for a moment. If we unit test the battery inside the car, there is a chance that our testing environment will throw off the results. Ideally, we would remove the battery from the car and put it in a test environment that we know is stable, thereby removing as many variables and potential sources of error as possible. Then our unit test results should be predictable, accurate and repeatable. The environment we put the battery in—the meters, the wires attached to it, the amount of voltage we put in or out, etc.—is the test fixture. It will stay the same during each test we run on the battery.

You have encountered fixtures in other contexts before without knowing it. A race track is an example of fixture. The cars and drivers racing around it are different, but the pavement and curves are the same for everyone. When a race (which is essentially a benchmark test) pits the cars against each other, the fixtures are important in ensuring that the winner is meaningful. Everyone faces the same conditions, yet one car will be faster than the rest. If every car raced on a different course the race results would be meaningless. Sports and competitive events are filled with examples of fixtures—generally known as “having a level playing field.”

The idea is to fix the environment so that the environment will not skew the results.

Read the rest of this entry »

I recently upgraded to Mac OS X Leopard. After the upgrade, MySQL was still working but PHP was not working at all. (The MySQL preference pane doesn’t work but I usually start and stop it from the command line anyway.) I discovered that there are three problems. I will briefly describe how to resolve them in case you have the same problem.

Read the rest of this entry »