So I ran into the Apple store in San Francisco and grabbed a new 60 watt adapter – the one with the “L” style MagSafe connector, versus the older “T” style connectors I’ve got on my other three adapters.

Raced back to the client. Plugged it in – and it didn’t work. Spent 20 minutes cleaning my connector, trying different outlets, etc. No luck.

Headed back to the Apple store, and verified the following:

• My new adapter works with three different MacBooks on display.
• None of the 60 watt power adapters with “L” style connectors being used for display Macs worked with my MacBook, but all of the 60 watt adapters with older “T” style connectors did work.
• The 85 watt power adapter at the Genius Bar did work with my MacBook.
• The new 85 watt power adapter that Mitch @ the Bar set me up with didn’t work with my MacBook.
• The older 60 watt power adapter Mitch extracted from the store’s repair supply stock did work.

After all of the above, I got in touch with a friend who works as a Genius at the Manhattan store. Turns out she’d just had to deal with a similar issue, and the root of the problem is that the System Management Controller (SMC) needs to be reset for some older MacBooks to work properly with new power adapters.

Apple has information about how to reset the SMC, and on that page it lists one of the reasons why you need to do this as “The battery does not appear to be charging properly”.

I’m hoping Apple updates the info found on both this page and their Troubleshooting MagSafe adapters page, to make it easier to find in the future for other users. Before Apple Stores run out of these older “T” style power adapters.

Previously I’d had a Sierra Wireless AirCard (595U) with Sprint, and it worked great, but I couldn’t justify $60/month for the occasionally trip to the Bay area.

But Virgin Mobile with its pay-as-you-go plan seems perfect. I can spend $10 for a 10-day plan with enough data (100MB) for my email and light web surfing needs. So I bought the modem, and went to sign up. Which brought me to this page on their web site:

This is the error screen you get when you don’t fill in the address fields. Which aren’t marked as being required.

But after using their Broadband2Go app, I can see that having a polished UI experience isn’t high on their priority list. I’m just hoping the Sprint-provided service works as well as with my old WiMax setup.

Previously I’d had a directory in my user directory called “SVN”, and this is where I’d checked out all of my SVN-hosted projects. At some point in the past I changed the name of this directory to be “svn”.

In the terminal, it shows the directory as having the lower-case name, as expected.

But in Java, if I call File.getCanonicalPath() on a file in this directory, the directory name comes back as the old “SVN”. And that in turn caused some tests to make assumptions about the nature of the filesystem, which triggered a cascade of failures.

To fix it, I created a new temp directory, moved everything from inside “svn” over, deleted “svn”, then created a new “svn” and moved everything back. Really strange…

Just pull first, fix any merge problems, and then push.

But this morning I still got the error after doing a pull, then a push to the Bixo project on GitHub.
It turns out I need to read the git output more closely. The error message said:

! [rejected]        master -> master (non-fast forward)
error: failed to push some refs to 'git@github.com:bixo/bixo.git'

But I’m working in a branch (called ‘fetch-flow’). And the “git push” command will try to push all of the branches. But “git pull” only pulls the current branch.

So I had to “git checkout master” to switch to the master branch, then “git pull” to bring that up to date, then “git checkout fetch-flow” to switch back to my branch.

And now my git push works fine.

There seems to be some new information required, where they want the secret question/answer pair that now seems to be part of every company’s registration system. But after my login I got this interesting message:

Looks like a case of the right hand and the left hand not being in sync.

The section on this vehicle from the article I linked to above says it all…

Winning first prize in the “You’ve got to be kidding me!” category was TH Auto­mobile’s TH2 RS. What’s wacky about it? Well, what started life as a pedestrian Volkswagen T5 van has been made into The World’s Fastest Brick.

First, TH Automobile swapped the engine from the front to the rear. But instead of a VW unit, TH dropped in a Porsche twin-turbo flat-6 breathed on by 9ff to produce 800 bhp. The rear axle and 6-speed manual transmission come straight from Porsche, as do the brakes.

The interior was also completely remodeled, the driver’s position switched to a central location, along with four carbon-fiber racing buckets for passengers. To handle the TH2 RS’s aero-defying speed of 193.1 mph (breaking the previous van record of 169.6 mph, set by a Claer-tuned T4 VW van), H&R provided an air suspension system that adjusts the ride height among three different levels depending on speed. TH claims the van can hit 62 mph in just 4.5 sec. A customer version would cost somewhere north of $225,000.

