What makes easy things … easy?

I had a thought this morning: “easy” things are easy because they’re familiar.

Do you remember the first time you tried to drive a car? It was a nightmare! The coordination between your hands and feet, reading traffic, getting used to looking in the mirrors. And now you do it effortlessly: you jump in, tune the radio, adjust the climate controls … all while being distracted by talking on your cell phone! The task of driving from home to work involves hundreds of individual steps and requires constant vigilance, but I can’t think of anyone I know that says “driving to work is too hard, so I’m not going in today.”

I went on the Net this morning to look around for an article to quote:

On the surface, easy is what we already know how to do or that which takes little mental or physical effort.

The Difference Between Easy And Difficult, Alex Licherman, M.D.

I’ve been building a new piece of software which is aimed at making a very complex task really easy: building a website. I did a Google search for “website builder easy” and got back 4.1 million hits. You would think if websites were so easy to build that one of these millions of links would actually do the trick. But I don’t think any have hit the mark quite yet.

What makes building a website “easy”?

I’ve been keeping a running list of hosted services and what easy really seems to have boiled down to is one trick: what you see is what you get. Sorry, WYSIWYG isn’t anything new. Yes, you can “drag and drop” all of these “modules” or “widgets” onto your site, but does that really make it “easy”? I argue it does not. What it does is leverage your innate ability to grab a colorful block and position it on the floor in front of you. Even after you put this module/widget on your site canvas you still have to decide how to style it, what to write in it, and how to arrange it so it complements the other modules/widgets on the page. Next you need to repeat this process for the umpteen pages on your site. Sure, templates bootstrap you by giving you graphics and layouts, but you still need to customize them all to your liking. Oh, and let’s not forget what I consider to be the real evil of having a website: maintenance.

That’s right. You spend days/weeks tweaking your website so that it’s beautiful, shiny, modern, flashy, ________ (insert other cool adjective) and then you release it to the world. … time passes … Then something needs to be updated. Then all those glassy reflections on your images start to look dated so you want to go with the new design style hotness but there’s oh-so-many pages and icons and Adobe Flash files you need to update… The cost of owning and maintaining your site just went from trivial to white-hot painful. So “easy” really wasn’t, eh?

I think the easiest hosted website to maintain in my opinion isn’t even really a web site: it’s your Twitter account. You pick some colors, you change your background image, and that’s it. This means you focus on your content. And you change your mind about the style later then it’s so simple. Plus, since you have that muscle memory of having gone to the Settings page -> Design tab, it’s easy for you!

What I’m building is something along these lines. For site owners it will make choosing your style so trivial that changing your mind about something will be effortless. The site editor will require you to learn only a couple of interface navigation concepts and only a handful of terms. Instead of giving you free reign over any number of layouts and templates, there is only really one. Instead of creating deeply-nested site hierarchies, it’s completely shallow. Instead of allowing you to do everything you could ever want to do (which in turn necessitates a complex editor), you get to only do a few things but you’ll do them so well.

More importantly, let’s consider the end-user experience: what will your customers see?

Good user interfaces on the web (or any device) have consistent, predictable interfaces. (I’m not the only one with this view.) Users will only need to get used to one visual layout, which means the organization of the rest of your site is also predictable. This in no way means that your site will be boring! It simply means that your design will have a higher degree of synergy. And synergy leads to familiarity. And familiarity leads right back to Easy St.

You win. Your viewers win. Even your graphic designer that helps you with your site wins.

This is my hope. Let’s see if my bet is right?

Devise for authentication … niiiiiice …

In the spirit of retraining myself this summer I was skimming Ryan Bates’ RailsCasts site and I saw an authentication solution, Devise. This is perfect because right now I’ve been trying to figure out what to do about logging users in. I’ve been using home-grown solutions for a while and I’ve seen good things about Authlogic. But Devise, wow. Talk about awesome.

One of the things I’m really liking about it is its modular configuration. Want the user to confirm their new account? No prob, just enable the :confirmable module in your user model. Want Devise to generate the basic views for you? Sure, just run the generator: rails generate devise:views. (You might have to use script/generate devise_views for Rails 2.3.) It’s seriously awesome.

See the RailsCast that talks about it http://railscasts.com/episodes/209-introducing-devise or the GitHub for the project: http://github.com/plataformatec/devise.

Kicking Rails’ “shifting failed” errors to the curb … logrotate

For quite a long time I’ve been using the built-in Rails log rotation since I like to change the name+location of my logs. One unfortunate consequence has been a strange error I got once in a while:

Error during failsafe response: Shifting failed.

I didn’t know exactly what was causing it but my guess is that because I’m using Passenger one process is rotating the log file and another process comes along and tries to rotate the same log file. I posted a question to StackOverflow and got pointed towards logrotate. This turns out to work great both on my Mac and on my production server.

After installing the command I can run:

/opt/local/sbin/logrotate /etc/logrotate.conf

The contents of that logrotate.conf file are:

/PATH/TO/APP/logs/*log {
  daily
  rotate 99999
  missingok
  compress
  delaycompress
  sharedscripts
  postrotate
    /usr/bin/touch /PATH/TO/APP/tmp/restart.txt
    /bin/mkdir -p /PATH/TO/APP/logs/archive
    /bin/mv /PATH/TO/APP/logs/*.gz /PATH/TO/APP/logs/archive
  endscript
}

Now I get daily rotation with compressed logs older than 1 day. The postrotate incantation there does some things that I prefer:

  • Touch the Passenger restart.txt file so the next request will restart my app instances and create fresh log files
  • Ensure a log archives directory exists
  • Move all compressed (.gz) files into that archives directory

One thing I ran into while trying to test this configuration was a cryptic message:

log does not need rotating

It turns out that logrotate does not use timestamps on the log files to determine when it needs to rotate things. No, rather it uses its status file (created as /var/lib/logrotate.status) which has the last dates of the affected files:

% cat /var/lib/logrotate.status
logrotate state -- version 2
"/PATH/TO/APP/logs/development.log" 2010-8-3
"/PATH/TO/APP/logs/info.log" 2010-8-3
"/PATH/TO/APP/logs/*log" 2010-8-3

To get logrotate to forcibly rotate things you have to 1) do not use -d, and 2) use the -f flag.