os x

Breathing New Life Into an Old Macbook with an SSD and OS X Yosemite

My Christmas gift to myself this year was to install a new Solid State hard drive (SSD) in my old mid-2009 Macbook Pro. Wow, what a difference! The most honkin’ app I run, Adobe Lightroom, now takes about 5 seconds to load, compared with what felt like an eternity on my old hard drive.

This post outlines what I did to perform this upgrade, which, all in all, was pretty easy. I’m writing it down so it might help others and also so I don’t forget my own steps if anything goes wrong in the future :)

Why I decided to upgrade

My old Macbook has served me well and is in great shape. A new Macbook would be fantastic, but shelling out $200 versus over $2000 is a no brainer. It’s also maxed out on RAM (8GB), and it was running OS X 10.6 Snow Leopard – four major updates behind. So, it was really showing signs of age and I was missing out on some of the newer OS X features.

In addition to doing personal coding on my home machine in Node.js, Java and the odd bit of Ruby, I also use my Macbook for:

  • Using Adobe Lightroom to process photos
  • Using Photoshop Elements to touch up the odd photo
  • Using VMWare Fusion to run a Windows 7 Virtual Machine so I can run Quicken for personal finance
    • Side note, this is sad, isn’t it?

So, I do a few things in there that require some power beyond the piddly stuff.

The Drive

After reading a lot of reviews for Solid State Drives for mac, I chose a Crucial M500 480GB Drive. It had the best combination of good reviews as well as price. I made sure to search the Amazon reviews for it to confirm it worked with my 2009 Macbook pro. (For my model, this was a particularly helpful review).

I had the drive in my Amazon shopping cart for a long time before getting it. I eventually setup a camelcamelcamel.com alert for it and got it about $40 cheaper than it usually is.

What I needed before installation

Besides the hard drive itself, I needed the following

External hard drive enclosure

I wanted to reuse my old hard drive. So, I found enclosure that would let me use it as an external USB drive. I went with a Sabrent enclosure.

This was doubly awesome because I could use this to just pop the old drive in this and convert all my data over using “USB 3.0” (see later on).

One drawback is that it sucks a lot of power (again, see later on).

A thumb drive 8GB or larger

Since I was going to install a new version of OS X on a new hard drive with no recovery partition, I needed to make an OS X installer thumb drive. To do this, I needed a thumb drive 8GB or larger.

Tiny-ass screwdrivers

Finally, I made sure I had my trusty set set of small screwdrivers (pentalobe, etc.) to use for the tiny screws in the macbook and the internal hard drive. Having this little kit around is indispensable if you’re going to do anything with a Macbook, iPhone or iPad.

The steps

Here’s how I did it

Find a bunch of free time

Having a 17-month old baby, I had to wait for a day when I would be able to “tend” to the install. While it’s not a lot of work, it does take a while and needs to be checked in on. Kind of like… A baby? No, that’s not right – a baby IS a lot of work! :)

Create a bootable USB installer

I decided to go straight to the latest OS X and use 10.10 (Yosemite) . To start this out, you have to go to the App Store and download the Yosemite installer. This is a few GB and takes a while to download, so I did that early on.

After you download the installer, I copied the installer out of my Applications folder for safe keeping. Then I followed Apple’s instructions on how to create a USB installer. They’re very good and very easy.

Virtual Machine Prep

I had a feeling that VMWare Fusion might not play well between Snow Leopard and Yosemite, so, I backed up my important stuff from my Windows 7 image and stored it on my Mac drive. In my case, this was really just my Quicken files.


First things first: I backed up all the things! I use two different external hard drives to run my backups for extra redundancy, swapping the drives every couple of backups. So, I ran a time machine backup of my old hard drive on both of them for good measure.

Replace the drive.

For my mid-2009 Macbook pro, page 35 of this manual shows how to replace the drive.

Side note: It is unfortunate that newer Macbooks can’t be modified like this anymore.

Put the old drive in external enclosure

A couple of screws in the Sabrent enclosure and that was it.

It’s worth noting that this enclosure needed to be hooked up to a USB hub that had external power. My old macbook’s USB ports couldn’t power it.

Additionally, I realized that even though the enclosure supported USB 3.0, my old Macbook did not. Slower speeds, oh well!

Format the drive

