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.

An iOS client for my Coffee Tracker API

About 9 hours ago I dandered down the road to see what was happening at the FlackNite event being hosted in Farset Labs.

When I finally got myself settled down with network access and a cup of coffee and said hello to everyone it seemed I was the only one without a project to work on. Nightmare.

Decisions, Decisions

I couldn’t think of what to focus on but Rob and Pete were sitting next to me and tinkering with some Objective-C and Cocoa. Considering that I’m now on the iOS developer program, doing something similar seemed like a good idea.

I needed to pick something that could be accomplished within a relatively short period of time and I’ve had a few small projects which I’ve wanted to get out of the way for a while but most of them would have required some research effort to take me into unchartered territory.

This constraint left me with a single task: the relatively straight-forward job of porting the OS X client of my Coffee Tracker API to iOS.

Double Jalapenos

Coffee was drank, pizza was eaten, many laughs were had and some Objective-C was cranked out.

Beyond creating a new iOS project and user interface, the existing code didn’t require much change. Turning off ARC for AFNetworking was the most involved thing I had to do.

After the basic port I added a few finer details like turning on the network activity indicator when the web service was being accessed and making sure the count was refreshed whenever the app became active. Simple.

Dive In

It was good again to sit down with a specific task, open Xcode and eventually come to a solution. Maybe some day I’ll produce something more involved but I’m pleased with how things are progressing.

Full source code is available on GitHub so fill your boots.

An introduction to Sinatra

Tonight I gave an introductory talk about Sinatra at the second meetup of BelfastRuby.

The Converser platform I’ve been building this last while uses a lot of Sinatra so when I was asked to give a talk about using Ruby to develop web apps without Rails it wasn’t hard to think of a subject.

This was my first technical talk and apart from a touch of nerves and forgetting some of the jokes I had in mind I think things went well. Maybe I’ll end up giving another one before too long :)

The slides are available at belfast-ruby-sinatra.herokuapp.com and make use of showoff which itself uses Sinatra. Meta.

The source, including the code samples, is on GitHub.

Update: some photos from the evening are now available on Flickr.

Tracking my coffee consumption with Redis, Sinatra and Cocoa

I’ve often joked about putting together an app to track my coffee consumption, such is my reputation for consuming the black goodness. Like a lot of my other personal projects, the idea had a prolonged gestation period and was finally born through a welcome spark of motivation.

Crafting fine web APIs

Over the past 6 months the bulk of what I’ve been doing day to day with Vigill has involved building web APIs for consumption by mobile clients. This has involved lots of Sinatra, Redis and MongoDB.

In this time I’ve also put together a couple more Cocoa apps.

Thick client boogie

An unexpected resurgance in enthusiam for developing desktop apps combined with a fluency in cranking out webservices put me in a good position to put together a simple API and client.

I’m not a big user of mobile apps but I do spend the bulk of my waking hours sitting in front of a Mac so producing a client for OS X was the logical choice.

For the API I considered using something a bit more esoteric than my standard toolkit, but no matter what combination of technologies I investigated not much seems to come close to the power and flexibilty I find with Ruby and it’s frameworks for performing the bulk of tasks required by the web applications of today.

Areas of note

A valid API key must be sent in the request headers when sending a POST to the Sinatra app. Validity of the key is determined by checking set membership in Redis. A 4xx status code is returned if the key is missing or invalid.

The daily count is boosted with an atomic increment of a hash field.

The client is not much more than a GUI wrapper around some HTTP requests sent using AFNetworking. A previous native iOS client I developed used NSURLRequest directly and I found AFNetworking much simpler to use.

Get the code

The source for the API and the OS X client is available on GitHub as usual and some further technical details are available in the READMEs.

You can keep up to date with my coffee consumption at coffee-tracker.herokuapp.com.

Enjoy.

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.

A tale of three pull requests

After years of earning a living through using free software I’ve finally contributed back to the open-source world.

Frustration

For the two and a half years I’ve been pushing some personal projects to Github and some of my code I’ve been told has even been helpful for others. While this is certainly open-source none of my efforts have affected existing codebases.

Numerous times I’ve scoured the bug trackers of projects I’ve had some sort of interest in, on the lookout for an issue I could investigate, even getting as far as reading through upteen lines of foreign code but ultimately unable to add anything.

A first attempt

The project I’ve been working on for my current client, like many other projects, makes use of a handful of libraries.

I discovered one library I’m using to access an API had failed to implement a feature I required. My choices were to abandon the library and the code I’d already written using it, open a feature request in the hopes it would be worked on or man up and do the needful myself. Can you guess what I decided upon?

After forking the repo and creating a feature branch I wrote a test for the needed behaviour, wrote some code to implement that behaviour, committed the changes when the test suite passed, pushed to GitHub and finally opened a pull request. Unfortunately the original author decided he didn’t want that feature in the library at that time.

Such is life, the code fit my own purposes, I was able to get with the task at hand and at the end of the month invoiced my client. Things have been worse.

Once more with feeling

A similar situation occured again a bit further down the line: another library I’ve been using required a small modification to fit in with the constraints placed upon this project. I went through the same procedure as above and this time there has been no response.

Ah well, things could still go either way and at the end of the day I still have the functionality I need.

Third time lucky

Last week i was debugging an issue involving authenticating against a SAML Identify Provider. I was eventually to deduce that the library in question on this occasion didn’t support the algorithm used to compute the digital signature of the authentication response.

I drank a lot of espresso, scratched my head a lot and then found a library supporting this algorithm. The downside was there was no documentation or tests.

