-
Notifications
You must be signed in to change notification settings - Fork 0
Facebook IO demo in rails
obskein/Friendtersection
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
== 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