Remove geocoding completely!

[gkop]

Currently we are geocoding venues in our test suite through google's API.

There are several ways to fix this.

We can stub geocoding in test everywhere.

Or maybe we don't need to geocode venues automatically.

[gkop]

I am thinking now we should remove geocoding completely. Yes, sometimes it's convenient - but it's not only slow but also inaccurate, and the inaccuracy causes confusion.

How about instead, we display a modal "Pick your school"?

[btaitelb]

Should we rethink how we're handling different schools, since both SF and Cville are having classes online? It seems like a lot of people (especially in other cities) may be missing out on good learning opportunities by being forced to choose a school. At the same time, the bulk of our students are still physically coming to classes and shouldn't have to deal with spam about classes from another part of the country/world unless they explicitly want them.

[gkop]

Yes, we should allow people to pick and choose which schools they want to subscribe to.

[donaldali]

I think the geocoding is being inaccurate because the value we use with the near method is too high. The distance between SF and Cville is about 2800 miles, but we are passing 5000 miles into near to find a school for a user. As currently set up, the school assigned would be dependent on how schools are sorted (as opposed to which school is closer to a user) because both schools would be within range of anywhere in the continental US. I think a parameter of 1400 miles to the near method would make the geocoder work as expected.

If we do decide to take out geocoding completely, it seems to me that the drop down button in the header would suffice for users to choose their school. If the user is a guest, then we can store that school in a cookie (in addition to the session).

I think, for now, we should try the geocoding with the 1400 miles and if it continues to be unreliable, then there would be no need to keep it.

[gkop]

Sounds good to me. Thanks Donald!

[cdale77]

@donaldali @gabe can we close this?

[btaitelb]

I got a report from Nene that when she pulled up RS on her phone last week, it opened to the cville site. I don't know if this was due to cookies being set from a previous time but I worry there might still be an issue. Can anyone in SF reproduce?

On Jun 9, 2015, at 5:08 PM, Brad Johnson [email protected] wrote:

@donaldali can we close this?

—
Reply to this email directly or view it on GitHub.

[gkop]

I feel like it's working better in SF with Donald's patch. How about out on the east coast, in a clean browser session, does the app show you Cville?

[gkop]

We definitely at least should set a timeout for the geocoding < ~10 seconds, because unicorn times out at 15 seconds.

[btaitelb]

if google doesn't respond within 1 second for geocoding, it's probably an issue, so it'd be better to retry once or twice and then fail fast, rather than waiting for it to time out.

[gkop]

I'm not sure I understand. Right now we're not timing out the google call, google isn't failing it's just taking longer than 15s to respond. So I propose we do timeout the google call.

[btaitelb]

If the google call is really taking longer than 15s to respond, then
something's wrong. This should be a fast lookup, so I'd consider anything
longer than 500ms to be an issue that we should mitigate.

On Thu, Oct 8, 2015 at 5:05 PM, Gabe Kopley [email protected]
wrote:

I'm not sure I understand. Right now we're not timing out the google call,
google isn't failing it's just taking longer than 15s to respond. So I
propose we do timeout the google call.

—
Reply to this email directly or view it on GitHub
#59 (comment).

[gkop]

Sounds good.