daydreaming

I hate having to build authentication structure, it creates extra code for me to write and it causes extra fuss for users in terms of the forms they have to fill out. Centralized authentication systems have long promised to get rid of this hassle. One notable examples which was never widely adopted was Microsoft’s passport. Such centralized systems allowed a system to authenticate it’s users against a central data store. To many consumers of authentication technologies having a centralized point of failure, both in terms of reliability and security was unacceptable. Especially when that centralized point of failure was Microsoft, hence Passport’s narrow adoption. Microsoft has now built a new system called Windows Live ID addressing some of Passport’s isssues.

In contrast to these centralized systems, OpenID allows a system to authenticate it’s users against any other system. I will leave an explanation of the key exchange to other sites here and here who do it much better than me. The one complexity left with the OpenID specification is that you need to remember or record an arbitrary url, which you must enter on the site you want to authenticate with. For users, this is as bad as them having to remember a password, except that the URL need not be kept secret.

The solution to this complexity comes from Clickpass. They have created a one-button graphical widget which lets users authenticate against Facebook, Google and Yahoo or any OpenID provider. The developer just has to implement a simple interface and is good to go. More importantly, the user’s experience improves dramatically since they now only have to login once with their authentication provider instead of over and over again at each site they go while repetively typing in a complex URL. So what’s not to like? Clickpass makes life easier for the developer and the user has a better experience.

Fire Eagle (not fireeagle) is a new location platform from some of my colleagues here at Yahoo! Brickhouse. I’ve put together a simple sample app called whereis which shows off the power of the platform.

What is whereis?

Each instance of whereis lets you share location within a trusted group of people. Whereis does not update location in Fire Eagle, you should do this using other apps (eg. Fire Eagle automatic device updaters, or other sites). This screenshot basically sums it up -

What can I use it for?

• Run it on your intranet to easily share location between your co-workers
• Run it on the internet so friends and family can share location

Who is whereis intended for?

Whereis is intended for developers who have familiarity with Ruby and access to a server.

Why are you releasing it?

It is a simple app (~200 lines of code) built on top of the camping framework. If you understand Ruby and the MVC pattern, it will give you a good idea of how FE works and can be used. I think the code is pretty self explanatory, drop me a line if you have any suggestions.

Continue Reading »

If you want to add a call to all the controllers in your Camping miroframework app you can use before or after overrides. These are similar to the before_filter in Rails.

Remember to return the superclass or Camping will throw a “Read error: #<NoMethodError: undefined method `status’ for nil:NilClass>” because it can’t call back into the returned controller. A modification of the above linked wiki page example illustrates -

Camping.goes :YourApp

module YourSession
  def service(*a)
    @session = YourApp::Session.new
    s = super(*a)
    @session.close
    #return s from above after completing
    s
  end
end

module YourApp
  include YourSession
end

Carlos did a quick test earlier in the day on our Apache Derby backend and found that in a particular like query Derby was 23x slower than on a equality query over the same data set. Very often, databases do not optimize LIKE queries, partially because it is rare for them to support the types of indices such optimizations would require.

It took me a little while to find this gem on LIKE Transformations in the Derby tuning manual. Basically the document covers some transformations which the Derby SQL parser goes through to make LIKE queries optimizable. For me, this solved the problem as it allowed me to rewrite my query into a form that was optimizable albeit with a slight loss of functionality in my application. Unfortunately, this is not the case for all LIKE queries. The transformations are quite obvious and easy to follow once you see them, so take a look if you are having similar performance problems.

Before:

SELECT checksum FROM tags WHERE tag LIKE ‘%element%’

Gets parsed into – SELECT checksum FROM tags WHERE tag LIKE ‘%element%’

After

SELECT checksum FROM tags WHERE tag LIKE ‘element%’

Gets parsed into – SELECT checksum FROM tags WHERE tag >= ‘element’ AND tag < 'elemenu'

These transformations are also potentially useful with databases other than Derby when LIKE queries are running slow, as you could do them manually on your statements to the fullest extent possible potentially eliminating LIKE altogether.