I tried it out by entering my home and work addresses. Most of the route it came up with matches my regular path, but one spot was horribly wrong.

First, Google wants me to ride along Ogden Avenue, which is suicidal, although this instruction may not be as bad as it seems, since no one would be stupid enough to ride in a busy street when a there’s an asphalt path (that’s the bright green line) that’s not only close by, but actually cuts a corner.

No, the real problem is crossing Ogden at Meadow Lakes Boulevard. During rush hour, cars can barely cross that intersection. There’s no traffic light, and Ogden—the main east-west street in the area—has two through lanes and one turn lane in each direction. And there’s no median, so there’s no way for you to cross halfway when one direction is clear and wait in the middle until the other direction clears. Google’s Street View for the intersection shows cars in every lane, and I can guarantee you the Street View photos weren’t taken at rush hour. Just riding on the bike path parallel to Odgen is a pain at this intersection, because drivers on Meadow Lakes are always pulling forward to block the path.

Weirdly, there are traffic lights a block east and a block west of this intersection. Either would be better than trying to cross here.

Google recognizes that its biking directions may be wrong. Here’s the warning/disclaimer that comes with them:

I filled out the little web form that pops up when you click that link, and I have little doubt that Google’s bicycling directions will improve quickly. Still, I think it’s odd to use the term beta for this product. Losing your data is a risk beta testers are used to. Here, you stand to lose a bit more.

I started reading Roger’s latest blog entry this morning and ran into the same problem I always do when reading him on my iPhone.

The screenshot above is from the MobileRSS feed reader, but I get basically the same horrible formatting when reading it through NetNewsWire

and through the Google Reader mobile page.

Everything past the first couple of paragraphs gets squeezed down to pass through a narrow chute.

Grabbing the feed via

curl http://blogs.suntimes.com/ebert/atom.xml > ebert.rss

and isolating the area where the formatting goes crazy, we get

<p> Todd McCarthy reviewed films for Variety for 31 years.
He was the ideal critic for the paper -- better, we now
realize, than it deserved. His reviews and the reviews of
Kirk Honeycutt at the Hollywood Reporter were frequently the
first reviews of a new film to see print. Honeycutt
fortunately continues. <br /> </p>]]>

