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.

Vagrant

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.

gem install vagrant

Once it’s all setup (read the full instructions for some additional steps), you need to initialise your directory:

vagrant init

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:

vagrant ssh

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

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

gem install chef

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.add_recipe("mysql::server")

Chef allows for configuration settings, such as passwords and installation directories, to be passed through to recipes. Vagrant supports this as well:

OpenPhoto

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.

Run

vagrant up

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:

Apache

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:

config.vm.forward_port 80, 8080

Then, fire up “http://localhost:8080″ in your browser, and you should be looking at your OpenPhoto install!

Selenium::WebDriver::Error::ElementNotDisplayedError:
Element is not currently visible and so may not be interacted with

After spending way too long to try and solve this problem (“THE ELEMENT IS VISIBLE DAMN YOU!!!!”) I found a few little tweaks to my setup that help remove and/or mitigate the error.

The key to this error is that Capybara is trying to find and/or interact with an element and it’s not quite ready on the page yet because some JavaScript hasn’t executed yet, or there’s a delay with the test web server.

jQuery Effects

If you’re running tests, there’s a pretty good chance you don’t care about any jQuery effects. You’re just interested in the result. If that’s the case, then add this line to your page layout:

= javascript_tag '$.fx.off = true;' if Rails.env.test?

That will turn jQuery effects off in the Rails test environment.

Capybara “wait_for”

This is a particularly helpful method that, like its name implies, causes Capybara to take a chill pill, and wait for a particular condition to be met. Call it like this:

wait_for(15) {page.should have_content "Some text."}
wait_for(30) {page.should have_button "Button Text"}


This just gives the page a little time to catch up before Capybara blows up on you.

capybara-webkit

A new Selenium driver from the fine folks at Thoughtbot, this is a headless (this just means it doesn’t open a visible window) browser that Capybara can interact with. Ideally it should be faster than opening up a browser window for each test. I managed to get it working, mostly. It’s still kind of new, so there are a few things missing, but it might be a good idea to watch the github project.

“We sell about 40 per cent less albums than we did three or four years ago because of [illegal] downloading” – John Butler

Of course, it’s got nothing to do with the quality of the stuff they’re putting out now. No. It’s all because of the computers. Because computers weren’t around three or four years ago.

I found this site because they’d just sent a takedown notice to Cameron Adams over his brilliant Definitive Daft Punk mashup, which has got to do more to promote sales of Daft Punk than any threat of legal action will ever accomplish.

For me, one of the best things about using Ruby/Rails/Sinatra for web development is HAML/SASS, which allow me to quickly write and maintain HTML/CSS without having to worry about all the pointless stuff, like brackets etc. A by-product of using HAML/SASS is that when you have to write in something else, it causes me grief. JavaScript is a case in point.

Coffeescript (and to a lesser extent) bistro_car solve this. It brings the beauty of a ruby-like language to writing JavaScript, so that once again you don’t have to worry about all the crap that goes along with it.

However, I ran into a slight problem when following Dr Nic’s setup tutorial today. CoffeeScript worked, bistro_car worked within the console, but it didn’t work when accessing the page through the browser. But some path re-working, and a kind word or two from @sutto, and we’re good to go.

For future reference, here’s what I did. I’m using the homebrew package manager. Mainly because it’s awesome, and I use MacOS X, which is also awesome.

So, I installed node.js, coffeescript and bistro_car like so:

brew install node
brew install coffee-script
gem install bistro_car

Then, add the following to your environment.rb file:

config.gem 'bistro_car'

Create an ‘app/scripts’ directory in your Rails app, which is where you can store all your .coffee files (application.coffee etc).

You then get bistro_car to include those script files by putting this in your layout/template/page/whatever:

coffee_script_bundle

Then, you load the page, and bistro_car automagically uses coffee-script to convert your .coffee files to javascript. Except, of course, when it doesn’t work because something is screwed somewhere.

As with almost every problem on a *nix computer, the problem is a path one, and thankfully solved with some simple symlinks. It seems passenger operates in it’s own little world when it comes to paths, and it just didn’t want to play nice with my environment. So, I tricked it as follows:

sudo ln -s /usr/local/bin/coffee /usr/bin/coffee
sudo ln -s /usr/local/bin/node /usr/bin/node

And that, my friend, is how you skin the unix path cat.

