first commit of test repo with README.md
Test repo to play with code Lester is testing...
updates to Lester's test repo...

Focused some real time into getting a version of friendography
prototype that does not use a database.  Simple implementation of Koala
with Facebok javascript sdk, Geocoder for encoding city names to
coordinates.

This repo should be run with rails 4.0 and it's dependencies.
reduce sleep time and add a frame to remind me whats where...
Quick implementation of a javascript google map with static map also in place still.
removing the old static map.  Also added a User model for current FB user.
quick update to add infowindow and markerclusterer
Work on speeding up geocoding process.

Right now, when building friend list, instead of geocoding for each
friend am building a hash like location_id => location_name from each
friend's location. Since locations have unique id's and the hash
auto-uniques on the keys, we end up with a unique list of places for
all friends.

Then, out of place, I make a new hash containing mappings like
location_id => [lat, lng]; that is, do the geocoding. Now, there is
some fancy ruby stuff to do all this with one hash in one or two
lines, but it doesn't work so well for rails, apparently, so I'm using
doing the update from names to coords out of place.

Finally, we go back through the list and assign to each friend the
coordinate as indexed by their location's unique id.

This can be made more efficient; the coords can be stored in the
session. Also, using this scheme the friends are all piled one atop
another on the exact same coord, which is bad -- need to space them
out
Lower time between geocodes.

The bound is ostensibly 100/sec.
Changes to add multinames to markerclusterer infowindow and change style for cluster markers.

In InfoWindow for markerclusterers we lose ability to show images
because marker infowindow and rails instance variables are gone at the
time of calling click command.

Now, I'm just pulling the friend name from marker.title which is all we
have.  We should also limit the number of names that appear on a
cluster, otherwise the window gets super long.
Merge branch 'speedup_markers'
Raise sleep time.

Had read that the geocoder could handle 100 goecodes/sec and so
thought that a 0.05 second sleep would suffice, but the thing
sometimes errors out with that. Replacing with 0.1 second sleep seems
to work.
Poor man's error checking on geocoder.

When we hit error limits, the geocoder returns nil. I would rather
catch a thrown error but I don't think the geocoder throws an error,
so am just checking for nil now. In future should store off the failed
geocoder and then try it again.
Better way to handle coords being nil.
Start to add own location lookups to replace geocoding service.

The service is slow and limited. The ideal situation will be a hybrid
between lists of common places an areas supplimented by geocoding when
a) very obscure places are needed and or b) a high degree of visual
resolution is needed.

Right now have a class in controllers/ (not obeying rails hierarchy)
called fblocation which, when an instance of it is instantiated, pulls
up a huge hash of countries, which are keys to more hashes of cities,
which are in turn keys to open source goeocodes. Each country also has
a special "coords" hash which is its centroid (or sometimes capital).

In the search controller than (again, bad form) we have a class
variable that is the master location list and then we simply do the
geocoding as before (although I have simplified down to one loop)
except for the "geocoding" is in fact lookups into this table. It
tries to get as deep into the table as it can, but at the worst it
returns the location of the country, which is enough for a cursory
visualization.

There are many wierdnesses to FB's location strings. For example,
mostly the strings are "city,country" but for the US they are
"city,state". Why? Also sometimes they are just "city" which is
bad. But anyway, this is a start.
Add simple default to geocoder in case of total failure.

Table lookup should always return something if there is a valid
country -- but sometimes the fb locations are incomplete, and in this
case we revert to doing a geocode. Am not sleeping here becuase,
nominally, this should be a rare event...
Add some comments to search controller.
Get user's location in the same way as friends'.

Try to lookup in table, if failure then geocode. Also add some error
checking around the location and the coords, which was absent before.
Add user's location/coords to location hash.

Same process as with friends; might as well not duplicate effort here,
too, because the user will no doubt share their location with at least
one friend. Now have some repeated code that should be factored
out. Also getting some geocoder errors -- they are silent (return nil
for coords) but I don't quite get what's happening.
Factor out geocoder strategy into seperate method.

The general geocode method is now a wrapper around other geocode
methods, in particular it tries to look up the code in a the hash,
then tries google. Better to factor this thing out because the
strategy is only going to become more complicated.