607 karma · joined December 17, 2010
A bit nitpicky; it wouldn't be an instant drop, but I'd still look at the rest a bit more cautiously. Oddly enough I only notice a resume's "tools" section when there's something weird in it.
I'm in a relatively spacious ~550sqft 1BR and I don't really know what I'd do with more space than that. However, unlike some of the people interviewed, I do get lots of light and it's in a nice area.
robots.txt also blocks indexing of non-html files.
http://bitcast-a.v1.o1.sjc1.bitgravity.com/seehomenow/yippy-...
A fun pasttime is testing their awful filtering. It seems like they just have a list of blocked words. You can sometimes get the "clouds" box on the left to come up with some racy results. For example, "big booty" returns a link for "Round Asses".
I currently have a Droid Incredible with a $70 plan on Verizon ($75 after bullshit fees) and I felt like a schmuck for paying so much when I saw her phone.
I previously had a prepaid phone on Virgin and it worked fine. Ended up switching carriers just to get a data plan. I think I'll be switching back once my contract is up.
But for you, special price! $10k!
When working on any API, it's often useful to show it to someone who will likely be using it. Getting a second opinion will help you quickly determine where it needs improvement. It's best to do this early on, lest you need to start over.
If you're doing a lot of disk access and you have control over it, try to make your reads/writes as large and sequential as possible. This can make a huge difference if you're disk-bound.
For choosing a worker count in a threaded queue, the number of hardware threads[1] on the system would be reasonable. However, if the workers are doing frequent disk reads/writes it may actually end up being better to reduce the number of workers to reduce thrashing, though in a perfect world the disk firmware would help negate this (is that the case these days?).
I generally just worry about documenting outward facing APIs and any parts of the code that are inherently dense or otherwise require background information. More docs can't hurt, but I've found that things change quickly enough that immaculate docs are often out of date shortly after their completion. On that note, I also like to keep docs as close to the code as possible, so that it's easier to keep them up to date when the code is being changed.
Something I picked up recently that I yet don't do as often as I should is to design each module as though it were an independent library with its own API, to the point that a working application could be written against that API. At the time this mode of thinking sounded extreme, but I've recently been trying it and it's turned out to be quite useful for enforcing module boundaries and allowing easy testing.
[1] boost::thread::hardware_concurrency()
Sure, someone might switch search engines (I have), but now they've got a huge market of third party sites running their ads for them, too.
Serious point though: It's relatively easy to take risks on your income when you're half of a DINK family.
Really, if you're looking at open source, I'd recommend joining an existing project that you find interesting. Nothing prevents you from making a site based on such a project, and they might even like the exposure it gets them.