Many years ago I took a job as a Database Administrator for a genetics company. On my first day I was given the option of a Linux or Windows box. The entire IT department was running Linux, so I naturally picked that. This was my first exposure to Linux as a day-to-day development environment – prior I’d only used it on the servers, ssh’ing in from my Windows XP machine.

It was nice, especially in a company that was full of Linux developers. My home directory was magically NFS mounted, all of our software “just worked” when I’d log in to another machine, and we could get pretty cheap computers that performed exceptionally well! All the software I had on the server I had locally (vim, psql, etc.) and it was very seamless and awesome.

When it worked, it was just magical. When it didn’t, which was rare, it wasn’t too difficult to work around whatever was going on. I learned the value of a really well-run IT department that had the budget to “do it right” instead of the typical “do it right now”.

The problem was all that infrastructure was pretty expensive to maintain. We had SAN guys who kept the home directories performant. I’d see company-wide emails go out “Please keep your home directories under xxGB!” as folks were publicly shamed for using “too much” shared storage. At the time, automatic updates wasn’t a “thing” so the IT folks would come by periodically and physically swap out machines that had the latest apt-get update run. Woe be the developer that installed anything outside of their home directory!

Anyway, after that I was hooked. Sure, Windows had some sort of “roaming profile” business but it really didn’t work as well as the Linux NFS solution. I made the decision that I was never using Windows again.

Fast forward a bit, and I found myself at an all Mac shop running OS X. I found OS X to be an amazing blend of a better GUI than Windows with the power of Linux (it’s BSD underneath). Wow! Finally, a decent GUI (GNOME was terrible at the time) but with all of my usual GNU/Linux tools! Huzzah! All was well in the land of OS X.

Except for one thing: the .dmg.

Mac Package Deployment

OS X has this peculiar method of deploying software. Instead of an “Installer” like Windows, that litters your environment with configuration, registry, and userland data files, OS X (typically) distributes software without installers as stand-alone .app directories bundled in mountable disks. This is quite an interesting and elegant solution, I think. Except it’s implemented in the worst possible way.

Download most OS X software and you end up with a .dmg file sitting in your downloads. Double-click it and you’re presented with the following:

What am I supposed to do here? There’s no discovery. What if I double click the icon? Oh, it opens the program. That’s how I run it, right? But what about the “Applications” folder there. What am I supposed to do with that? Turns out you’re supposed to DRAG the Skype icon to the Applications folder, thus “Installing” it to your machine.

It’s gotten so bad that some apps, like the most-excellent Cloak, give you instructions:

Provided I follow those instructions, I’ve now installed it to my Applications folder, I guess. Now I want to get rid of the installer, so I delete it and empty the trash:

But, cloak isn’t running? What do I need to do now? Turns out you need to “eject” the dmg. What you’re doing, under the covers, is actually unmounting the virtual disk that OS X helpfully mounted for you when you double-clicked the .dmg.

Only then can you empty your trash.

This makes no sense for the average user.

I guess eventually you can figure that out and memorize these steps except for one thing: OS X, as of Mountain Lion, hides the “Applications” folder. If you install a fresh copy of Mountain Lion you rarely see the “Applications” folder. It’s not on the dock, like “Documents” and “Downloads” are. Why not?

OS X App Store

With Mountain Lion, Apple has introduced the concept of the App Store as the way to install apps to your computer. If your app is downloaded outside of the app store, you’re presented with a scary dialog that doesn’t (easily) let you install the app.

Apple is trying to push OS X developers to distribute through the app store; the .dmg is not long for this world. I doubt we’ll see any design improvements to the .dmg process in further OS X releases. Developers should consider the App Store and, if it fits your business model, target the store first. If you must deliver software via the .dmg, please make it as easy-to-use as possible, like Cloak.

Some time ago I noticed that my iPhone and iPad stopped appearing in iTunes. I didn’t think much of it since my devices still seemed to successfully sync and, since I had converted them to “WiFi Syncing”, I figured it was just a quirk of the wireless sync.

Today I happened to have iTunes open when I plugged in my iPhone for charging and I noticed that the iPhone quickly appeared in the “Devices” list before mysteriously vanishing again. To the internet!

A quick Google search showed quite a few people feeling my pain – the devices sync but don’t appear in iTunes and only reinstalling iTunes would fix it. I dug into my Mac’s system logging and saw various red herrings about being unable to sync via USB but nothing panned out. I tried turning it off and on again but nothing worked.

Defeated I gave up and went back to iTunes to resume IDD (Inception Driven Development) when my mouse cursor errantly floated over the “Devices” column. Actually, not the column itself, but the word “Devices”. And all was clear.

Clicking “Show” revealed my iOS devices.

Wow.

What terrible UX! The iOS devices live in an invisible panel with no visible affordances to indicate that this panel exists. Is this really necessary? Are there iOS fanatics out there with dozens of attached devices that need the extra screen space granted by hiding the list? Even if so why not put those little arrows like you see everywhere else in iOS (and Windows and websites)?

A few weeks ago I wrote a post lamenting the lack of standardized project bootstrapping. Several of the commenters suggested Vagrant, so I have spent the last week or so giving it a try.

Here is what’s awesome about Vagrant:

• Uses Chef or Puppet to add packages to a base VM
• Easily maintain and rebuild VMs
• Pretty straightforward install process on OS X, Linux, and Windows
• Mounts your source project internally so you can work on your code in the VM

Here’s what I don’t like about Vagrant:

• SSH’ing into the VM all the time is a pain
• Creating your own box from scratch is a bit difficult
• Working in a group/team environment is left up to you to figure out

Enter: veewee. Veewee helps you build your own vagrant boxen instead of using predefined boxes that come with Vagrant. If you’re an untrusting person, as well you should be, you kinda want to build your own VM from scratch.

Combined with something like Dropbox or a local server, you can easily set up a group/team environment, build your own boxen, and then distribute them to your teammates.

Once you have your base VirtualBox boxen defined, you can skip straight to running the last step of loading the box into vagrant, of course, so this is really only necessary if you want to define your own boxen.

Here’s how I did it:

1. Download and install VirtualBox
2. Download and install Vagrant
3. Setup Dropbox and put my Ubuntu ISOs in a shared location
4. git clone git@github.com:FundingGates/fg_veewee_scripts.git
5. Run fg_veewee_scripts/setup.sh
6. Follow the instructions to build a box
7. Note, the validation of veewee-validation nfs mount may fail; it appears to be a transient bug in VBox. It doesn’t appear NFS is at fault, so it seems you can safely ignore it.
8. Place the VirtualBox boxen in Dropbox (box box box).
9. Load the boxen into vagrant, run vagrant up in your project (check in a Vagrantfile to all your projects). The end!

I created a little shell script to help share the virtual box definitions within our team. You can see how the shell script works for more information but basically I do two things:

1. Pull down veewee
2. Symlink /definitions and /iso into veewee from shared locations

Now that we’ve got a repeatable, sharable dev/vagrant setup, we can now work on integrating it with all of our projects!