Interviewer: What are your strengths?
Me: Cache Invalidation and Naming Things.
We paused and looked at each other for a minute and then we burst out laughing.
584 karma · joined May 26, 2011
We paused and looked at each other for a minute and then we burst out laughing.
if (conditionA && conditionB && !conditionC) cache_it()
to
hey look, an item with featureset X is cacheable while one with featureset Y is not.
This reflects in the API which is just two calls predict() and feedback()
this simplifies the integration code and is easily debuggable even in the face of changes.
With Spiral, we were able to approach this top down as a classification problem.
e.g.
If you have a cached query for "Friends that liked my post", the Spiral classifier quickly learns that "Post Last Viewed At" or "Post Last Modified At" is not relevant to this via the feedback from the caching code.
Pre-spiral, this was expressed via a curated blacklist/whitelist which had to be recreated if the query characteristics changed.
He is a big dinosaur buff and wants to be a paleontologist when he grows up. His project brief was "Build a pokedex... but for dinosaurs"
Still kind of a WIP (Search is very basic and Text to speech / Listen feature may not work on iPhones, works on iPad/Nexus and Desktop using Chrome and Safari) and very much a weekend hack.
Built using python, tornado, wikipedia data and the skeleton html5 boilerplate. Uses ResponsiveSpeech for text to speech.
Enjoy! (and do send in your comments and suggestions)
with the std::list, everytime I refreshed a node... i did a copy.
basically to the tune of list.push_back(*iter) where as I wanted to keep it as a simple unlink and relink of the node
copy of the comment: https://news.ycombinator.com/item?id=12391069
https://gist.github.com/Quinny/09e34afb1d187e43dea2f3c3b0c04...
the key refresh in std::list required a copy of the std::pair, where as I wished to keep it as an unlink / relink
cache.remove(const Key& k, F deleteCallback) method.
Thanks for the feedback
the TL;DR is that it is written the way it is to achieve constant time remove/remove_and_add_to_end operations which is not an erase+append but more like an unlink/relink operation.
The reason for the specific implementation is to get constant time removal and remove-add_to_end operations. Truth be told, it is a hold-over from the previous implementation. I shall be writing benchmarks for this next up and shall revisit the decision on whether or not to use std::list soon-ish :)
The : private NoCopy is just to block the copy constructors.
Also, keep in mind that most of the library is templates, which need to go in the header files.
BTW, most of boost is header-only :) e.g. boost/noncopyable.hpp would give you a header only equivalent of the NoCopy class I wrote.
I've always felt weird about having to include some big-arse library for just using a simple container, so for things like this I prefer to write header-only versions.
e.g. if I had Hello.h and Hello.cpp, you'd need to either add Hello.cpp to your make/build or build a library and link to it.
Header-only version means all you do is
#include "Hello.h"
and you're all set to go.
shameless plugs for two similar projects(open sourced both) I did a while back 1) Algorithmic Summarizer: https://github.com/mohaps/tldrzr 2) Readability Clone / Article Body Extractor with summary, significant image and text : https://github.com/mohaps/xtractor
Both are deployed on heroku and the urls are in the github readme files.
kinda like cordova/phonegap for desktop
I know my dad would fall for that.
Searching for a generic/theoretically all-encompassing solution is quite akin to looking for the perfect pub-sub system for all workloads. :)
My comment was related to lat/lon indexed data clustered around cities. If you know beforehand that you're going to deal with such a dataset (static or dynamic), one can pragmatically decide on some sort of by-convention partitioning (e.g. Partitioning by continent/region which will bring it down to in-memory indices not needing continuous disk access).
I love the non-euclidean bit in the piece you wrote. Anyone who has tried to do a k-nearest neighbor query east of New Zealand will appreciate that bit. :D
As someone who has spent the last 15 years basically trying to plumb bandwidth aware/adaptive chatty AND bulk-data-transfer applications, I always look at the RFC's and see a ton of good ideas.
No fan of XML... but that's a personal bias.
Have fun, be good, enjoy! :)