Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Bringing Reason to Zip Code Radius Searches (ageemichael.com)
2 points by jesusmichael on April 13, 2014 | hide | past | favorite | 6 comments


> there were quite a number of unnecessary SQL queries being executed with each http request

Like more than zero?

> seemed extremely inefficient to do the calculations each time a user initiates a search

In general, the radius can vary for each query.

> coders are in love with writing elegant code instead of solving a problem

It seems that way because you're using the wrong tool for the job.

> python script to populate these columns

So, caching?


Tantalor, your post would be much better if you simply gave the solutions you think are better rather than being all smug. For example, what tool is he using that's wrong for the job, and what are examples of the right tool(s)?

Yes, radius varies, but the OP's solution addresses that, so what's your point?

10/10 would be drenched in smugness again.


I apologize for the smugness, I was just a bit irritated. Thanks for pointing that out kindly :)

Michael complained that the query repeated the same computation each time, which is an odd thing to say, because that is its purpose. He expected memoization, which the library function did not offer, so he added that. But there's no reason to be dissatisfied with the code for not doing something its not supposed to do, or its developers for not adding an unnecessary feature.

His memoization does support varying radius, but only in a narrow subset of {5, 10, 20, 30, 40, 50}. Of course this is a huge performance optimization for the app, but in general it is impractical for provide memoization like this for an arbitrary radius.


No the purpose of the function, which is what is returns, is a group of zipcodes within a radius of a give zipcode.

Memorization=tabling which is exactly what I'm doing, but in a static sense.

Yes, its narrow, but the owners of the app don't want more than the 6 options given.

My point is that doing calculating the area of a circle around a give point on earth more than once is redundant. points on the earth don't move so if two points are within 1 mile of each other. They will always be so..


I don't mind... he just doesn't understand...

1. If you can eliminate the http req/query ratio... love to hear it.

2. A radius of 5 miles from a give point never varies...

3. What tool would you use?

4. Caching is not possible for this scenario...


I thought of that... but with 50,000 zips... there wasn't a caching solution that as efficient (memory wise) as pre-computation and layering query caching on top of that.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: