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!
If you do integration/request testing of an AJAXified web application using Rspec, Capybara and Selenium there is a pretty good chance that you might have run into this error:
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.
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:
That will turn jQuery effects off in the Rails test environment.
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:
This just gives the page a little time to catch up before Capybara blows up on you.
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.
File under “Things for me to remember when reinstalling stuff”
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:
Then, add the following to your environment.rb file:
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:
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:
And that, my friend, is how you skin the unix path cat.