Philip Roberts

Fresh, free music with Sonic Router

Thu, 03 May 2012 12:10:00 +0100

I recently came across Sonic Router which have a nice collection of dubstep/electronic/hip-hop mixes from various artists. One of my favourites so far is by Lapalux.

Bored of opening the Sonic Router homepage, finding the list of mixes, choosing a random one, hitting play, I knocked up a little Ruby script that opens a random one in your browser. And if you have dotjs installed there’s a little snippet that will autoplay too.

The making of Shakey: a Realtime, Massively Multiplayer, Shakespearean parlour game

Tue, 01 May 2012 22:35:00 +0100

At Culture Hack Scotland (#chscot) last weekend, we won most playful and the grand prize for a real-time game we made using Rails, JavaScript and Pusher. For a bit of background read this post.

I thought it might be interesting to break down the technical details of how it was developed and worked. Bear in mind that apart from a tiny bit of prep work, all the code in this project was coded in 16 hours - so the architecture/code will not be optimal.

Credit where it’s due, the code and architecture I am talking about here was created by myself, Rory Fitzpatrick and Jim Newbery, with a little help from Phil Leggetter of Pusher.

The Premise

The idea of the game was thus:

On a big projector screen would be an image of a theatre stage complete with actors and audience.
Players register by visiting a url on their phones.
Players are assigned to be in the cast, or in the audience, and appear on the big screen using their twitter avatars.
The game starts
The actors then recite a short piece of Macbeth, reading the lines from their phones as they are prompted to do so.
The audience have the option to throw tomatoes/flowers depending on how well they think the cast members are doing.

Getting Started [Midnight friday]

Since we wanted a game that worked in real-time, with multiple devices communicating with each other, we quickly settled on using WebSockets, which allows JavaScript on the browsers of two devices to talk to each other. We quickly settled on using Pusher which is a hosted solution for implementing websockets easily. We were pretty pleased with that decision as it was easy to use - the only drawback being no fallback support for the default Android browser (unless Flash lite is installed).

The rest of the app (serving assets etc) was served from a rails app running on heroku. Here’s a very rough diagram detailing the architecture.

see bigger

I’ll explain what’s going on a bit better below.

Getting up and running with Pusher [1am Saturday]

I quickly spiked out some JavaScript code to demonstrate two browsers talking to each other with pusher.

Pusher is essentially a PubSub implementation on top of WebSockets. Pusher’s normal operating mode is that you would have your server sitting on the internet somewhere Publishing messages to a channel, and browsers (the clients) Subscribe to those messages.

In Shakey however, we wanted the game server to be running in a browser (the left hand side of the image above), so as far as Pusher is concerned, even our game-server is a client. (Yup, it is confusing, try figuring this out at 2am, after cocktails!)

This requires setting up pusher to enable client to client messages. The process for this is:

When setting up your pusher channel, make it a “presence” or “private” channel. A presence channel allows for client-client messages, and is suitable for games where you need to know “who” is speaking/listening.
Presence channels require your users to be authenticated (you don’t want any old Joe Bloggs sending messages to your other users. To do this Pusher hits an endpoint in your app (/pusher/auth), where you must check the logged in user, and tell Pusher about them (using the Pusher gem makes this easy, more info here.

Once you have setup your presence channel and authentication, you can now talk to each other, as an example:

Open game_server.html in one browser, and game_client.html on another, and an alert will appear on the server’s window with the message “Hello, world!”.

Baby Steps

Now that we had very basic communication between a server and a client working, we could comfortably split into two teams. To keep ourselves straight, we wrote down all the messages we would need to run the game, they were.

Sent from the clients

// register a new user
"player:register", "<username>" 

// audience member wants to throw flowers
"player:hurl", "<username>", "flowers" 

// a cast member has finished reading their lines
"player:exuent"

Sent from the game-server

// starts the game
"scene:start" 

// announces which role the user is going to play
"player:assignRole", "<username>", "audience/cast" 

// player should start reading lines
"player:deliver", "<username>", {lines: '---'} 

// ends the game

The beauty of having a nicely event-driven architecture like this was that Rory and I could develop the game-server, completely oblivious of what Jim was doing with the messages, and vice-versa.

Indeed, Jim wrote his game-clients in JavaScript, and we wrote the game-server in CoffeeScript and it didn’t matter a bit.

Building out the server

Now that we had the messaging setup, and the protocol designed, Rory and I focused on building out the game-server. It’s responsibilities (roughly in order) were:

Grab the current scene we were going to act out, along with the characters in it.
Listen for “player:register” events, and when one was heard, assign the new player to be in the audience or cast, and announce it to them by triggering a “player:assignRole” event”.
Wait for someone to click the “start” button, and when it was pressed, trigger a “scene:start” event to everyone, followed by a “player:deliver” event to the first cast member, who needed to speak, with their lines.
While someone was speaking, listen for “player:hurl” events, and trigger the appropriate fart-noise and animation on the screen to indicate something had been thrown at the current speaker.
Wait for “player:exuent” events, and when one was heard, send a “player:deliver” event to the next speaker.
And so on.

We built the server using Backbone.js, as it makes breaking up the code into Models (for us Player and Game), Collections (of Players) and Views (the animated Player avatars on the screen) easy.

The event driven architecture was really useful again on the game-server. We wanted to add a “news-feed” down the side of the display, with things like “@philip_roberts threw a tomato”. This was in the end trivial, as we just had another little bit of JavaScript, completely independent from the rest of the game, listening for “player:hurl” events only, and updating a list when it did so.

Building out the clients

We left Jim to build out the game-clients that would be running on people’s phones. It’s role was pretty much the inverse of the server:

Register a user by sending “player:register” events
Wait to find out which (“player:assignRole”) role it had been assigned
If it was a cast member, wait till it received “player:deliver” events and display the lines to the player, and wait for the player to press “done”, thus triggering “player:exuent”
If it was an audience member, display “throw flowers”, “throw a tomato” buttons, and trigger “player:hurl” events when clicked.

The game-clients were also built in Backbone.

Done [4pm Saturday]

Apart from some awesome visual polish, that was pretty much it. I’ve neglected to show much real code here, as it’s pretty hideous, but you can dig into the repo.

Caveats, lessons learned

A few things tripped us up using Pusher that are good to know if you are doing something similar.

First, the presence channel and client setup isn’t that hard, but takes a minute to get your head around.
When using a presence channel, all clients receive all events. You can’t just send an event directly to a single client. In our case that meant we always sent the “username” of the intended client along with the data, and the client on the other end filtered out messages that weren’t intended for them. We could have set up separate channels for each player, but decided this was simpler to manage.
The exception to the above is that the client that sends a pusher event, doesn’t receive the event itself. We tried to listen to events published by the game-server (which is a client remember!) within a different part of the game-server, and it doesn’t work. It’s easy fixed by using non-pusher events, but confusing when you bump into it.
Because Pusher is hosted in the cloud, all your development/testing/production servers will be using the same pusher account (unless you setup different pusher accounts (we didn’t)). This gets pretty mind boggling when 3 people are testing code on three separate machines, but they are still all interacting. We could have fixed this by setting up different channel names on each machine, but we didn’t figure that out at the time.
3G providers really like to screw with your internet. Before the demos everyone was asked to not use WiFi on their phones - which was less than ideal as companies like O2 like to smush websocket traffic not sent over encrypted connections. Pusher will fallback to an encrypted connection if unsecured doesn’t work, but to ensure that it worked first time, Phil Leggetter from Pusher suggested we force encrypted connections: First encrypt the Pusher socket and then serve all the assets over ssl (easy done with heroku, just stick https in front of the urls).

And finally

If you have any questions about what we did, (or if you want the four of us to make you an ace multiplayer game!), just get in touch on twitter.

Giving up on self-defeating self-talk

Tue, 01 May 2012 10:56:00 +0100

The mind is a powerful thing.

It can convince us that ghosts exist; that the position of the planets demonstrably affects our lives; that the answer to the Monty Hall problem is not “choose the other door”.

It can convince us we hate foods that we later come to love; that the aged mouldy excretions of a cow’s mammary glands are in fact a delicacy.

It can convince us that innocuous eight legged beasts 1/60,000 of our own weight are terrifying; whilst striped, fierce, clawed, fanged creatures 5 times our weight are cute.

It can convince us that other human beings don’t deserve to live because of the colour of their skin, or the country they were born in.

It can convince us to end our own lives.

Might it not be then, that this mind of ours, while powerful, is often pretty stupid.

That perhaps sometimes we should question the validity of what it tells us, or ignore it completely.

That when it says “you suck”, or “you are stupid”, or “you are not worthy”, that perhaps it is wrong. That perhaps we should not give into, or even enjoy this feeling, and fight it instead. Banish it along with all the other myths, and fallacies, and fantasies, and biases that a mind crafted over 3.8 billion years comes up with when it is placed in a modern world free of genuine threat and scarcity.

Perhaps.

Posing with our champagne after winning Culture Hack Scotland...

Mon, 30 Apr 2012 17:33:18 +0100

Posing with our champagne after winning Culture Hack Scotland 2012 with @roryf, @praymurray, @froots101, @druichmckay and @suchprettyeyes.

A Shakey Victory: Culture Hack Scotland 2012

Sun, 29 Apr 2012 15:04:00 +0100

Having just returned home from Culture Hack Scotland 2012, I can safely say that it is one of my favourite tech events of the year. Since anyone who wasn’t there will have seen all my tweets without knowing what I was up to, I thought I should give a run down of what I’ve been up to for the last 24 hours.

Culture Hack what?

Culture Hack is a 24 hour long hackathon. This year it was held at SocietyM in Glasgow - a beautiful coworking space under the equally cool CitizenM hotel.

The basic premise is thus: lots of cultural organisations (festivals, museums, libraries, universities) generate a crap load of interesting data that they don’t do anything with or share. Meanwhile there are lots of developers and designers who would love to build useful/interesting/cool things using this data, but they don’t get the chance. Culture Hack is an event that encourages these organisations to share their data, and see what cool stuff developers and designers can do with it in under 24 hours.

This years data included things like:

full event listings from numerous festivals in Scotland (Glasgow International, the Edinburgh Festivals, Arika)
electricity, water, gas usage data for some of Edinburgh Universities buildings recorded every half hour for the last year
data and images of the National and Glasgow museums

Our hack: Shakey, a Massively Multiplayer, RealTime, Macbeth Parlour game

This year I teamed up with the hugely talented Jim Newbery (@froots101), Rory Fitzpatrick (@roryf) and Padmini Murray (@praymurray).

Jim, Rory and I had met up in the pub the night before, and discussed using one of the datasets: a fully digitised, annotated and computer friendly copy of Macbeth, to create a massively multiplayer, realtime parlour game. We met Padmini on the night who came on board as producer, Shakespeare expert and all-round great gal.

The idea of our game was to merge Shakespeare’s Macbeth, with modern technology (computers, projectors, mobile phones and realtime tech). Here’s a photo of the game in action during our live demo:

It works something like this:

On the big screen there is a picture of an empty theatre stage
Everyone in the room can join the game by visiting a link on their smartphones/computers, and entering their twitter handles
The game puts most people into the audience, and a few people are selected to be in the cast. Everyone’s twitter avatar’s appear in the proper place on the screen
The game begins
The cast are now prompted when it’s their turn to recite lines from Macbeth, with the lines appearing on the screen.
Meanwhile everyone in the audience has the option to “throw a tomato” or “throw flowers” which are animated on the screen behind the cast with appropriate fart/splat noises (of course)

Here’s a clearer screenshot of the projected image halfway through another game, along with what an audience member sees on their phone:

Note in particular:

The awesome stage design, by Duich McKay
The wicked Macbeth, Lennox, Porter and Macduff characters by NIcola Osborne
The tomato/flower splats on Macduff as animated and sonified by Rory
Terrible grammar

The Tech

Jim wrote a little Ruby on Rails app that imported the Macbeth script and characters into a database
Pretty much everything else was written in JavaScript/HTML/CSS. The computer hooked up to the projector acted as the game server: animating the screen, keeping score, sending lines to phones, and listening for hurled tomatoes/flowers.
Communication between all the phones and the game server was done over websockets using Pusher

Building something so real-time was fairly new to us all, and mind-meltingly confusing, but I think we were all pretty chuffed with what we achieved in such a short space of time. Once I’ve recovered I’ll try and write the tech stuff up in a little more detail

The demo

At the end of the day, everyone demos their hacks, and prizes are awarded. Our demo went pretty well, until 100 people in the room tried to throw tomatoes - promptly crashing Google Chrome on my computer. Apparently 1400 tomatoes/minute were being thrown!

Our hack was awarded most playful and the overall grand prize winner. Not bad for 24 hours work! Look out for a video of our demo soon - I can’t wait to see it myself.

Founder depression, and a meetup proposal.

Fri, 20 Apr 2012 10:43:00 +0100

As both a capital-F founder and developer, the last 12 months have been tough. I have personally been stuck in some pretty deep lows, and of the assumption that I was the only one struggling with a lot of questions about who I am, what I am doing, and whether I’m good enough to do it.

The last couple of months have been a lot better, triggered by a few things:

Going to the doctor: who said lots of nice things like “what you are doing sounds really hard”, “the most common thing I see in this room is depression”, “yes it looks like you have mild depression”, “here’s some practical things you can do that aren’t drugs”.
Speaking to an (off-duty) counsellor: possibly the most “productive” hour I have spent in a long time.
Writing that blog post

But the most powerful thing has been opening up to a number of different founders and developers about what I’ve been going through, and them replying with “wait, I say those things all the time too - I thought I was the only one”. The following relief of finding someone else going through the same stuff has been palpable for both of us.

A proposal

As a result of this, I am thinking of starting a meetup/support-group in Edinburgh to help founders, developers, and anyone building products share some of their personal experiences with this stuff and learn from each other.

I haven’t got it all figured out yet - so I’m looking for feedback, but here’s some rough thoughts:

Non-technical/business: we have plenty of technical meetups, this is a place to reflect on our selves rather than code/biz. Clearly a lot of our emotions are affected by the work we are doing - but the focus is definitely on the personal stuff.
Open to anyone related to running businesses/building stuff (not just founders)
Confidential: at the meetup: share, otherwise: shush. :)
Supportive, not dismissive: I think this goes without saying. None of this: “oh, sure, that’s easy, you can just fix yourself by … eating more! My problem is much more serious!”
Small: I’m not sure how we would manage this if the group became a run away success, but I think at least initially it would be good to try and keep the groups small as sharing this stuff is hard enough as it is.
Format: As a first meeting, I am thinking I would talk about some of the stuff I’ve been going through, and see if we can use that to kick-start a bit of a group discussion and take it from there.
When/where?: I’d like to have a first meeting soonish, but I haven’t got a venue - so if anyone has any thoughts for somewhere that’s free, I’d love to hear them.

So what do you think? If you are at all intrigued, I’d really appreciate it if you’d fill in this quick form just so I can gauge interest (and collect feedback if you have any). Thanks!

We recently had a Rubik’s Cube themed party for everyone...

Sun, 01 Apr 2012 18:52:09 +0100

We recently had a Rubik’s Cube themed party for everyone who has been helping out at TechCube.

Since I was on playlist duty, I figured we needed some appropriate visuals and whipped up a little visualizer that responds to the music in Processing. Particularly cool was that since it was projected onto the ceiling it could be seen from the street below.

Blog post coming soon.

A Short Lesson in Perspective

Thu, 22 Mar 2012 20:41:09 +0000

A Short Lesson in Perspective:

It is a universal truth that all artists [and developers!] think they a frauds and charlatans, and live in constant fear of being exposed. We believe by working harder than anyone else we can evaded detection. The bean-counters rumbled this centuries ago and have been profitably exploiting this weakness ever since. You don’t have to drive creative folk like most workers. They drive themselves. Just wind ‘em up and let ‘em go.

A profound piece on business and creativity. Read. (with thanks to @roanlavery.

Generalists, Founders and the Impostor Syndrome

Fri, 16 Mar 2012 17:55:00 +0000

As the technical co-founder of a web startup, it’s easy to think of yourself as a software engineer first and a founder second. This is patently wrong and potentially dangerous for your mental health.

To make my case, here is a list of job titles that I could quite easily give myself based on the work I have done this week.

Business analyst (considering the benefits and implications of switching payment provider)
SysAdmin
Data analyst (running analytics on some data to see if it can help us find a solution to “the big problem”)
System architect (planning how our application should integrate with a new API)
Rails developer (integrating our web application with the new API and a new payment provider)
JavaScript developer (building our backbone.js based webapp)
Front-end developer (building out the HTML and css for our webapp)
UI/UX Developer (trying to improve our sign-up flow)
Marketing (improving our pricing plan communications, blogging about our company’s second birthday)
Copywriter (both in-app microcopy, and marketing copy on our website)
Design (designing/building a page to thank our Founder members: http://floatapp.com/founder_plan)
Customer support (interacting with users via email and phone calls)

I don’t say all this to boast or complain, it’s simply a fact. As the technical half of a two-person company, I have to cover a number of different roles.

Truthfully, I love it. I have been, and always will be, a generalist. However, I also push myself to be the best at every individual thing that I do—no small feat given the list above—and this is where the imposter syndrome kicks in. Instead of evaluating my performance holistically, I tend to compare myself against experts in each of the roles I perform.

For example, with my JavaScript developer hat on, I think of myself as a JavaScript developer, not a founder. This means I start comparing myself to other JavaScript developers (like some of the best, in, the, business. At that point I start to feel inadequate. The trouble is, I do this for all my hats: compare myself to the best in the business for each vertical. At that point I start to feel really inadequate.

Having spoken to two other co-founders with similar feelings this week, it’s clear that this is a foolish mindset. A more appropriate perspective is:

I am a capital-f Founder, not a JavaScript developer, or Rails developer, or designer or customer-support guy. I will still strive to be the best in the world at each of my hats, but if I don’t quite make it that’s okay—I’ll just hire them one day instead.

This shift in thinking has a had a massive positive effect on my mental health—but I’d love to hear what other founders think?

Mandelbrowser - Google Maps for fractals

Fri, 24 Feb 2012 18:59:00 +0000

A while ago I made a tool that lets you explore the Mandelbrot Set (a famous fractal) using an interface a bit like google maps.

It’s rendered using the <canvas> element, and JavaScript. It performs awfully, and the code is hideous - but it does makes pretty pictures, eventually!

Collider - a d3.js game

Fri, 24 Feb 2012 17:43:00 +0000

I made a quick game using D3.js as a way to learn, and show, how it works. It feels like jQuery++, with extra confusion.

I’ve documented the source pretty thoroughly to show how it fits together:

Float and backbone.

Fri, 17 Feb 2012 18:27:40 +0000

Float and backbone.

Live-coding a simple backbone.js app

Fri, 17 Feb 2012 18:26:40 +0000

Live-coding a simple backbone.js app

A few live coding tips

Fri, 17 Feb 2012 11:16:33 +0000

Last night at Scotrug I live coded some of ToDoMVC in Backbone.js to introduce Rubyists to Backbone and how it looks & feels.

Since it went surprisingly well, I thought I’d share a few quick tips:

Keep it simple

The todo list app I wrote is very simple (and I didn’t even finish it), but complex enough to demonstrate the basic elements and power of backbone.

The power of live coding isn’t to show off how fast you can type, how complicated you can make something, or even really to show people code, but to give you a stage to talk through the elements and design choices of what you’re building. The simpler it is, the more time and energy you’ll have to talk.

Think of your audience

I thought pretty hard about what I could expect my audience to know, and what I couldn’t. You want to remove as much extraneous talk and code as possible - so if you’re confident that most people will know something, don’t just throw it in anyway. Keeping it out will keep their minds clear for the important stuff - and give you less code to make mistakes on.

The flip side of course is that you need to make sure you set the stage for what you are doing, and don’t assume too much of your audience, or you’ll lose them quickly.

Think like a beginner

In the demo, I did a lot of back and forth between writing a little bit of JS in VIM, then using Chrome’s console to play with the code I had just written (here’s a quick guide to increasing the font size so the audience can read it). I got a couple of compliments on that approach, I think because it helped me drive home the point at each step - rather than just diving ahead and writing the whole app at once.

I also added a couple of small “deliberate mistakes”, mostly around JavaScript’s async nature, to keep people thinking, and not just drifting off because everything was going too smoothly.

Practice, publicly

My preparation for the demo went something like:

Built the app up from scratch completely, keeping a README explaining what I was doing and why, and carefully committing at every logical step.
Dumping it all and doing the same thing again from scratch a couple of days later.
Going through the commit logs and deciding what stuff was extraneous, and where I should actually start my live coding (I didn’t want people to get bored watching me setup a rails app).
I then put a shout out on twitter to see if anyone wanted a one-on-one tutorial. Thankfully @ryanstenhouse did. So I took him through the demo from start to end in a bar. This was the best prep. I did: it added a bit of pressure, and weeded out a few more mistakes I was likely to make. His enthusiasm also gave me the confidence that it was a good idea, and people would find it interesting. It also meant I had an ally in the audience who could help spot my bugs if something went really wrong.
I did a final run through, recording myself via quicktime to get an idea of how long it might take, and to help me focus on slowing down and not making mistakes.

And finally…

Pray that the demo gods are on your side…

Look out for the video which should be popping up online in the next week or so.

Over the Blue Moon.

Thu, 12 Jan 2012 16:23:08 +0000

Over the Blue Moon.

"Time is not a nice person, I know because the signs said it. Time can be generous, but ultimately,..."

Thu, 12 Jan 2012 16:20:27 +0000

“Time is not a nice person, I know because the signs said it. Time can be generous, but ultimately, time is indifferent. Time does not give two damns or a fuck. So what will you do? What will we do . .?”

- Pase Rock From Sign (feat. Pase Rock) by Nujabes on Modal Soul

Departing the North Sea on New Years Day 2012.

Thu, 12 Jan 2012 09:18:59 +0000

Departing the North Sea on New Years Day 2012.

A wee whisky cocktail.

Tue, 10 Jan 2012 22:34:18 +0000

A wee whisky cocktail.

Faster rake tasks in Rails

Tue, 10 Jan 2012 16:39:00 +0000

Rake tasks are awesome for project specific scripts among other things, but in rails projects they suck for short tasks that don’t depend on rails. Here’s why:

You type rake my_task_that_doesnt_depend_on_the_rails_environment
Rails loads (10-20 seconds)
Only then does your superfast rake task run. Boring!

Looking for a solution I came across Xavier Shay’s attempt to deal with this.

His solution is to maintain a list of rails tasks which depend on Rails (like rake db:migrate) in your Rakefile, and have the Rails environment autoload when any of those tasks are called. Any tasks in lib/tasks will now run nice and fast.

This helped, but it means you have to maintain a list of all the Rails tasks you may want to use (and any rake tasks included by gems used in your app) in your Gemfile, or remember to append LOAD_RAILS=1 to your rake call to force rails to load.

Because I can’t be bothered trying to remember which of my tasks depend on rails, I modified his Rakefile to autoload the Rails environment if Rake can’t find a task (on the assumption that it’ll be hidden in Rails/gem somewhere. This has the side-benefit of loading the :environment task, that any tasks which require the Rails environment depend on, if and when needed.

If you have any thoughts I’d love to hear them, the gist is here.

Courgette Frittata

Mon, 09 Jan 2012 19:33:52 +0000

Courgette Frittata