The main limitation on my iPod use is the small size of the display at 480×320 pixels. It makes reading complex documents hard on the eyes, I doubt that my Mum’s eyesight could cope with the iPod at all, but scale the display up to the iPad — 1024×768 pixels — and the story might be very different. It’s probably no mistake that this resolution matches a long established web design standard size, an indication that the App Store isn’t the only way to get content onto the platform.

Web applications can be docked on the Home screen in the same way as Apps, and open the way to a graphically richer experience even without Flash. It also allows closer integration with proprietary database applications on private networks, I guess they’ll need redesigning to be less dependent upon IE6, but even Microsoft would be in favour of that!

We sometimes lose sight of the fact that this restricted platform isn’t aimed at us geeks. We want to customise everything about our desktop environment, and if that’s you want take a look at Linux. In my opinion it’s flexibility has kept Linux from many desktops. I’ve personally been asked to replace perfectly good Linux installations with Windows because it’s unfamiliar and looks really complicated.

This platform is aimed at the often insignificant majority of people that aren’t like us. They just want a simple to use system that works without any special incantations or sacrificing animals at a full moon. Give them a wide range of applications that are stupidly easy to install and an internet connection that doesn’t need fettling and they’ll be happy, and why not.

On the geeky side, the iPhone OS can’t multi-task and some don’t like the fact. As a seasoned iPod Touch user, I’ve found that the single app life can have advantages, it enforces simplicity and robustness in the platform and the user’s activities.

The fact that I can’t open everything at once means that I focus more closely on the task, or the feed, at hand: we could probably all do with more of that. Neither can I have all the usual junk running in the background like it does on my laptop, reducing a quick machine to a crawl. Truly mobile machines need to conserve power and rarely have the extra resources to waste, opting for a single application environment allows modest processors to run like lightning… apparently.

Whilst listening to the conversation about the iPad on the Dev Show from 5by5 it seems that those in the medical profession won’t like the on-screen keyboard of the iPad. Personally I think the iPhone implementation is very slick, but I wouldn’t want to use it for an essay.

Anyhow it transpires that Doctors generally prefer to dictate notes. This could be a driver for another interesting interface: the ability to dictate into text files, the Mac already has limited voice recognition functionality and I believe the iPad specifications include both a microphone and bluetooth.

Dan Benjamin said that he sees the iPad as a platform for content manipulation not creation, and he’s right. You can’t code software on it, or edit images, or even write a book, but you can consume all of these. I can see myself having an iPad to carry on where my iPod Touch leaves off… but not for a couple of iterations, let them fix the bugs first.

This complete, I pushed the Mac OS X Snow Leopard Family Pack upgrade disc into the drive, and after a quick read, I’d signed away my life to Apple, pressed the install button, and found something else to do for the next hour.

I’d checked that all my key applications were compliant with Snow Leopard before I started, so the mainstream upgrade process was pretty painless: very promising for my chances of surviving my next upgrade.

I also remembered to install Xcode and the developer tools, vital for the next step.

The Pain of the Developer.

The problems started with the developer environment I’ve become accustom to using: PHP and Ruby. I started to wonder whether a clean install might have been a better idea.

I’m happy using the bundled Apache and PHP at the moment; these have been upgraded to versions 2.2.11 and 5.3 respectively, so there’s no major drama until they need to connect to MySQL.

Conversely, I prefer to build the majority of my tools from source in the /usr/local directory: MySQL, Ruby, RubyGems and Git.

Dan Benjamin has a great set of posts to help you do this, but he starts with a clean install, and if you’re upgrading it might not go so smoothly. Here are a few pointers gleaned from the Web and personal experience.

A new MySQL build.

I’ve been using version 5.0.51a for a while and decided to upgrade to 5.1.39 as part of the whole process. The first step was to create a dumpfile of the old database to upload into the new version:

mysqldump --opt -uroot -p --all-databases > currentdatabasedump.sql

In my experience, following Dan’s instructions gives great results, but I install each version into its own directory and symbolic link the one I want to use:

lrwxr-xr-x 1 root wheel 12 28 Oct 16:05 mysql -> mysql-5.1.39 drwxr-xr-x 12 root wheel 408 28 Oct 13:24 mysql-5.0.51a drwxr-xr-x 10 root wheel 340 28 Oct 16:07 mysql-5.1.39

