dira ⋅ geek ⋅ girl

The Robot Game at RailsGirls Krakow


I think it is hard to introduce people to programming by having theoretical presentations about code, commands, terminals & servers. That's why during Railsgirls Krakow I organized a game that allows participants to experience, in real life, a lot of programming concepts.

The game

The goal is to drive the 'robot' through a maze, by giving it a sequence of commands, and have it bring back an object. At Railsgirls, some of the coaches played robots, and the objective was to make the robot reach a cupcake placed in the maze.

Robots at work

What I love about this game is that, by playing it, one gets a lot about how programming works.

The robots accepted instructions only when written on a piece of paper, and did not respond to any other interaction - just like machines run programs. We emphasized that the instructions in the program must have a specific structure - one command per line, and that the commands must belong to the set of available commands. Robots would 'error' in funny ways if the program wasn't valid - which will (hopefully) help the players understand why they get syntax errors in real programs as well.

The game also makes you see how the program 'runs', in real life; you follow its progress, and see clearly why it errors (the robot hits a wall, or there is no cupcake to pick). It's also very easy to see if it works correctly or not - you either have a happy robot with a cupcake in hand at the end, or not.

How it worked

To introduce the game, I held a short presentation in which I explained the concept, accompanied by a robot which executed commands, for the attendees to get a glimpse of the available commands and how the robot works. Then we went to playing the game!

Some teams took a very analytical approach, measuring the step length, calculating how many steps were needed and writing the program in one go. Some were a bit intimidated by the task, and we encouraged them to write some small, test programs, and iterate from there.

Writing programs

It was very exciting for me to see them get involved, the empathy with which they watched their program run, some almost imitating the robot, cheering for it, and celebrating each victory - getting the robot to turn at the right location, getting the second turn right, getting the cupcake.

Yay, robots!

The coaches were great robots, executed the programs as rigorously as a machine would do, but error-ed in funny, creative ways.

After each team wrote a successful program to get the cupcake, we asked them to make it shorter by inventing new commands. They quickly came up with compound commands (step = step right + step left) and repeating instructions (10 x step), turning the ~25 lines of the initial program into less than 10. One team understood that the number of characters must be minimized, so they wrote an algebra-like one-liner like i 10*(x,y) j 7*(x,y) i 4*(x,y) t.

Notes on organizing the game

The main challenge was the limited available space, as RailsGirls Krakow had 50 attendees, and about 25 coaches & organizers. To optimize the space, I created 3 labyrinths, each one with 2 robots, and 2 teams x 4 girls per robot. Each labyrinth also had a person that answered questions and interfaced between the teams and the robots. So I made sure that there is enough room for 20 people around each game.

For the labyrinth itself, the goal was to have it as small as possible, while having at least two paths to go to the cupcake, and at least one long line on each path (to compel them to invent loop commands). We also needed it to be large enough for the robots to walk relatively confortable. After a couple of tests we settled on this shape, and used masking tape directly on the floor to make it:


Testing also revealed that it is hard for the (human) robots to make even steps, so we instructed them to make small, tip-to-toe steps. They also called out loud each command as they executed it, and kept track of the current command, to show the error line if the program failed.


Big thanks to WebMuses for organizing RailsGirls and having me organize the game. Monika Starzyk helped me with ideas, real-life testing, feedback and encouragement. The coaches that volunteered to be robots or to manage labyrinths were awesome. I also thank DrTechnico, whose posts about the game inspired me to do it.


2012 at a glance



In the first 9 months of the year I worked with an american company in the health industry, developing a custom CMS tailored to their specific needs. It was an interesting project from which I learned a lot on a wide range of topics, from Rails specifics to using MongoDB to store a hierarchy of document types, smartly indexing data with ElasticSearch allowing for flexible searches, integrating video processing services, generating PDF's from html pages or customizing the CK Editor.

In October a startup company asked me to integrate my open source S3 proxy in their rich single-page application. I continued working with them, developing new features. I led the team in refactoring the application to apply MVC better, use Backbone effectively and simplify the code.


Enjoyed the pink, bubbly Railsberry conference in April. Lots of interesting talks, met old friends and got to know new interesting people. Gave a lightning talk about tzigla, about the fun of personal projects and pixel drawings.

While in Cracow I also took part in hackkrk #4. There was speed dating, where I shared some ElasticSearch wisdom, and learned some cool command-line tricks. On the code retreat I paired with two Java developers; one important lesson was that none of us had a simple project setup ready and that wasted a lot of time.

Euruko started with a hackday, in which I teamed with a group of german developers and tried to fix a mongoid bug. Learned that we heavily depend on the internet for our work; that the bug was fixed a couple of days before; and how to use git bisect to find which commit changed something in the repo (in our case, which commit fixed the bug). Also found out about konacha as an alternative for Guard::Jasmine.

