This post was originally published on the New Bamboo blog, before New Bamboo joined thoughtbot in London.
About a week ago we tried something new in Bamboo HQ. We had a hack day. This was a day we had set aside in advance where we didn’t schedule any client work to be done. In the days leading up to it we filled up a whiteboard with ideas to hack on during the day.
We didn’t really know what to expect because we’d never done it before, but it actually went really well. We had a scrum as usual in the morning, where people had a final opportunity to ‘pitch’ their ideas to get others to work on it. Some people joined forces to collaborate on ideas, whereas others worked on their own.
We had a couple of opportunities to ask others for help during the day in the form of mini-scrums, but it mostly went pretty smoothly, because everyone is fairly versed in the idea of self organising teams.
Some of the diverse results from the day are listed below.
We created a tool to visualise the visitors of a site in realtime using push notifications from a central server using NGINX. The visualisation itself was done using the HTML 5 canvas element, which lent itself quite nicely to the job. We had to monkey around with long-polling in Ajax to get the desired effect, and our visualisation vaguely modelled real physical forces.
I’d like to do more weekend trips. But they take a lot of work to organise, and sometimes I find I’m paralysed by the options. In fact, I’m reading a book about why choice is bad for you. In groups, the problem gets even worse. Wouldn’t it be nice to just go?
So I wrote an ejector seat. It scrapes Ryanair to find the £1 flights, checks with Hostelbookers that there’s somewhere cheap to stay, then hooks in to Wikipedia to tell you about where you’re going. Note that it doesn’t tell you where you can go: it does some analysis to pick what it thinks is the best combination and then presents you with only one option. Are you going, or not?
For some time now I’ve wanted some way of showing clients and businesses just how much it costs to support Internet Explorer, and the hackday gave me an opportunity to make a site that did just that.
Based around the billing system that designers use to invoice clients, I built a simple application that allowed developers to file invoices against certain IE bugs, quoting the time and the hourly rate charged, and accumulating them to show the total cost and time spent supporting the browser.
I find restaurant reviews pretty useless; the majority are written by irritable people who have nothing better to do than write a scathing review of how some waiter ruined their life. I want to hear what real people think about the places they go. Instead of asking people to remember to visit that review and write up their meal last week, why not send a tweet there and then!
Yumyumyuck watches the two Twitter hashtags #yum and #yuck for people’s restaurant tips. We did some fun stuff with EventMachine plus Martyn’s noodler and juggler code to scrape around ten thousand restaurant names in a matter of minutes.
Dragon Fly is a Rack on-the-fly encoding/processing framework. It’s really really customisable and extensible, but I’ve included ‘standard’ configurations and extensions for activerecord/rails, so it could be used as an alternative to Paperclip etc.
(the main advantage being that everything is done on the fly, so no more reprocessing thumbnails when image sizes change, etc.)
It’s up on github here and gemcutter, and I’ll be adding how to’s and docs over the next couple of weeks.
In one of our current projects I was using RSpec to specify a behaviour of an object which makes HTTP requests. I also wanted this spec to run in isolation from the network. I basically needed to stub HTTP requests in Ruby.
While looking for some solution on Internet I found Fakeweb. It allows stubbing Net::HTTP requests. Unfortunately it matches requests only based on URL and I also needed to match requests based on body and headers. Due to the Fakeweb architecture it wasn’t easy to extend it to support these features. Another problem is that Fakeweb only supports Net::HTTP and it’s not easy to extend it to support for example Eventmachine HTTP client.
I also wanted to put some expectations on HTTP requests my object is making. Pat Allan wrote an RSpec matcher for Fakeweb that allows you to assert if a request was made or not. It solves some problems but unfortunatelly it works only in RSpec and has the same issues Fakeweb has (matching on request method and URL only)
I found that there is no good solution to stub HTTP requests in Ruby, so I decided to implement new solution.
Here are some of the WebMock planned features:
- matching requests based on method, url, body and headers
- asserting execution of requests in testing frameworks
- support for test/unit and RSpec and possibly other test frameworks
- extendable architecture which will allow adding support for other HTTP libraries like Eventmachine
Coming soon on Github…