You can play music on a locked Mac OS X

At some point today my Macbook Pro, running Mac OS X 10.6.8, locked my screen due to inactivity yet I was still able to control the audio via helper keys on the top row of the keyboard. That’s pretty cool. It made me think of my Android phone, and how that too offers audio controls when locked. It made me think of how designing a product requires attention to the most subtle of details.

When beginning a new project, I often start off in total ignorance at the amount of work that will ensue. I think to myself, “sashimi slices, it’ll all work out” and then I plug away at writing some code, designing some views, and seeing it all come together. At some point I find myself customizing the little pieces of the Application: the footer. Woah, seriously the footer is valuable real estate but I rarely look at it that way. Yet, in it’s tiny form it can hold some of the most important links and people naturally go there. We actually expect a footer on the pages we frequent; we expect it has worthwhile resources that we may need. And what goes into this footer is exactly what I’m talking about: subtle features.

I’ve tried to come up with a name for these features and I think I’ll stick to unoriginality and call them Core Application Functionality – CAFs.

Apple loves their CAFs and it shows. My Macbook Pro understands me. It knows that just because I’m not logged into my computer I still may need to adjust the volume. It knows that physical components of my machine, like sound, need physical controls.

Mac OS X reminds me of how CAFs can make or break an (web) application. For example, looking at user authentication we have a baseline rubric for what we need to use a service. We expect a web application to let us register, login, and logout. That’s the basics. Of course we are missing one very important feature: password reset. Unfortunately, not all web apps are created equally and some fail to provide a password reset mechanism. A missing CAF like this highlights the little attention to detail in core functionality of the Application. That’s pretty bad and what’s worse is how the user is left feeling helpless. A negative experience such as this will have the Application failing — what a silly way to break the bank!

CAF gaps happens. Trust me. As an avid user of new web applications I find myself stuck more often than I’d like. These gaps creep up on start-ups as well as medium-to-large sized companies. They just happen. And they suck. So my advice is to take a moment and ask yourself this, “does my application get me?”

New Rails Deployment Stack

This is a post more geared towards getting feedback. What do you guys think of this proposed Ruby on Rails infrastructure stack for deployment of a Facebook Rails app?

  • Ruby 1.92 via RVM
  • RubyGems 1.5
  • Nginx
  • Unicorn
  • CentOS
  • Git or Subversion — to be decided. Weight in if you have a preference!
  • MySQL

The major change from my current set-up is removing HAProxy and putting in Unicorn and moving away from Env.Config’s to Gem Bundler.

Update 2/23/2011: I went with Ruby compiled, not via RVM, and skipped Unicorn and went with Passenger (for now). My reasoning behind both decisions was purely based on my experience with Passenger and inexperience with RVM/Unicorn. I’ll continue to develop locally w/ RVM/Unicorn and maybe the next version of the application using this stack will get to see Unicorn. Very happy so far with the deployment stack; been running about 4 days now with very minimal server load. I’ll be interested to see how the new stack performs when the thousands of users via Facebook start hitting it :)