Using Vagrant and Chef to setup a Ruby 1.9 development environment including RVM and Bundler

It has become common practice these days to use tools like RVM and Bundler to manage a project’s dependencies. When these pacakages are in place, getting up to speed with another project is a breeze.

The Pain

But how about installing these tools themselves? How about other dependant pieces of software such as databases and the like? What if they have to be compiled from source? What if they have to be installed with a package manager? Which package manager do you then use: Fink, MacPorts, Homebrew?

Not always so easy!

It’s a UNIX system! I know this!

I love UNIX. I’ve worked in the investment banks, telecoms companies and startups of the world building and supporting software on FreeBSD, Solaris, RHEL, Debian and more. For just over a half decade now I’ve been using a Mac to do this. I was reluctant to begin with and I could care less for the fanbois but I now strongly believe that a Mac running OS X is the best UNIX workstation I can get my hands on.

Despite all I like about it, OS X can be pretty hostile towards developers, just ask anyone who has setup a Ruby dev environment on a fresh install of Lion recently or who uses Xcode regularly.

Enter Vagrant and Chef

Vagrant can be used to provide an isolated environment running inside a virtual machine. When combined with a provisioning tool like Chef it’s possible to concisely specify the necessary environment for an application and then have it available in a dependable manner on a on-demand basis.

This combination is to systems what RVM and Bundler are to Ruby interpreters and libraries.

I’d been hearing good things about Vagrant and Chef for some time but what prompted me to delve deeper was the upcoming addition of a junior dev and an intern at Converser. Having all dependencies scripted, including operating systems, programming languages, document and key/value datastores seemed like a good way to get the new starts up and running with the minimum of time and headaches.

An Example

I have an example of what I’ve learned on GitHub. It’s a simple Sinatra app but demonstrates all the moving parts.

Standalone installers for Vagrant, Chef and Git are to be found here, here and here which removes the need for any form of package manager on the host OS X system.

Once everything’s installed and the repo cloned, the following commands will start up the example app within a fresh virtual machine:

vagrant up
vagrant ssh
cd /vagrant
bundle exec rackup

Browse to http://0.0.0.0:8080 to view the output.

For the curious, the versions or Ruby and Bundler can be checked thus:

$ vagrant up
$ vagrant ssh
$ cd /vagrant
$ ruby -v
ruby 1.9.2p320 (2012-04-20 revision 35421) [x86_64-linux]
$ bundle -v
Bundler version 1.1.4

The virtual machine can be powered down and disposed of with this:

vagrant destroy

Should Things Be This Convoluted?

Perhaps the world would be a better place if all this was simpler. Perhaps returning to a Linux workstation would remove some of these headaches. Maybe I’ve just grown accustomed to the pain.

For the time being OS X appears to have the correct balance of desktop software and UNIX-y stuff for my needs. Until something appears that surpasses the form-factor, power and utility of my current setup I’ll continue to pay the Apple-tax.

A simple app to monitor Google Chrome on OS X

I was on-site with Vigill one day before Christmas and I mentioned to Oisin an idea I had for an app.

I was sick of having endless tabs open in Chrome, hogging memory, each one some seeming important enough at the time that I read it but now just a contextless enigma.

If I at least knew how many tabs I had open, it would be a step in the right direction I thought. There’s got to be an app for that, right? Not that I could see. Opportunity knocks.

Enter AppleScript

I knew that AppleScript would likely give me the functionality I was after so that night in the hotel I installed the Ruby version of the easier to use though now abandoned AppScript and was eventually able to get some details out of a running instance of Chrome concerning it’s open tabs.

Over the Christmas holidays I spent an evening playing with the NSAppleScript class and figuring out how to add an item into the OS X status bar. Huzzah!

Give it a name

Naming things and cache invalidation, 2 notoriously hard things. Inspiration soon struck though and I stumbled upon a catchy name for the app which corresponded to an available dot com domain. I didn’t register it straight away but later in a moment of entusiasm I whipped out a card card and starting piecing together a single page site with Bootstrap to give the app somewhere to live online.

Oisin and myself have been using Bootstrap a lot these last few months as we’ve been building out the Vigill platform and it’s truely a godsend for those of use with the natural tendency to produce apps which look like they’ve been designed by a programmer. I recommended it highly.

The Future

