Whatever happened to Benjamin Ragheb?

About a month ago I finally started watching LOST. By the time it sounded like something I’d be into, it seemed like it would be too much work to catch up. Maybe knowing that next season is the final season made it seem like an attainable goal? Maybe I should be more ambitious in my goal-setting?

Anyway, I’ve watched four seasons in thirty days and I kind of want to talk about it. So here we go. I know the show is five years old and probably everything here has been written by someone else, but this is my blog.

» Read the rest of this entry «

I intended FatWatch 1.4.1 to be a minor update, primarily to fix a display issue that appears on iPhone OS 3.0. If you’ve upgraded, you may have noticed that when you switch between Variance and BMI in the Log view, the table rows no longer update immediately; you must scroll to force them to redraw.

I submitted an update to Apple, changing as little else as possible, hoping that it would get through their review process in time for the public release of 3.0. Unfortunately, it was rejected for violating the iPhone Human Interface Guidelines. That’s right: I was nailed for something that they previously approved.

What I got away with

I could bitch about it, but they were right: the objection was to the Wi-Fi Import/Export feature, which in FatWatch 1.4 was enabled by a simple switch.

If you want to import or export a CSV file containing your weight history, all you had to do was turn that switch, and a new row would appear beneath it with an IP address to connect to.

If you didn’t know what to do with all those geeky numbers and slashes, hopefully you would tap on it, because doing so would display an alert explaining that you are supposed to enter that into the address bar of a web browser on your computer.

Even when working properly, this is a spartan interface. I’d honestly be surprised if anybody who doesn’t describe themselves as a “geek” figured it out. What’s worse (and this is where I got into trouble with Apple) is when you turn on Wi-Fi Import/Export and you’re not even connected to a Wi-Fi network. You get a blank row.

So yes, I could say to Apple, but that’s how it worked all along! But that’s like telling the police officer you shouldn’t get a ticket because you run this red light every day and nobody gave you a ticket before.

Making things right

Initially, I tried to fix things by detecting whether a Wi-Fi connection was available and, if not, snapping the switch back to the OFF position and displaying an alert with an error message. While that would have been an improvement, it still felt… terrible.

After sleeping on it (always more productive than hammering away all night, will I ever learn?) I realized that Wi-Fi Import/Export really deserves its own screen, rather than the series of alert views I had allocated it. In practice, you aren’t going to use your iPhone or iPod touch for anything else while you are importing or exporting a file, so there’s no need for it to operate in the “background” of the app.

So in FatWatch 1.4.1, the Wi-Fi Import/Export changes from a switch to a menu item.

When you tap it, you see a screen that explains what Wi-Fi Import/Export does and how to use it. It also tells you that you can use Bonjour, instead of typing in a series of dots and colons and numbers. FatWatch always used Bonjour, but there wasn’t enough space in the old interface to explain it.

FatWatch will now remember the last time you imported or exported a file; very useful if you want to export a file as a backup every so often and you can’t remember when you did it last.

But, most importantly, if you are not connected to a Wi-Fi network, FatWatch now makes it abundantly clear.

As a bonus, now that I have a whole screen for this feature, I was able to get rid of the alerts and do some nice things, like display a progress bar so that you know things are working when you’re importing a large file.

I won’t claim it’s perfect: even now I want to edit some of the text in those screenshots. I held myself to a fairly tight schedule because I didn’t want people to be waiting too long for the bug fixes that was supposed to be the primary focus of this release. However, I am glad Apple challenged me to improve this feature, because it has gone from an embarrassment to something I can feel mildly proud of.

More

A few other improvements that are coming in 1.4.1:

• The Wi-Fi Import/Export web pages are easier on the eyes.
• FatWatch puts today’s date in the exported file name, for example: weight-2009-06-29.csv. Useful if you let those files accumulate in your downloads folder.
• The Go To Date screen displays its buttons in a navigation bar; looks a lot nicer.
• Fixed a bug where BMI values were calculated incorrectly. Basically, if you select your height in feet and inches, FatWatch always added an extra centimeter to your height. That has been fixed.

