Comments Off
Comments Off
Comments Off
It was nothing like as dramatic as my iBook dying one evening, but there was no getting around the fact that my nearly five year old MacBook was no longer up to the tasks that I was trying to throw at it. Developing applications, even for resource limited devices such as the iPhone, needs a pretty substantial piece of Mac software called Xcode. My photography pushed me towards getting Aperture to manage all my pictures. It’s great, but it did have a tendency to grind to a halt when it was least convenient.
Anyway, long story short I just got one of the shiny new MacBook Pro’s. I went for the 15″ since I have the iPad for portability and I liked the idea of a quad-core, eight-thread CPU and the discrete graphics card would be a good thing for Aperture. The increased screen resolution, for me, is just gravy.
I was a bit concerned about upgrading from my old machine. In the olden days you could use the Migration Assistant to copy files from your old machine (put the old one in “Target Disk” mode and plug the machines together using FireWire). These days there’s an added complication, in that you can also use a Time Machine backup. Which is the best, quickest option? I didn’t get a great answer from the guys at the Apple Store but in the end I had to use the Time Machine since I don’t have a FireWire 400 – 800 cable.
I picked the default options and I was pleased to see that it was pretty quick; only a couple of hours. It dropped me into a very familiar looking desktop (my old one). Upgrading a Mac can be so much of an anti-climax — everything the same but faster.
Things changed after that. I clicked on Tweetie in my Dock. Nothing. The same with Aperture. Activity Monitor did start, but it just told me that the other two apps were not responding.
I decided to go for the Windows solution and rebooted. Not, it turns out, a good idea. I got the white screen with the Apple logo, a pause and then a black screen. The sleep light came on.
Um, hello?
I think what happened is that it restored a little too much from the Time Machine backup, over-writing some video drivers perhaps. I reinstalled the OS and all was good in software land.
I played around for a while and was very happy with what I found. It really is very much quicker. iTunes actually launches fast enough that I don’t think twice any more. Aperture doesn’t stutter. And the geek in me loves to see a build in Xcode using all eight (virtual) CPUs. I kept Activity Monitor running for a couple of days just so I could see what it was up to. It really is a thing of beauty in hardware terms, too. I’ve poked around with the unibody models in the Apple Store before but even there you don’t get the impression of just how solid they feel.
Eventually the high — maybe it’s the chemicals in the incredibly minimal packaging — started to wear off and I began paying attention to some of the details. Such as, well, take a look at the picture above. There’s a horizontal line of non-operational blue pixels all the way across the screen. One row higher and I probably wouldn’t have noticed and, even now, it’s quite subtle. But now I know it’s there I can’t not see it.
I think this is the first Apple hardware product that hasn’t been perfect out of the box (not including some of their software!) so, while disappointing, I’m confident they’ll replace it and I’ll get a good, fully working model without too much fuss. And if that lasts as long and works as well as my old MacBook, I’ll be very happy.
Comments Off
It’s hard to explain to someone who is not already a programmer the kinds of things that you have to do when building an application. The thing you’re trying to explain is often very abstract and the answer frequently would involve lots of code.
That’s why I thought this particular problem might make an interesting discussion. In talking about this very simple problem we can talk about the things that developers deal with every day and, hopefully, the process can be followed by most people who have used an iPhone (or, actually, any computer). You won’t be a programmer at the end but you might have a greater appreciation for what happens behind the scenes.
The basic problem can be seen in this screen shot.
The login button is a toggle. That is, if I’m currently logged in it says “Log out.” And when I’m not logged in it says “Connect,” which is “log in” in Facebook parlance. A subtlety that you might not ordinarily notice is that when the user clicks the button, the keyboard should move out of the way when it’s not needed and come back again when it is.
There are two basic cases to consider:
Easy, eh? (That’s what I thought when I started, too.)
Let’s sketch out the code.
when the button is pressed
if I'm not logged in then
make the keyboard move out of the way
log in
else
log out
This is called pseudo code because while a computer can’t actually execute it we’ve broken down the processing into the required basic steps. You’ll have to trust me when I say that the real code (called Objective-C) isn’t terribly different.
Not so hard.
Except… you didn’t really think it would be that easy, did you?
It turns out we’re missing one important detail from our algorithm.
One thing we do a lot when programming is use pre-existing components (standing on the shoulders of giants as Isaac Newton, or Oasis, would have it). When you write a component you’re going to come at the problem with some specific ideas of how it’s likely to be used. Hopefully these ideas are the most common ones as this will make everyone else’s life significantly easier.
In this case, our button — a pre-existing component that I didn’t write — is a clever one. It already “knows” how to log in and log out of the service. This sounds like a great time saver and it simplifies our algorithm to just this:
when the button is pressed
if I'm not logged in then
make the keyboard move out of the way
else
do nothing
Only, it turns out that that doesn’t work.
Why not? Well, the implicit assumption in the above pseudo-code is that it is run first, that is, before the instruction to log us into or out of the service. But if the button logs us out before any of my code is run then no matter whether I was logged in or not before I pressed the button, the above code will find that we’re logged out and move the keyboard out of the way.
When you’re writing a user interface you find dozens of these tiny little details getting in the way of what you’re trying to do. Any non-trivial screen will have lots of these little problems, and the worst thing? No-one will ever know. If you do your job well no user will ever see these little glitches.
Talking of which, how do we eliminate the anomaly that we’ve just found? The solution is pretty simple. At the moment we’re trusting that the button “knows” whether we’re logged in or not. Instead, we’re going to have to take responsibility for doing that as well. That adds a little bit of complexity but isn’t too scary:
if the value I saved says that I'm not logged in then
make the keyboard move out of the way
else
change the stored value to "not logged in"
And that’s it, we’re done. We have a working version of the log in button.
The final point I’m going to make here is that I ended up discarding all the code above. It just didn’t work as well as I wanted and I ended up implementing it in a completely different way. And this really is the kind of detail that you never notice. A good chuck of any programming project is prototyping, building mock-ups and other activities that don’t directly end up in any shipping product. All this discarded work — which does, at times feel like a waste of time — is designed to make the product better.
Some people who have never programmed say things like “there’s nothing complicated there” or “it’s only a button!” Hopefully this post has shown that even a simple button can be far more work that it initially seems.
It’s nearly four years old now, so I do expect the odd beach ball occasionally. When my MacBook is doing something hard or complex or just opening iTunes, it often shows its “I’m too busy to respond to you right now” indicator. But this time it was different. The beachball appeared and didn’t really go away again. Sure, it occasionally hid but as soon as I instructed the machine to do anything it would return.
And I do mean anything. From accessing a menu item, to quitting, to switching application, everything resulted in the beachball returning.
I powered off for the night, optimistically hoping that it was transitory, maybe a software failure that a simple reboot would fix.
The picture above and the title of this post probably tells you that it wasn’t.
Fortunately I was pretty well prepared and I lost little more than a few days use of my MacBook and less than £50. My backup regime has changed a little since I last wrote about it so it’s probably worth discussing what I’m doing these days.
Previously I used SuperDuper to clone my main disk. The nice thing about this is that there is a full, bootable copy of my complete Mac. The disadvantage is the small print surrounding the word “complete.”
It’s absolutely complete, but only to the point that the last backup was actually made. Using SuperDuper is fairly quick and easy, but it’s still a manual process that needs to be initiated manually.
Fortunately I realised this before I lost any data. A couple of years ago, shortly after I upgraded to Mac OS X 10.5, I also picked up a Time Capsule. Long story short, a Time Capsule is a wireless router with a built-in disk. And 10.5 has a feature called “Time Machine” that automatically performs hourly, incremental backups.
Since the disk in my MacBook went so suddenly this was brilliant. I would lose a maximum of one hours work with only one proviso: that the backup actually worked.
But skipping straight to actually restoring the backup would be missing a few steps. First I had to replace the broken disk.
CPUs and disks are things that I understand more in theory than in practice. I know that CPUs come in different clock speeds and with varying numbers of cores but if you start to discuss Intel part number I’m going to reply with a blank look of incomprehension. Similarly, I know that disks come in a number of physical and capacity sizes. So when I was looking at the specifications question such as “What’s the difference between SATA and SATA-II?” were asked. I quickly became confused.
Answers were not entirely forthcoming. In the end I took a bit of a punt and bought twice the capacity (320Gb) with a faster rotational speed (7200rpm). Most disks were SATA-II so I crossed my fingers on that. And nowhere did I see a physical size mentioned so there was no way that I could check to see whether it would actually fit in the aperture left by the old, failed disk.
As luck would have it, it all worked out just fine. Replacing the old disk was suspiciously easy, so much so that having switched over I was wondering which steps I had missed or which vital component had dropped on the floor and whose absence would short out the motherboard.
I booted up from the Snow Leopard install disk and told it to restore from the Time Capsule. On first attempt it couldn’t find a disk to install on to. I missed a step. I went back and formatted the new, 320Gb disk.
I let out a big sigh of relief when I realised it could find and format the disk. I guess that meant by confusion over SATA and SATA-II wasn’t going to be a problem.
This time the restore started. It would, the installer said, take about eight hours to complete.
I don’t know exactly how long it took but it was ready the next morning.
I rebooted.
It looked good.
My familiar desktop was there. The backdrop was there, the few documents and folders that I had there before the crash were still there now. The dock showed all my old applications. I poked around my Documents folder.
All good.
Phew.
I clicked on Mail. Slight panic when the setup dialog appeared, and then I realised that Time Machine would not have backed up in the mail index. The messages were all there. It churned away for a while, processing all the messages. It finished. And then it crashed.
I restarted.
It re-crashed.
Okay, let’s Google the error message.
Ah, Safari crashes when launching too.
Everything with an embedded web view crashed either on launch or when the web component was used. Even the Software Update app. Worrying, but not cause for concern yet. Using Firefox, which did still work, I downloaded the 10.6.4 updater from the Apple website and proceeded to install.
In doing so, I learned something new. Did you know that the installer application has an embedded web view?
Luckily the command-line does not scare me — I have a history of voluntarily using Emacs — and I found the appropriate incantation to install the patch the hard way.
It didn’t work. Applications crashed in exactly the same place as before.
In hindsight I probably should have tried installing Safari again but instead I went straight to reinstalling the whole OS from scratch. From past experience I knew that my data was safe. It may have been a brute-force approach, but I was confident that it would work.
And it did.
It took about an hour to do the initial install, then I had to download and install a bunch of updates. Excluding the time it took to copy my data from the Time Capsule to the local disk, it took perhaps three hours to swap out my old disk and get my laptop to pretty much exactly the state it was in when the old disk stopped working.
It’s disappointing that the restore from Time Machine backup option didn’t work in its entirety but, to its credit, I didn’t lose any documents, emails or data. And in that sense it was a complete success.