I'm a Ruby developer who works for Five Senses Coffee. I ride bikes.
With the recent change of government, there is likely to be a change in attitude to some slightly arcane Free Trade Treaty regulations. One such regulation that the Howard, Rudd and Gillard governements all seemed to agree on is that including a Investor State Dispute Settlement (ISDS) regulation wasn’t always in the best interests of Australia. The Abbott government doesn’t seem to hold the same opinion.
The ISDS provides a mechanism for companies to seek compensation from a country where they feel they were penalised due to the laws of that country. How is that a bad thing? Well, take the case of Phillip Morris, the tobacco company that lost it’s case in the High Court of Australia. They argued that the Gillard government’s crackdown on cigarette packaging was unconstitutional because it infringed their right to trade. The High Court felt otherwise and ruled in favour of the government.
The highest court in a country rules against you, so you should suck it up and leave it be, right? Well, not if there’s a 24 year old free trade agreement that includes an ISDS provision.
Less publicised is the fact that having failed in the High Court, the company now is pursuing the matter via a bilateral trade agreement signed between Australia and Hong Kong in the early 1990s, which includes ISDS provisions.
The contempt such an action shows for Australian legal process and sovereignty, says Patricia Ranald, is plain.
“They’re saying: ‘We’re going to ignore the High Court, when it says we’re not entitled to compensation; we’re going to go off and find an obscure trade agreement to sue you under’.”
Australia is about to become a member of one of the largest free trade regions in the world, the Trans Pacific Partnership Agreement. The US is pressuring Australia to agree to the ISDS provisions, which would allow, say, a coal-seam gas mining company to sue the government if our environmental regulations prohibit them from operating in Australia.
I’m constantly amazed by the talents of the people I work with at Five Senses: Photographers, musicians, and artists. So I guess I shouldn’t be surprised when one of the roasters, Damon Steponavicius, pulls out an amazingly eloquent piece on what it means to be a Coffee Roaster, and how Five Senses is managing that responsibility:
We see the inequity in our industry, and our Green Bean team are witness to the human toll the global market takes upon growers who remain predominantly from the developing world. The beans that arrive on our doorstep are thus indeed a gift from those far away, the result of years of hard labour and sacrifice, of love and of craft. But this gift also comes with an unwritten legacy, and a specific bequest:
‘Do me, and my grower, justice’.
And, crucially, our ability to comply with this unspoken demand is precisely where our ability to invest has profound implications
The speed at which iOS6 devices are being upgraded to the latest OS is quite incredible. I can’t imagine that there has been a software upgrade that’s had an adoption rate like this ever. To be near 60% after less than a week is astonishing.
A graph of adoption rates: Mixpanel
It’s a remarkably simple system: Create a repository in github called username.github.com, configure Jekyll, and then commit and push your code to your repository. GitHub then automatically runs Jekyll on your site, generating the static files, and then publishing the site.
No more having your site locked into a database format, or using some blogging engine that can be compromised. And automatic backups!
Here’s my repository so you can copy the config files.
I’ve spent the past couple of days playing with Vagrant , which is an add-on for VirtualBox that allows you to quickly build virtual machines, configured exactly how you want them, on a project by project basis. The advantage of this is that it lets you replicate your production environment (or as close to as is possible), which should hopefully reduce headaches when you deploy your updates.
Vagrant VM’s are portable, which means that all of your team members can have exactly the same development environment, regardless of their own system setups. Once again: less headaches.
How does it work? Well, first of all, you need the latest version of VirtualBox, and the vagrant gem. I installed it into my system gems, but there’s no reason it couldn’t be in your Gemfile if you’re working on a ruby project.
Once it’s all setup (read the full instructions for some additional steps), you need to initialise your directory:
This creates a file called “Vagrantfile” which configures your VM’s for each project. The most basic file would look like this:
This tells vagrant to start up a VM using an Ubuntu image. It will boot the VM, and then set a port redirect up so that you can SSH into the VM with the following:
That’s all very handy, but of course, you’re going to want your machine to have some software configured. Enter Chef, stage left.
Chef is a framework that lets you create “recipes” to install and configure software on VM’s. Basically, it’s a scripting system for getting a blank VM up and running.
As a good starting point, Opscode have a great repository of “cookbooks” (collections of recipes - natch) on github that you can fork and start using without having to make too many (if any) changes.
To work with Vagrant and Chef, you need a VM configured for Vagrant with a recent build of Ruby installed, as well as the chef. Setting up an Ubuntu 11.10 VM for Vagrant is relatively simple. Just follow steps 1-3 in these instructions.
Once that was complete, you need to install Ruby. Here’s a quick guide to installing Ruby 1.9.3-125 from source on Ubuntu.
Then I installed the chef gem
to get chef-client and chef-solo on the VM. (Note: I’m only dealing with chef-solo in this post. chef-server adds a layer of difficulty that isn’t necessary at this stage.)
Once you have your base VM setup, you need to package it up for Vagrant, so it can load it up in VirtualBox as needed.
At this point, you should have a base VM ready for configuring with Chef.
Vagrant and Chef, sitting in a tree
Vagrant is built to work with provisioning software such as Chef (and puppet). You add a series of Chef commands to your Vagrantfile that it will run on your VM as it is being configured.
To add recipes to your VM you just add the following to your Vagrantfile:
Chef allows for configuration settings, such as passwords and installation directories, to be passed through to recipes. Vagrant supports this as well:
OpenPhoto is an open source photo service that allows you to retain control of your photos, rather than store them with some site that may not even exist in 3 years. Your photos are stored on AmazonS3 or on Dropbox, and you can run a server yourself to maintain total control over the whole setup if you wish, or use their hosted service available here: http://openphoto.me.
Being open source, anyone can contribute to the system, and as with most open source projects, they need as much help as they can get. So, I’ve started tinkering with it, and I thought it was a good candidate to run with Vagrant and Chef to setup test servers quickly and painlessly.
So, if you want to do the same, here’s my Vagrantfile for my OpenPhoto directory, which is a git clone of my fork of the OpenPhoto repository on github. It should hopefully allow you to get up and running if you’ve done everything outlined above.
and that will build your new VM using the base image, and then configure all of the required software. It might take a little while :)
One of the great things about Vagrant is that you can quickly share folders with your VM, which means I can edit files in my repository on my Mac, which are shared onto the VM. This is accomplished with this line:
You’ll also need to configure Apache to use this directory. Here’s my config file:
You can then add a port forwarding rule to provide easy access to the Apache server running on the VM, like so:
Then, fire up “http://localhost:8080” in your browser, and you should be looking at your OpenPhoto install!