I, and many smarter people before me have noted that time is the only truly limited resource. Everything else we can get more of, but time we can never get back. We’re using it literally all the time, and one day we’ve used it all up and we’re gone. As someone with a never-ending list of things to do that will surely extend beyond my alotted time, I find this rather unfortunate.

Many would argue that this is the natural order of things and the way it should be. That it is time’s limited nature that makes life so great, and that death is a necessary, natural change agent. I’m inclined to agree, but still, no one wants to die, and given the option, most would surely stave it off for as long as possible. Hence humanity’s nearly-eternal search for the fountain of youth—in whatever form it might take—in order to gain more time.

Personally I consider it a noble endeavor, and I’d like to join in the pursuit, but I’m no Spanish Conquistador, and despite being a programmer my science aptitude is tenuous at best, so those avenues are kind of out. But there is another way that seems to be largely unexplored, or at least I’ve never heard anyone else mention it. And that is using time’s relative nature to alter your own perception of it. It’s something we do every day, albeit unintentionally. The speed at which we perceive time ebbs and flows, and we notice it—we even point it out to other people after it’s happened—but we never really seem to pinpoint why it happens. In order to do that, we have to look at when.

The most obvious example is childhood. When you look back on it, you remember growing up seeming to take eons, but as you get older time seems to accelerate exponentially. This could of course just be something about the way children perceive time, which I think is the common wisdom. But there are times when adults perceive time the same way, most notably when on vacation. You can even just go away for the weekend and it can seem like you’ve been gone for two weeks. The only real common denominator between the two is new, or varied experiences. For children, everything is new all the time. As they get older, things become more familiar and repetetive, until finally they’re just doing the same thing day in and day out until they die. Which is why time seems to accelerate as you get older. The longer you do the same thing over and over again, the quicker time will fly by. Vacations are little pockets of varied experiences that interrupt the normal pattern of your life, which is why they seem to last way longer than they actually do.

So what that means is that in order to slow down time, all you have to do is mix it up every single day; have lots of different experiences as often as you can. New restaurants, new clothes, new friends, new cities, new jobs. You don’t have to give up the old, but make sure you get a healthy dose of new. People will probably think you’re weird, but if they ask you about it, just tell them you’re trying to live forever.

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.