My role at the conference was basically to be the room monitor for the main auditorium, which meant that I only really got to see those speaking in that room. As a result, I didn’t really get to see all that I wanted to see, but I can’t complain in the slightest, because there were some fantastic presentations. And I got to see them for free. Which was nice.

So, here’s a brief run-down of who I saw, and what I remember. Unfortunately, I didn’t have a chance to take notes, so some of this is going to be hazy.

Anil Dash (@anildash)

For a few days it looked as though Anil wasn’t going to be able to make it to Perth at all. Some last minute flight shuffling, and some program jiggling saw our opening and closing keynotes swapping. This meant that Anil would be able to come, and I’m fairly sure everyone was glad that he did. It was the perfect opening for the conference: an inspirational call to arms, urging us to embrace the open web and build the apps and sites that people will be talking about. Perth can be isolated, both mentally and physically, and it was great to hear someone talk about breaking the myth of Silicon Valley.

Just a quick time out to thank Anil for his superhuman efforts in coming to speak. He ended up only being in Perth for about 35 hours, and spent 45 hours travelling to do that. I can’t imagine how he felt at the end of the trip. Thanks heaps Anil.

Lachlan Hardy (@lachlanhardy)

Having received the perfect lead in from Anil, Lachlan spoke in depth about the open web, the technologies available and the ethos behind keeping information free from copyright and the patent-lock. A great talk that hopefully encouraged attendees to challenge themselves to use open technologies.

View on slideshare

Dmitry Baranovskiy (@DmitryBaranovsk)

Always entertaining, Dmitry has the knack of making a detailed and technical journey into the world of JavaScript highly entertaining. Quote of the day: “The public scope in JavaScript is like a public toilet. You don’t know who’s done what in there, but if you have to use it, touch it as little as possible”

View on slideshare

Nick Cowie (@nickobec)

Local web legend Nick Cowie gave an informative talk on some of the upcoming features of CSS3, and how well they are supported in local browsers. He had a surprising example of some features that are supported by even the venerable IE6. One for the code monkeys.

View on slideshare

Alex Payne (@al3x)

Alex gave the opening keynote on day 2, and it was a great start to the day (ok, the coffee was the real start to the day). He spoke about how the languages and tools that we use shape the way that we approach our work. Watching Alex’s talk, I was reminded of his tweet from when he was researching the talk:

“Researching tech history is a good reminder not to get too worked up about the tech of today. It mostly looks ridiculous in ten years.” – http://twitter.com/al3x/status/5327550871

While we all love a good language fight every now and then, seeing a laundry list of forgotten languages, specs and companies certainly showed that it’s not worth getting too worked up over.

Quote of the day: “Throw the wallaby over the bush fire.”

View on slideshare

Kevin Yank (@sentience)

Being entirely in love with HAML and SASS I had only paid the slightest of attention towards CSS frameworks. Kevin gave a good run through of what they are, when they’re a good idea, and how they work. I suppose it made an impact, because I actually started using aspects of the 960 Grid on a project at work.

View on slideshare

Ash Donaldson (@ashdonaldson)

Unfortunately, I only got to catch the last part of Ash’s talk, so I can’t really say a great deal about it, except that he has introduced me to an insanely addictive iPhone game: Doodle Jump

View on slideshare

Malcolm Day

After two days of talking about the benefits of various development methodologies and discussions on W3C standards and the like, it was refreshing to hear a talk about money, and to earn it. Malcolm, CEO of Adult Shop (NSFW!), gave an entertaining (and potentially libellous) talk on his journey from being an engineer for a mining exploration company to the CEO of a publicly traded ecommerce company.

Derek Powazek (@fraying)

Wow, what a close! Derek was an exceptional presenter, taking us through the types of “crazy” that we encounter while building communities on the web, and how to deal with each of those crazies. Highly entertaining and hilarious, it was a brilliant end to the conference.

View on Slideshare

I’d like to thank everyone involved in the conference, particularly the AWIA events committee (Myles, Miles, Kay and Helen) for their tireless efforts in putting on a wonderful show. I’d also like to give props to our international speakers, for taking time out of their lives to travel to the other side of the world to give a little something to the Australian Web community.

Your keynote at Edge of the Web is titled “The Wisdom of Community”. How do you define a community on the web?

