Steve Jobs

There’s been so much written about Steve Jobs that there’s not much to add.  Like millions of others, I remember the first time I ever used an Apple product.  It was to play Number Munchers and Oregon Trail.  My first Macintosh experience was on an LCII in one of the few airconditioned rooms in Taiwan – my elementary school’s computer lab.  While I was too young to appreciate the differences between the (at the time) very outdated Apple II and our fairly outdated IBM compatible XT Turbo, the Macintosh was clearly completely different.  I managed to swing an editor job on our 5th grade newspaper which afforded me almost unlimited time to learn how it worked.  Everything was exciting on that machine, even word processing!

I bought my very first Apple product in college, the 2nd generation iBook with a 500Mhz G3 processor and OS X.  It was a little underpowered, but the hardware design was incredible and I remember being thrilled when I got several OpenGL school projects to run on Windows, Linux, and my new Mac.

To me, Steve Jobs embodies hope.  A college dropout becomes a billionare.  A man with limited technical skills becomes the an incredible driver of technology.  Fired from his company, failing at NEXT, he stakes almost all of his personal fortune and strikes gold with Pixar.  He affects industry after industry, despite many many setbacks along the way.  Sure, he was a jerk, but that’s a hopeful story too – jerks can learn to movitate people and soften when they get older.  Of course, none of these thoughts are based on personal experience, but it’s the perception I get.  Steve’s life to me is a story of hope triumphing over reality.

I’m excited to read his biography, and I’m sad I never got the chance to meet Steve, except through his products, but here’s to a legacy of hope.

Web Development on Mac OS X (Lion)

Others have written about this before,  but I’ll underscore the sentiment that managing a local development environment on OS X where that environment requires Open Source Software is a royal pain.  At the companies I’ve been involved with, we generally eschewed local development environments and instead gave everyone access to a development server that included the requisite databases and web servers and vhost entries.  It worked OK, but there are some significant drawbacks.  Namely, unit testing, environment experimentation, single point of failure if the dev environment goes down, and the needs of a developer to refresh their own copy of a dev database or make other similar changes tend to suffer.As a hobbyist with a simpler environment, or as a developer that’s deploying to Heroku or other cloud platform, local development is the way to go, and here is where Mac OS X makes life difficult.  There are several package management systems out there that tend to step on each others’ toes (and it seems language and framework ecosystems always prefer the one that you’re not using).  Mac OS X also tends to haphazardly ship versions of Python or Ruby or whatever that are a couple of versions behind, then not upgrade them until they do an OS refresh.  That refresh (cough, Lion) will fail to mention it’s upending your world until you try to use your environment that’s always worked.Here’s my solution: just use VirtualBox.  Deploy an Ubuntu or Debian server, link that server to your local development directory and you’re done.  Then use the excellent package management that Linux affords to setup your environment in about ten seconds.  This has another advantage in that you can also use all your deployment hooks (Chef or Puppet) that you’re using on your production servers.Once you’re up and running, here’s how I work: I edit and run git from outside the virtual machine, and run the environment and web browser from within the machine.  Still todo: see if I can use my OS X browser to hit the virtual machine’s private IP so that all my tools are running externally (a little easier for workflow) so the virtual machine is just acting like an external server.Now you have a fully fledged (free, and always available) server, and you can still retain your Mac toolchain when and where you want it without worrying about Apple and OS X pulling the rug out from under you.  Remember: encapsulation of a work environment is just as important as encapsulation of code.

A Few Things I Wish the Apple Appstore Had…

My first app store experience was many years ago, before Apple, before iOS, before any of the other app stores you see today.  It was Redhat’s Redcarpet subscription service which delivered a library of applications (packages) via the internet in an easy to use command line tool.  There was even a GUI if I remember correctly.  Then Debian/Ubuntu came around with their package repositories and it was such a major usability difference between Linux and Apple/Microsoft that it was only a matter of time before it caught on.  Of course, the ideals behind the Linux offerings of ease of use, reliability, and compatibility are supplanted somewhat by the key aims of profitability and control inherent in modern app stores, but who’s counting?Things I wish the Apple App Store had (these are post-Lion upgrade thoughts)

  • Some way to know what the schedule of app update notifications is – it’s unclear to me if this is daily, whether I have to have the appstore application running all the time, etc.
  • The App Store should intelligently close your application when updating an existing application.
  • The App Store should be able to store your credentials, and not require credentials for doing an update if the app is in safe state (e.g. closed).
  • There should be a compatibility layer in Lion that lets you run your iOS apps on your Mac.  I’m sure this is coming, but I wonder when.
  • The App Store should offer to scan your hard drive and find applications that it can manage for you.
  • On the Featured and other pages, you should be able to hide apps you’ve already installed.
  • Somewhere down the line, it might be interesting to have a “lists” feature like Amazon.  Apple could even show what apps certain celebrities use in lists like the inflight magazines do for travel accessories.  Maybe that’s too much on the pointless-marketing side.

I’m sure there are some other options that I’m missing, but overall I’m happy with the experience.  The App Store managed Lion install was incredibly painless, and so much nicer than having to mess with the Apple store, or a nasty CompUSA.

Sluggish Mac OS X Performance Resolved

I’ve been having problems with horrible performance on my Mac desktop.  Constant grinding of the hard driver, non-stop lagging apps.  Turns out MDS (the spotlight process) seemed to be constantly running.  Google brought some suggestions such as completely rebuilding the spotlight index, but this ultimately didn’t work.  Even turning spotlight off seemed to miss the mark.Finally, I made two changes which solved the problem completely:

  • I added /Library/Backblaze to the Spotlight exclusions list.
  • I forced a Time Machine backup, then added that volume to the exclusions list.

That’s it!  A simple fix restored the performance of my machine.  I’m unsure as to why it started happening all of a sudden, but I’ll take it.UpUpdate 2/5/2011: A clue to what might be going on as evidenced by the following command:

  • sudo fs_usage -w -f filesys mdworker

This command shows exactly what Spotlight is doing, and essentially it appears that whenever a file is accessed on the filesystem, Spotlight gives it a look for indexing.  This means when you’re backing up (either via Backblaze or Time Machine) lots of files are getting “touched” and thus need to be examined by Spotlight.  This impacts an already I/O intensive process, bringing the system to a crawl.  Since this post, I’ve had zero performance problems and I’m going to consider this one solved.  Also, on my MacBook Air, Backblaze had already added itself to the exclusions list, so it’s possible that this has been addressed when you do a fresh install of Backblaze nowadays.