Everybody cross your fingers, and hopefully it will appear on iTunes soon!

iPhone OS 3.0 update is supposed to be available via iTunes any minute now, which means this post is long overdue.

If you are using FatWatch 1.4 (the latest version at the time of this writing) then you can safely upgrade to iPhone OS 3.0 if you are willing to suffer a cosmetic issue. Specifically, if you have BMI Monitoring enabled and use the control on the top of the Log view to switch between BMI and Variance, the values will not update unless you force them to by either scrolling the table or switching to and back from another view. It’s annoying, but not fatal.

I submitted an update to Apple that fixes this issue (and a few others), hoping it would be available on iTunes before the 3.0 update was released. Unfortunately, Apple rejected the update for a human interface issue concerning a feature that I hadn’t changed. It feels a little unfair to be rejected for something that was previously approved, but “I got away with it before” is not really a defense. They are right, it is something I should fix, it’s just that the timing is obviously less than ideal.

I intend to fix this issue and resubmit today or tomorrow, which means that FatWatch 1.4.1 should hopefully be available sometime next week. Or maybe not. I wish I could say. In the meantime, should you want to install the iPhone OS 3.0 update you can continue to use FatWatch 1.4 and be mildly annoyed at the display issue.

A friend asked me to help fix her computer. It’s a Dell laptop running Windows XP Home and it became infected with a virus. She was able to partially remove the virus, and I helped her remove the rest of it, but now the infamous Blue Screen of Death appears about a minute after booting into anything other than Safe Mode.

It wasn’t obvious what was causing the crashes, but I found out I could use a Microsoft Debugging utility to read the memory dump files that Windows creates on each crash. I offered to take the computer home with me, so I could plug it into a network and install the utility and finish the job.

Booting into “Safe Mode with Networking” worked, so I was able to download the utility, but I was not able to install it. I was told, “The System Administrator has set policies to prevent this installation.” That was confusing, because I logged in using the fucking system administrator account. Now I am pretty sure that the error message is inaccurate, because some lazy asshole at Microsoft decided to use that very specific text as a generic “operation failed” message.

It turns out that the installer program requires the Installer Service to be running, but the Service cannot be started in Safe Mode. So, if I want to use the debugging tools, I am caught in a catch-22: the computer will crash if I don’t use Safe Mode, but I can’t diagnose the crashes if I do use Safe Mode.

After chasing my own tail for longer than I’d like to admit, I realized I could try finding some other tool to extract the utility from the installer package. I found such a tool, and in the process I learned that MSI archives are apparently unable to store file extensions, so when you unpack them, you have to manually insert the dot in hundreds of file names. I do this for a subset of the files that seem necessary to run the diagnostic program, and finally, I get it to run.

At least, I think I do. It outputs a lot of error messages, but the instructions I am following from some sketchy website say it is normal to see a lot of messages, so I have no clue if it’s working or if I need to add more dots to more filenames. I blindly forge ahead, and finally get it to generate a report from one of the memory dump files.

The goal, in case you’ve forgotten, is to find out what is responsible for crashing the kernel. The report indicates the memory location where the crash occurs: Good. It also contains a list of loaded drivers and what memory locations they occupy: Good. So I scan the list to find the culprit. While every other line has a driver name, this one has the name “00001b6f” or something like that. No name, just a hexadecimal number without context. WTF?

So, I give up.

To be clear, I’m not just giving up on this job, but I’m giving up on ever attempting to “fix” a computer running Microsoft Windows ever again. It’s been so long since I used one regularly that I’m no longer familiar with all the voodoo incantations required to make them work. The only thing my technical knowledge buys me is a misleading sense of being “one step closer” when in fact I am running in circles. It is painful and frustrating and humiliating. I honestly feel like I’m the butt of a joke right now. Like I’ve spent four hours trying to catch a pig on a dare.

By taking this computer home, I thought I was doing a favor for a friend, but now I realize that she has done a favor for me. I’ve learned a lesson. I’m sorry, I can’t fix your computer, I don’t know how.