Posted May 23, 2007 by Eric
Today marks the passing of my first Apple certification exam. I’ve gone the Novell and Microsoft routes in the past and witnessed how the tests have evolved. What have I learned?
Back in the day Novell used “adaptive” tests where the more questions you answered correctly the fewer asked. In contrast, if you answered incorrectly the next question was easier and you needed to answer more of them. It was a fine day when I’d walk out with a passing grade from 12 questions.
Eventually people realized that rote memorization of the study guide was enough to pass so Microsoft upped the ante. They changed the question methodology to require first-hand knowledge of the software. Knowing the book inside and out meant nothing to solve the word problems thrown at you. Fortunately, most of Microsoft’s questions were “industry accurate” meaning they weren’t based on “how Microsoft (but no one else) does it.”
Apple has taken the middle-ground. The tests aren’t adaptive and there are no complex word problems. Can you read a study guide from PeachPit Press and pass? No. The study guide didn’t cover some of the questions asked in my exam making memorization pointless. However, a balance of hands-on experience and book-reading should get you a passing grade. Hint: whatever topic you feel weak in, get your hands dirty using it on the Mac before taking the test.
Today’s test was in the Technician track and my direction from here is Pro certification. It’ll be interesting to see how those tests differ.
Posted May 17, 2007 by Eric
In January I designed an icon for one of my favorite (and indispensable) Mac applications: PhatMac.
I offered it to developer Cameron Silver to use as he saw fit and the latest release (0.6.1) on April 22nd rolled it in. With every passing day there is more and more support for the Mac platform but PhatNoise is one of the hold-outs. Without Cameron's hard work I'd have to boot into Windows to sync my music.
Posted May 16, 2007 by Eric
With Apple’s WWDC coming in mid-June the rumormill should start churning out speculation for new product announcements. Apple did spill the beans about the iPhone and Apple TV in January, the Mac Pro was updated last month, the MacBook updated just days ago, Leopard pushed to October, and Final Cut Studio updated in May, so what’s left?
That leaves the MacBook Pro. What’ll be new? Maybe not much but in celebration of the speculation I present to you a gem from the internets. Mister BG, whose site/blog appears to lie dormant, houses one page that holds true today, yesterday, and tomorrow for every Apple fanboy and girl that gets crazy-giddy on what will spring forth from Cupertino.
Enjoy The Apple Product Cycle.
Posted May 15, 2007 by Eric
A long time ago in a galaxy far, far, away there was Macintosh OS 9. In an effort to make file management easy Apple created a filesystem that used two physical files for each user document.
The primary file in the pair was called the “data fork” and contained the actual document contents. The second file was called a “resource fork” which provided metadata for the primary file. Over time Apple would need resource forks less and less but for some reason they still persist in OS X.
If you’ve ever used Terminal to ls -al or copied files to a flash drive and viewed it in Windows you’ll see a hidden file for each visible file. Likewise, those hidden files have the same name preceeded with a period (.). Why the period? Files beginning with a period are automatically hidden in UNIX. Most (if not all?) Mac OS X applications don’t require a resource fork but they appear to be created anyway. Windows will never use the resource fork so they can be safely deleted.
When do resource forks become a PITA? When your Mac is connected to a Windows network share or you’re passing files along via flash drive. Most recently I copied a number of photos to a MiniSD card for use in a digital picture frame. The frame’s minimialistic OS tried to view every resource fork file which meant every other image threw up a “broken” thumbnail. Not ideal.
Now that we know resource forks are inconvenient outside of the Mac world how do we control them? The easiest method, thus far, is using BlueHarvest to automatically delete these files. Once installed, simply enable the deletion of resource forks from non-HFS disks (aka: “not a Mac” disk) and you’re good to go. I haven’t tested BlueHarvest exhaustively but it works as advertised. Using a MiniSD with 250 JPEG files it took BlueHarvest between 10 and 20 seconds to delete the resource forks. In contrast, using rm -Rf .*in Terminal took less than five seconds. Perhaps I didn’t give BlueHarvest a required reboot, login, etc. but I’ll keep it installed and soon forget resource forks ever existed.
For anyone in the know (JJ, this means you) “Blue Harvest” was the codename for Return of the Jedi when it was in production. I’m guessing this little Mac app is paying homage.
