Coming Up: My First ZendCon

Thanks to a slight relaxation in departmental travel/education funds, I get to go to a conference this fiscal year.  I chose ZendCon, and I’m pretty excited about it.

Unless I find other folks from my institution that are also going, I’ll be “flying solo”…an introvert at a geek conference…should be interesting.

Anyway, I’ll try to resist my nature and make some new connections.  Mostly I’m just excited about the wide range of subjects and the potential to soak in as much of it as possible.  If you’re also headed to ZendCon, drop me a note.

iPhone 4 3G Reception Testing with iOS 4.0.1

I’ve stayed silent on the iPhone 4 antenna “debacle”, and I frankly think that although there is a legitimate issue at the heart, it has been overblown by a media eager to find a chink in Mr. Jobs’ armor.

Before I get too far into this let me just say I’ve become quite the Apple fan over the last three years and even stood in line for 7 hours outside the Apple Store on June 24th to pick up my iPhone 4.

I’ve been able to replicate the “Death Grip” bar loss on purpose, but I’ve yet to have it cost me a call either on accident or when purposefully trying to kill a call with it.

I just downloaded the new iOS 4.0.1 update with its modified signal bar algorhythm and decided to do some of my own testing. Granted this is not controlled testing and it is not terribly randomized, so take this test with a grain of salt, just like all other tests that you read on blogs.  I’m not even terribly confident that Consumer Reports’ testing was done in the proper environment.

Anyway, I have a generally good 3G signal at my house, owing mostly to being in the Nashville metropolitan area.  The test methodology was to conduct 5 tests using Speedtest.net app, take a photo of the 5th test in each phone position/mode, and then average the 5.  The positions/modes tested were: Wifi (a control), 3G-no hands (control), 3G w/2-fingers, 3G casual hold, and 3G Death Grip.  What follows are the results of the testing along with some pics. All speeds are in kbps.

Wifi

Methodology: Home Wifi network, Airport Extreme Base Station, Comcast Cable Modem, phone on desk, no hands.

Test Download Upload
1 3403 3073
2 3407 3196
3 3637 3178
4 3583 3089
5 3560 3129
Average 3518 3133
SDC10567

Wifi Test #5 (Yeah I know the bars have nothing to do with Wifi...)

3G No Hands

Methodology: 3G, phone on desk, no hands. Full 5 Bars.

Test Download Upload
1 890 897
2 1223 955
3 1351 1257
4 1322 1151
5 689 1273
Average 1095 1107
3G test #5, no hands, 5 Bars

3G test #5, no hands, 5 Bars

3G 2-Fingers

Methodology: 3G, phone on desk, Thumb and pointer finger tightly gripping, bridging antenna gaps on either side of phone. 2 Bars.

Test Download Upload
1 789 297
2 591 218
3 951 229
4 1399 203
5 1093 655
Average 963 320
3G 2-finger test #4, 2 bars

3G 2-finger test #4, 2 bars

3G Casual Hold

Methodology: 3G, phone in hand casually (not tight at all), like I’d be dialing or surfing the web. 3 Bars.

Test Download Upload
1 0 127
2 794 277
3 917 265
4 97 206
5 1119 136
Average 585 202
3G Causal Hold test #5, 3 Bars

3G Causal Hold test #5, 3 Bars

3G Death Grip

Methodology: 3G, phone in hand so tight it hurt my hand for a few minutes (see second photo below), like I’m an Apple-hater trying to score points on my blog. 1 Bar.

Test Download Upload
1 11 52
2 0 0
3 5 0
4 0 76
5 2 0
Average 3.6 25.6
3G Death Grip Test #5, 1 Bar

3G Death Grip Test #5, 1 Bar

My hand after 5 tests of the death grip

My hand after 5 tests of the death grip

Conclusions

Let’s just throw out the death grip completely.  Why?  Because I had to hold the phone so tightly it hurt, and no reasonable person is going to hold their phone that tightly to make a call or surf the web or do anything else one does with an iPhone.  Its not a realistic scenario that is likely to occur in the real world.

Having said that, the Casual Hold is entirely valid, and its results were hardly better.  While the average speeds for Casual Hold are way higher than for Death Grip, note the wild inconsistency among the tests in download speeds.  I’m curious to see if this variance continues if one were to conduct a couple dozen tests.  Whatever causes the inconsistency in a casual grip is probably why the problem seems so hard to reproduce for some folks (including me).

I think we can throw out the 2-finger test for the same reason we threw out the Death Grip, no body holds their phone this way. If you did, you’d drop it.  Its a nice way to demonstrate the flaw in a controlled and explicit way, but its not a realistic demonstration of the scenario that causes the problem in actual use.  Having said that, the results are similar to, but more consistent than the Casual Hold.