Now to load the old databases into the new management system, so I logged in as root:

mysql -uroot

notice there’s no password yet, and from the mysql command line I loaded the contents of the dumpfile:

source path/to/dumpfile/currentdatabasedump.sql;

Finally, the databases need to be checked for incompatibilities and upgraded:

mysql_upgrade

and the database was acting like the old one, with the expected users and passwords assigned.

Why PHP still can’t use MySQL.

Snow Leopard doesn’t come with a php.ini file, so I copied /etc/php.ini.default to /etc/php.ini, but this file still needed a little modification to work with MySQL.

I changed all the occurrences of /var/mysql/mysql.sock to /tmp/mysql.sock, restarted Apache and my local WordPress installations were back in action, but MediaWiki wasn’t.

At this point the irony of having my troubleshooting notes in the form of a local wiki struck home, fortunately an upgrade to MediaWiki version 1.15.1 solved the problem.

Building Ruby, Rails and Gems.

I based my attempt on Dan’s instructions, and this time I was greeted by a series of make errors from readline.

Rob Seaman sums them up nicely and making the suggested adjustments to config.h allowed me to complete the installation.

I also tried to uninstall readline, but this only resulted in more errors, so pragmatically I upgraded to readline 6.0, and stuck to with the file modifications; must solve this problem one day…

Back to Dan for RubyGems, and installing the MySQL gem, and the first leg of the job was complete.

Rebuilding all the other gems.

Time to upgrade every gem, and gem update won’t do the job, they all need to be reinstalled. I picked up this handy line of Ruby code that can be run in irb from Victor Costan’s blog:

gem list.each_line {|line| system "sudo gem install #{line.split.first}"}

It executes the gem install command for every gem on your existing local list, and it was at this point that I noticed that the arrow keys were behaving strangely in irb.

It turns out that the readline extension isn’t installed along with the rest of Ruby:

cd /usr/local/src/ruby-1.8.7-p174/ext/readline ruby extconf.rb make sudo make install

should fix the problem.

The fly in the ointment.

Everything was going great, but whilst building the Nokogiri gem I ran into more errors. As Roger Neel worked out, I also tracked the problem to MacPorts, and the thing is that I can’t remember why it’s installed in the first place! So I took a risk, cloned first of course, and removed all traces of MacPorts:

sudo port -f uninstall installed

No good, MacPorts was too broken to uninstall itself, so next I took the direct approach:

sudo rm -rf /opt/local \ /Applications/MacPorts \ /Applications/DarwinPorts \ /Library/Tcl/macports1.0 \ /Library/Tcl/darwinports1.0 \ /Library/LaunchDaemons/org.macports.* \ /Library/StartupItems/DarwinPortsStartup \ /Library/Receipts/MacPorts.pkg \ /Library/Receipts/DarwinPorts.pkg \ ~/.macports

Gone, and with it the Nokogiri compilation errors, I can’t help wondering whether I’ll regret this step later… when I figure out why I installed it in the first place.

Building and installing Passenger.

Like all the gems, Passenger needs to be rebuilt using the new gcc compiler bundled with Xcode. My original Passenger configuration file disappeared from the /etc/apache2/other directory during the upgrade, so I made a new one:

-r--r--r-- 1 root wheel 73 18 May 20:44 bonjour.conf -rw-r--r-- 1 root wheel 287 28 Oct 20:06 passenger.conf -r--r--r-- 1 root wheel 194 18 May 20:44 php5.conf

This file contains the configuration instructions given at the end of the Passenger installation invoked by:

passenger-install-apache2-module

And Git.

Followed Dan’s recommendations and there were no problems.

I’ve always edited my online content remotely, I have a local copy and can work off–line. I use TextMate for most of my development work and I’ve been using it for blogging too.

OK… I was reluctant to change. I like having full control over mark–up and haven’t been impressed by a WYSIWYG editor yet, for Web use at least. Untried, I ranked MarsEdit amongst them.

I must apologise to the developers. It’s a great and flexible tool. Hope I’ll be doing a little more blogging!