A little detail that I’ve always taken for granted is the term that is used to invite a person to log in or sign in to a system – that is, to provide their username and password for authentication. I usually just default to the term “log in”, which is what Mac OS X and most UNIXs call it.

It really doesn’t seem like a big detail, except that today I found myself scratching my head thinking “what do my users think when they see ‘log in’?” If you really sit there and think about it, the term “log in” doesn’t make any sense at all. It makes me think of wood – what am I putting the log into, anyway? But on the other hand, “sign in” seems awkward too, if you think about it long enough. So lets look at the alternatives.

Log in and log out, as far as I can tell, are derived from the idea that one would write your name down in a logbook for an important activity. “Login” can also be used as a noun, as in “provide your login and password”, and as an adjective, as in “give me your login information and nobody gets hurt”. It seems like a pretty natural thing to say, but that could be because of all the times I’ve “logged in” to Mac OS X. You can still say “provide your signin information”, but that seems pretty awkward. So “logging in” seems more versatile than “signing in”.

Sign in and sign out seem to have a slightly more friendly feel. Many websites end up using these over login/out. Saying “sign in” feels like signing a guest book, where “log in” feels like registering oneself for some important activity. Sign in and sign out also have the benefit of historical usage. People who remember listening to the radio (remember radio?) would recognize the familiar “this is So-and-So, signing off”.

What do you think?

• Log in/Log out
• Log on/Log off
• Sign in/Sign out
• Sign on/Sign off

Some posts that I found helpful:

• Eric Bowen’s .NET Technology Blog
• Fog Creek Software
• Redneck Definitions

If you’ve hopped on the Mongrel bandwagon, you know how convenient and efficient the Mongrel server can be for running Ruby on Rails applications.

The only thing that’s not so convenient about Mongrel is the way you start it when you’re working in development mode. Typing that long command (mongrel_rails start -d -p 3000 -e development) every time you want to start your web app can be a real pain.

So I came up with this quick shell script (UNIX/Linux only – sorry Windows folks) that does the same thing as the script/server command.

The script/mongrel file

#!/bin/sh
/usr/local/bin/mongrel_rails start \
 -d \
 -p 3000 \
 -e development \
 -c /path/to/your/web/app

To use it:

1. Go to your Rails app and make a file in your script directory called mongrel (no file extension – just “mongrel”).
2. Paste the above code inside the file, modifying it as necessary. Save the file.
3. Go out to your terminal, and navigate to the root of your web app.
4. Run script/mongrel.
5. That’s it! Your web server should be running! Test it by browsing to http://0.0.0.0:3000.

To shut down the web app, just run mongrel_rails stop from the root of your web app.

Cool: CoverFlow

Link: http://www.steelskies.com/coverflow/

CrossConnector got linked up at 37signals blog, Signal vs. Noise. They were impressed by our nifty Keynote and Powerpoint slides, which you can download from www.crossconnector.com/downloads to promote your CrossConnector site.

Signal vs. Noise Article: Screens Around Town: CrossConnector, Dandelife, and Wufoo

Stowe Boyd takes a lesson from Deep Survival by Laurence Gonzoles, and applies it to small bueiness.

The ones that survive avalanches, airplane crashes, being snow bound, or cast adrift in inadequate life boats are those that manage to suppress their urge to panic long enough to ask — and answer — the essential question of survival: what do I do next to survive?

Read the article at the FreshBooks Blog.

I’m no expert on REST-ful development. But after seeing David’s presentation on ActiveResource, MLY’s article on HABTM, and after looking at Molecule I was inspired to refactor some of my controllers a bit. When I was done, I managed to squeeze the CRUD (Create, Read, Update, Delete) part of my controllers down from around 50-75 lines per controller to around 20-30 lines.

class ApplicationController < ActionController::Base
  ...

  private

  def save_or_update(obj,params=nil)
    begin
      ((params and !obj.new_record?) ? obj.update_attributes(params) : obj.save) or raise errors_for obj
      flash_notice "#{obj.class} saved successfully", :good, :now
      redirect_to :action => "show", :permalink =>obj.permalink
    rescue Exception => e
      flash_notice "There was an error saving the #{obj.class.downcase} #{e}", :bad, :now
    end
  end

  def errors_for(obj)
    "<ul>#{obj.errors.full_messages.collect{|e| "<li>#{e}</li>"}}</ul>" if obj and obj.errors
  end

  def flash_notice(message,status=:good,now=false)
    now ? (flash.now[:notice], flash.now[:class] = message, status) : (flash[:notice], flash[:class] = message, status)
  end

end

class PageController < ApplicationController
  ...

  def show
    @page = get_page
  end

  def new
    @page = Page.new(params[:page])
    save_or_update(@page) if request.post? 
  end

  def edit
    @page = get_page
    save_or_update(@page,params[:page]) if request.post? 
  end

  private

  def get_page(permalink=params[:permalink])
    Page.find_by_permalink(permalink)
  end

end