Do you have long-running requests in your web applications? Say, requests that can take 30 seconds or longer. Before, you might run into web server queuing problems.
However, this is now a problem of the past. 37signals has sponsored the development of a new feature in Phusion Passenger called global queuing. Read more about this on blog.phusion.nl.
We’ve just released default_value_for, a plugin for declaratively defining default values for ActiveRecord models.
Using validates_uniqueness_of in conjunction with ActiveRecord::Base#save does not guarantee the absence of duplicate record insertions, because uniqueness checks on the application level are inherently prone to racing conditions. For example, suppose that two users try to post a Comment at the same time, and a Comment‘s title must be unique. At the database-level, the actions performed by these users could be interleaved in the following manner:
User 1 | User 2
------------------------------------+--------------------------------------
# User 1 checks whether there's |
# already a comment with the title |
# 'My Post'. This is not the case. |
SELECT * FROM comments |
WHERE title = 'My Post' |
|
| # User 2 does the same thing and also
| # infers that his title is unique.
| SELECT * FROM comments
| WHERE title = 'My Post'
|
# User 1 inserts his comment. |
INSERT INTO comments |
(title, content) VALUES |
('My Post', 'hi!') |
|
| # User 2 does the same thing.
| INSERT INTO comments
| (title, content) VALUES
| ('My Post', 'hello!')
|
| # ^^^^^^
| # Boom! We now have a duplicate
| # title!
This could even happen if you use transactions with the ‘serializable’ isolation level. There are several ways to get around this problem:
When the database catches such a duplicate insertion, ActiveRecord::Base#save will raise an ActiveRecord::StatementInvalid exception. You can either choose to let this error propagate (which will result in the default Rails exception page being shown), or you can catch it and restart the transaction (e.g. by telling the user that the title already exists, and asking him to re-enter the title). This technique is also known as optimistic concurrency control.
Active Record currently provides no way to distinguish unique index constraint errors from other types of database errors, so you will have to parse the (database-specific) exception message to detect such a case.
I’ve just contributed this documentation to docrails, so you’ll see it in Rails 2.2′s validates_uniqueness_of API documentation.
Today wiki.rubyonrails.org was briefly down, for like 30 minutes or so.
I thought it might be a problem in Phusion Passenger, seeing that the wiki is running on it. I wanted to the restart Apache, but I decided to look in the wiki log files before doing that.
It turned out the server ran out of disk space. I truncated the Apache log files, which were consuming 40 GB or so. After that, everything went back to normal.
Last time I blogged about the state of Ruby on Rails documentation. Those of you who have been around long enough probably remember manuals.rubyonrails.org. Back in the days, this website was very useful. But today, it’s horribly outdated. The first manual is “Upgrading to Rails 1.0″. I don’t think I need to say more.
In fact, it was not too long ago when that website was linked from rubyonrails.org. It appears they removed the link because it’s so old. But why hasn’t that website been updated?
Which is a shame. Some of the manuals on that site are really good, if only they’re more up to date.
Ever since I found out that the Ruby on Rails documentation on testing is horribly out of date, I’ve felt this irresistible urge to write documentation. In truth, I had been secretly contributing more documentation. And it was not without result. I’ve been working on converting some of the manuals to Asciidoc format while updating their content at the same time. Asciidoc is the documentation formatting tool used by Git. You write documentation in plain text files, and Asciidoc can convert it for you to HTML, Docbook, PDF, Unix man pages, etc. By saving the manuals in plain text files, they can be put on the Ruby on Rails source repository, so that everybody can contribute. Asciidoc is great – the Phusion Passenger manual is also written in it.
Unfortunately Asciidoc’s default HTML output layout isn’t good enough, and Asciidoc doesn’t allow you to specify a different layout. So I’ve spent my entire Saturday hacking together a new documentation formatting tool, based on Asciidoc: Mizuho. Mizuho accepts Asciidoc input files, and generates nicely formatted HTML. Multi-page HTML output is also supported! Furthermore, the HTML layout can be customized with ERB templates.
How does the result look like? Here are some previews:
These have been generated by Mizuho with the “manualsonrails” template.
I’ve committed the new Asciidoc-formatted manuals to the docrails repository, so you are likely to see a revival of manuals.rubyonrails.org. You can find the manuals source files under railties/doc/guides/.
I’ve spent some time updating “A Guide to Testing Rails Applications”, but it’s likely still out of date. If anyone spots outdated information, please contribute a patch. Thanks. 
Jeremy has recently stated his concerns about the state of Ruby on Rails documentation. It isn’t the first time that people have criticized the documentation, but it is a bit worrisome that people are apparently posting less documentation blog entries about Ruby on Rails. The Ruby on Rails website itself is also in a pretty bad shape: it has many broken links and some information is outdated. (it actually recommends FastCGI as a viable deployment platform 
)
But complaining and criticizing will only get one so far. The best way to improve the documentation is by… well… improving it!
People have heavily criticized api.rubyonrails.org. It’s basically just an rdoc dump, and I don’t think it’s that bad. I actually like the javadoc-style usage of frames that allows me to quickly navigate through the different classes of modules. It has no search functionality, but that’s okay because I can easily navigate. I’ve never been a fan of N00bkit or RailsBrain. They look nicer but they’re also harder to navigate because of the way they sort the classes and modules.
Then came Rails-Doc.org. I like Rails-Doc.org. No, I love Rails-Doc.org!
Apart from these, I can’t really describe why Rails-Doc.org is better. It’s a feeling. Maybe it’s because of the way it looks. It just feels more comfortable than the other API doc sites when I use it, and because of that I’m encouraged to contribute useful comments (which I have).
I’ve ditched api.rubyonrails.org completely, in favor of Rails-Doc.org. Nice job, Nodeta! Too bad I can’t use Rails-Doc.org offline.
Posting comments on Rails-Doc.org is nice and all, but one should ideally change the API documentation directly.
A while ago, Pratik Naik announced the docrails project. Anybody can contribute API documentation, just give Pratik a call and he’ll grant you write access to the repository. Every once in a while he reviews the changes and pushes them to the main Rails repository.
Yesterday I tried to write some functional tests for an application that I’m working on, only to find out that the Rails testing manual is outdated and that the API documentation on functional tests is almost nonexistent. So I thought, this is a good opportunity to contribute to docrails. Within a few minutes, Pratik gave me commit access and I contributed some documentation. (more) While I was at it, I also merged some of the user comments that I posted on Rails-Doc.org back to the API documentation.
So, I strongly recommend everybody to contribute. Head to http://github.com/lifo/docrails/tree/master and commit away!
I’m currently working on a Rails application. It has some non-trivial business rules, so I ended up writing test methods along the lines of:
Okaaaay….. This is what I think of that method name:
Nice boat!
Other than the mental-psychological stress as well as an unexplainable impending feeling of doom that such a long method name brings forth in our minds, one have to ask oneself whether it is morally justified to unintentionally punish whomever will ever read this code by presenting them with such a NICE BOAT, even if said person deserves it.
As much as I love RSpec, it doesn’t feel totally appropriate to use it, because then everything must start with “it”. Unfortunately not all rules in my application can be described with sentences that start with “it”. Rails edge has a solution though. You can define test methods in a declarative style ala RSpec, like this:
After staring at my test cases for the 2^32th time in a futile attempt to understand what the test method names are actually trying to tell me, I gave up and decided that it’s time to dig up a series that I’ve been trying to finish for the past 3 months. Surely only this will save me from going completely insane.
The face of un-insanity (?)
There Chu Yeow, I did what you asked me to do.
Baka baka baka! ….or maybe not.
Anyway, under the hood, the test method translates that block to:
That’s nice. But it could be nicer. I don’t want to upgrade to Edge so I decided to copy & paste the ‘test’ method from ActiveSupport edge – it’s only 6 lines. And yesterday I found out that it’s apparently possible for method names to contain arbitrary binary data, except “\0″. So you can do this:
Cool! So this means we can have RSpec-style test method names even when using Test::Unit.
So I modified the test method a little bit. Copy and paste this into your test/test_helper.rb to enjoy this:
My test method now becomes:
Phusion Passenger™ 2.0 RC 1 and Ruby Enterprise Edition have finally been released. See http://blog.phusion.nl/2008/06/09/phusion-passenger-20-rc-1-and-ruby-enterprise-edition-released/ for the announcement.
http://www.RubyEnterpriseEdition.com/ has been “launched”.
Next hint to be revealed on May 20, 2008.
Please help us with modding/digging these up.
