patnakajima.com: Articles

On “doing cool shit...”

Pat Nakajima — Wed, 19 Nov 2008 08:13:09 +0000

Any argument against re-inventing the wheel or that can be summed up by “don’t try to fix it if it isn’t broken” is usually made by someone who hasn’t done anything worthwhile.

Argue with me.

This is a blog, damnit.

Pat Nakajima — Wed, 19 Nov 2008 08:00:04 +0000

It’s about time I post some posts. I’m figuring the stuff not worth spamming my Twitter followers is going to end up here. Unsubscribe at will. I know I will.

East Village on Election Night

Pat Nakajima — Thu, 06 Nov 2008 00:49:59 +0000

Times Square on Election Night

Pat Nakajima — Thu, 06 Nov 2008 00:49:25 +0000

Conditionals in method names considered annoying

Pat Nakajima — Sat, 25 Oct 2008 09:45:31 +0000

I’ve been noticing a few projects recently where there are
method names that contain conditional descriptions, such as
foo_if_bar or rant_if_loaded. Here’s where I weigh in:
Don’t do it. The right way to name those methods is simply
foo and rant. If foo really only ought to be called
when bar is true, then a simple guard clause ought to work:

def foo return unless bar # foo logic goes here end

This works most of the time, when no one cares whether or
not foo relies upon bar. If it’s important that readers
of your code see that foo only happens when bar is true,
then you can just specify the conditional wherever you invoke
the method:

def fizz foo if bar # make it clear that we only foo if bar end

Why?

You should ask the other Pat if you
want the good answer, but I’ll try to put it as well as possible.

First of all, requirements change. So at some point, foo may
be callable without ever worrying about bar. By leaving the
conditional crap out of the method name, you can remove the conditional
logic as needed, and aren’t stuck using a method name that no
longer means what it says.

If the conditional logic can be in-lined as a guard clause, then
a method name with conditional bits is leaking information about
implementation. If the conditional logic should be placed alongside
method calls, then putting the conditional description in the method
name is just redundant.

FYI: I intend to post some cool stuff soon, so this blog isn’t
solely populated by stuff that bugs me.

Your underscores are showing

Pat Nakajima — Fri, 24 Oct 2008 06:33:05 +0000

Listen: You’re writing some Rails code, as you tend to do. All of
the sudden, you recognize the need for an association that goes both
ways. You could use a has_many_and_belongs_to_many but that dude you’ve
heard of said that you should be using has_many :through instead. So
you say “join tables? pfft! join models!”

So you need to create your join model. First, you need a name.

Here’s where many, if not most, go wrong. Let’s say you’ve got a User
model and a Compulsion model. A User can have many :compulsions, and
a Compulsion can afflict many :users.

For the love and/or respect of everthing remotely decent, do not name
that join model UserCompulsion.

It’s a stupid name. And it’s not even the worst. Not by a longshot. It’s just
the worst I could think of while concocting this convoluted example of a
practice I regularly lament. Why is it stupid? Because it does nothing but says
“hey, these two things are related, but I dare you to try figuring out how.”

Join models should describe the relationship that they’re modeling. You don’t
call your User table name_username_passwords, because that wouldn’t divulge
any information about your problem domain. Only rubbish about your implementation.
That’s lousy. In this spirit you should give your join models a name that counts.

So what do you call your join model between a User and a Compulsion? Well,
an Obsession may be appropriate. “But wait!” you say, that doesn’t apply to your
particular problem domain. Then pick something that does. An underscore can’t possibly
convey the problem solved by your creation of a join model.

My Cuil experience

Pat Nakajima — Wed, 30 Jul 2008 01:17:05 +0000

With all the hubbub about Cuil these days, I thought I’d give it a whirl. And what better way to try out a new search engine than a self-search?

Cuil found most of the pertinent details about me, though there were a few unanswered questions. The biggest mystery, of course, was who on earth is the guy that they pictured next to the result for patnakajima.com?

The only other weird thing about Cuil is how much their results just look like Google ads, which I strive so hard to ignore when looking at regular Google search results.

Remember the :active styles

Pat Nakajima — Tue, 29 Jul 2008 02:45:40 +0000

The hyperlinks of today look way better than they did five years ago. Designers and developers have become better and better at styling links to not only be usable, but beautiful as well. We know how to indicate the basic behavior of a link using only color (for example, red usually indicates a destructive action). And we know how to style links to give them a stronger affordance of click-ability.

Most web applications make clever use of the :hover pseudo-class, which allows us to tweak link backgrounds to add an even stronger affordance of click-ability, and draws the eye to the link, which focuses the user on task at hand. All of 37signals’ apps provide great examples of tasteful rollover link styles.

When we begin to think about rollover styles, we’re no longer thinking about how the app looks. We’re thinking about how it feels. Different styles for link rollovers make a page feel much more responsive. Everybody these days knows this, and takes advantage of it.

Unfortunately, few people take advantage of the :active pseudo-class, which allows you to style the link differently while it’s being clicked. This is just as important, if not more important than the rollover state. Changing a link’s :active style provides immediate visual feedback that the link is being clicked.

Try clicking each of the following links. See which feels better.

This link does not have an active state.

This link does have an active state.

The chances of a person successfully completing a task increase with the level of feedback that that he/she receives before, while, and after performing that task. (if you’ve read The Design of Everyday Things, you know what I’m talking about). With links, the “before” feedback can be achieved using :hover styles, and the “after” feedback is usually just the browser doing something, be it going to a different page or just updating something dynamically. The “during” feedback can be achieved by simply using a good :active style.

Now, just as much thought must be given to a link’s :active style as to its :hover style, if not more. Usually, a click is less than a second, so changing the style too much can be distracting, and actually do more harm than good. I’ve found that the best :active styles tend to just make the background a bit darker. I first saw this on flickr (which was where I first noticed the :active state in use and fell in love). You might also think about adding an underline during the click. Experiment and see what works best for you.

One thing’s for sure though. Once you feel the difference in your web apps between a good :active style and a non-existent one, you’ll wish every site made use of them.

“ASSISTANZA”

Pat Nakajima — Thu, 19 Jun 2008 13:52:01 +0000

I love these.

Dear Friend,

I am an official for a bank here in Milano. I require your assistance and partnership in transferring huge amount of funds in euros out of Italy. You will be required to:

(1) Assist in the transfer of the said sum.

(2) Advise on lucrative areas for subsequent investment.

(3) Assist me in purchase of landed & viable properties.

Should you be willing to assist us in the transaction, your share of the sum will be 30% of the €21,500,000.00, 65% for us and 5% for taxation and miscellaneous expenses. Please establish secured communication with me through my email address.

Regards,

Toma Petrova

UI Glitch at Smashing Magazine

Pat Nakajima — Thu, 05 Jun 2008 20:27:40 +0000

Smashing Magazine is a great site. Full of beautiful site designs and helpful tidbits, it has only one major failing: its pagination.

This is what the links at the bottom look like:

To get to the next page, you’re expected to click the “»”. It’s unlabeled, and a rather small target (Fitts’ Law anyone?). I can’t tell you how many times I’ve clicked “Last” by accident.

It would seem to me that visitors want to go to the next page far more frequently than they want to jump to the last. I think the pagination links should respect that.

Update: Looks like they added a “Next” link. Well played.