asemanfar - a blog about programming

Today, Facebook announced their new Open Graph API. The Open Graph API allows any website to have all the features of a Facebook Page. So you'll be able to "Become a Fan" of any site, make comments, have discussions, and receive updates published by fanned sites. Think Amazon's Universal Wishlist but not just for things you can buy.

This leads to some interesting business opportunities for Facebook. Facebook will be able to capture socially relevant information from anywhere on the Internet. Facebook will collect information about "what's on your mind" from everywhere on the Web, not just on facebook.com.

Now let's take that and see how Facebook can profit from that: they can do exactly what Google does but enhanced by your social graph. They will be able to give you Web Search Results but unlike Google, they'll be able to tell you that "Joe Smith likes this" and what was "on his mind" when he visited that site. Not only that, but they'll maybe even cross some privacy boundaries that Google couldn't and use that information to target ads.

The challenges Facebook will face in the coming months/year will be dealing with privacy issues and adoption of the Open Graph API. I suspect something similar to a bookmarklet, browser toolbar, or full-blown "socially enhanced" browser will be used in order to gain traction and bootstrap their social indexing efforts. I'm also interested to see how well they'll execute on search results with social graph information and if they can complete with Google's myriad of well-tested and proven search ranking algorithms.

Arya likes this.

For roughly 2 years now, I, among many many others, have been working with the Ruby on Rails framework. During this period Rails has evolved in many aspects including but not limited to design principles, deployment strategies, and development styles. For example, in 2006 (or maybe earlier) DHH (the creator of Rails) became an advocate of REST and thus implementing it into the framework. Although the REST principle has been around for a while, it was new to a lot of Rails developers. In addition to changes in framework itself, the Rails community has picked up some other interests like switching to the Git version control system. Anyway, getting to the obvious non-point: Rails is a fast-paced community.

So, Why Bring This Up?

I started working at a company where nothing is written in Ruby (which is what I've been mainly using for a while now). And all the source code is in a different version control system than I'm used to. And the list goes on. Naturally, there is a learning curve for all this and its slope will vary per-person. But luckily, since I've spent the last 2 years following and constantly learning from this fast-paced Rails community, I've been able to adapt pretty quickly and learn a lot in the past couple weeks.

Moral of the Story

Don't be afraid of learning new things. Always learn new things.

Here is some code I just threw together for fun, I don't actually use it. Some would call this monkey patching.

   1  class Symbol
   2    def to_proc
   3      Proc.new { |*args| args.shift.__send__(self, *args) } 
   4    end
   5  end
   6  
   7  class Array
   8    def all?(*args, &block)
   9      !!self.each { |e| return false unless block.call(e, *args) } 
  10    end
  11    
  12    def array_of?(klass)
  13      self.all?(klass, &:is_a?)
  14    end
  15  end
  16  
  17  
  18  puts ["Will", "this", "work?"].array_of?(String) # => true
  19  
  20  puts ["But", "this", 1, "will", "be false"].array_of?(String) # => false
  21  
  22  puts ["But", "wait", "this still works"].all?(&:to_s) # => true

Read more...