There was nothing to do but read the code. I was able to get something working after a while and thought it would be a shame not to share my understanding so I wrote a quick test and put in place the mechanics to run the test which in itself yielding some more know how.

Forks, branches, pushes, pull requests, merges, deploys, happy client, problem solved, home time.

Conclusion

All I basically contributed was a unit test. I didn’t invent anything new or expend any great time or effort but I did give something of myself and didn’t expect anything in return. This has always been the spirit of open-source software and it’s why I use it all day, every day.

No matter how insignificant you feel your contribution may be, it’s the small changes that keep the wheels of the open-source machine turning.

The pull request was merged into master, maybe you’ll find it useful.

An iOS client for my UK inflation app

After last week’s great Xcake meet I felt a fresh surge to take on new challenges and bend some less-familiar pieces of technology to my will.

Motivation

The first product of this enthusiasm was a prototype web app built to get a bit more experience with Python and Google App Engine. A few days later it got an API.

The resulting rapid feedback loop led me to pick up my copy of Beginning iPhone Development which had been sitting gathering dust for the last couple of years and get stuck back into following the examples.

Revisting Cocoa

I first dabbled with developing for Cocoa when I first started using a Mac and managed a range of “Hello World” apps, simple calculators and embedded WebKit views, but nothing substantial came of it. Thankfully a few of the concepts seemed to have stuck and after working through the first few chapters of the book again I felt confident enough to get started on something of my own and an iOS client for ukinflation.appspot.com seemed a logical choice.

This is the result:
UK Inflation App - Screenshot

What I Learnt

Even though this is a trivial app there have been a few aspects which have been useful from a learning perspective:

  • accessing an external API
  • decoding JSON
  • local data persistence with a plist file
  • interacting with view elements

These are all things which could make for useful reference material in the future.

Moving on

I’m not part of the paid iOS developer program at this time so I haven’t been able to test the app on actual hardware, which would have been nice. I may stump up the 99 bucks to get my hands on Xcode 4 and have the ability to run my code on a device. I may decide to have a crack at developing a desktop Mac app. Who knows.

The topic of push notifications was mentioned at the last Xcake so there’s another potential area of investigation involving both server and client technologies.

Stay tuned!

Keeping an eye on UK inflation with Google App Engine

For a long time now whenever I’m on the search for something interesting to work on that could potentially be of value to myself and others my attention is brought to topics like machine learning, data mining and natural language processing.

These are all areas within computer science which are not particularly easy and have a higher barrier of entry compared to building a typical web application for instance. Yet, if implemented correctly they can provide great insight and fame and fortune are bound to be near.

Joking aside. I studied artificial intelligence at university and my undergraduate dissertation was focussed on expert systems so I’ve a bit of exposure to these topics but nothing decidedly practical nor within the past decade.

Interesting Books

Some searching on Amazon turned up a couple of books which looked to be talking about the type of tasks I was interested in performing.

One thing these books have in common is that they use code examples in Python.

For nearly half a decade now a lot of my interest has been with Ruby and related technologies and so I’ve largely avoided Python considering the similarity of the space the two languages sit in. A look through the most popular AI books revealed none using examples written in Ruby however.

The other day I came across a copy of another book using Python so I thought I may as well get a bit of hands on experience with the language and take it from there.

Something Practical

In the past I’ve tried to teach myself many languages from books but it has never been until I’ve needed to use the language for something practical that the know-how stuck.

Thankfully I didn’t have to wait long until inspiration struck. As a private investor in the current economic climate, a topic that has been in my mind has been the rate of inflation. Every time I want to check how quickly my assets are being eroded by inflation I have to unleash Google and hope I land on the correct page and from there find the current rate amongst all the other information. This seemed like the perfect fit for yet another single serving web app.

My starting point was to write a Python script to scrape the Office for National Statistics for the current value for the Retail Price Index.

Next up was creating a basic web-app with App Engine. I’d tinkering with App Engine a bit previously so it was relatively straight-forward to follow the tutorials and piece together a single page app. Slightly more complicated was reading up on the Datastore and Memcache APIs but there were plenty of examples to follow.

Conclusion

The end result is ukinflation.appspot.com. It’s basic but deals with the job at hand. It’s also been a good introduction to various components of the App Engine environment: Datastore, Memcache, Cron, templates and the built-in webapp framework.

I’ve used in all of these types of technologies in other forms over the years and it’s amazing that you get so much functionality out of the box and as long as you embrace the constraints, scaling out comes for free.

I’ve still to make my mind up about Python though, maybe I’m just too accustomed to Ruby. Still, I’m glad to have another tool in the toolbox and to not be restricted to any one set of tech.

Share the Love

As always the code is available on GitHub, fork away!

A minimal Rack app to lookup your external IP address

I think I first heard the term “Rack-app” when I started using Heroku to host a couple of projects. I didn’t know an awful lot about Rack but I did know that it helped a great deal when it came to getting my Rails and Sinatra apps off my workstation and onto the web.

Tonight I thought I’d have another quick look at how it works, what it takes to build a Rack-app and what information about the request is available to the handler.

The result was the following, an object which responds to call and returns a HTTP response code, headers and a body:

ip = lambda do |env| 
  [200, {"Content-Type" => "text/plain"}, [env["REMOTE_ADDR"]]]
end
 
run ip

I have this running on ip.stevenwilkin.com and it provides the same useful function as whatismyip.com but without the ads :)

The code is available on GitHub as always.