Rails Rake Tasks Plugin

By Cody in Rails, Software Development

Just like everyone else who develops software, we found ourselves constantly typing the same commands over and over for a variety of little tasks while developing Rails apps. Over the course of a number of projects, we developed a collection of rake tasks to automate many of them.

I find some of the tasks really useful, so we created a plugin called the Sakuzaku Rails Rake Tasks Plugin to make them available to everyone.

Some of the tasks that are particular time-savers for me are:

• db:remigrate, which drops your database and migrates it from scratch.
• db:migrate:all, which migrates both your development and test databases at once.
• db:migrations:test, which runs any uncommitted migrations backwards and forwards to test them.
• db:migrations:merge, which renames uncommitted migrations as necessary to make them follow any migrations committed while you’ve been working.
• The testing convenience tasks, which drastically reduce the amount of typing necessary to run tests. For example, you can run all tests for the User model and User controller by doing rake user (instead of ruby test/unit/user_test.rb ; ruby test/functional/user_controller_test.rb), or just the name test on the User model with rake user:name (instead of ruby test/unit/user_test.rb -n test_name).

We’ve added this plugin to a little section of our site called the Sakuzaku Goodie Basket, which contains a growing collection of random, potentially useful, open-source stuff that we’ve developed. We’ll keep adding to the goodie basket as we have the time to pull out and write documentation for all the internal stuff we’ve developed that might be useful to other people. Watch for more additions soon.

Surly: Shortened URLs from Multiple Browsers and Services

By Matt in Web Services, OS X

In response to recent well-founded worries about URL-shortening services and inspired by John Gruber’s endorsement of Metamark, Dr. Drang posted a short script for getting the URL of the frontmost Safari window (or tab, as it were), shortening it with the Metamark URL-shortening service, and storing the result in the clipboard. Even better, it can all be done with a flick of the wrist in Quicksilver.

Awesome, but I don’t use Safari. So I created some scripts to generate either a TinyURL or Metamark URL for your clipboard that works with your default browser. The scripts currently support Safari, Firefox, Camino, and Opera.

Surly — TinyURL to Clipboard.applescript

4 Kilobytes

Surly — Metamark URL to Clipboard.applescript

4 Kilobytes

Or, grab them all in one easy-to-download package:

surly_and_furly.tar.bz2

8 Kilobytes

Installation