As for the 3G on the desk with no hands, those results speak for themselves. I won’t bother discussion the Wifi results, they are here just for comparison’s sake and validation of my methodology.

Overall the casual hold represents a 47% drop in download speed and a 72% drop in upload speed. That’s significant enough to notice, but the raw speed is still well above 2G speeds and fast enough one ought to be able to use the phone if in an area with a half-way decent signal to begin with.

I’d also like to note that in both Death Grip and Casual Hold positions I was still able to dial and complete calls.  So one might say looking at data speeds when the issue is call reception is comparing apples to oranges (pun intended). That is a valid criticism.

Clearly the exposed antennas are prone to some attenuation issues. Oddly this seems to only really affect the 3G antenna though.  So yes, its a flaw.  Is it fatal?  I don’t really think so.  And judging by the lack of long return lines at Apple stores and continuing high demand, I don’t think the majority of consumers are all that upset about this.

Are there folks who’s phones are virtually unuseable because of this flaw? Yes, I’m sure there are some, but its hardly approaching even a large minority of iPhone 4 buyers.  Is it a great number as a percent of the whole than had issues with previous models or would have issues with another brand of phone?  Who knows, nobody’s sought fit to actually find any real data, this whole thing seems to be one giant anecdotal evidence party.

The media and Apple-haters (is it hate or just jealousy?) are certainly enjoying the brief exposure of Apple’s soft underbelly. Apple has gone from counter culture chick to mainstream in just a couple of years.  As other articles have noted, though they are still barely 10% of the PC marketshare, they dominate the all important mindshare.  Everybody loves to hate the big kid on the block, be it Microsoft, Wal-Mart, or GM in years past.  Now that Apple is at the top of the heap and making busloads of money, they should get used to taking shots from the media, competitors and even perhaps formerly allied counter culture.

My guess on the press conference tomorrow is that Steve sends everyone who has already bought an iPhone 4 an Apple Store credit for $30 to be used on a bumper, which actually costs just a buck or two to make.  Some who don’t have a reception problem will end up spending the credit on something else, perhaps even a significantly higher priced item.  This remedy actually ends up making Apple more money, much to the chagrin of the Apple haters.  The white iPhones will be announced to have been delayed while a modification (a coating?) is made to the steel band, and future black models will receive the same modification.

Never Use $_GET Again

Matt Butcher’s new blog entry, Never Use $_GET Again, discusses using the filter_input function that is available in php 5.2+ to remedy concerns about input validation.  Its an elegantly simple approach that solves a busload of problems.  This is worth reading and I think is going to not only be worth implementing but also worth retrofitting to your existing applications.

Lifehacker: Teach Yourself to How to Code

Lifehacker continues to move up my list of favorite sites to visit on a daily basis.  They recently ran a list of top how-to guides from 2009, and included among them is Programming 101: Teach Yourself How to Code.
PHP gets plenty of attention in the section about server-side scripting languages, althought I will note they chose to post the cover of a Python book in the paragraph.

Server-side scripting: Once you’re good at making things happen inside a web page, you’re going to need to put some dynamic server action behind it—and for that, you’ll need to move into a server-side scripting language, like PHP, Python, Perl, or Ruby. For example, to make a web-based contact form that sends an email somewhere based on what a user entered, a server-side script is required. Scripting languages like PHP can talk to a database on your web server as well, so if you want to make a site where users can log in and store information, that’s the way to go. Excellent web development site Webmonkey is full of tutorials for various web programming languages. See their PHP Tutorial for Beginners. When you’re ready, check out how to use PHP to talk to a database in WebMonkey’s PHP and MySQL tutorial. PHP’s online documentation and function reference is the best on the web. Each entry (like this one on the strlen function) includes user comments at the bottom which are often as helpful as the documentation itself. (I happen to be partial to PHP, but there are plenty of other server-side scripting languages you might decide to go with instead.)

The author, Gina Trapani, is Lifehacker’s founder and, like me,  is a self-taught programmer:

Good coders are a special breed of persistent problem-solvers who are addicted to the small victories that come along a long path of trial and error. Learning how to program is very rewarding, but it can also be a frustrating and solitary experience. If you can, get a buddy to work with you along the way. Getting really good at programming, like anything else, is a matter of sticking with it, trying things out, and getting experience as you go.

New theme for my blog…

I’ve been paying more attention to web design lately.  Why?  Well I’m definitely not morphing into a designer–I don’t have the DNA for it–but rather because design is relevant, even in an enterprise environment.  As I have mentioned before, the interface matters to the end user–perhaps moreso than all the backend code you’ve spent hours building and that only other coders can truly appreciate.

