Thousands of developers have used the first edition of Rails Recipes to solve problems known to stop even experienced programmers in their tracks. Now, five years later with Rails 3.1 released, it's time for a new edition of this tested collection of solutions, completely revised by Rails master Chad Fowler.
I’m excited to announce that as of today (March 28th), I’ve accepted a new position at LivingSocial! I’m an Engineering Director, managing a few teams that work on backend architecture such as email, scaling, etc.
For the past 5 years, Engine Yard has been an amazing employer. Back in 2007, Tom Mornini took a chance on hiring me, enabling Rubinius to progress in a way it never would have otherwise. I can’t say enough about how much I appreciate everything they’ve done for me. It has been an embarrassment of riches.
So what does all this mean for Rubinius? Rubinius started as a passion project and continues to be. I’ll keep working on the project in all the same roles I have in the past. Because I won’t have the same amount of time, I’ll be doing more project management so that the amazing Rubinius community has a clearer picture of the work that is outstanding and can apply their talents to help move things forward.
I know some of you will read this and say “Evan left EY? Rubinius is dead.” I ask that you reserve judgement. The Rubinius community is an amazing group and I know that we all will continue to build a great platform. Brian Ford will continue working on Rubinius full-time and doing his amazing work getting Rubinius 2.0 finished.
I want to close by saying again how truly amazing Engine Yard is. I’ll always call this experience one of the most amazing opportunities of my life. For me, this decision was driven entirely by the chance to help LivingSocial build their architecture. I wish Engine Yard all the best and I’ll continue to help them with Rubinius related ventures in the future.
Working in the View layer requires a breadth of knowledge and attention to detail unlike anywhere else in Rails. One wrong move can result in brittle, complex views that stop future development in its tracks. This book will help you break free from tangles of logic and markup in your views as you pick up the practical skills you need to implement your user interface cleanly and maintainably.
In a recent post, I talked about how the Rails first and limit/offset modifiers to queries are not specified to return a particular result—databases are free to determine the order of rows in a result set if the query doesn't contain an explicit order by clause, so the actual row(s) returned by these methods may not be determined.
Some folks responded (in comments, tweets, and emails) by suggesting that you can easily solve this problem by adding a default_scope call at the top of models that you use first and offset on. Ignoring the fact that this really isn't a solution (both the names first and offset imply an ordering which they don't deliver, and the fix should be in them); ignoring that, the suggestion might lead to another unexpected problem.
Lets start with a simple ActiveRecord model:
class Wish
end
Executing Wish.limit(10).offset(10).to_sql returns the SQL
SELECT `wishes`.* FROM `wishes` LIMIT 10 OFFSET 10
Noticing the lack of an order by clause, you add a default scope:
class Wish
default_scope order(:id)
end
Now when we execute the query, the SQL contains an order by clause:
SELECT `wishes`.* FROM `wishes` ORDER BY id LIMIT 10 OFFSET 10
Cool. Problem fixed.
However, the user also wants a list of the 3 most recent wishes, so you code
Wish.order("created_at desc").limit(3)
Imagine your chagrin when you look at the SQL that gets run and see
SELECT `wishes`.* FROM `wishes` ORDER BY id, created_at desc LIMIT 3
Because the id column is unique, it totally determines the ordering—the created_at desc part of the query has no effect.
Once you add a default_scope with an order clause to a model, all subsequent finders on that model will have that order as their primary ordering. If you want some other order, you'll need to remember to add unscoped to the chain:
Wish.unscoped.order("created_at desc").limit(3)
And that's an accident waiting to happen.
The ActiveRecord component in Rails offers a convenient and powerful interface between the set-oriented world of relational databases and the object-oriented world of Ruby programs. However, there's a potential bug lurking in many (if not most) Rails applications due to a subtle implication of the fact that sets, and hence database result sets, and not ordered.
Take a simple ActiveRecord call such as Post.first. Ask Rails developers what this does, and most will say that it returns the first row from the posts table. And, most of the time for small to medium size tables, on most database engines, it does. But thats purely a coincidence, because SQL does not define the order of rows in an SQL result set—database engines are free to return rows in an order that is convenient for them unless an explicit order by clause is used. But the SQL generated by ActiveRecord for this query is select `posts`.* from `posts` limit 1.
When talking about select statements, the Mysql reference says: You may have noticed in the preceding examples that the result rows are displayed in no particular order. The Oracle documentation says Without an order_by_clause, no guarantee exists that the same query executed more than once will retrieve rows in the same order. And PostgreSQL says If ORDER BY is not given, the rows are returned in whatever order the system finds fastest to produce.
So that innocent select statement is just returning a row at the whim of the database engine. It could be the first. It could be the 42nd. It could be any row. The same applies to queries using limit and offset, often used to paginate results. Call Post.limit(10).offset(10) and ActiveRecord executes select `posts`.* from `posts` limit 10 offset 10. Again, there's no ordering applied, and no guarantee that the same rows will be returned given the same query.
Does this actually affect us? Not often. In fact, probably you're never seen it happen. I have seen the results of a query change when using Oracle. As a table filled, Oracle decided to reorganize an index. As a result, paginating through a set of orders suddenly stopped displaying orders in date order. Adding an explicit order by fixed it.
The moral? Well, first, this isn't a big deal. But, whenever you use finders that assume an ordering in a result set, make sure you make the order explicit—add an order() call to the ARel chain. If you want first() to be compatible with last(), add order("id") to the call to first() (because, somewhat inconsistently, last() currently does add an order by id clause). If you want your paginated result sets to be consistent, make sure you order them (perhaps by id, or by created_at).
Rather than arouse speculation and keep you in unnecessary suspense,
What an awesome weekend to be unencumbered and unemployed! ...
— Nick Sieger (@nicksieger) March 16, 2012
I’m happy to announce that I’m joining the Living Social team on Monday! Besides the obvious reason of jumping at the chance to work with the caliber of team they’re building, I see this new opportunity as a chance to focus my attention. More about this below.
Of course that means I’m leaving Engine Yard. They have been a great company to work for, and continue to be. I’m extremely grateful that they have supported myself, Charlie, Tom, and the JRuby project for the past two and a half years. If you have a passion for developer tools, cloud computing, virtualization, and customer satisfaction, I would still recommend them unequivocally.
While being paid to work on open source is certainly a dream job for many, I’ve learned that I work better (and feel better about my work) when I have fewer immediate goals in front of me, and something to focus on. Open source is still great fun that I intend to enjoy when I have some time and inspiration to put something into it.
So what does this mean for my involvement with JRuby? Nothing at all, really. Of course, I won’t be working on JRuby full-time. I have already been soliciting new contributors for JRuby-Rack, Warbler, and AR-JDBC, and many of you have stepped up your involvement and contributions (thank you!). These projects will still keep moving, and I intend to still help out when I can. I still am very much personally invested in seeing JRuby win, and I think that JRuby continues to gain traction all over the place. And I still am involved and invested in making JRubyConf a top-notch experience this year in my hometown Minneapolis. (Please join us!)
So, [insert your change metaphor here]. Life goes on. Gotta keep moving!
Speak directly to your system. With its simple commands, flags, and parameters, a well-formed command-line application is the quickest way to automate a backup, a build, or a deployment and simplify your life.
Learn from legendary Japanese Ruby hacker Masatoshi Seki in this first English-language book on his own Distributed Ruby library. You'll find out about distributed computing, advanced Ruby concepts and techniques, and the philosophy of the Ruby way---straight from the source.
Over the years I have seen some confusion about what is exactly docrails and how it relates to the documentation of Ruby on Rails.
This post explains everything you want to know about this aspect of the project.
docrails is a branch of Ruby on Rails with public write access where anyone can push doc fixes.
If you see a typo, you'd like to correct a factual error, complement some existing documentation, add a useful example... before docrails existed you had to open a pull request (or the equivalent in those days) and follow the ordinary workflow to get it accepted. docrails allows you to clone the repo, edit, and push. Done!
Changes to the code base need review before they are pushed. Each individual new feature or bug fix needs the perspective and responsability of core team members to take a decision about it.
Documentation fixes, though, are much more likely to be fine as they are. So, docrails has a public write policy to ease the workflow for contributors.
All commits have to be reviewed anyway, so docrails needs the same effort from Rails committers than going through pull requests, please everyone give big props to Vijay Dev who is nowadays in charge of this time consuming task.
The point of docrails is to provide a way to contribute to the Rails documentation that is fast and easy for contributors.
docrails is a separate branch because it has a different access policy, but you are editing the actual Ruby on Rails documentation.
Every few days, once all new commits are reviewed docrails is merged into master, and master is merged into docrails. Also, very important edits may be cherry-picked into stable branches at the discrection of who merges.
You can freely push changes to any RDoc, guides, and READMEs.
No code can be touched at all. That's a hard rule. No matter how insignificant, not even a one character typo in a string literal.
CHANGELOGs cannot be edited either.
No, Ruby on Rails has no documentation project. Treating documentation as a separate aspect of the project would be similar to treating testing as an external part of the project.
Documentation is an integral part of the development of Ruby on Rails. Contributing a feature or bug fix means contributing its code, test coverage, and documentation.
No, docrails is meant only for quick doc fixes.
Pull requests should be complete: code, tests, and docs. If a pull request lacks any of those in general it won't be accepted as is.
Also, updating docs does not only mean that you edit the RDoc next to the code you are touching. Often the change needs grepping the project tree to find instances of what the pull request is about, to update examples, revise explanations affected by your change, or writing new documentation.
Tidbit: run ack -a to have guides included in the search.
Rails releases are a complete set. The documentation itself is part of the release. The fix is going to be online in the stable API or guides websites when the branch that contains the fix gets released.
Edits merged into master are always online in the edge API and edge guides, which are regenerated after every push to master. Thus, edits done via docrails are online in the edge docs website after the next docrails/master cross-merge.
Absolutely. Specially if you are unsure about the fix. But if you feel confident just push to docrails.
Please do not open pull requests in docrails.
Note that docrails has no issues tab. The reason is docrails is not a project, as explained above, only a way to bypass pull requests. Documentation issues are Ruby on Rails issues and belong to the Ruby on Rails project just as any other kind of issue.
No, documentation comes with each push to master. Everyone documents Rails.
The only exception is guide authors. Guide authors take the task to write an entire new guide about a certain topic, and they are allowed to push early drafts to docrails for convenience (only guides in the public index are considered to be published).
That's for new guides. Once published, guides maintenance happens in master as everything else.
Rails 3.2.2 has been released. This release contains various bug fixes and two important security fixes. All users are recommended to upgrade as soon as possible.
For information regarding the possible vulnerabilities, please see the announcements here and here.
Some highlights from this release are:
Log files are always flushed
Failing tests will exit with nonzero status code
Elimination of calls to deprecated methods
Query cache instrumentation includes bindings in the payload
Hidden checkbox values are not set if the value is nil
Various Ruby 2.0 compatibility fixes
For a comprehensive list, see the commits on github.
Rails 3.1.4 has been released. This release contains various bug fixes and two important security fixes. All users are recommended to upgrade as soon as possible.
For information regarding the possible vulnerabilities, please see the announcements here and here.
Some highlights from this release are:
thrrubyrhino is added to the Gemfile for JRuby users
Routing cache improvements
Assets group may be skipped with the --skip-sprockets flag
Various Ruby 2.0 compatibility fixes
For a comprehensive list, see the commits on github.
Rails 3.0.12 has been released. This release contains various bug fixes and two important security fixes. All users are recommended to upgrade as soon as possible.
For information regarding the possible vulnerabilities, please see the announcements here and here.
Some highlights from this release are:
require and load will return the value from the superclass
ActiveModel confirmation validation fixes
Increasing rack dependency
For a comprehensive list, see the commits on github.
The HTTP method PUT means resource creation or replacement at some given URL.
Think files, for example. If you upload a file to S3 at some URL, you want either to create the file at that URL or replace an existing file if there's one. That is PUT.
Now let's say a web application has an Invoice model with a paid flag that
indicates whether the invoice has been paid. How do you set that flag in a
RESTful way? Submitting paid=1 via PUT to /invoices/:id does not conform to
HTTP semantics, because such request would not be sending a complete representation of the invoice for replacement.
With the constraints of the methods GET, POST, PUT, DELETE, the traditional answer
is to define the paid flag of a given invoice to be a resource by itself. So,
you define a route to be able to PUT paid=1 to /invoices/:id/paid. You have
to do that because PUT does not allow partial updates to a resource.
Now let's think about ordinary edit forms in typical Ruby on Rails applications.
How many times are we sending a complete representation for replacement? Not
always, perhaps we could say that it is even rare in practice that you do so.
For example, the conventional created_at and updated_at timestamps normally
can't be set by end-users, though they are often considered to belong to the
representation of resources that map to records.
PUT in addition is an idempotent method. You should be able to replay a request as many times as you want and get the same resource, something that sometimes is violated by conventional idioms for creating children resources using nested attributes while updating a parent resource.
There's nothing theoretical preventing PUT from doing partial updates, but when HTTP was being standarized the replacement semantics were already deployed.
Because of that, the PATCH method was defined in 1995 and standarized later. PATCH is a method that is not safe, nor idempotent, and allows full and partial updates and side-effects on other resources.
In practice, as you see, PATCH suits everyday web programming way better than
PUT for updating resources. In Ruby on Rails it corresponds naturally to the way
we use update_attributes for updating records.
Thus, PATCH is going to be the primary method for updates in Rails 4.0.
This is an important change, but we plan to do it in a way that is backwards compatible.
When a resource is declared in config/routes.rb, for example,
resources :users
the action in UsersController to update a user is still update in Rails 4.0.
PUT requests to /users/:id in Rails 4.0 get routed to update as they are
today. So, if you have an API that gets real PUT requests it is going to work.
In Rails 4.0, though, the router also routes PATCH requests to /users/:id to
the update action.
So, in Rails 4.0 both PUT and PATCH are routed to update.
Forms of persisted resources:
form_for @user
get "patch" in the hidden field "_method". The RFC is deliberately vague about the way to represent changes in a PATCH request. Submitting a form is perfectly valid, client and server must simply agree on the accepted ways to update a resource.
Let me emphasize that the "_method" hack is a workaround for the limitations in web browsers. As you probably know Rails routes real HTTP methods. That is, actual PUT, DELETE, and now, PATCH requests are routed to their respective actions.
PATCH requests are available in all places where the rest of the methods are
available today. There is a patch macro for the routes DSL, :via understands
the symbol :patch. Tests can issue PATCH requests, request objects respond to
patch?, etc. Please see the original commit for details (with an important
followup here).
Yes, it should. I have personally tried Apache, nginx, Phusion Passenger, Unicorn, Thin, and WEBrick. They all understood PATCH requests out of the box.
Also, HTTP clients should be in general able to issue PATCH requests. For example in curl(1) you'd execute:
curl -d'user[name]=wadus' -X PATCH http://localhost:3000/users/1
We would like to thank David Lee for this contribution and endless patience to keep interested in this even after months of discussion.
Also I would like to highlight the quality of the patch itself. It is excellent: code, tests, all docs revised, comments in code revised. Everything carefully and thoroughly updated. An exemplar patch.
I've been really enjoying James Edward Gray II's Rubies in the Rough articles. Every couple of weeks, he publishes something that is guaranteed to get me thinking about some aspect of coding I hadn't considered before.
His latest article is part I of an exploration of an algorithm for the Hitting Rock Bottom problem posed by by Gregory Brown & Andrea Singh. At its core, the problem asks you to simulate pouring water into a 2D container, filling it using a simple set of rules.
As I was coding up my solution, I found I had code like
Here " " is a cell containing air, and "~" a watery cell. So clearly we should create some named constants for that:
But it occurred to me that we could use Ruby's singleton methods to give AIR and WATER a little smarts:
Now you could argue that the cave object should do this: cave.watery?, or that the individual elements in the cave should be objects that know their moisture content, rather than simply characters. I don't agree with the first (simply because the cave is the container, and the water/air is the separate stuff that goes into that container). I have a lot of sympathy for the second, and I'd probably end up there given a sufficiently large nudge during a refactoring.
But, for the problem at hand, simply decorating the two constants with a domain method seems to result in code that is a lot more readable. It isn't a technique I'd used before, so I thought I'd share.
(And remember to check out Rubies in the Rough…)
Your customers want rock-solid, bug-free software that does exactly what they expect it to do. Yet they can't always articulate their ideas clearly enough for you to turn them into code. The Cucumber Book dives straight into the core of the problem: communication between people. Cucumber saves the day; it's a testing, communication, and requirements tool - all rolled into one.
Rails 3.2.1 is out, with some fixes and doc improvements. Please check the CHANGELOGs gist for details.
So we didn’t quite make the December release date as we intended, but hey, why break a good tradition and start hitting release targets now! In any case, your patience has been worldly rewarded young grasshopper: Rails 3.2 is done, baked, tested, and ready to roll!
I’ve been running on 3-2-stable for a few months working on Basecamp Next and it’s been a real treat. The new faster dev mode in particular is a major step up over 3.1.
Do remember that this is the last intended release series that’s going to support Ruby 1.8.7. The master git branch for Rails is now targeting Rails 4.0, which will require Ruby 1.9.3 and above. So now is a great time to start the work on getting your app ready for the current version of Ruby. Let’s not hang around old versions forever and a Sunday like those Python guys :).
There’s a v3.2.0 tag on Github and we of course we still have the 3-2-stable branch as well. You can see all the glorious details of everything that was changed in our CHANGELOG compilation.
For documentation, we have the 3.2 release notes with upgrade instructions, both the API docs and the guides have been generated for 3.2 as well, and there’s a brand new 3.2-compatible version of Agile Web Development with Rails. A smörgåsbord indeed!
Note: If you’re having trouble installing the gems under Ruby 1.8.7, you’ve probably hit a RubyGems bug with YAML that’s been fixed in RubyGems 1.8.15. You can upgrade RubyGems using “gem update—system”.
If you can’t be bothered with the full release notes, here’s a reprint of a few feature highlights from when we did the first release candidate:
Faster dev mode & routing
The most noticeable new feature is that development mode got a ton and a half faster. Inspired by Active Reload, we now only reload classes from files you’ve actually changed. The difference is dramatic on a larger application.
Route recognition also got a bunch faster thanks to the new Journey engine and we made linking much faster as well (especially apparent when you’re having 100+ links on a single page).
Explain queries
We’ve added a quick and easy way to explain quieries generated by ARel. In the console, you can run something like puts Person.active.limit(5).explain and you’ll get the query ARel produces explained (so you can easily see whether its using the right indexes). There’s even a default threshold in development mode where if a query takes more than half a second to run, it’s automatically explained inline—how about that!
Tagged logger
When you’re running a multi-user, multi-account application, it’s a great help to be able to filter the log by who did what. Enter the TaggedLogging wrapper. It works like this:
Logger = ActiveSupport::TaggedLogging.new(Logger.new(STDOUT))
Logger.tagged("BCX") { Logger.info "Stuff" } # Logs "[BCX] Stuff"
Logger.tagged("BCX") do
Logger.tagged("Jason") do
Logger.info "Stuff" # Logs "\[BCX\] \[Jason\] Stuff"
end
endActive Record Store
Key/value stores are great, but it’s not always you want to go the whole honking way just for a little variable-key action. Enter the Active Record Store:
class User < ActiveRecord::Base
store :settings, accessors: [ :color, :homepage ]
endu = User.new(color: 'black', homepage: '37signals.com')
u.color # Accessor stored attribute
u.settings[:country] = 'Denmark' # Any attribute, even if not specified with an accessorDear Sen. Klobuchar, Sen. Franken, and Rep. Ellison,
I am writing to express my deep concern about the pending SOPA/PIPA legislation. I have seen reports that Sen. Franken and Sen. Klobuchar are both in favor of this legislation. This troubles me.
I see the intense legal pressure applied by the movie and recording industries to Congress as evidence that they simply don’t understand how to run their businesses in an ever changing technological landscape. They should realize that they could increase revenues by embracing new channels of distribution instead of wasting time tracking lost revenues due to piracy or fraud.
Based on this view, I see SOPA/PIPA as yet another misguided government attempt to intervene, prop up, and rescue an industry that doesn’t know how to alter its own business models to align with the current economic and technological climate. This attempt comes at the expense of taxpayers and citizens who view freedom of speech and information as inherent, unalienable rights.
Frankly, I find the amount of money raised for Sen. Franken and Sen. Klobuchar to be a disgusting example of special interests buying legislation. As a constituent of the the state of Minnesota and its fifth congressional district, I urge Sen. Franken, Sen. Klobuchar, and Rep. Ellison to return all funds contributed for and against this legislation and to remove any support for this bill.
Regards,
Nick Sieger
Hi everyone,
Rails 3.2.0.rc2 has been released!
vendor/plugins/*. These are finally deprecated!Extract your vendor/plugins to their own gems and bundle them in your Gemfile. If they're tiny, not worthy of the own gem, fold it into your app as lib/myplugin/* and config/initializers/myplugin.rb.
ActionMailer
ActionPack
Add font_path helper method Santiago Pastorino
Depends on rack ~> 1.4.0 Santiago Pastorino
Add :gzip option to caches_page. The default option can be configured globally using page_cache_compression Andrey Sitnik
ActiveModel
ActiveRecord
ActiveResource
ActiveSupport
Railties
Rails 2.3-style plugins in vendor/plugins are deprecated and will be removed in Rails 4.0. Move them out of vendor/plugins and bundle them in your Gemfile, or fold them in to your app as lib/myplugin/* and config/initializers/myplugin.rb. Santiago Pastorino
Guides are available as a single .mobi for the Kindle and free Kindle readers apps. Michael Pearson & Xavier Noria
Allow scaffold/model/migration generators to accept a "index" and "uniq" modifiers, as in: "tracking_id:integer:uniq" in order to generate (unique) indexes. Some types also accept custom options, for instance, you can specify the precision and scale for decimals as "price:decimal{7,2}". Dmitrii Samoilov
You can find an exhaustive list of changes on github. Along with the closed issues marked for v3.2.0.
You can also see issues we haven't closed yet.
Thanks to everyone!
The forthcoming 3.2.x release series will be the last branch of Rails that supports Ruby 1.8.7. There’s a new 3-2-stable branch in git to track the changes we need until 3.2.0 final is release and for managing point releases after that.
So for now you should stop floating on rails/master if your application is not compatible with Ruby 1.9.3. We have updated the version numbers to indicate this backwards incompatibility to be 4.0.0.beta. This doesn’t mean that 4.0 is anywhere close to being released, mind you. We’re simply doing this now because we’re dropping support for Ruby 1.8.7 in rails/master and people should know what’s up.
Major versions of Rails has been on about 2-year release cycle since 1.0 (released in 2005, followed by 2.0 in 2007, followed by 3.0 in 2010) and we intend to continue this pattern. The current internal target for Rails 4.0 is sometime in the Summer of 2012 — but we have blown every major release estimate in the past, so don’t bet your farm on it.
There’s not a lot of details about what we’re going to include in Rails 4.0 yet as the primary purpose for bumping the major version number is to drop Ruby 1.8.7 support. But unlike Rails 3.0, we intend for it to be a much smoother transition. The intention is not for this to be a REWRITE EVERYTHING release in the same way 3.0 was to some extent.
But we’re getting ahead of ourselves. First mission is to get Rails 3.2 out!