At almost 200MPH, that would get us to the South Rim in about, let’s see, 4 hours. Though we’d have to remove all of the camping accessories, move the engine from the front to the back, pay $225K, etc., etc., etc. But the look on driver’s faces as we sucked their doors off might make it all worth while.

But one day, while Jenna and I were speculating about what kind of sighthound would give him his deep chest and curled tail, I did a search on “greyhound labrador mix”, and found out that we’d been wrong all these years.

He’s not a mutt, he’s a lurcher!

What’s a lurcher? Well, according to Wikipedia (source of all truth and goodness) a lurcher is:

a hardy, crossbred sighthound, generally a cross between a sighthound and any other breed…the lurcher was bred in Ireland and Great Britain by the Irish Gypsies and travellers in the 17th century. They were used for poaching rabbits, hares and other small creatures. The name lurcher is derived from the Romani language word lur, which means thief.

There’s even a new group called the North American Lurcher & Longdog Association. It’s a bit hard to tell, but I think Emmett is very excited about the possibility of membership.

So in the process, I’ve found a few irritations that could easily be fixed:

1. Display the list of apps in two groups – at the top, the apps that aren’t responding (usually just one). So then I never see the list displayed without the offending app clearly at the top. When you’re running a lot of apps, the list often winds up being displayed such that the hung app isn’t visible.
2. When I force-quit a non-responding app, don’t ask for confirmation. It’s not responding, that’s why I’m explicitly asking you to make it go away.
3. And in the same vein, when I’ve force quit a non-responding app, don’t display a scary dialog telling me that an app unexpectedly quit, and whether I want to report the problem to Apple.

If you have a WordPress.com-hosted blog (like this one), and you use categories, then the RSS feed is:

http://<domain>/category/<category name>/feed/

For example, the RSS feed for things I’ve categorized as being about “Nevada City” is http://ken-blog.krugler.org/category/nevada-city/feed/

In one of his emails, he said:

However, what I’ve learned is that whenever you’re working with web-scale collections, it exposes bugs in otherwise seemingly solid code.  Sometimes it’s not bugs, but rather obscure corner cases that don’t happen for the most part.  Screwy data is inevitable…

I borrowed his “screwy data is inevitable” line for the talk I gave at December’s ACM data mining SIG event, and added a comment about this being the reason for having to write super-defensive code when implementing anything that touched the web.

Later that same week, I was debugging a weird problem with my Elastic MapReduce web crawling job for the Public Terabyte Datset project. At some point during one of the steps, I was getting LeaseExpiredExceptions in the logs, and the job was failing. I posted details to the Hadoop list, and got one response from Jason Venner about a similar problem he’d run into.

Is it possible that this is occurring in a task that is being killed by the framework. Sometimes there is a little lag, between the time the tracker ‘kills a task’ and the task fully dies, you could be getting into a situation like that where the task is in the process of dying but the last write is still in progress.
I see this situation happen when the task tracker machine is heavily loaded. In once case there was a 15 minute lag between the timestamp in the tracker for killing task XYZ, and the task actually going away.

It took me a while to work this out as I had to merge the tracker and task logs by time to actually see the pattern. The host machines where under very heavy io pressure, and may have been paging also. The code and configuration issues that triggered this have been resolved, so I don’t see it anymore.

This led me down the path of increasing the size of my master instance (I was incorrectly using m1.small with a 50 server cluster), increasing the number of tasktracker.http.threads from 20 to 100, etc. All good things, but nothing that fixed the problem.

However Jason’s email about merging multiple logs by timestamp value led me to go through all of the logs in more detail. And this led me to the realization that the job previous to where I was seeing a LeaseExpiredException had actually died quite suddenly. I then checked the local logs I wrote out, and I saw that this was right after a statement about parsing an “unusual” file from stanford.edu: http://library.stanford.edu/depts/ssrg/polisci/NGO_files/oledata.mso

The server returns “text/plain” for this file, when in fact it’s a Microsoft Office document. I filter out everything that’s not plain text or HTML, which lets me exclude a bunch of huge Microsoft-specific parse support jars from my Hadoop job jar. When you’re repeatedly pushing jars to S3 via a thin DSL connection, saving 20MB is significant.

But since the server lies like a rug in this case, I pass it on through to the Tika AutoDectectParser. And that in turn correctly figures out that it’s a Microsoft Office document, and makes a call to a non-existing method. Which throws a NoSuchMethodError (not an Exception!). Since it’s an Error, this flies right on by all of the exception catch blocks, and kills the job.

Looks like I need to get better at following my own advice – a bit of defensive programming would have saved me endless hours of debugging and config-thrashing.