<![CDATA[<blockquote><blockquote><blockquote>Films are
traditionally screened for the "trades" before anyone else.
Historically, when independent theater owners around the
world booked their own theaters, they depended on Variety's
advance reviews to plan their bookings. These days theaters
are booked by accountants in Hollywood, often before a film
has been completed. Now that it's "product," it doesn't
matter so much if it's any good or not.

and the problem is clear: it’s the three consecutive <blockquote> tags that lead off the skinny part. Why are they there? The answer comes from looking not at the feed, but at the site itself.

Here’s the main page of Roger’s¹ blog,

and here’s the page for the latest entry

Each entry on main page has an image and a paragraph or two of text. You’ll note that the length of the text matches the height of the image almost exactly, a feat that probably comes easily to a guy who’s been writing newspaper copy for five decades, but which seems amazing to me.

The triple <blockquote> comes right after those lead paragraphs and is what gives the subsequent text its left indentation. And turns that text into a thin trickle running down the center of my iPhone.

(The indentation also appears when I read his feed on my computer, of course, but it’s not as annoying on a full-sized screen.)

I don’t know whether it’s Roger himself that’s putting in those <blockquote>s or whether it’s some blogging program he’s using, but whatever the source, it’s the old problem of using HTML for formatting instead of semantics. I wish one of Roger’s web-savvy friends—Andy Ihnatko, say—would step in and give him a little CSS assistance.

March typically isn’t a great month for riding, and I don’t expect this one to break the mold. Although temperatures this week got up into the 40s, we still have snow on the ground, especially near intersections where the plows piled it up. My usual route to work through the Springbrook Prairie Preserve probably won’t be ready to ride on for a few weeks. Even after the snow melts, its crushed limestone bike path will be impossibly mushy on warm days until we get further into spring. Last year I tried to ride it too early and the glop oozed up over my rims and stopped me cold.

So I’m taking an alternate route to work, one that has me mostly on sidewalks along busy streets. The way is mostly clear, and getting better every day, but there is one low spot of snow that forces me off the bike

and another place under a bridge where, in the morning, the refrozen meltwater is so smooth and slick that I can barely walk across it.

If you’re an urban cyclist and thinking about chastising my for riding on sidewalks, don’t. Suburban riding is not what you’re used to; I can go weeks without passing a pedestrian. Also “sharing the road” is not a concept familiar to drivers out here.

I didn’t plan to start riding quite this soon, so my bike isn’t in the best shape. The frame is still dirty from the wet, messy rides of late November (it was too cold to give it a good washing then), the tires are nearly bald, and the brake pads need replacing. I’ll start fixing it up this weekend.

My replacement tires, by the way, will be the same as what I have on the bike now: Continental Contacts. I’ve ridden about 4000 miles on the current set, over twice what I got out of the tires I had before that.

The commute to work is pretty chilly—this morning’s windchill was in the teens—but the sunny ride home in the late afternoon makes it worthwhile.

US military deaths in the Afghanistan war went up and passed the 1000 mark. I don’t recall seeing anything in the news about this sad milestone.

Strictly speaking, these numbers are for the whole of Operation Enduring Freedom, not just Afghanistan and the neighboring countries. The folks at icasualties.org point out that this includes deaths in (or due to wounds received in) Afghanistan, Pakistan, Uzbekistan, Guantanamo Bay, Djibouti, Eritrea, Ethiopia, Jordan, Kenya, Kyrgyzstan, Philippines, Seychelles, Sudan, Tajikistan, Turkey, and Yemen. I’ll continue to refer to OEF as the Afghanistan war—the war started in response to the attacks of September 11.

I’m increasingly pessimistic about our chances of being out of Afghanistan before September 11, 2011.

In addition to my nerdy calendar interest, there was a family angle. My son plays Modern Warfare online with many of his friends. Last night he told me that a few of them were locked out because they couldn’t get online. It seemed weird that 3-4 kids would have network problems simultaneously, but now we know it wasn’t a coincidence.

Unless there’s a leak out of Sony, we may never learn the precise cause of the bug, but it must have acutely embarrassing for an international electronics giant to have to post this:

We are aware that the internal clock functionality in the PS3 units other than the slim model, recognized the year 2010 as a leap year.

Let’s first note that recognized is the wrong verb; you wouldn’t say you saw Ernest Borgnine in a restaurant and recognized him as Brad Pitt. How about mistook? More to the point: can you imagine spending millions of dollars to develop a product that can’t figure out whether a given year is a leap year or not?

My guess is that the firmware takes every even-numbered year to be a leap year. The PS3 came out in late 2006, too late for the bug to have an affect that year. 2008 was, of course, a real leap year, so the faulty code worked. Yesterday was the first time in the PS3’s product life that the bug would cause a problem.

I’m pretty sure that Sony has no real fix. The solution, like Microsoft’s solution for the Zune’s leap year bug back in 2008,¹ was to simply wait until the calendar flipped again. Now that February 29 March 1 is over in the GMT zone, the bug is safely tucked away. If my guess is right, it won’t resurface until 2014, by which time most “fat” PS3s will be out of service.

I’d put on an old pair of jeans to paint the bathroom, and when I was done I gave them to my wife, who was about to start a load of laundry. I was, of course certain that my iPhone wasn’t in the jeans’ pocket, because I wouldn’t want the phone on me when I’m painting, so I didn’t check the pockets when I handed the jeans over. This is the stupid part of the story.

A couple of minutes later I ran down to the laundry room and opened the door to the washer. As I pawed through the clothes, I saw the phone’s screen glowing through the denim. The jeans had barely gotten wet, but enough moisture had gotten into the dock connector to make the iPhone think it was plugged in. It had put up the warning message that I’d plugged it into an unapproved device.

I shook the phone and blew into the dock port until the warning message went away. I tried to turn it off, but it wouldn’t respond to the power button. The screen told me I had no cell service, so I dug out a paperclip and popped the SIM card from its slot so it could dry. I was hoping the extra opening on the top would help dry out the power button, too.

At first, the phone seemed to be working pretty well. I could flick to change screens, the home button worked, and most of the apps launched without a problem. Buttons near the lower right corner—iPod, Google Reader, and PCalc on my home screen—were iffy; sometimes they responded and sometimes they didn’t. Soon, though, the phone began to run amuck. Apps were launching on their own, mostly those same apps near the lower right corner. The iPod app would not only launch, but begin playing music or videos. I’d hit the home key to stop it, but a few seconds later another app would launch. Basically, it was acting as if someone were tapping randomly on the lower right quadrant of the screen.

I got out a blow drier and ran it around and around the phone to speed evaporation. All the while, I kept pushing the power button, hoping to get the phone to shut down so it wouldn’t damage itself any further. But it wouldn’t go to sleep on its own, because the phantom tapping kept launching apps and keeping the phone awake.

After a reminder via Twitter from @kshanemcfarland, I put the phone in an airtight plastic bag with some rice, a sort of poor man’s desiccator, and left it there until morning. Eventually, it stopped launching apps and went to sleep, but then it started flashing the Apple logo every 15-20 seconds. I was reminded of HAL:

I’m afraid, Dave.

Dave, my mind is going.

I can feel it.

I can feel it.

My mind is going.

The next morning the battery was dead and there was no more flashing. I plugged it in and waited. Several minutes later, it was charged enough to start up. It worked! Every app worked, although the power button was still dead. Not so bad, I thought. If I shorten the autolock time down to one minute, battery life won’t be too bad. I unplugged the phone, put it in my pocket and went off to work.

Unfortunately, this is not the end of the story. When I got to work and pulled out the iPhone to dock it, it was flashing the Apple logo again. Shit. I talked to one of my coworkers about it, and she set me up with a real desiccator that she’d been using on a project a few weeks ago. And that’s where the phone stayed the rest of the day, under a plastic dome, cut off from the rest of the world.

I removed it from the desiccator that evening and plugged it in overnight to give it a full charge. The next morning, its behavior was the same: perfectly fine when plugged in (except for the dead power button), perfectly fine for a little while when unplugged, then back to the flashing logo.

I did a full restore, which took over an hour, but in the end the result was the same: an iPhone that would work only when plugged it—basically unusable. I was resigning myself to a a trip to the Apple Store for a replacement.

Let me interrupt the narrative here and give you some background. This is a first generation iPhone, bought about two years ago. Although it was working well before the incident, I had firm plans to replace it with a more modern model. But I didn’t want to replace it with a 3GS, not, at least, until I saw what the fourth generation iPhone was going to be. My expectation was, and still is, that this summer’s iPhone will blow the 3GS away, probably using the A4 chip that’s in the iPad. My goal was to hang onto my old phone until June or July when the new model arrives. Getting tangled up in a new AT&T contract this close to the launch of a new iPhone was the last thing I wanted.

I did have a safety valve. My daughter has been agitating for an iPhone for months. If worst came to worst, I could get a 3GS now, then give it to her when I got the fourth gen phone.

OK, back to the story:

I felt certain the dead power button was the key to the phone’s failure. Something was in there, screwing up the connection. That, I reasoned, was the cause of both my inability to turn the phone off and the flashing logo (which looked like an interrupted reboot). Since the phone was useless as-is, I decided to crack it open and try to clean out the power button. I had nothing to lose.

I followed the instructions on ifixit.com and soon had a few pieces of iPhone laid out on the table.

The power button is in the upper right corner of the aluminum back piece. I dug around in some crevices there with a thin stainless steel pick. I blew compressed air in and around the area. I swabbed the area with isopropyl alcohol. And when I put the phone back together the power button worked! And so did the rest of the phone—no more flashing logo.

I have no idea which part of the cleaning did the trick, and I don’t care. My iPhone is working again, and if I can baby it through these next few months, I’ll have a new phone in my hands and can put this ugly incident behind me.

I should mention that the phone did not make it through the case cracking unscathed. I left a couple of scratches on the aluminum back. More important, the black plastic antenna cover didn’t snap fully into place when I reassembled the phone. Fortunately, I have an Incase Slider Case that fits tightly around the phone and will keep everything together no matter how much it gets jostled.

So there you have it. Monumental stupidity rescued by perseverance, pluck, a set of instructions posted on the internet, and a heavy dose of blind luck.

News reports will, of course, focus on the devastated areas, but most of the buildings must have done an excellent job of protecting the people within. This is not to say that the buildings weren’t damaged; there’s too much energy in a big quake to expect most buildings to escape unscathed. But I would expect to see most engineered buildings¹ to have absorbed the energy without large-scale collapse.

Oh, there’s still a feed, but it provides only the headlines of Fallows’ posts, nothing more. Not even the first paragraph or two to give a you a decent sense of the post’s topic. I assume the idea behind this change is to force us to go to the main site, pumping up the pageviews for The Atlantic’s advertisers. It won’t work; you can’t force someone to follow a link, and readers who’ve jumped on the RSS train will not be jumping off.

Merlin Mann has written a couple of tart posts today about the stupidity of this change. I’m more disappointed than angry, but the source of our displeasure is the same: we like reading Fallows, and we will read much less of him because of the anemic new feed. I sent this email to Fallows:

Is there some way you can prevail upon the Atlantic’s webmasters (and their masters) to return the RSS feed to providing the full text of your posts? I understand the need to make money and would not complain if the feed included ads. Many of the feeds I subscribe to have ads (Talking Points Memo, for example), and I stay subscribed to them. But I won’t continue to subscribe to a feed that provides only headlines.

I’m sure I’m not alone in this. People who do a lot of reading online have gotten used to using RSS and will not go back to the old way of clicking back and forth between dozens of sites. Especially since much of our blog reading is now done on our smartphones.

I mentioned Talking Points Memo because I know it’s a site Fallows is familiar with. I could just as easily have mentioned Daring Fireball or TidBITS. They’ve all figured out ways to get ads in their feeds, meeting the advertising requirements necessary to keep their businesses going while still providing articles in a form their readers want.

1. Don’t open any sites that play sounds, as these will be recorded on top of the show.
2. Don’t quit Safari when I was done browsing, as that will kill the recording.

Sometimes I’d forget to follow these rules and ruin a hour or more of recording. Whenever this happened, I’d try to fix the problem by swearing at myself, but that never seemed to work.

What has worked is creating a site-specific browser (SSB) for recording. I used Fluid¹ to create an SSB, called BBC iPlayer, that opens a generic BBC page.

BBC iPlayer, then, is the application whose sound output gets hijacked by AHP.

AHP tells BBC iPlayer to navigate away from the generic page to the URL for the stream. Now I can browse in Safari without worrying that something I do will screw up the recording.

Luckily, the various scripts I wrote for getting the streaming URL from the BBC—all collected in this GitHub repository—are browser-agnostic, so they didn’t have to be edited at all. Only the settings in AHP itself needed updating.

I was going to use the current BBC logo as the icon for the BBC iPlayer SSB, but its horizontal layout doesn’t work well as an icon. So I found a screenshot of the old spinning blue globe logo (the one you’d always see during Monty Python’s Flying Circus) on this BBC logo history page and did a bit of editing.

It doesn’t look great at a small size, but it’s instantly recognizable to me.

One more thing: As you can see in the AHP screenshot, one of my upcoming recordings is of an episode of Radio 2’s semi-regular show, The Record Producers. The subject of this Saturday’s show will be Todd Rundgren. Obviously, I have no idea if the show will be any good (personally, I’m hoping they don’t spend too much time on Bat Out of Hell), but Todd fans will probably want to listen regardless.

So I went ahead and did the vCard export, and typed up this simple Python filter:

 1:  #!/usr/bin/python
 2:  
 3:  contacts = open('/Users/drang/Desktop/contacts.vcf')
 4:  
 5:  for line in contacts:
 6:    if line[:3] == 'FN:':
 7:      print line[3:],
 8:    if line[:6] == 'EMAIL;':
 9:      colon = line.find(':')
10:      print line[colon+1:]

The name and path to the vCard file is in Line 3. I had the vCard file open in TextMate as I wrote the script. The lines with the important data looked like this:

FN:Ms. Laura Ipsum
EMAIL;type=INTERNET;type=HOME;type=pref:lipsum@gmail.com

Lines 5-10 were written with this format in mind. The output was a list of names and addresses

Ms. Laura Ipsum
lipsum@gmail.com

Ms. Dolores Amet
dolores@ametfamily.com

Ms. Elizabeth Consectetur
liz1729@aol.com

which I copied into a email to my wife. Five minutes of effort, maybe, with some interruptions.

I’m sure the script won’t handle every situation, but that’s OK. It was easy to write and it got me what I wanted quickly. I didn’t even save the script. I ran it within TextMate, using the Run Script command (⌘R) in the Python bundle. When I was done, I kept the script in an open window until I wrote this blog post around it.