Rails contributor Prem Si­cha­nu­grist reminded us about two releases that dropped last week. The first is Rails 3.2.15 which contains a security fix to patch a potential Denial of Service vulnerability in the log subscriber component of Action Mailer. So you better upgrade quick. The second release of the week is Rails 4.0.1 RC1 which — among over 450 bug fixes — deals with a regression in the way ActiveRecord handled chained calls to the order() method. Since this change had broken backward compatibility in Rails 4.0.0 and that release wasn’t supposed to introduce such changes, it was reverted. The Rails core team encourages testing release candidates so that regressions can be found and fixed early. To submit a bug report, check out Issues on the Rails GitHub repository.

Speaking of upgrading, I recently spent a lot of time learning about Rails 4, and one of the tools I used was Andy Lindeman’s ebook, called Upgrading to Rails 4. Last week he announced that he is open­-sourcing his book, so now if you learn something useful about Rails 4, or if something changes in Rails 4, you can add it to the book by submitting a pull request. You should still buy the book because it’s great, and Andy now donates all proceeds from the sales to a neat educational charity called CFY.

While playing with a brand new Rails 4 app this weekend I discovered a gem I wish I had known about years ago, it’s called migrant and it provides a simple DSL to define attributes inside your model so it’s easy to reference them. Unlike other gems like annotate_models or annotator, migrant offers a neat auto­ migration feature. I think Rails migration generators are a neat feature when discovering it, it’s always weird to me to be deciding what fields my ActiveRecord models should have in the console, instead of inside the model itself. With migrant, you call a structure method inside of your model, pass it a block. Within this block you can define the names of your model’s columns. You can specify their type, and even give example data or add comments to them. You just call rake db:upgrade and it will create a migration for each model and their respective attributes. It even works with serialized attributes, it creates validations, and even allows for column type changes. You don’t have to, it infers foreign keys for associations based on association declarations in the models. It even creates indices for those foreign keys, and you can also declare indices manually.

Mathias Meyer of the Travis CI team wrote an interesting blog post about the growth of the distributed architecture of Travis. In the post, Mathias goes over the lessons the team learned over the last few years as they went from 700 to 7000 builds a day, how they reduced the number of responsibilities of each piece of the system, and how — surprisingly — Travis is still running on a single Postgres database.

In a brief blog post, Josh Peek from GitHub discusses a recent decision to persist user sessions in the database instead of storing them in cookies entirely. Josh mentions that stateless session stores are vulnerable to replay attack which allow attackers to impersonate other users. Storing the session inside of cookies also makes it impossible to revoke a session, which can be a serious issue. They created their own UserSession model which allowed them to easily customize the behavior of the UserSession, for instance with a sudo mode that requires the user’s password to be entered at least once every hour when accessing sensitive settings. They still create a user_session cookie which references a unique ID generated by the UserSession model, but the only things stored inside of that cookie pertains to non-­sensitive data like flashes and form state.

Today only! Some feature testing tips, a tour through all things random with Ruby, Capistrano and Wicked get some updates, reactive_record, and your fairy godmother Ruby pays a visit to tell you all about Heroku support for Websockets.