I like to take the broadest possible definition, so I’d say that a community is any group of people brought together by some common denominator. Lots of things have invisible communities around them – people who care about that thing – even if they haven’t ever met each other. The web gives us the power to find each other, which is why it’s such a powerful, and terrible, place for social interactions.

It seems that, given enough people, a comment thread can quickly devolve into rapid fire insults and grandstanding. How can we foster and encourage thoughtful commentary and participation?

There are two parts to this, and you can only control one of them.

The part you can’t control is human nature. People are weird, messy, and complicated. They react strangely to things. They behave irrationally in groups. And you can’t change that.

The part you can control is how your website interfaces with that strange mass of humanity. Certain interfaces stand up better to the weirdness of humanity than others. It takes a lot of trial and error, and the line is always moving because we’re evolving.

We’re all still learning how to behave online. It’s the first time in human history that you can be both alone and in a group at the same time. How weird is that? It’s no wonder we haven’t figured it out yet.

One of the benefits of investing your time and efforts in building a community is the the personal rewards that come from interacting with the members of the community. One of the perils of that can be when things start to go wrong and it can lead to heartbreak. You had a fairly public parting of the ways with JPG Magazine. Not wishing to get into specifics with you, but how hard was that to deal with, and did the community that you and Heather helped foster help you “heal”?

JPG was an enormous learning experience for me, both for what I learned about fostering creative communities, as well as learning some hard truths about founding a company. There are a million stories out there about founding partners in a startup falling apart. In fact, it’s probably what happens more than anything else. The only difference in this case was that I chose to talk about it publicly. I did that because I had to – the community that built JPG deserved to know what happened. But one side-effect was that many other founders and entrepreneurs came out of the woodwork to tell me their stories. It helped me immensely to know that I wasn’t alone.

The web never ceases to amaze me. When you approach it with honesty, it comes back a thousand fold.

With seriously large amounts of money going after the “Social Web”, do you see people having multiple social locations (eg facebook, twitter, flickr, Goole Reader etc) as a hinderance, or does this fragmentation actually help, by allowing us to compartmentalise our social interactions into different areas, much like we do in our offline lives.

Good question! To a geek, this repetition of signup, login, create profile, over and over, just seems like an inefficiency. But people are inefficient. We all maintain multiple identities already. Who we are with our parents isn’t the same as who we are with our friends. So I’m not as bothered by all these disparate digital identities as some. In fact, I think trying to meld them is going against human nature.

“Strange Light” was an intensely quick project, born from an idea and fully realised in less than two days, and seems to have had an incredible response both from photographers and from the web at large. Do you see these magazines as having their own community? Or one that augments existing online ones (such as flickr)?

I think that magazines are, essentially, communities. At least, the successful ones are.

In the case of the first issue of Strange Light, there were two groups out there: the people who experienced it were a community of experience, and the rest of us who saw the astounding photographs coming out of the storm formed a loose-knit community of interest.

I was hoping that a few of those two groups would want a beautiful printed edition of photos from the storm, and they did! What I like about this is it allows the web to do what it’s good at (connect people) and print to do what it’s good at (create a coveted object).

And finally, when the hell is MagCloud going to deliver to Australia? It’s not like we’re on the other side of the world or something.

The short answer is, I don’t know. But I can tell you why it’s complicated.

Most of the printed matter around you right now is printed in China, put on a boat, and then a truck, maybe a train, and then another truck, and finally makes its way to you. It’s horribly inefficient and disastrous for the environment.

MagCloud is changing all that, because we’re going to have print partners all over the world. So when you buy a magazine on MagCloud, it’ll always be printed as near to you as possible. That way the buyer pays less, the publisher makes more, and we expend less carbon shipping paper all over the world.

But that means shipping is much more complicated than just licking a stamp. We’re setting up printing partners as quickly as possible, but it takes time. We’ll get shipping here as soon as possible. Promise.

Derek will also be running a workshop on “Creative Community Building. Tickets available now!

Then you need to create a “.autotest” file with the following:

Then it’s just a case of typing “autotest” in RAILS_ROOT.

Simple.

Around a year or so ago, someone posted a link to this photo on Flickr:

duty

Uploaded by Godiex { … } on 20 Dec 06, 1.20PM WST.

