Linkbait aside there are some reasonable points being made here, specifically "Failover means downtime" about HBase. We run into this pretty much every day in one of our customer facing applications or APIs and it's quite frustrating to have to explain that there's very little you can do to prevent it.
I haven't looked too closely at MapR yet, but "instant recovery, seamless sharding and high availability" are impressive claims. It's still decidedly differently than HBase in my mind given the cost.
Which version of HBase are you running? If we have a node or two go down in our cluster, HBase is completely unaffected. Recoveries can take up to a few minutes, in the old ages it took hours.
I know that MTTR (mean time to recovery) is being worked on together by several large companies to get down to seconds.
Sorry, I should have clarified. When a node goes down, there isn't any sort of "minute" interruption...When there's a full scale outage and you need to perform an actual recovery, that can take minutes.
Also, if you use the Thrift service as an interface to HBase (we do), you can have it running on several machines on the cluster and be able to set them up using a failover architecture - as long as the cluster itself is healthy, Thrift should work from any machine you have it running on.
I believe someone is working on writing up a more detailed post about this, but I'll throw the sanetime library out there. It's pretty slick and even has built in Django support.
I'll echo what skates and iba said -- battlecode was probably one of the most productive things I did in school. when everyone else is trying to teach you how to properly to document your preconditions, battlecode is purely about GSD (get s* done) - an extremely valuable lesson for an aspiring young entrepreneur.
my favorite battlecode hack: we used to assign a fixed "cost" to certain methods, namely Arrays.hashCode(). one of the more experienced players figured out that everyone was using this to checksum their radio broadcasts. he then proceeded to reverse engineer the hash code algorithm and spam teams with enormous messages that had legitimate checksums but were actually just megabytes of trash! the poor opponents would just sit there chewing cpu until the engine finally killed them for using too much heap :)
edit: actually read through cory's post - glad to see he already mentioned this one!
Good stuff! Reimplementing old hardware on an FPGA is a really fun and enlightening exercise that I would highly recommend to any CS people with some extra time and patience. I've been working on an FPGA based GameBoy implementation in my spare time (with no prior FPGA experience) and it's been a blast.
As a software developer I've always had a vague understanding of how computer hardware works, but after building fpgabee I have much deeper understanding. eg 1: I always knew what a VGA controller did, but had know idea how. Now that I've actually built one (albeit in code) it's pretty clear to me now. eg 2: I never really understood why hardware can't be just clocked to higher and higher frequencies... but now I totally get it.
Indeed. I wrote a similar framework in Actionscript / Flex a few years ago, actually with a lot of input from the Scratch team. I've been thinking about porting it to JS recently. Glad to see someone beat me to it :)
Waterbear isn't a language like Scratch, it's a toolkit to create a Scratch-like visual programming interface to any language you like. There is active development on wrappers for Javascript, Java robotics, and Arduino.
Very impressive stuff. For what it's worth, I played around with the new audio reCAPTCHA a bit.
- I heard 50+ distinct words, plus the numbers 1-9
- Numbers are not written out anymore (e.g. "nine" does not work, it must be "9")
- You must get 9 out of 10 words correct to complete the CAPTCHA
So they're still working with a very small dictionary of words, and with a little practice it's not hard to nail these consistently (as a human). The extra noise makes it a little more difficult to split the samples, but that's a solvable problem. I bet they can re-break it with their existing program and not too much additional effort to retrain the system.