To date the app doesn’t do much, it sits in you status bar, displaying the number of open tabs in Chrome. You can click on the number and choose to quit the app. Fits a need but it’s nothing fancy.

Suggestions have included to show how long the oldest tab has been open, how much memory is being used and even an idea to apply some gamification and have an online leaderboard of tab fetishists.

As with all my personal projects I never know if I’ll ever come back to them after the initial buzz of motivation has passed. In the early days of this blog, nearly 6 years ago now, I was hacking on desktop apps and I can feel myself being drawn back to the world of compilers and executables so chances are good I’ll revisit this app in order to sharpen my skills with Objective-C and Cocoa. Suggestions on a postcard please.

Get It

The app is available to download from chromitor.com and the code is available on GitHub, hopefully you’ll find it useful.

My also-ran Markdown Editor for OS X

Quite often I feel the need to learn something new for the sake of learning something new. Covey aficionados would know this as sharpening the saw.

I usually struggle deciding upon something however as there are so many areas to choose from in the software world and it isn’t everyday I feel drawn enough to something to put time and effort into it on top of holding down a day job.

Five years ago it was Rails, two years ago it was testing that I wanted to improve my skills with and I’m now waiting on whatever will be the next major piece of technology or practice I feel I need to push myself towards.

Before the web

When I started out teaching myself to write code I didn’t have access to the Internet and the web as we know it didn’t exist. My output was to evolve from simple CLI programs to games to desktop apps.

These past years a lot of my work life has involved developing web software with scripting languages. Compilers, graphics routines and assembly language have all started to become lost in the mists of time.

Returning to desktop software development seemed like both an interesting challenge and a break from dealing with the web. As I’ve little interest in cross-platform toolkits this meant Objective-C and Cocoa, technologies which I pick up every once in a while but haven’t produced much with. But what exactly to develop?

Eating my own dog food

In May I was working on-site with a client in Dublin and had to produce some documentation for the analytics platform I was building at the time. As usual I chose Markdown and put up with the workflow of editing the content in Vi and running it through the supplied Perl script to see what the HTML, which was eventually to handed over to the client, looked like.

It struck me that here was repeated effort I could automate with software and there didn’t appear to be a widespread, simple Markdown editor for OS X. An opportunity at last to start work on a first offering from my software company I thought.

The possible beginnings of a product-based business

Over the course of a few months I added a bit of code here and an interface tweak there, mostly while staying in hotel rooms in Dublin. Any time I wanted to edit some Markdown I used the app and it suited my purposes fine.

I toyed with the idea of publishing what I had on the Mac App Store. I shared the binary with a couple of people to see what they made of it and was extremely pleased when one asked if it was ok to pass the app on. I could see a possible path opening before me allowing me to start stepping away from a consultancy business model to one centred on selling products.

Beaten to it

Life moved on though, I started a new contract which gave me a lot of new technology to play with and development of this side project was put on hold.

About a month ago I spotted Mou. Not only was it more complete than my effort but it was better designed than I could hope for considering the limitations on my time and Cocoa experience. “Fair play” I thought, I wasn’t quick or decisive enough and as a result, if I’m to build this planned business it will have to be on the back of a different product.

Today I spotted Marked and a quick search turns up a number of other apps and text-editor plugins. Such is life.

Open source

As of today it’s been over 3 months since the last commit to the repo and many superior alternatives exist so I thought I may as well give it away.

The app suits my needs though it would be even better if it could saving/load files from the local filesystem. I may well tinker with it for my own learning purposes but who knows what side-project my interests will wander to next.

The code is available on Github and compiles with Xcode 4.1. Enjoy.

Back in Mac

I’m writing this on the shiny iMac Matt dropped off the other night. As it stood, I was the only guy in Infurious not on the Mac platform, which is a pretty fundamental prerequisite for working in a Mac shop, don’t you think?

I’m having to get re-used to the keyboard again and the mouse is giving me some difficulty which might just be due to the mouse itself, but all-in-all it’s been a not-unpleasant experience so far!

I’d forgotten how elegant the whole Mac lifestyle is. I’m used to Linux on my desktop and so I’m accustomed to a certain degree of clunkiness and things not always working the way I’d like. Not to mention that I have to use Windows 2000 during the 9 to 5, so it’s been like a breath of fresh air, which makes the contrast even greater.

I do most of my work on Linux boxen via the command line, along with a web browser and a mail client, so at the end of the day I have a similar experience no matter which platform I’m on and through the magic of free software I can use pretty much the same applications which makes things even easier.

