Rafblog - Jake Cohen's Blog

On Creating Strong Passwords

It's getting harder to generate secure passwords these days. Part of the problem is that, the stronger a password is, the harder it is for someone to remember. A password such as 'F7c%el(9xfka$hsa' is an extremely strong password, but probably almost impossible to remember unless you type it many many times a day for a long time.

Here are a couple of ways of creating strong passwords that are much easier to remember.

• Use the first letters of each word of a long and memorable sentence. The lyrics from a song you like will work well for this. For example, from the song I Don't Know by Ozzy Osbourne, the first line of the song is, "People look to me and say, is the end near, when is the final day." This would become "Pltmasitenwitfd". To make it even stronger, you can tack on the name of the song, separated by some symbol, to get something like "Pltmasitenwitfd$idontknow". Very strong password, pretty easy to remember (assuming you know the song well).
• String several memorable words or a phrase together separated by symbols. Examples: "We.the*people", "Skyline:miter-crane", "Top%of%the$morning".

Airport Security for Parents

I've recently been following a thread on one of my company's internal mailing lists about tips and tricks for air travel with small children or infants. One of the major stress points seems to be getting through security.

This is stressful because parents are usually traveling with a whole bunch of extra stuff, and have to somehow get all of this through the security checkpoint one-handed while dealing with an unhappy child. The TSA staff is often inconsistent on what sorts of liquids can be brought through the checkpoint, and the parents are stressed about keeping their kid happy and not irritating all of the people behind them in line by taking forever.

I think a solution to this would be to dedicate at least one, and probably some percentage of all available security gates to serving only people who are traveling with small children (e.g. young enough to need strollers or car seats or other similar bulky items). This would have many advantages.

First, the security checkpoint could be set up to cater to these travelers, with more room to get everything packed down and through the scanner. The TSA agents staffing the station could be trained specifically to the sorts of things parents are usually trying to bring through the checkpoint.

Also, since it would separate parents and children into a new line, it would take a lot of stress off of the parents trying to get through the checkpoint. Everyone behind them in line is in the same situation and would be understanding if they needed to take a little extra time to make it through security. However, since the line is comprised of *only* parents traveling with small children, there would be fewer people in line and the whole process would not take longer.

iTunes Store requires WiFi

To access the iTunes store from an iPhone, you need to be connected via WiFi. It won't let you connect over the 3G internet connection.

This restriction baffles me. Why would they do this? The 3G internet connection is perfectly fast enough. You can connect to the App store over 3G. It seems like they are leaving a lot of business on the table.

As an example, if you are listening to a song on Pandora, wouldn't it be useful to be able to buy that song immediately from iTunes without having to wait until you're connected to a WiFi network? And there are several applications already (such as Shazam) that will identify a song if you hold your phone up to the speakers for a moment. Wouldn't it be useful to be able to buy that song right away?

It may very well be that there is some valid business reason for this, but from a customer's point of view, I can't see it.

Rock Band Wish List

I've been playing a decent amount of Rock Band recently. I've been staying away from the vocals, but I can get through almost all of the songs it comes with on "hard" on bass, guitar, and drums. This game is a great way to build or maintain hand-eye coordination.

But it has left me wanting more. This game is in dire need of more songs available for download. The total catalog is only a few hundred songs. I'm sure it's a pretty decent chunk of work to get a song, secure all the appropriate distribution rights, cut it up into its various parts, create the track information for each instrument on all of the different difficulty levels, etc, but it would definitely keep the game fun for a much longer time if the catalog of songs was larger.

In addition to more songs, I hope they are working on expanded instrument capabilities, particularly around the drum set, which comes with 4 drum pads and a kick drum pedal. I would love to see an expansion drum set that attaches a hi-hat pedal, a hi-hat drum pad, and drum pads for one or two cymbals. This would allow the four main drum pads to be used for snare, toms, and percussion without their assignments changing in the middle of a song like they do now. It would also allow for a more complete drumming experience, using both feet and a greater variety of drums.

For the guitar and bass instruments, it would be pretty fun to have the ability to use the microphone and add a backing-vocals track. Many of the songs that come with Rock Band have multi-part vocal tracks, but only the lead vocals are available to perform.

Disable Menu Items

In a recent post on his blog, Joel Spolsky writes that you should not "hide or disable menu items". His alternative is to leave all of the menu options in place, and provide messaging to tell the user why an action can't be completed.

I have to respectfully disagree with his assessment. I think that leaving menu items active all the time is actually harder to use and understand. It requires the user to spearfish through the menu and live in fear of clicking the "wrong" menu item that triggers a warning message. Worse, it actually makes it harder to understand what the various options do if they are always available. Take your typical application Edit menu, for example. Many of these will have Undo and Redo options available. If you leave these active all the time, it can even be confusing before the user tries to click. If you've just opened the application, what would Undo actually undo? If you haven't undone any actions, what would Redo actually redo?

Now don't get me wrong, I don't think that hiding menu options that can't be used is any better. Looking for an item in a menu and not seeing it where you expected it to be undermines your ability to get accustomed to how an application works. It derails your mental schema of how the application works, even if the application's behavior hasn't in fact changed at all.

I think the most reasonable way to handle this is to provide the "disabled menu item" design that almost all applications are already using. This can be augmented by visual aids to indicate why an option is not available. A subscript text to say something like "already at oldest change" under a disabled Undo option, or a subscript that says "nothing is selected" under a disabled Cut option.

But if that is not feasible, I think just leaving menu options disabled in the appropriate context is the best compromise. The confusion of seeing a disabled menu item to me is preferable to the uncertainty of not knowing whether clicking a menu option will actually do something, or just pop up a warning message telling me why I can't do that right now.

Fedora Update

The Fedora system has been running for a few days now. One minor annoyance I've encountered so far is the way the system uses yum. It's not that I find yum to be a bad package manager. On the contrary, it is very easy to use. The problem comes from how yum will create a lock file whenever it is doing anything, and no other yum operation will proceed until that lock is available.

I can understand the purpose behind such a lock. After all, you wouldn't want concurrent modification of the system's picture of what is installed and what version everything is, and so on. However, the problem arises from the fact that the lock is held for absolutely everything. I started a routine system update, and it held the lock for the entire time it was downloading all the new packages. It was waiting for network data while holding an exclusive lock on the whole system.

It is generally considered best practice to hold an exclusive lock for the minimum amount of time necessary to ensure correct behavior. It seems yum is going far beyond this limitation and just trying to acquire the lock before anything happens at all.