Halogen Labs

I’ve written up my experience at Interaction 10 the other week in Savannah, GA.

I’ve been giving my much-ignored blog some love lately. I noticed my SEO-friendly permalinks broke a while back. I’m not sure when it happened, but I only really noticed it after Dreamhost moved my hosting to a different box. It could just be a coincidence, but at least it’s fixed now.

I’ve also implemented some fancy fonts using the awesome Kernest service, and I’ve also tweaked some of the other ugliness on the page. The bit of stuff between the page footer and the content has a proper background now, and I’ve made it a little wider. I’ve also fixed some of the padding and margins around the page headers. Hopefully the blog is easier to read.

It starts out simple enough. You’re building a webapp, and you want people with a certain role (read: Administrator) to have access to a separate “back-end” part of the system. They have to do different stuff, so it makes sense to make a separate administrator interface. A classic example of this is something like WordPress, where you have a totally different area of the website to sign into, and you have a myriad of different tasks you can perform.

At first, it seems to make sense — administrators have various goals they want to accomplish, like mass-approving comments or creating a draft of an article. The part of a blog that faces the reader is usually geared towards reading content, not making changes to it.

Lately, I’ve been thinking about something that I remember hearing a while back from Edward Tufte. The phrase is “administrative debris,” and Ryan Tomayko wrote about it a year ago.

Anyway, I’ve had the itch to finally write my own blogging app for personal use, and I’m following some of the ideas that Ryan writes about — things like using in-place editing, and making content look identical between reading/editing.

The nice thing about having your content be your interface is that it’s a lot quicker to make changes. Because it’s less painful, I’ll be more likely to write.

• I don’t have to remember the secret admin URL.
• When I’m logged in, I don’t have to parse a cluttered admin interface.

I’ll post more thoughts about design of the project when I get closer to actually having it live.

I recently installed the wonderful test_benchmark plugin for Rails, and ran it against our code. I was surprised to find that we had a couple unit tests that were taking 4 seconds to complete.

Digging in, I found code that was doing the following on a time range:


range = # .. a time range 24 hours "wide"
start_time = range.min
end_time = range.max


I looked up the API for Range, and there are no .min and .max methods defined, but they live in enumerable. So what’s going on here?

A little more digging:


>> count = 0; r.max { |a,b| count +=1; a <=> b }
=> Fri Apr 03 20:07:29 UTC 2009
>> count
=> 88200


Oops. 88,200 comparisons for a time range. Switching the code in the test and the class under test to use .first() and .last() instead of .min() and .max(), and I shaved off a cool 8 seconds from rake test

Is our beloved Mac text editor, TextMate, dead? The TM Blog hasn’t updated since the middle of August, 2008.

The latest cutting-edge version is 1.5.8, r1498, and it’s been a while since that’s updated, too.

Has TextMate died, or has it just reached a maturity level where it doesn’t need updates and new features as often? Whatever happened to the fabled TextMate 2.0? Last I read about 2.0 was back in 2006 when Alan mentioned 2.0 would require Leopard. Not even a peep about 2.0.

What’s going on?

Edit: I found a TextMate 2.0 FAQ, which indicates that TM2 was actively being developed, at least towards the end of November 2008. Hopefully we’ll see something in 2009.

The Wheres and Whens of User Expectations is a good article by UIE that talks about user expectations for account sign-in links and fields:

As we watched users, it seemed they first looked for two text-entry boxes of equal size. Their eyes would scan the page (often with the mouse cursor in tow) searching for the two entry fields.

Sites that had two text-entry boxes, often contained in a larger box with a distinct background and border, would quickly acquire the user’s attention. They’d type their username into the first box and their password into the second.

This pattern is so strong that we see it work even on sites that don’t follow the pattern. Over at Etrade.com, the online trading and banking site, their design has two pairs of dual text-entry boxes. One pair is the standard login field, but a more prominent pair is for stock quotes and the site’s search functions.

Because of the strong drive of the user to react to this pattern, it’s common to see users type their username and password into the stock and search buttons, completely missing the proper sign-in fields. From this, we can see designers need be careful when placing pairs of text fields that users don’t confuse them for the sign-in boxes.

The Sign-In Link Pattern

If users don’t see two boxes, they then start scanning for a link called Sign-in or Log-in. (We haven’t seen anyone who uses a button for this, but it’s also an option. However, we’d wonder if a button would create cognitive dissonance if it appeared without corresponding fields.)

A pattern that worked well in our research was, once logged in, to replace the sign-in link with the user’s name, id, or email address, followed by a sign-out link. Users showed they understood the semantics and reassured them that the system had recognized their account information.

Just futzing with the layout of the site. Not that anybody reads this thing anymore :)

Not a lot going on. I had a very busy spring. The house almost burned down. Summer was busy too, as well as fall. Hopefully I can relax this winter :)

Scope me on Twitter.

More later.

One of the first things I’ll do when working on a new project is to automate the build ASAP. Starting a new job a couple weeks ago, I took the opportunity to get CruiseControl.rb up and running and getting the tests running reliably.

At my last job, we had automated the build by having CC.rb run rake db:migrate followed by rake test. This worked out fairly well, and we made it a practice to peer-review all migrations before committing them.

This technique had a few drawbacks, however. One thing was that we were testing our migrations. If someone committed a migration that broke, the build would fail. Likewise, if someone committed a migration and then needed to change it later, we would have to manually roll back the database and re-migrate up, which was a pain in the butt.

Having the build run the migrations was nice, since other developers would be alerted to a potentially bad migration, but it ended up being more trouble than it was worth.

At my new job, there’s an established practice of using migrations to add static data to the database (which is the subject for another post). Migrations are an easy way to do this, but you run into trouble if the data being added depends on other data in the database, or if the migration was bad.

I’m of the opinion that you should avoid hitting the database as much as possible during tests, and by running migrations during the build (especially ones that depend on static data in the database), you end up coupling yourself even more tightly to the database.

After thinking about it for a while, I’ve decided that the schema.rb file is, after all, the de facto source of the database schema (big DUH here). Therefore, each build should wipe the the test database clean of tables and then load the schema.rb file from the repository.

Our new rule here now is that if you check in a new migration, you must also check in the new schema.rb.

By doing this, we consider migrations a tool for communicating small changes to developers over time, and we have a reliable, repeatable way to load a fresh db schema into a new development environment.

Google Analytics can help you in a lot of interesting ways sometimes. Recently I noticed my traffic had dropped to zero:

What does this mean?

1. Nobody’s visiting the site
2. Web server died
3. Google stopped indexing my site and stopped referring links to the site.
4. Sky is falling

I knew the first option wasn’t the case since I usually have a low level of “background radiation” traffic even when I’m not posting. I knew for a fact my web server was up. I checked my robots.txt file and it was fine, so WTF?

Well, after checking my page source, realized I blew away my old Google Analytics code in the Wordpress Template, and the only thing that Google Analytics was reporting was the fact that I didn’t even have it installed!