My wife pre-ordered a copy of Harry Potter and the Deathly Hallows a couple of months ago. UPS delivered our copy around 1:30pm yesterday afternoon. I started reading the book at, let’s say, 1:31pm, and continued reading until I was finished at 12:10am. I took two half hour breaks, once for a late lunch, and once for dinner. I can’t recall ever gulping down a 750-is page book quite so eagerly.
The book was good by the way. Really good. And it ended well. That is all I’ll say. Everyone should be able to enjoy discovering all of the bits and pieces of this wonderful story in the order that the author intended.
So much for my two computing professions blog posts though.
I think that the news media and blogosphere are doing an adequate job with iPhone coverage on the device’s first weekend of commercial availability. I doubt that I’m going to add substantially to what’s already been said.
I will say that I’m exceedingly pleased with the iPhone and have only three non-trivial gripes. One is AT&T’s pokey EDGE network. I hope that Apple is getting the message loud and clear that EDGE is unacceptably slow and that they’ll do something about this in the next generation of the device.
My second two gripes are software absences that I hope will get fixed soon. I wish that the iPhone had an RSS reader and a real chat client. For feeds, using Safari and reader.mac.com is better than nothing. But typing in the feed URL of every RSS feed you want to read isn’t great. My quick fix for this problem was a Python hack to convert OPML into an iPhone-ized blogroll. The code is available here. To use it, do the following:
- Use the export OPML feature of your RSS reader to produce an XML file containing your subscriptions. We’ll assume this is called export.xml
- Run ‘python iphone_blogroll.py export.html > blogroll.html’
- Copy blogroll.html to some convenient place on the web reachable by your iPhone
The resulting blogroll should be properly formatted for the iPhone Safari browser and uses reader.mac.com for actual feed reading. My iPhone-ized blogroll is available for those who are curious about how it looks.
[NOTE: you'll need to download and unpack Juri Pakaste's python-opml library before my script will work.]
So. I am going to be one of the true-believers hoping to get a jesus phone this weekend. I had the opportunity to play with one a few weeks back. The thing that I most worried about, usability of the virtual keyboard, was a non-issue for me. One of my other big concerns–battery life / no replaceable battery–doesn’t appear to be that big a deal according to David Pogue and Walt Mossberg.
I’m still not happy about the slower-than-hell EDGE cellular data network, but I’ve been enduring that with a Cingular Blackberry for a couple of years now. It wouldn’t make any sense to elevate that to a deal breaker. The price isn’t a problem. The lifeless shells of more expensive phones clutter up my junk drawer given my futile attempts to date to find a “smart phone” that actually lives up to the name.
I’m very hopeful about the iPhone’s prospects.
Hiring great engineers is perhaps the toughest and most important challenge that any tech startup faces. You want smart, energetic, adaptable people with a broad range of skills and interests, the ability to finish what they start, and who fit into the culture you’re trying to establish or maintain. There’s no foolproof set of techniques for predicting whether or not a candidate will have the right characteristics in the right proportion once hired into your environment. Sometimes it’s hard to tell even after you’ve hired someone and have had a chance to observe their performance for many months!
Many tech startups (justifiably!) focus lots of energy on assessing smartness in the context of basic computer science and engineering. It is widely accepted in tech that job candidates are ‘treated’ to lots of brain teasers and problem solving ‘opportunities’ during interviews. Another mechanism that I’ve noticed recently is the use of programming puzzles as a pre-interview filter. Google tried this in 2004 with the Google Labs Aptitude Tests. Recently I’ve seen some buzz around the programming puzzles that Facebook is using to gather applications.
It’s hard to say how predictive these puzzles are of future success in startup engineers. Regardless, they can be fun and in and of themselves can perhaps attract applications from good people who otherwise wouldn’t apply to your company. I even got sucked into one of the Facebook puzzles, Prime Bits which has a trivial solution whose slowness may at first be hard to see, and at least one fast solution which might not at first be obvious. That, by my estimation, makes this a pretty good puzzle. I will also note that someone at Facebook must have a thing for combinatorial puzzles.
Nerdness, The Tech Biz
First, the Computer Language Benchmarks Game is an interesting approach to resolving the old-as-computers question “which programming language is faster?” Many folks (self included) will tell you that the question is mostly nonsense. But, if you insist on asking it and then answering it with benchmarks, the CLBG is a great way to remove some of the experimental biases that commonly plague that approach.
The second thing, and perhaps even more interesting than the first, is how I came across the CLBG. The link was presented to me as a recommendation from Google search personalization due to some Python-related searches that I had done recently. I was dubious about how effective query-less searches would be. The degree to which this result matches my interests seems to indicate that I should have fewer doubts.