Certainly an interesting photo, and one that deserved further investigation. So, I started looking at Godiex’s photostream, and noticed there were a few photos of this girl, who turned out to be his girlfriend. I found her photostream, and then saw this photo

home town

Uploaded by randompanda on 6 Jun 05, 10.41AM WST.

which is a shot of the hill I grew up on (our old house is just around the corner). I thought that was pretty intriguing, and so I added both randompanda and Godiex as contacts.

It turns out that Godiex is an artist from Argentina, and that he and randompanda began a long distance relationship in the comments on a photo on flickr. So, all of a sudden, I’m watching the relationship of two people I don’t know, who met through a photo sharing site. Their photos showed them being apart, randompanda going to live in Buenos Aires, and then the pain of separation when randompanda had to return back to Australia (I presume caused by visa-expiry). I’m guessing I felt an affinity for their situation, as Caren and I spent 10 months of our first 2 years together in different countries.

Through my virtual stalking, it appeared to me that they were waiting for the opportunity to be back together and that all would be well again. Then Godiex posted this photo:

this moon is over

Uploaded by Godiex { … } on 28 May 09, 5.10PM WST.

In the description for the photo he basically said that their relationship was over, effectively being ended by the distance apart. It was weird. Here were two people that I had never met, and only shared the random fact that I grew up in the same town as one of them, and I followed their relationship through the photos they posted. And I was sad that they had made the decision to break up. And it’s clear from the comments on the last photo that there’s a large number of other people feeling the same way.

Well, I hope that these people are still together at least (read the comments on that photo for an amazing story).

DropBox

DropBox is simply file synchronisation done right. You install it, drag the files you want to have synced between two computers into the Dropbox folder, and BOOM, it copies everything up to their server, and when you set it up on the second computer, copies everything back down again. After the initial sync, which can take quite a while if you’ve got lots of stuff, it’s pretty much seamless. Create, or make a change to, a file on one computer, and before you know it, it’s available on the other computer.

Need access to those files from another computer, or even from your phone? No problem, they have a web interface that give you full access to all of your “synced” files. Simple.

To add a lovely cherry to the ice cream sundae that is DropBox, they also have versioning. That means if you make a series of dunderhead changes to a document, you can just rollback to the last good copy. Awesome.

Git and GitHub

For the longest time (mostly while I was still working on Windows) “Source Control” was some mystical mumbo jumbo that only people in large companies needed to worry about. Of course, that was mainly because at the time the options for Visual Studio only included Microsoft SourceSafe, which is perhaps some of the crappiest, most unusable software ever foisted on the unsuspecting public by a company with a long history of foisting crap on the unsuspecting public.

Once I switched to MacOSX and started working with Rails, it became clear that all source control systems weren’t created equally. Subversion seemed to be the choice of the community, so I loaded everything up onto my own SVN server. A world was opened up to me, and I could code with wild abandon, safe in the knowledge that I could rollback with no danger. Of course, that was the ideal world, but the basic approach worked. I created branches, tagged releases and deployed sites from SVN.

As with most things, people started grumbling about SVN and some of it’s shortcomings: difficulties in merging different code branches, no distributed repositories and some general discontent. Git was the solution, and the rails community just jumped ships in the middle of the night. Before you knew it, everyone was using Git, and also GitHub. I won’t go into the specifics of why this combo is so good, except to say that if you’re not using git, well, good day to you sir.

git and config_files

In addition to using git to store your development work, you can also use it to manage system configuration files. I found the wonderful config_files. It’s a collection of shell, git, vim and irb configuration files. So? How does that help?

A great feature of git, and github in particular, is that you can “fork” a repository. You effectively copy someone else’s repository, and you can then make all the changes to it you want, without affecting the original. If you want to let other people know about your changes, you can send the original developer a “pull request”, and they can grab your changes, and incorporate them, or not.

So, fork the config_files repository, and then clone it to your own system. Run the “install.sh” script, which basically just sets up a series of symlinks in your user directory. These symlinks point to the files in the git repository. You make any changes you want to the repository and commit them up to github. Then do the same on your other computer, and bingo, you’re synchronising your configuration between machines.

And why would you want config_files? Well, you get some great all round system setup tidbits, but my favourite bit is how it prints the current git branch as part of your prompt, saving you the need to try and work out what you’re in the middle of doing.

Tasty.