I wrote the blog post, thanks Serge for the great library! I considered the self-contained app without the web server method, but I've already done the images before and I'm way more comfortable with Go web programming (I wrote that book too).
You're probably right, I'm just mucking around with various things, didn't really thought too much about optimizing the code. The frame rate on the terminal is basically as fast as iTerm2 can display the image, I can't really control it (except maybe make it slower). It looks rather fast on the GIF because I cut down the number of frames in the GIF, but the actual game runs more reasonably.
Not really. I started with Ruby, Python and PHP but it's very much possible with compiled languages like C/C++. There's a whole bunch of client software that allows you communicate with RabbitMQ - https://www.rabbitmq.com/devtools.html
The implementation today is as a task queue which removes the request from the queue once a responder acknowledges, but it could be a pub-sub model, where a number of independent responders can work on the same message in parallel, and only 1 responder need to return a response. In this case, persisting in the queue is useful.
An alternative is to chain the responders where one responder can leave a message in the queue for another responder, and the final responder returns the response.
Polyglot is still experimental though, and the current implementation is a prototype.
Thanks for the suggestion, it's a good one. A few cases a message queue can be advantageous -- (1) persistence (2) a few responders can work on the same request in parallel (3) adding/removing responders dynamically according to the load.
These are not common/generic use cases but would be useful under particular circumstances.
* I could be wrong with (3) -- I'm not very experienced in reverse proxies.
It's supposed to be more fine grained than load balancers, and you should be able to scale up and down different parts of the same web app dynamically. That probably didn't come up well in the write-up.
I see what you mean. The current service is entirely cloud-based meaning you can't view the slides without an Internet connection. It follows the model for most remote presentation software.
I see the benefits of having off-line presentations but that's more in the domain of Slideshare, where you can download the slides and view them offline. However this means the presenter is no longer able to control the presentation any more and this is one of the main reasons for the service.