== Welcome to Friendtersection

This wee applet has been a very, very interesting project for me. In truth, the 
application functions are of almost secondary importance.

In the process of completing this test I have

* Written my first facebook application
* Used Oauth for the first time
* Got my heroku account and github sorted out
* Written one of the very last 2.3.x branch Rails applications


A demo can be found running at friendtersection.heroku.com

== Choices

As this is a coding test, I have made several options, mainly based on expediency and the 
contrived nature of the application.

1. Views
    Cohesive
      One view. The features requested should fit in one page, as a standalone app.

    User Experience
      No navigation is required; no learning curve, and all requested features immediately
      visible to our non-specific user.

    Grid layout
      Rapid prototyping with a focus on user experience; regular design that can lead designers
      and allow designs to be 'dropped in'.

    Failure Resistant
      The simple techniques here allow for information to be added to the page at the whim or 
      success of the controller. This makes the service more robust as API limits are reached, 
      or when remote services are not available.

    Helper-dependant
      Almost no ruby in the views, allowing simple chaching and testing solutions for more robust 
      code.

    Haml
      As if it could be anything else in this day and age.

2. Controllers
    Simple
      The single view allows for very simple controller design; we have only the default

    Semi-restful login

3. Models
    Non-existent
      NoSql applet, facebook is the sole data provider

    Ready to populate;
      Examining the use of data in the controllers would lead model development here, likely various
      Person, Like and Friend models to encapsulate return data. Domain model would depend on 
      specification, but the app will obviously scale in a restful way with trivial re-writes.

= How to make the app better

1. Add caching of responses, these could be mined for use and esoteric tracking/trending/digging/whatever
2. Add cucmber tests, using the selenium headless ff or wkt interfaces -really test the app did what it was supposed to
3. Consider reducing single-page functionality in favor of user-trips to resourceful access
4. Add ajax support after accessible rest implementation progresses