If you use MongoMapper or Mongoid (or anything other than ActiveRecord) and recently upgraded to Rails 3.1.0.rc5, you may have noticed that the asset pipeline stopped working even thought it was working fine in 3.1.0.rc4. That’s because in rc5 the sprockets/railtie require is now explicit.

Just add require 'sprockets/railtie' to your config/application.rb file and you should be golden. Like this:

# config/application.rb
# require 'rails/all'
require 'action_controller/railtie'
require 'action_mailer/railtie'
require 'active_resource/railtie'
require 'sprockets/railtie'

If you’re using SQL, then you’re probably using PostgreSQL. And if you’re using PostgreSQL, then you probably get those annoying as hell notice messages outputted everywhere when you do anything that alters the database schema. They look something like this:

NOTICE:  CREATE TABLE will create implicit sequence "groups_id_seq" for serial column "groups.id"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "groups_pkey" for table "groups"
NOTICE:  CREATE TABLE will create implicit sequence "projects_id_seq" for serial column "projects.id"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "projects_pkey" for table "projects"

So annoying. And the more tables your project has the more annoying it gets. I first noticed it a year or so ago and have been half-assedly trying to fix it ever since. Google suggests putting various combinations of SET client_min_messages TO WARNING; in a .psqlrc file, but no matter what I tried I could never get it to work, so I always gave up.

Until today, when I finally got so fed up with it that I decided I wouldn’t do anything else until I figured it out. Three hours later I got it, kind of.

What eventually worked was setting min_messages in the database.yml.

# config/database.yml
defaults: &defaults
  adapter: postgresql
  encoding: unicode
  min_messages: warning

development:
  <<: *defaults
  database: something_development
  username:
  password:
  pool: 5

It’s not ideal, I would have rather it been something global that I could put in my dotfiles than have it per project, but this will do for now.

You know how they always say to not forget to include a favicon and robots.txt and whatnot in your website or app so browsers and bots don’t fill up your error logs with 404’s? Yeah, well, don’t forget that if you have a catch-all route in your app and those resources don’t exist they’re not going to 404, they’re going to mysteriously throw a 500 on nearly every request.

I know you wouldn’t make a stupid, obvious mistake like that and spend twenty minutes staring at your error logs trying to figure out what the hell is going on. But I figured I should mention it anyways. You know, just in case.

The title is a stretch—I know—but I couldn’t resist.

Like most programmers I have a fairly strong opinion about how code should be indented and formatted. And while much of formatting is subjective and comes down to personal preference, there are many times when one could probably make a solid, logical argument as to why one particular method is better than the others.

I think one such instance would be the handling of private and protected declarations in classes and modules. Here are the methods I’ve seen:

Method 1

class Stuff

  def something_public
    #
  end

  private

    def something_private
      #
    end

end

This is, in my opinion, the most awful. It’s easy to see where the private methods start, but something just feels very off. Having some methods indented once and others indented twice feels more inconsistent than helpful. And in a long file if nothing is currently visible except twice-indented methods, with no other points of reference it might not be evident that the methods are in fact twice-indented, in which case they may as well not be.

Method 2

class Stuff

  def something_public
    #
  end

  private

  def something_private
    #
  end

end

This is by far the most consistent. Everything is only indented once, which makes it fairly easy to parse. But when scrolling through a long file the private declaration blends right in.

Method 3

class Stuff

  def something_public
    #
  end

private

  def something_private
    #
  end

end

This is the one I use. I believe it combines the best of both other methods. Everything is indented once for easy visual parsing, but the private declaration is left flush with the edge of the document to provide a nice visual break when scrolling through a long file.

If you’re of a different mind than I on the method to use and/or the reasoning behind it I’d love to hear from you.

If you use Devise for authentication and deploy on Heroku, or really just use any database that is case-sensitive by default (like PostgreSQL), you’ve probably run into the problem that some users like to type certain letters in their logins (email and/or username) in uppercase, but expect it to be case-insensitive when they try to sign in. A not unreasonable request considering that’s pretty much the universally default behavior that most applications exhibit, but that’s not the default with Devise.

Unfortunately, if you google the problem, the most common solution given is to downcase the login in a before_save callback so that it’s always lowercase in the database, and then overriding like eight different methods on several different controllers to downcase the login in the params. Thus always comparing a lowercase submitted login to a lowercase login in the database. Besides being annoyingly overcomplicated, it strips users of their ability to capitalize their login as they so choose, which is the whole reason this problem exists in the first place.

Devise should really have a way to do this automatically, and it does as of a few months ago in version 1.2 and later, although the way their wiki is set up makes it difficult to find. Here it is in all its one-line glory.

# config/initializers/devise.rb
Devise.setup do |config|
  config.case_insensitive_keys = [:email, :username]
end

Maybe this will push the old/incorrect answers out of the search results.