I plugged in the bootable USB installer into the Macbook, held the Option key, and booted up.

I opened up Disk Utility and choose the new hard drive then formatted it.

Install Yosemite

Exit Disk Utility and then install Yosemite. It took about 45 minutes for mine to complete.

Migrate data

Once Yosemite was installed, I created a new user to test things out, making sure it had a different username than the one I used to use. Then, I opened Migration Assistant to move my data and settings over from the old drive to the fresh Yosemite install. You can also Migration Assistant from time machine backup on my existing external USB hard drive.

Install new XCode

I use Homebrew and after the upgrade, I was having some issues with various utilities. Running brew doctor gave me the hint I needed to upgrade Xcode from the app store. This took about 30 minutes to download and install.

Fix Homebrew

I ran brew update and brew prune along with brew uninstall macvim then brew install macvim --override-system-vim. I was having some issues there.

Deal with the VM

As expected, VMWare Fusion didn’t work across OS X versions. Migration Assistant was very clear about that. I decided to give up on VMware Fusion and just try out using VirtualBox since it’s free.

This article gave a really good overview of how to convert my VM over from VMWare Fusion to VirtualBox.

I also installed the VirtualBox Guest Additions by using the “Devices -> Insert Guest Additions DVD Image” once my VM was up. Then I could share folders, resize the screen, etc.

Time machine backups

One thing I did not anticipate was that I would have issues with my existing Time Machine backups. When I went to run a new Time Machine backup, I was told I didn’t have enough space on my external hard drive.

It seems like Time Machine has not been able to “reconnect” to my old backups and is trying to basically back everything up again and doesn’t know that it should delete older copies of my backups. this article from pondini.org has some good information about how to reconnect backups if this happens.

As of now, I have not been able to solve this issue and may just reformat my external hard drive and start a fresh backup with Yosemite. If I get this fixed, I will update this post.

Update 1/10/2015: I ended up reformatting my backup drive and just started over. Using tmutil inheritbackup and tmutil associatedisk as mentioned in the pondini article and this article by Simon Heimlicher unfortunately didn’t work for me.


That’s it, now it’s like I have a new Macbook!

Getting started with Golang on OS X

I’ve heard a lot of buzz recently about the (relatively) new language Go (aka Golang) created by Google. Notably, that the fantastic Docker was written in it.

I decided to try learning it recently, so thought I’d share my experience getting setup with a development environment on OS X. I’ve been doing a lot of Node.js development recently, and I come from a Java background, so it was a bit of a shift in what I’m used to setting up a development environment.

My intention with this post is not to teach Go fundamentals (see later on in the post for some resources), but rather to help you get your environment setup so you can start writing and running Go code quickly on your Mac.

Finally, at the end, if you’re still reading, I’ll share some of my thoughts about how my experience went and about the language itself.

Getting started using Homebrew

First off, I use Homebrew to install all my developer tools, so I pursued that route to get myself started as opposed to installing from source. I’ll document those steps below and note where they’re Homebrew specific, however, you can also install from the source

First, install Mercurial (using Homebrew)

Go needs this to install lots of common packages.

brew install hg

Second, install Go itself (using homebrew)

brew install go --cross-compile-common

You’ll get some information about exporting some directories to your $PATH variable. More on that below.

The cross-compile-common option will come in handy later if and when you want to try creating executables for OS’es other than OS X. This option will increase your install size, though. So, if you don’t plan on trying cross compilation, don’t worry about adding that flag.

Third, set the right environment variables

Go has a much different directory setup than I’m used to with something like Node.js, where you can simply put a project wherever you want on your filesystem and run a command.

Go expects you define where your main workspace is, and it will then install packages and compile binaries relative to that path. It does this by using an environment variable called $GOPATH.

Additionally, if you don’t install in the “standard” Go install location, you’ll need to tell Go where to find binaries. You can do this by setting the $GOROOT variable. If you installed with Homebrew, see the output it gives you during the install, but the install location is most likely something like this:

export GOROOT=/usr/local/opt/go/libexec

Finally, you’ll want to make sure anything you compile you can execute easily on your path. When you compile, Go will by default put your binary in the root of your Go workspace in the bin/ directory. You can use the $GOPATH variable to reference it.

