sign up, sign in, sign out

What is your Ubiquitous Language for authentication?

Common language includes “logging in”, “registering”, “joining up”, “creating an account”, “signing up”, & “signing out”.

Do you interchange these words in your UI? How about in your application code? Tests? Does your whole team use the same language across all layers of the software?

When writing a library like Clearance, I feel the authors should take a stand on language to alleviate the mental burden on designers, developers, & business analysts involved in the project.

The decision is basically arbitrary. No one set of terms is truly better than the other. What’s important is to take the opportunity to standardize all the places this shows up in code.

So we picked “sign up”, “sign in”, & “sign out”, a lingual trinity of authentication.

We liked the symmetry. We liked that there was less of a chance of writing “log in” (sounds like a verb) or “log_in” in certain places and “login” (sounds like a noun) other places.

About a half a year later and we still feel good about the effect:

Tests

context "when signed out" do
  setup { sign_out }

  context "on get to new" do
    setup { get :new }
    should_deny_access
  end
end

context "when signed in" do
  setup { sign_in }

  context "on get to new" do
    setup { get :new }
    ...
  end
end

context "when signed in as an admin" do
  setup { sign_in_as Factory(:admin_user) }

  context "on delete to destroy" do
    setup { delete :destroy }
    ...
  end
end

Application code

class UsersController < Clearance::UsersController
  def create
    ...
    sign_in(@user)
  end
end

class ParticipationsController < ApplicationController
  protected
  def ensure_signed_in
    unless signed_in?
      store_location
      flash[:failure] = "Please sign in to participate in this deal."
      redirect_to sign_in_path
    end
  end
end

module NavigationHelper
  def authentication_links
    if signed_in?
      signed_in_links
    else
      signed_out_links
    end
  end

  def signed_out_links
    [link_to("Sign up", sign_up_path),
     link_to("Sign in", sign_in_path)]
  end

  def signed_in_links
    [link_to("My Account", edit_user_path(current_user)),
     link_to("Sign out",   sign_out_path)]
  end
end

UI

For something as common as authentication, familiarity for users breeds comfort. So what do the big boys do?

Basecamp is a little inconsistent, mixing sign in with login:

Apple is pretty as usual:

Google is perfectly consistent. Youtube & Gmail:

Ahh… sweet, sweet consistency.

sign up, sign in, sign out

What is your Ubiquitous Language for authentication?

Common language includes “logging in”, “registering”, “joining up”, “creating an account”, “signing up”, & “signing out”.

Do you interchange these words in your UI? How about in your application code? Tests? Does your whole team use the same language across all layers of the software?

When writing a library like Clearance, I feel the authors should take a stand on language to alleviate the mental burden on designers, developers, & business analysts involved in the project.

The decision is basically arbitrary. No one set of terms is truly better than the other. What’s important is to take the opportunity to standardize all the places this shows up in code.

So we picked “sign up”, “sign in”, & “sign out”, a lingual trinity of authentication.

We liked the symmetry. We liked that there was less of a chance of writing “log in” (sounds like a verb) or “log_in” in certain places and “login” (sounds like a noun) other places.

About a half a year later and we still feel good about the effect:

Tests

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

context "when signed out" do
  setup { sign_out }

  context "on get to new" do
    setup { get :new }
    should_deny_access
  end
end

context "when signed in" do
  setup { sign_in }

  context "on get to new" do
    setup { get :new }
    ...
  end
end

context "when signed in as an admin" do
  setup { sign_in_as Factory(:admin_user) }

  context "on delete to destroy" do
    setup { delete :destroy }
    ...
  end
end

Application code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

class UsersController < Clearance::UsersController
  def create
    ...
    sign_in(@user)
  end
end

class ParticipationsController < ApplicationController
  protected
  def ensure_signed_in
    unless signed_in?
      store_location
      flash[:failure] = "Please sign in to participate in this deal."
      redirect_to sign_in_path
    end
  end
end

module NavigationHelper
  def authentication_links
    if signed_in?
      signed_in_links
    else
      signed_out_links
    end
  end

  def signed_out_links
    [link_to("Sign up", sign_up_path),
     link_to("Sign in", sign_in_path)]
  end

  def signed_in_links
    [link_to("My Account", edit_user_path(current_user)),
     link_to("Sign out",   sign_out_path)]
  end
end

UI

For something as common as authentication, familiarity for users breeds comfort. So what do the big boys do?

Basecamp is a little inconsistent, mixing “sign in” with login>

Apple is pretty as usual:

Google is perfectly consistent. Youtube & Gmail:

Ahh… sweet, sweet consistency.

How Ruby Mixins Work With Inheritance

Yesterday I asked on Twitter whether anyone was successfully using is_paranoid in a Rails application, because I had confused myself into thinking it couldn’t possibly work.

The problem I was having wasn’t is_paranoid’s fault, but it turns out it actually can’t do what I wanted it to do in its native state. The explanation of why is something I thought a number of Rubyists might benefit from hearing, so here it is.

Briefly, an explanation of is_paranoid: if you declare an ActiveRecord model to be paranoid, whenever you attempt to delete that model, is_paranoid will instead set a flag which indicates that the record is deleted. is_paranoid uses default_scope to filter out soft-deleted records in your queries. So you can act as if records are deleted without actually removing the rows. If is_paranoid is new to you but sounds familiar, you might be thinking of acts_as_paranoid, which is Rick Olson’s original implementation of this idea.

What I wanted to do for the specific application I’m working on is to declare that every model should inherit the is_paranoid behavior. Easy enough, I thought, given the way these things typically work in Rails’ inheritable accessor setup:

But when I tried to destroy an instance of (for example) Person, the regular ActiveRecord destroy code was invoked and the records were being actually destroyed. Bummer.

So I cracked open the code to is_paranoid and found this perfectly reasonable idiom:

At this point, after pretending I was an idiot for a few minutes, I realized that this code was indeed incapable of doing what I wanted it to do.

Some of you already know why. For the rest of you, let’s talk about how Ruby’s mixins fit into its inheritance mechanism.

Maybe it’s just me, but when I think of something getting “mixed in” to something else, I imagine the two things becoming intertwined. So, the natural assumption when mixing a module into a Ruby class would be that the methods of the module get intertwined with the Ruby class. And for the HelloWorld of mixins, that indeed appears to be the case:

But if you start mixing modules that implement methods the class also implements in, things don’t go quite as smoothly:

Instead of “Overridden do_something” as some might expect, this code prints “Doing something in Thing”.

Why?

Because when we mix a module into a Ruby class, we’re not actually intermingling the methods of the module and the class. Instead we’re inserting the module into the class’s inheritance hierarchy. A good way to see how this works is by using the “ancestors” method:

When a method is called on an instance of SubThing, you can see that it is looked up first in SubThing’s class, then Thing’s class, then in IneffectiveOverride, and so on.

(I used yuml to generate this. Cool site!)

To further demonstrate that mixins don’t really get “mixed in”, notice what happens when you try to include a module at multiple points in the inheritance hierarchy:

If a module is already present at a higher point in the hierarchy, it won’t be mixed in again.

So is_paranoid was apparently built without the goal of being able to mix it into ActiveRecord::Base. Sounds reasonable to me.