Decorating Sorcery's current_user with Draper

I already wrote about how to apply your decorator to the current_user when you’re using Devise. However, the trick is a bit different when applied to Sorcery. Instead of being nil when no user is signed in, Sorcery uses an explicit false value, no nil. In your ApplicationController at app/controllers/application_controller.rb add this: def current_user UserDecorator.decorate(super) unless super == false end I’m using the most recent version of Draper by the way.

Rails migrations: decimal precision and scale

I’m always confused when using decimal in a Rails migration. Normally I need to store a value that has 2 or 3 numbers behind the comma (or dot), or decimals. Let’s say you have a Product model with a discount_percentage attribute. This attribute is currently an integer, only allowing non-decimal values. To allow 2 digit decimal values (e.g. 12.54), you can mak the following migration: change_column :products, :discount_percentage, :decimal, precision: 5, scale: 2 This will allow you to store values like 80.

Search and Replace in multiple files with Vim

I recently learned a nice VimTrickā„¢ when pairing with Arjan. We upgrade an app to Rails 3.2.6 and got the following deprecation message: DEPRECATION WARNING: :confirm option is deprecated and will be removed from Rails 4.0. Use ':data => { :confirm => 'Text' }' instead. Well, nothing difficult about that, but we have quite a few :confirm in this app. Firstly we checked where we used them (note we use ruby 1.

Decorating Devise's current_user with Draper

I’ve become a big fan of decorators, especially Draper. Decorators allow you to move view related functionality for your models in to separate decorator classes. This keeps both your models and views clean and readable. Anyway, if you use Devise you’re provided with a current_user helper. However, this helper returns an instance of User - without your decorators. To enable decorators for your current_user by default, simple add this to app/controllers/application_controller.

Showing Ruby, Rails and git info in your app

Some people’ve asked me how I show rendering information on ariejan.net. There are a few things going on here, let me explain them one by one. Rails version The current Rails version is probably the easiest you see here. Rails exposes its version information like this: Rails.version Ruby version Ruby also exposes version information, albeit using constants: RUBY_VERSION => "1.9.3" You may know that ruby also has different patch levels for each release.

Automatically switch between SSL and non-SSL with Nginx+Unicorn+Rails

Scroll down for setup instructions. Or, read this bit about SSL in the real world first. SSL or Secure Socket Layer is a nice way to secure sensitive parts of your Rails application. It achieves to goals. Firstly is encrypts all traffic between you and the remote server. Consider the passwords and personal information you submit to websites. When unencrypted (using HTTP), all this data is sent over the internet for all to read.

Rails 3: Customized exception handling

Exceptions happen. There’s no way around that. But not all exceptions are created equally. For instance, a 404 “Not found” error can (and should) be handled correctly in your application. Let me give you an example of how to handle a ActiveRecord::RecordNotFound exception. Let’s assume you have an application that could show a user profile: # GET /p/:name def show @profile = Profile.find(params[:name]) end Now, it may happen that the :name paramater contains a value that cannot be found in our database, most likely because someone made a typo in the URL.

Fast specs - Run your specs in less than 1 second

Okay, let me clarify that title first. I, as most of you, have two sets of tests for my Rails application: rspec and cucumber. rspec heavily focusses on testing models and business logic while cucumber focusses on testing the entire application stack and user interaction. The problem is that as your app grows, your test set grows - and so does the time it takes to run those tests.

Testing Rails 3 scopes revisited

In my previous article I told you about how I like to tests my scope. There was a fair amount of criticism on that post and after considering it all (and hearing Corey Haines’ talk on Arrrrcamp last friday), I’m convinced it’s the wrong path. In essence Rails allows you to create a scope to generate a custom database query for you. Now, if you only test your configuration of Rails (as I did in my previous post), you don’t know if that scope works or not.

Properly testing Rails 3 scopes

The content of this post is no longer correct. Please read this article for details. Testing scopes has always felt a bit weird to me. Normally I’d do something like this: class Post < ActiveRecord::Base scope :published, where(:published => true) scope :latest, order("created_at DESC") end describe Post do context 'scopes' do before(:all) do @first = FactoryGirl.create(:post, :created_at => 1.day.ago, :published => true) @last = FactoryGirl.create(:post, :created_at => 4.day.ago, :published => false) end it "should only return published posts" do Post.