Friday will be the 14th anniversary of my first tweet. Umm... it hasn't aged well. The Internet was stunned by the revelation that I was reading my email. Reading email and messing around with Eclipse 3.3M5. — Brian Duff (@brianduff) March 5, 2007 In more contemporary news, this week I joined Twitter as a Principal Engineer in Engineering Effectiveness. I'll try to build things that help engineers inside Twitter have a lovely, productive time creating the cool things that they make every day. Delighting developers is something that I've continued to be passionate about across Oracle, Google, and Facebook. I'm really excited to make the jump from being a long time user of Twitter to being part of the Twitter team. It's pretty cool that I get to continue to work on stuff that I enjoy so much. Onboarding remotely is a... weird... experience, but so far I'm having a whale of a time (geddit? gurgle). I do leave Facebook with a great amount of sadness and
Previously , I introduced a problem I was trying to solve where a large datastructure was being pinned into memory for occasional lookups. This post delves into the implemented solution which pushes it onto disk but retains (relatively) fast lookups. I think using a database or a B-Tree is a good solution to this kind of problem in general, but it was fun and inexpensive to implement this utility, and it turned out to be generally useful. Bear with me if you already understand HashMaps pretty well, because I'm basically describing a HashMap here, but it's a disk-based HashMap. Logically, the data consists of a series of key-value pairs. The keys and values are of variable size, because they contain strings. If we were to write only the values to disk in a binary format, we might have something like this for the JSON example in the previous post : There are two records, at offsets 0x00000000 and 0x000000A4 . If we had some way to map a key to one of these offsets, we could seek