Eurucamp was a mix of interesting workshops, interesting talks - from practical command line tools and scripts to more general best practices. There was plenty of time for socializing and I enjoyed talking to people about ruby, single page apps, and contracting.

While in Berlin I gave a talk on javascript testing at the Berlin Javascript Applications Meetup. It was very well received and a lot of people had questions about the tools and processes they should use to introduce testing to their JS projects. I actually wrote a test-driven Node app that takes a markdown presentation and creates a web page with the contents - which are about testing JS code. Meta is fun!

In September I volunteered as a couch for Railsgirls Cologne. I enjoyed explaining Ruby, Rails, developing web applications and the ecosystem of tools and systems involved, and seeing 'my' girls learning, and tinkering with the application. Memorable takeaway: one attendee said 'done? the app is never done'. There's always room for progress, for improving 'the app', your skills, your life.

Rupy was very dynamic, with short talks on two different tracks. Lots of different subjects, ideas, problems seen from different angles: modularization and decoupling in JS and Rails, AngularJS, command line tips, abstracting production, API design, scaling and availability.

Heroku, S3, canvas and the Security Error of doom


Let’s say you have a nice little project, involving Heroku, S3 and <canvas>. It works like a charm… that is, until you need to do something totally crazy. Such as, stitching some of your images together in a canvas and uploading the result to your application. That should be easy, right? But… browsers throw a security error when you do it, and you find out that you cannot access the data in a canvas that contains images loaded from a different domain.

Update: In September 2012, Amazon added CORS support for S3. See more about how this helps.

Enter postMessage

Cross-document messaging, represented by postMessage, a little-known hero of the browser world, comes to the rescue. It allows to send messages to other windows in the current browser, and receive messages (asynchronously). It works in all modern browsers.

The sender specifies the recipient <window> and domain, and the message as a string. The receiver can see, for each message, from what domain it comes, and take into account only the trusted ones.

How does this help with image loading?

You create an HTML file that will act as a proxy loader, and upload it on S3, next to the images. The proxy’s job is to receive the URL of an image, and return that image serialized as a string.

The application commands, via postMessage: "load /image_path". The proxy, being on the same domain as the image, loads it without any restriction, and replies: "loaded /image_path, here is it, serialized". Now the application can create a new image from the serialization, and the image’s origin will be the application’s domain, not S3.

The good news is, you don’t have to create the proxy or image loading handlers by yourself. I already wrote that code so you can steal my shiny implementation. Check out the live demo to see it in action.

More about the problem

You can include any image, from any domain, on your website with <img>. But when it comes to getting the pixels of an image from another domain – for example, by putting it in a <canvas> and calling getImageData() or getDataUrl(), browsers throw the Security Error because of the Same Origin policy.

This is frustrating if the other domain is also yours. If you could just say, somehow, “this image on S3 is mine, as well as example.com, let the site use the image”.

That is exactly what the Cross-origin resource sharing specification aims to fix. With CORS, the owner of the image grants access to the image to some domains, by setting certain HTTP headers. CORS has decent browser support, but unfortunately S3 does not allow setting the CORS HTTP headers and does not plan to do it either. Update: In September 2012, Amazon added CORS support for S3.

Other solutions

A common solution is to make a proxy on your server, relay all image requests to S3 and return the result. You can do it if you own & configure your server, but for a hobby project hosted on the free plan of Heroku it is not a good fit. When you have one dyno for the entire app, keeping it busy with relaying tens of images per board view is not acceptable.

Another solution is to use a Flash proxy. Enough said.

A third solution involves having a Javascript proxy hosted on S3. If the application is tzigla.com, the S3 bucket would be aliased to images.tzigla.com. The proxy would be loaded in a hidden iframe and it would load the images via Javascript. Then it would declare that its domain is no longer images.tzigla.com, but tzigla.com. After that, it could communicate with all the javascript loaded form tzigla.com and send it the images. The drawback is that after a batch of loading, the proxy cannot be used anymore (because it is not in the same domain as the images anymore).

There is also easyXDM, a library with the same purpose that covers all browsers using a combination of postMessage, Flash, the iframe url hash technique, providing an interface with Socket and RPC abstractions. But if you support modern browsers only, it is too much.

In conclusion

postMessage saves the day and, with a few lines of code, you can get rid of the Same Origin Browser Security error. You can load your images from S3, process then in a <canvas>, and then access the resulting pixels, save the canvas as an image, or whatever else you fancy.

I’ve put the full working code for the demo on github. Let me know if it helps you and, if you have any questions or suggestions, drop me a note to @dira_geek_girl on twitter.


This code is extracted from Tzigla, a lovely collaborative art project with tiles and pixel art. You should definitely make some tiles there, it’s pretty fun.