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

Samuel Folkes: 17 PHP Practices That Should Be Banished Forever

stop-150x150Samuel Folkes has posted a great article about bad PHP programming habits.  In his article, titled 17 PHP Practices That Should Be Banned Forever, Folkes describes 17 specific behaviors which can lead to bad code, security holes, or both.

Not all of the 17 items are PHP-specific. Not properly commenting your code is of course a problem in any programming language.  This is also one I am ashamed to say is a problem for me.  Particularly when you are a one-man shop and you don’t have anyone else working in or maintaining your code, commenting doesn’t seem that necessary.  Having said that, I have always commented complex sections of code for my own benefit.  I’ve gotten better at more generalized commenting lately, particularly with writing Doc Block comments in my classes.  However, I would like to think that most of my code–at least the more recent stuff–is well written and logical enough that it is fairly self-explanatory to an experienced developer.

Other notable bad PHP habits include reliance on the ubiquitous Register Globals, failure to sanitize user input, not closing database connections, overuse of error supression, and using functions inside loop declarations.

One habit Folkes describes hit home with me in a very direct way.  He suggests reliance on short PHP tags (<?, <?=) is a no-no, principally because not all hosts have short tags enabled in php.ini, and also that potential conflicts can come up when working with XML, since XML documents begin with <?xml, the PHP parser may try to parse the XML open tag.

These are both valid concerns, particularly so if you are working extensively with XML, and/or if you are developing code to be distributed widely to server environments you have no control over.

I use the <?= tag extensively, since becoming a convert to Brian Lozier’s PHP Templating Class.  Further, I develop in an enterprise environment, on a project which we do not intend to distribute, on a server where we (meaning the institution) do indeed control configuration.

I have developed a small number of XML documents generated from PHP scripts, but to this point my XML open tags have been encapsulated in strings (‘<?xml’) and would therefore never be parsed as PHP to begin with.  Perhaps due to my limited exposure to XML with PHP, I’ve not run into a scenario in which this compatibility problem would arise.

Finally, I’ve read recently on one site that short tags will be deprecated in PHP 6, then on another site I’ve read that <?= is about to make a comeback, since Zend Framework is pushing a Brian Lozier-esque PHP-as-template-engine approach.

We’ll see.  Until I see more obvious handwriting on the wall regarding short tags, I’m sticking to my current approach.  As for the rest of Folkes’ recommendations, they are well worth a read for any newbie or seasoned PHP developer.