OpenomyFS: Using FUSE to mount your Openomy Account

In my last post I mentioned that I was working on a new Openomy application-- finally, here it is:

OpenomyFS (or OFS for short) is a Ruby script that uses the Ruby bindings for the FUSE library to mount your Openomy account on Linux! It provides a fast way to upload and download files without having to go through the web interface, and also lets you manage all of your tags. The best part is that since it looks like a regular mounted partition-- you can use it to save your work to Openomy from any application.

I've been using this version for a few days now and I think it's really cool. Here is how the filesystem is structured:

The toplevel has two directories, /tags and /files:

• /tags : This directory contains a directory for each tag you have defined on Openomy. You can define new tags by using 'mkdir' and you can delete tags using 'rmdir'. Each tag directory has all of the files that are stored under this tag. Deleting a file from these directories removes the file from the tag. Similarly, copying a file into one of these directories saves that file under that tag.


• /files : This directory contains all of your Openomy files. Deleteing files from this directory actually deletes the files from Openomy. Writing to these files saves the changes to Openomy, and creating new files here will upload them as well.

For more information on how to download, install and use OFS, click here.

PS: OFS uses the latest version of the Openomy Ruby bindings-- I added a few API calls while working on OFS. You can download the latest version of the Ruby bindings in the a the Openomy Ruby project page.

More Ruby: method_missing

It's been a while since I've shared some cool stuff you can do with Ruby-- here's a trick I've been playing with recently.

Ruby defines several hooks-- methods that it calls behind the scenes when something happens. For example, in a previous post on metaprogramming, I used 'method_added' to refer to a method before it was even defined.

Another useful hook is method_missing: This one is called whenever someone tries to call a method in your object that doesn't exist. Using this hook, we can "pretend" to accept method calls that aren't defined.

This is especially powerful when combined with object composition. Here's an example:

class SimpleCallLogger
  def initialize(o)
    @obj = o
  end
  def method_missing(methodname, *args)
    puts "called: #{methodname}(#{args})"
    a = @obj.send(methodname, *args)
    puts "\t-> returned: #{a}"
    return a
  end
end

This object "intercepts" all method calls made to it, prints out a message and forwards on the method call to an internal object using the 'send' method-- without knowing anything about the object passed to it. I've used this a few times to debug some code without littering it with print statements. Try that in your static language.

Another cool application of this is caching: I'm writing an application with the Openomy APIs that I thought was going a little too slow. I made a class that I could wrap around my openomy-ruby objects and cache the results of some of the calls. Using method_missing, I did this without changing the library or worrying about the cache all over the place.

I posted the caching class, as well as a slightly modified call logger, on my new projects page. An improved version of the Contract library from my previous Ruby metaprogamming post is on there as well (which I submitted to the upcoming Ruby Cookbook). If you have questions about things that are on there, shoot me an email.

Annoyed with Google single sign-on

UPDATE: It seems that Blogger deleted this post somehow.. here it is again. Sorry!

Google let users register for a "Google Account" which they can use to sign in to Gmail, Google Analytics, Google Reader, and all the other Google services.

Single sign on has great benefits: there's only one username and password to remember, it eliminates the hassle of registering for new services, and no need to manage separate user profiles. I think it's great for usability, when done correctly.

However, the most annoying "feature" of the Google system is that when you click "Sign Out" on ANY Google application, it logs you out of *ALL* of their applications.

Here is what frequently happens to me: I'm catching up on my blog reading on Reader when I decide to check my Gmail. I go to gmail.com, and instantly my inbox is displayed, since I'm already signed on via Reader. Awesome. When I'm finished reading my email, I instinctively click "Sign Out", close the tab, and go back to Google Reader.

All of the sudden, it stops working. No new stories come up. It gives me an error message: "Oops...an error occurred. Please try again in a few seconds."

?!?!?!

Waiting a few seconds isnt going to magically log me back into their application. The least they can do is tell me that I've been accidentally signed out and prompt me for password again. It actually took me a little while to figure out that the "single sign-out" feature was the cause of my problem.

I agree this is partially caused by my own habits-- but who would have thought that a system meant to increase usability would cause such an annoying user experience?

Openomy Developers' Community launched!

Someone emailed us today about the Openomy APIs with a pretty good question. They asked, if I want to release my Openomy application open source, how do I protect my application key and private key?

We had been thinking about this problem for a few weeks now. We ran into the same issue when we released the source to Openomy/RSS. We emailed this person with how we were thinking of fixing that problem and asked for their feedback.

Currently, aside from Ian's and my inbox, there is no one place that records all of the questions we've gotten about developing Openomy applications. That is why we have launched the Openomy Developers' Community on Google Groups.

We want it to be a place of dialogue and of sharing ideas. We've kicked off the discussion with our proposal on how to fix the problem with Openomy open source apps. Let us know what you think! Also, if you want to share your idea for a new Openomy application, to announce a launch, ask for new API calls, or to report that annoying bug, please use this group as well.

Corporate speak

Matt from 37signals has a hilarious post today making fun of Adaptive Path's latest essay.

As a geek, reading articles like this just hurts my soul: there are no new thoughts, just buzzwords and overly complicated diagrams. When I first read the original AJAX essay, I wanted to rip my eyes out. I couldn't believe that these guys were getting so much attention just because they coined a new buzzword.

But of course, geeks aren't the target audience for this stuff. As a fellow consultant, I can appreciate the intent: it can be hard to explain technical things to non-technical people. I just wish they tried to do it without the incredibly cheesy portraits and terrible diagrams.

Matt also links to an old 37signals joke, Enormicon, where they make fun of branding consultants. Some claim that Sapient was the first "*nt" company (we were founded in 1990). Surprisingly, Sapient's name didn't come from the branding guys-- Jerry, one of our CEOs, found it in the dictionary and just liked how it sounded (or at least that's the story they like to tell).

The Innovator's Dilemma

Due to the nature of my job, I spend a good amount of time in airport terminals catching up on some reading. I'm currently reading Lawrence Lessig's The Future of Ideas"-- it's really interesting so far.

Anyway, Lessig references a book called "The Innovator's Dilemma" by Clay Christensen. Apparently, this is one of those "classic" business books that I've been missing out on. Here's the gist of it: Successful companies are bad innovators because they resist betting on disruptive technologies until its too late. Why? By definition, a technology is "disruptive" when it fundamentally changes the market... that is, that same market that made the company successful to begin with. So in a sense, they are being perfectly rational: They are already seeing great growth and revenue from their core market, why risk it by introducing something new that might screw that up AND might not be as successful? Some people call this cannibalizing your market.

This behavior is exploited by startups all the time. Innovation and agility is their competitive advantage. They disrupt the marketplace, but once their innovation catches on and they become successful, they are doomed to face the same innovator's dilemma that gave them their opening in the first place. Apple/Motorola is a good example of this: the ROKR phone was a great opportunity to disrupt the MP3 player market, the cellphone market, and the market for ringtones-- instead of doing that, they delivered an enormous flop.

But, why must this be the case? Can startups avoid it? I think they can: just never stop acting like a startup. Keep your teams small. Force different your business units to compete with each other. Make them operate almost like independent businesses. Encourage a culture that rewards innovation and creativity above all, and give people ownership of their creations. Have a division that's resting on its laurels? Keep the best, most entrepreneurial people, spin the rest off, and invest that capital into the next big thing. The startups that are still successful as huge companies, such as Yahoo, Google, and Amazon, are famous for keeping that culture of innovation alive in their companies.

Christensen apparently gives his own solutions in his book. It's now next on my reading list-- I look forward to seeing what he suggests.