Now that I have the hardware, you never know, I might actually become a “Mac Guy” yet!

PHP predefined variables on BSD

I’ve been getting ready for the deployment of wow4kids.com and one of the final features to be into place was restricting access to the administrative back-end.

I enabled admin routing in CakePHP and put all the back-end code into admin_* functions in my controller which are accessible via /admin/controller/action. I wanted to enable some form of access control but without utilising a full user management system which would have been overkill.

The /admin/ directory only exists through some mod_rewrite magic so I couldn’t just use a simple .htaccess file. After much head-scratching and reading of documentation I arrived at a simple solution:

  1. I created a .htaccess protected directory, /adminauth/
  2. in this directory I created an index.php file which redirected to a URL passed to it via HTTP GET
  3. in /app/app_controller.php I defined a beforeFilter() function which uses a regular expression to determine if the called action contained “admin_” in its name
  4. if so, check if the $_SERVER['AUTH_TYPE'] variable is set
  5. redirect to /adminauth/, passing the current URL, if it isn’t set
  6. let mod_auth take care of the rest

This worked a charm on my home Linux box, but when it came to testing the code on the iMac the site is being developed on, the script couldn’t detect the server variable and was thrown into an infinite loop of redirects, doh!

The same result was had when I uploaded the code to the FreeBSD web-host the site will be deployed to, so I had no choice but to rethink my solution.

It was either going to be sessions or cookies and in the moment cookies seemed appealing. I changed the controller to check $_COOKIE[] instead of $_SERVER[] and /adminauth/index.php to call setcookie() . It seems to be working so far, fingers crossed it’ll be suitable for production purposes!

iTerm on OS X

Over the past week and a half I’ve been fine-tuning my Mac experience: getting used to the system in general, in particular the keyboard, and building up my arsenal of applications.

I’m not a Unix wizard, but I do make a lot of use of the command-line so I’m enjoying the underlying BSD-goodness of OS X and multiple terminal sessions are a necessity: one to tunnel select local ports to my home slackware box via ssh, one to perform local operations and one to host a screen session on our development box.

I initially used Terminal.app but running several instances of it proved a bit fiddly: if I avoid cluttering my screen real-estate by minimising my terminals and then try to switch to one it isn’t automatically unminimised. Enter iTerm.

iTerm seems to solve my problem: it allows me to have multiple shells open and accessible via a single, tabbed interface without having to think about the implications of running a screen session within another screen session.

The only real difficulty I’ve had is the behavior of the arrow keys within vim, but after much head-scratching and googling this post came to my rescue: I added export TERM=dtterm into my ~/.profile, executed a quick source ~/.profile to make the changes active and went about my merry way.

A minor niggle is when I create a new tab: it’s background colour doesn’t seem to match up with that I specified in the preferences, but this seems to be fixed by going to View > Show Session Info and turning Transparency on and then off.

All in all, I’m adjusting and next on my agenda might well be looking into Quicksilver and possibly VirtueDesktops. I still haven’t found out how to go to the start or the end of a line in vim without using ^ or $ in normal mode though…

First post from OS X

I’m composing this from the MacBook my new job has has provided me with. Coming from PC-land it’s a culture shock, a very sleek, stylised culture shock, but a culture shock none-the-less.

I’ve got a 2GHz Intel Core Duo processor along with 1.5 GB of RAM at my disposal, so everything is very smooth and shiny but I’m having to adjust to an operating system I’ve never used before so I feel almost crippled when it comes to doing things I don’t normally even have to think about. Oh, and the keyboard just seems wrong.

First thing I did when I got my new toy home was to set up wireless networking: before I put together an IPCop router I was using a Gigabyte GN-B49G and had never used the wireless facility, but I plugged its WAN port into the switch for my “green zone” and went through the router’s setup wizard and bingo! As a finishing touch I configured it to use MAC authentication to prevent any of my lovely neighbours hi-jacking my bandwith ;)

So far there has been nothing that has struck me with “ah, this is what I’ve been missing all along” but I’m looking forward to adding another string to my bow, regardless of the amount of muscle memory I’m having to fight against to do anything via the keyboard. The only negative side I can see to using a Mac is that the experience might be a one-way thing and I’ll never be able to go back to commodity hardware. I’ll always have Linux running on my servers though!