The results of the Rails Hosting Survey for 2009 are out. Thanks to Planet Argon for putting it together!

With about 1250 respondents, it has some pretty interesting results.

Here are the things that stood out to me:

• 63% use Git vs. 36% use Subversion. I knew Git was growing fast, but I didn’t expect 2:1 over SVN.
• 75% use Capistrano. About 25 percentage points higher than I would have guessed.
• 97% use either MySQL or PostgreSQL. I’m not surprised how popular they are, I’m surprised that all other database make up only 3%.
• 68% Mac, 25% Linux, 7% Windows. I know “everyone” uses Mac, but I’m surprised Windows is that low.
• 37% use Hoptoad to manage application exceptions. I had never heard of it and will have to check it out.
• 68% don’t use uptime monitoring tools. 60% don’t use any process monitoring tools. Is that a reflection of improved reliability and ISP/Hosts providing the monitoring? Or is it just hope-for-the-best developers who will wait to hear from users that the site is down? (Of which I am frequently guilty.)
• 25% use Nginx for their webserver. That’s a lot considering only 2% of all websites uses Nginx. It’s an interesting trend to keep an eye on.
• And finally, WOW some people are paying a lot for their hosting. More than $50K/month?!?! I’m dying to know who that person is.

I only wish the results had included more information about the survey sample. How did they get their sample? Independent or corporate developers? What size companies? What country and/or U.S. state are they from? If 20 developers taking the survey are all from the same company then it will skew the results in favor of that companies preferences. If they are all from San Francisco, then it says more about SF than about Rails preferences worldwide.

But it is an interesting and informative snapshot nonetheless.

I have been very delinquent in posting to this blog. Fatherhood plus several big projects have forced me to put it on the back burner. I’m hoping to resume regular blogging in January.

But until then, I do want let everyone know that Rails 2.2.2 is out. Here’s the announcement. There are lots of new features that make the upgrade worthwhile.

A few notes about upgrading though. You need RubyGems 1.3.1 first. Here’s how I upgraded RubyGems, including the error I got while trying.

Next, edit the /config/environment.rb file in each of your Rails applications so that RAILS_GEM_VERSION is 2.2.2. Now you application will demand the new Rails version. (Even if you didn’t do a “gem cleanup” and still kept the old version installed. As long as you have both versions of the Rails gem, you can have some applications loading up 2.2 while others use still use the old Rails version.)

Then from the root of each of your Rails applications, you can run rake rails:update to update the application to the new version. (Never a bad idea to make a backup copy first.) What does that update change? It may depend on your current Rails version, but for me, it updated the default JavaScript files and also /config/boot.rb.

I installed the latest version of attachment_fu for a project I’m working on. I ran into a problem that I wanted to document here in case anyone else runs into the same thing.

The before_thumbnail_saved callback in attachment_fu is useful for tasks like giving thumbnail versions the same attributes that parent images have. So if an image belongs to an artist, the callback can give the thumbnail the same artist_id as the parent. The callback originally yielded two values to a block—record and thumbnail—like this:

But now it yields only one value: thumbnail. To get the same functionality as before, you will need to add a line of code to first find the parent record.

If you haven’t tried attachment_fu yet, here are some links you may find helpful:

• Install RMagick on Mac OS X Leopard from source
• Mike Clark’s attachment_fu Tutorial

Rails 2.1 removed the original scaffold generator and replaced it with a new RESTful scaffold generator.

Bummer.

I’m not talking about the dynamic scaffolding that comes from putting “scaffold :model” in a controller. That “dynamic scaffolding” was removed in Rails 2.0 and few of us miss it. I’m talking about when you type “ruby script/generate scaffold Model” from the command line and get generated model, controller and view files as a result.

While I understand that Rails is “opinionated software” and that they want to encourage everyone to get on the REST bandwagon, I think completely removing the old scaffold generator was a mistake for one simple reason:

It unnecessarily raises a barrier to entry for beginners.

When beginners first start on Rails there is a lot to digest. Installation issues, Ruby language, MVC architecture, ActiveRecord, Rails syntax, routes, migrations and deployment—just to name a few. In my opinion, asking someone eager to learn Rails—someone who may have a background in PHP but who still doesn’t understand code blocks or the basic Rails .find syntax—to also use REST from the start is only going to frustrate them and slow the growth of Rails adoption. They need to walk before they can run. We have added best practices for advanced users at the expense of the newbies.

(more…)

A student sent me email to ask: “In a general sense, when writing code, is there a sequence of steps or a pattern to the logic when writing the code?”

It’s a good question. Experienced computer programmers have learned these steps—either through intuition or experience—but beginning programmers are often mystified. Once you learn the language syntax, how exactly do you use it to approach a programming problem? Especially if you want to try to use good programming techniques and to solve the problem in a smart and efficient way.

The answer to the question “Are there steps to writing code?” is “Yes”. After the jump, I’ll give three ways to develop the logic necessary to write good code.

(more…)

A List Apart, Issue #257, has two articles on Ruby on Rails. Both articles are targeted toward Rails beginners and curious designers who may have heard the buzz but few details.

The information may be old news for many developers, but both articles are up-to-date, well-written introductions that are still worth bookmarking. Save them for the next time a beginner asks you for an explanation. Forward them to co-workers who don’t understand what you’ve been raving about. Print them out and leave them laying around so your most earnest PHP/.NET/Java friends can sneak a peak at them when no one is looking. Maybe they can even help explain to your parents/friends/significant-other what you do for a living.

• Creating More Using Less Effort with Ruby on Rails by Michael Slater
• Getting Started with Ruby on Rails by Dan Benjamin

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.

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.

(more…)

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.

(more…)