1. Download the Surly & Furly collection.
2. Move the scripts you want to somewhere out of the way, but where Quicksilver can find it. Dr. Drang recommends your home directory, but if you like to keep your directories clean, you can put it in ~/Library/Scripts, which Quicksilver will index automatically if you’ve enabled the “Scripts (User)” catalog item in the “Catalog” section of your Quicksilver preferences. After a re-scan of the Quicksilver catalog (which you can force by activating QS and running ⌘+R, the appropriate scripts should be available.
3. Activate Quicksilver and call up your script. If you want to create a TinyURL from your browser’s frontmost URL, for example, typing TinyURL should find TinyURL.scpt (if Quicksilver has figured out where you’ve stored it). Just hit Enter, and after a few seconds your shortened URL will be in the clipboard. Note that Metamark seems to take a few seconds more than TinyURL, but you shouldn’t need to wait more than 2 or 3 seconds for either of them.
4. Paste away!

Questions, Comments

I will modify and create scripts for other URL-shortening services and browsers upon request by email. Also, don’t hesitate to send bug reports — you might get a Sakuzaku pin badge for your trouble.

Acknowledgements

Inspiration for these scripts is owed to the aforementioned Dr. Drang, to whom I extend many thanks. (If you’re writing about webpages, Dr. Drang’s furl script for getting full URLs is a great companion to Surly.) Thanks also to Daniel Bogan of Waferbaby, who provided testing and debugging.

Hunt and Peck: An Investigation and Proposal for Better Custom Keyboard Shortcut Management in OS X

By Matt in OS X, Constructive Criticism, Design, Commentary, Usability

The short story: The interface and functionality of custom keyboard shortcuts in OS X is awkward and unreliable. There are two possible direct reasons for this — Apple’s development priorities and non-standard application resource organization — and any number of underlying causes. I propose a solution.

This is the very long story. I am primarily a Camino user, but like anyone developing for the Web on a Mac, I usually have Firefox and Safari open at the same time too. My keyboard shortcut habits were formed in Firefox, though, and it’s too late to switch from ⌘+K for the search box, and ⌘+⌥+← and ⌘+⌥+→ for tab navigation. Having acquired a new laptop recently, I was reminded just how awful the process for setting up custom keyboard shortcuts is in Mac OS X.

Of Mysteries and Ellipses

If you’ve set custom keyboard shortcuts before, this interface will look familiar. In fact, it remains unchanged since OS X 10.3.

The problems here are manifold.

First, you have to find the exact name of the menu option you want to access. This requires switching back and forth between an open application and the Keyboard & Mouse preference pane, with nowhere but your mind (or a piece of paper, or a Sticky, but come on) to store the title of the menu command, which is itself potentially buried several levels below the top-level menu options.

This is further complicated by the fact that keyboard shortcuts don’t take effect until you’ve closed the very application you were getting the menu option from. (It doesn’t say that anywhere in the interface itself; you just have to come to that conclusion by trial and error or Help when it doesn’t work immediately.) Even if you remember whether, say, that app capitalizes “to” or “from,” there’s no way to assure you’re typing the right thing. The best example of this is the ellipses, used to denote a menu option that triggers further action in a dialog box.

Can you spot the difference?

Here you go:

Apple specifies in the HIG section on Style that menu options requiring further input or confirmation should feature genuine ellipses:

Important: Be sure to create the ellipsis character using the key combination Option-; (Option-semicolon). This ensures that an assistive application can provide the correct interpretation of the character to a disabled user. If you use 3 period characters to simulate an ellipsis, many assistive applications will be unable to make sense of them. Also, 3 period characters and an ellipsis do not look the same because the periods are spaced differently than the points of an ellipsis.

But just because something’s in the HIG doesn’t mean developers will abide. Firefox is a great example. A sample custom shortcut:

And sure enough, it matches up:

This is problematic.

Of course, it’s known that third parties aren’t the only ones who don’t adhere to the HIG. The “Search Google…” menu option in Safari, pictured above, raises a few tangential questions: Does it even deserve an ellipsis? It just quietly puts focus on the Google search bar, which I didn’t notice until I’d tried selecting it a few times. The neglected HIG doesn’t account for menu items that do things like that. Hidden as it is, this menu option in Safari almost seems to exist for the sake of being custom-shortcut’d.

Assuming you do get the menu command title right, there’s no guarantee that setting the custom shortcut function is actually going to work. I spent twenty minutes trying to set keyboard shortcuts in Safari and wondering why they would show up sometimes but not others. In the end I had too many screenshots to deal with. I think this one, taken after I attempted to create a shortcut for “Private Browsing,” will suffice:

Some sort of type-ahead mechanism that would fetch the right menu command for you would solve this problem, but that brings us to why this functionality isn’t already built-in.

Not a Key Feature

Obviously, making the custom keyboard shortcuts interface eminently usable is not a priority for Apple. For the most part, only a minority of users actually know and use keyboard shortcuts. Of those I bet a significant number desire at least some level of customization, but at the end of the day, it’s not a feature that moves units. It’s understandable, then, that it hasn’t been prioritized.

I initially suspected another reason: that improving the process would actually be quite difficult. Here’s why.

While it’s possible to get a complete list of the menu options of any running application with Applescript, it would be best if the preference pane didn’t need to run the application just to get the menus. So instead, providing a searchable list of default menu options for an application (dynamic things like the bookmarks and history in a web browser should be ignored) would require a registered list thereof for every available application. But do these even exist? If so, where?

Turns out they do. But “where” is exactly the problem.

In many applications (both Apple’s and those by third parties), the default menus are found in the MainMenu.nib interface file of an application. See for yourself: ‘Show Package Contents’ on the Safari application, navigate down through Contents › Resources › English.lproj › MainMenu.nib. If you’ve got Developer Tools installed, you should be able to open that file. You’ll see in the MainMenu.nib window something called “MainMenu,” an object of the NSMenu class, which manages an application’s menus.

Theoretically, a list of menu options should be obtainable from this .nib file. Unfortunately, it’s not always in the same place. For Calculator, it’s in Calculator.nib instead of MainMenu.nib. With DVD Player, it’s in MenuBar.nib. For Mail, I couldn’t even find it. So the preference pane wouldn’t know where to look without loading the application to tell it. Right?

Wrong! The location of the MainMenu-containing interface file is specified in the NSMainNibFile property of a given application, listed in the Info.plist directly inside the Contents folder of every application. Knowing this, it’s easy, for instance, to find the appropriate .nib for Mail, MailViewer:

Peachy Key’n

I’ve leave the implementation for another day, but all of the pieces are already there. The Keyboard & Mouse preference pane can already tell when an application disallows keyboard shortcuts:

And it knows that because — and here’s the kicker — it checks the Info.plist file! Check it out:

If a property exists to disallow keyboard shortcut customization, we can only assume that the list of available applications listed in the Keyboard & Mouse prefence pane is drawn from a cached list of applications whose menu commands can be edited. It wouldn’t be too far a stretch to get Keyboard & Mouse to then cache a list of the available commands from the MainMenu object in the appropriate .nib for each safe application.

The interface for finding the right menu command should work just like the new Help menu in Leopard. The screen would dim and a facsimile of the selected application’s default menus would appear. Start typing a command, and the close matches would be pointed out visually with the bobber. Once you’d selected a command (by searching or by manually navigating through the menus with the mouse), the command would fly from the menubar into the preference pane, where you could set a keyboard shortcut for it which would then be checked against existing shortcuts.

Click for a larger view.

A warning dialog indicating that changes to existing keyboard shortcuts wouldn’t take place until the application was restarted would then appear, offering, like Software Update, to quit said application immediately or postpone quitting.

It can be done. It should be done. The ball’s in your court, Apple.

See Also

John Gruber’s article Losers, Weepers speaks to the problems of the OS X custom keyboard shortcut feature, and was written way back in 2003 when the feature first appeared. (There are a lot of similarities there, but it’s worse that the problems haven’t been addressed in four years than me not remembering John’s original post.) He mentions a key problems not mentioned or addressed here but just as vital — the lack of conflict management.

This Is Important. Do It. Now.

By Matt in User Science, Commentary, Business

We received an email from the Wall Street Journal recently as part of a campaign to encourage their subscribers to complete a survey. Everything is wrong with it, and it’s a great example of how not to solicit feedback from your customers.

See for yourself:

First, there are some obvious but minor offenses: The visual design is terrible. What’s with the bright blue text? And the light blue background on the logo? If you’re going to send HTML email, do it with style. And couldn’t they have merged our name into the form letter? But there are some more fundamental problems here which we’ll address.

Dear Newspaper,

Please pay attention to these rules of user engagement:

Be polite.

It’s a no-brainer, but people respond much better and more often when they’re addressed nicely. Being blunt and businesslike may be an efficient way to do business, but when you’re bargaining for your customers’ valuable time and giving them nothing for it, you should at least butter them up a bit.

Ask or encourage, don’t demand. “We’d appreciate it if…” or “Would you like to help us…” is much better than “Please do this.” Note that the word ‘please’ here doesn’t do anything to make the request polite — it just makes it sound even more superficial and curt, since everything else about the letter screams rudeness.

Write from my point of view.

This letter is all about what the WSJ wants, and it operates under the completely erroneous assumption that what I want corresponds with what the WSJ wants. Ha.

I, quite understandably, want my business to be successful, want to finish this last piece of code, want to respond to these emails, figure out why my USB hub isn’t working, finish writing this blog post, to get to the bank before it closes, and to make a quick dinner. I could care less what the WSJ wants. This letter is like the annoying friend who comes whining to you when they, very reasonably, get fired for being late every day and losing an important file one too many times, but who isn’t there for you when your mother dies. The WSJ is asking me to do them a favor out of the goodness of my heart, but they don’t even bother to acknowledge that there is, without a doubt, a hundred more important things of my own that I could be doing.

How could this be improved? Simple: ‘We understand that you’ve probably got more important things to do, but completing this very short survey can really help us improve our service to you.’

Offer reward.

Why should I spend ten minutes on your survey? What’s in it for me? How about $10 off my next year’s subscription? This rule is the more concrete corollary of the previous one.

If there’s no promise of anything but a “Thank You!” page waiting at the end of your survey, don’t expect heavy participation.

Sometimes, even the illusion of reward is enough — automatic entry in a drawing, for example. People know they probably won’t win your sweepstakes, just as they know the chances of winning big at a slot machine or on a lottery ticket are small, but there’s a chance, and everybody loves chances.

Don’t deadline.

Your users are busy people. Giving them a deadline and expecting them to complete your survey by then is just asking to get ignored. It sounds imperious and as if you don’t care at all about the fact that the recipient probably has many other deadlines that they consider far more important.

Of course, there does have to be a deadline — you need to cut off submissions and aggregate the data eventually. Handle it like this: First, set it more than eight days in the future (much further, in fact). Second, just don’t tell your readers when it is. There’s no need to create a false sense of urgency with brusque statements like “Please complete it by October 22nd.”

Make it quick.

Ten minutes is a long time, and exactly the sort of length that seems too long to bother with. And it’s probably not even accurate. Anything above two or three minutes is actively discouraging participation.

If your survey does take more than a few minutes, though, there’s no reason to lie. Like the deadline, just leave it out your estimated time. Better to risk people leaving in the middle of a survey than not starting it all.

Explain yourself.

Why are you conducting this survey? “To help improve The Wall Street Journal” is too vague. What about your services are you improving? Why should I care? Again, this ties in with writing from the recipient’s point of view and thinking about what’s in it for them. Just referring to your survey as an “important project” doesn’t necessarily make it one to me. You’ve got to convince people what you’re doing is important, and every bit of communication you have with your customers is a valuable opportunity — make the most of it and don’t make them regret they gave you their attention.

If all you’re doing is running an annual survey to ensure the relevancy of your advertising and there’s really nothing interesting or exciting about it, well, there better be some nice prizes.

And besides, everybody loves to talk about advertising — you might be surprised at the responses you get by allowing your users to sound off about it.

Be brief.

You can be friendly, honest, and sufficiently explanatory without being overly verbose. Leaving out details like deadlines and completion times can help. Ask nicely, offer reward, and let people do your survey on their own time, on their own terms.

The rest is results.

Lunch With You: Mike Lee

By Matt in Interviews, Systems, Business

Mike Lee makes an impression. Several, actually.

The first: this guy is in an aloha shirt and he could break me in half with his pinkie finger. The subsequent impressions, taken in over Brazilian barbecue for over three hours, make you realize this guy has a lot of big ideas and opinions. So, it was our pleasure to have him and his wife Mary inaugurate our “Lunch With You” series when he visited Honolulu recently.

For those who don’t know, Mike works at Delicious Monster, whose flagship product Delicious Library is a best-selling library management software for OS X. The app allows you to scan in all of your books, movies, music, and video games (using either your iSight camera or a custom barcode reader) and keep them organized, automatically pulling in cover art and a plethora of other data from Amazon. It keeps track of to whom you’ve lent what and is kind of addicting for those crazy about organizing.

We asked Mike a number of questions that we’ll paraphrase his answers to here.

The Delicious Monster team has just begun the Library 2.0 private beta, after about two years of work. Leopard has caused the team a lot of work — nearly every change they make has caused problems and incompatibilities that require bug fixes and adjustments. Mike said, “We spent a year working on what was going to be Delicious Library 2, then delayed it a year after deciding to go Leopard, all the while cramming in features. It’s almost like we skipped 2 and are shipping 3.” He said it’s been frustrating for them. But, such is the nature of building software for an evolving platform, said Mike, and it’s the most difficult part of working at a commercial desktop software company. But it’s not just Apple — all of the cover art and metadata for the software comes from Amazon, making the software’s functionality subject to Amazon’s whims.

We asked some technical questions. Delicious Monster uses Subversion for version control. The team doesn’t do any automated unit or functional testing. Mike’s opinion is that all the testing in the world won’t make your software free of bugs, and there’s just no way to account for things you can’t account for. A serious insight that we definitely concur with and that we see a lot of people missing is the importance of planning for but not implementing the plan for ‘what if’ scenarios. There’s a good chance that those things may never even happen. Citing his boss Wil Shipley, Mike put it well: “If we ever get to the point where we have so many users that this is actually a problem, we will be so rich we can pay someone else to deal with it, while we sip rum on a beach in Tahiti.” Take care of the real problems today, and don’t worry about what’s going to happen if your servers are hit by a flaming tornado filled with sharks during an earthquake, or three hundred people with the same name sign up for your software.

Being coffee shop hounds ourselves, we wanted to know what it was like to work out of one every single day (Delicious Monster works out of Seattle coffee shop Zoka everyday). Mike said it has its ups and downs. There’s no office overhead, it’s cheap, and it’s brought some great publicity. But it doesn’t take long to get sick of the menu, the intrusive atmosphere, and the not really having an office.

Getting back to Delicious Library, Mike admits that the app has its detractors, many of whom ask the obvious question: “What’s the point?” Well, if you don’t get what the point is, then there probably isn’t one for you. But the fact remains that Delicious Library is selling extremely well, meeting the needs of a niche market that includes families, collectors, and, interestingly, Bible scholars, each with lots of different media that needs organizing. In Mike’s opinion he thinks it helps that Library is so well put together and the competition isn’t, but also that their competitors are few and far between.

But while Library is the only thing Delicious Monster is focusing on at the moment, they don’t seem to have any shortage of ideas. What else is the team thinking about? Pinball, human slide-puzzles and Pokémons on the iPhone. We waxed nostalgic for Sonic Spinball. It’s true — there is no great pinball software for the Mac. Delicious Monster obviously has no fear of peripherals if they help get the job done, having developed a barcode scanner to use in place of an iSight for scanning into Delicious Library. The ideas were flying: Network play, of course, and how about some flipper dongles and customizable boards?

But none of it has begun to crystallize yet. Delicious Monster has their hands full with Library and their professed object is keeping it The Best Solution. This idea — complete dedication to a vision and executing it well — kept popping up and telescoping in scale as lunch went on.

If we got one thing out of the conversation, it was that Mike Lee loves to write software. He says it best himself: “I was born a programmer. The rest is just implementation detail.” Whether it’s working without pay in Wil Shipley’s basement designing the application that won multiple Apple Design Awards or developing a poker program with lemurs for face cards for his wife’s birthday (really!), programming is Mike’s creative outlet, and one that he says he can’t seem to turn off. And he wants to tell you about it. His blog and Twitter feed, named exactly what you think they’d be, are the best evidence of his outspokenness.

Which is not to say he lacks other passions. Mike’s email signature pegs him as the “Delicious Monster Majordomo. He’s as likely to be programming beside [the Delicious Monster team] or cooking them dinner. He serves as bodyguard and confidant, jester and enforcer.” He’s in love with lemurs and wants to save Madasgascar. But he first and foremost thinks of himself as a software engineer. We got the impression that he understands the economics of being a productive human being.

When I asked whether he had thought about helping Madagascar directly, making the move from computer scientist to natural scientist, the answer was instantly and unequivocally “No.” He’d obviously thought about this, and immediately compared his approach to work to that of a diesel-electric locomotive. Much as the diesel and electric components of the engine do what they are designed to do and pass on the output of their work to other pieces of the system, Mike wants to do what he’s best at — programming — and offer his resources to the charitable organizations already helping Madagascar.

We talked a lot about charity, actually — Mike was in the middle of a piece he’s just published on his blog with a number of ideas about how to work charity into software development (and everywhere else). Mike thinks working against human nature isn’t just difficult, it’s a bad idea — intelligently leverage the compassion and tendencies of people, and there’s no reason you can’t build a better way to keep spam off blogs or prevent the extinction of a cute ancestor. We think Mike Lee is genuinely interested in applying his skills to have a wider impact on an audience greater than a single piece of software’s immediate user base. It downright gave us some inspiration.

He is, after all, the (self-titled) World’s Toughest Programmer. He said what was on his mind and it’s clear he doesn’t tolerate nonsense. And while the rest of us are too full, you better believe he’s going to finish what’s on his plate. (Literally — we couldn’t possibly finish all that Brazilian barbeque.)

So, Who’s Next?

Would you like us to have Lunch With You? Are you in Honolulu? Will you be soon? Have some good ideas or some insight to share? If we know who you are (or if you think we should), let us know, and we’ll take you out to lunch on us.

Email us if you’re feeling talky.