Blender is a Thrift and HTTP service built on Netty, a highly-scalable NIO client server library written in Java that enables the development of a variety of protocol servers and clients quickly and easily. We chose Netty over some of its other competitors, like Mina and Jetty, because it has a cleaner API, better documentation and, more importantly, because several other projects at Twitter are using this framework. To make Netty work with Thrift, we wrote a simple Thrift codec that decodes the incoming Thrift request from Netty’s channel buffer, when it is read from the socket and encodes the outgoing Thrift response, when it is written to the socket.
Here are six random ideas that will help you fail better, more often and with an inevitably positive upside:
Whenever possible, take on specific projects.
Make detailed promises about what success looks like and when it will occur.
Engage others in your projects. If you fail, they should be involved and know that they will fail with you.
Be really clear about what the true risks are. Ignore the vivid, unlikely and ultimately non-fatal risks that take so much of our focus away.
Concentrate your energy and will on the elements of the project that you have influence on, ignore external events that you can't avoid or change.
When you fail (and you will) be clear about it, call it by name and outline specifically what you learned so you won't make the same mistake twice. People who blame others for failure will never be good at failing, because they've never done it.
We started a project at Facebook a little over a year ago with a pretty big goal: to build one of the most efficient computing infrastructures at the lowest possible cost.
We decided to honor our hacker roots and challenge convention by custom designing and building our software, servers and data centers from the ground up.
The result is a data center full of vanity free servers which is 38% more efficient and 24% less expensive to build and run than other state-of-the-art data centers1.
But we didn't want to keep it all for ourselves. Instead, we decided to collaborate with the entire industry and create the Open Compute Project, to share these technologies as they evolve.
For years, we've known that ConcurrentHashMaps have initial
footprints (over 1000 bytes using default constructor) that
are too big for casual use. And that the best way to address
this would be to use the Fences API to emulate "final field"
memory model guarantees in the presence of lazy initialization.
But we aren't releasing the Fences API. So I committed a version
that instead uses Unsafe calls to essentially the same effect
(reducing initial footprint to around 100 bytes, plus a few
percent savings for large populated tables). Also, this
version includes throughput improvements under contention
(mainly by interleaving locking with probes, to absorb cache misses),
which can double performance on big tables with many threads.
While conceptually straightforward, these lead to many
My girlfriend moved house, and her Airport Express no longer made it with her wireless access point. I figured it'd be easy to find an ApEx emulator – there are several open source apps out there to play to them. However, I was disappointed to find that Apple used a public-key crypto scheme, and there's a private key hiding inside the ApEx. So I took it apart (I still have scars from opening the glued case!), dumped the ROM, and reverse engineered the keys out of it.
links for 2011-04-13