With that said, I think this blog was getting stale, and although I continue to adore everything Apple, the “Mac” themed blog thing is just a little dated.  After searching WordPress.org, I stumbled upon MacPress, a very clean and modern Web 2.0-ish theme by the folks at Sizlopedia.  I hope you enjoy the cleaner look, which I happen to think is vastly more readable.  I’ll probably tweak here and there in the next few weeks, but I am largely happy with it as-is.

You can download MacPress from WordPress.org or from Sizlopedia.com.

Mac OS X 10.6 Snow Leopard: My upgrade experience

My Snow Leopard disk arrived Friday, and I promptly began upgrading my three Macs (A 2008 Mac Pro and early 2008 MacBook Pro at work, and a 2008 Mac Pro at home).

I’ve read very few horror stories so far about folks and their upgrades.  I had no issues whatsoever.  Install took about 1 hour for each of these three machines.

I likewise had virtually no issues with any of my apps.  Preference pane add-ons iStat Menus and Blueharvest didn’t work.  Fortunately, Blueharvest’s developer already had a new 10.6 compatible version available. Still waiting on something for iStat Menus however, but it is not a big operational loss for me to not know the exact load of my CPUs at any given moment.

hero_osx_2009082810.6 boots by default into 32-bit kernel mode. This is done to maximize compatibility with dozens of apps that haven’t been updated to work in 64-bit mode.  10.6 is great in 32-bit mode, though if you’re like me and cannot use the new Exchange features (We’re in the midst of migrating from Exch 03 to 07 and my account hasn’t been moved yet), you were left Friday a little bit disappointed by just how few visible perks Snow Leopard gives you.

So this morning I booted into 64-bit mode on my Mac Pro at the office (done by holding down “6” and “4” keys during boot, hold “3” and “2” during boot to go back to 32-bit).  All I have to say is “WOW.”  This machines flies now…start up was multiple times faster (or at least seemed..I didn’t time it) than before, and all my login items fired up at least twice as fast as before.

Mac Pro64-bit mode, as you might suspect, produced more software incompatibilities.  My Parallels 4.0 (mission critical for me to run a few Windows apps, as well as IE6 and IE7), would not load a VM.  The problem was a driver incompatible with 64-bit mode.  Big kudos to the folks at Parallels, however, because they released an update over the weekend that resolves the issues.

1Password 2 also encountered issues with 64-bit mode, but a few minutes spend cruizing the Agile Software website got me into the 1Password 3 BETA program and a 64-bit compatible version. Thanks to Brett Terpstra of TUAW for the tip.

Everything else seems to work, and work fantastically well.  I’ve read reports of Office for Mac 2008 not running well in 64-bit mode, but its been fine for me, if not much quicker to load than in 32-bit mode.

Other Apps I’ve tested in 64-bit mode so far:

Netbeans 6.7.1 – works just fine

The Gimp (in X11) – seems to work fine

LittleSnapper – hung on my first try

Panic Transmit – works fine

BlueHarvest Fixes pesky ._DSstore and resource fork files

For those developing on a Mac in an otherwise non-Mac environment (Windows or Linux desktops and/or servers), you’ve undoubtedly run into the dreaded ._DSstore files.  These are resource files OS X creates for directories, and when connecting to a remote file system of another flavor, OS X will leave behind these files and cause you great torment from co-workers as you litter their machines and the servers with these files.  ._DSstore files are hidden by default in OS X, which is why you won’t see them until and unless you access the given directory with another OS.

The simplest fix for this comes from Apple itself.  In this support document, Apple describes a Terminal command designed to turn off writing ._DSstore files to attached network drives.  The command looks like this:

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

We use a virtual Windows Server as our dev environment, and I run Win XP under Parallels on my Mac in order to access some Windows-only software we still use.  I found even with the above terminal command, I was still leaving ._DSstore droppings everywhere I went.
Fortunately I found Blue Harvest, a system-preference pane add-on for OS X 10.4 and 10.5.  The software is $12.95 but it is free to try.  In the words of the developer:

BlueHarvest allows you to keep your disks and servers free of Mac “trails” by:

  • Automatically removing DS_Store files.
  • Automatically removing resource forks (“dot underscore” files).
  • Automatically removing hidden folders such as “.Trashes” from removable disks.
  • Providing simple Control-Click Finder based cleaning of disks, folders and Zip archives.

BlueHarvest is fully customizable (via a System Preferences Panel) and is a Universal binary, supporting Intel and PowerPC based Macs. BlueHarvest 2 requires 10.4.x or 10.5 and later.

Blue Harvest Preference Pane

Blue Harvest Preference Pane

So far I could not be happier with Blue Harvest.  Apple appears serious about making inroads into the enterprise office environment with Snow Leopard’s upcoming native Exchange support.  Though I don’t wish anything bad for the developer of Blue Harvest, one cannot escape the conclusion that such functionality should also be native if Apple really expects wide-spread adoption of Macs into Windows networks in workplaces around the world.