Also, because the Homebrew output suggested it, I added the $GOROOT/bin location to my $PATH variable for good measure:

export PATH=$PATH:$GOROOT/bin:$GOPATH/bin

(Note that that last part may not be necessary given that Homebrew does a lot of this for you. I was a bit confused by the message Homebrew output during the install. If anybody can clarify, please leave a comment and I will update this post.)

Fourth, try installing the Go Tour as a test

It should be easy:

go get code.google.com/p/go-tour/gotour

This retrieves the source code into your $GOPATH/src directory under the right namespace directory.

Then, once that’s done:
go install code.google.com/p/go-tour/gotour

This will actually compile the code for you in the $GOPATH/bin directory.

Hopefully, at that point, you’ve got no errors. If you don’t, you should be able to simply run the gotour command on the command prompt and it will spin up a webserver which runs the official Go tour on your local developer machine.

Fifth, go forth and learn!

Finally, grab a coffee, and try out some Go code!

I wouldn’t actually recommend learning Go from the “official tour” (see my thoughts at the end of this post). However, it is a good test to make sure your install is running well, which is why I note it above.

In retrospect, I wish I had tried some of the tutorials found on Dave Cheney’s “Resources for new Go Programmers”, at a glance they appear to be much better. When I have more time I will try one of them out.

Also: Here’s a quick and easy command line trick to help speed up your learn / code / test process: Use logical operators to make sure you compile then run your program in a one liner:

go install code.google.com/p/go-tour/gotour && gotour

This will compile and execute your program assuming that the compilation is successful. This is just using the Go tour as an example. Rinse and repeat as needed for your own package and executable while you learn.

Sixth (optional): Try cross-compiling

One of the things I wanted to try out while I was learning was cross-compiling. I wanted to see how easy it was to code on my Mac and then build an executable for some of the Linux (RHEL) servers we have at my organization.

If you used the --cross-compile-common flag in the Homebrew install above, you should have many of the common OS and Architecture combinations that you can compile to.

You can cross compile by running a command like this:

GOOS=linux GOARCH=386 go install code.google.com/p/go-tour/gotour

This will compile the Go tour executable for Linux on a 386 architecture. It will put the binary in $GOPATH/bin/$GOOS_$GOOARCH. Whereas your normal compile without flags simply goes into $GOPATH/bin

You can replace $GOOS and $GOARCH with a valid combination* from the list here (search for “$GOOS and $GOARCH”). And, of course, substitute your own package name for the Go tour :)

(The “valid combinations” may not work unless it is one of the “common” ones that the Homebrew recipe installs for you. You can see which ones are installed in the recipe itself. You can also run the Homebrew install with --cross-compile-all and it will install all options for you, but it will take up a lot of space. This Coderwall article was very helpful in figuring this all out)

Parting thoughts

Finally, if you’re interested, here’s my thoughts on Go itself and my experience learning it.

The good:

  • Go has built in package management system from the get Go (ha, get it!?)
  • You can import packages directly from a Git repository (awesome!)
  • It’s pretty easy to cross compile, which is nice to create simple executables for different environments
  • Concurrency is easy (see “the bad”)

The bad

The official language tour is not very good.

Given that this is the first place people will likely start to learn the language, I thought that this tour did not explain concepts very well, leaving them to short code examples that took too long for me to grasp, given how short they were. Additionally, leaving math exercises to the user is not engaging or effective for me, and I’m assuming the same goes for many developers interested in using Go.

As I mentioned above, try seeing if Dave Cheney’s “Resources for new Go Programmers” has something better for you.

Making concurrent function calls is almost too easy

I was trying to make some HTTP GET requests with goroutines and very quickly learned that I would overwhelm the machine running it and it would fail with a “too many open files” error. Trying to throttle those concurrent requests to a manageable amount was not nearly as easy as creating all of them. The pattern I came across using semaphores seemed a bit convoluted for a language that’s supposed to make concurrency “easy.”

Still need native drivers to connect to Oracle

This is a biggie in the large organization where I work. We use Oracle heavily, and it would be great to have executables that were able to connect to Oracle without native Oracle drivers installed separately. Alas, this is nothing new, however, since in the Node.js and Ruby world, this is the standard as well. It’s not the end of the world, but using Oracle in Java is still a heck of a lot easier.