sausheong

A fiction short story on AI for people managers or anyone who have managed people before

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. Subsequent studies show that the original experiment by Kettlewell was valid. I'm not an expert in this field but the scientific papers seem sound. http://rsbl.royalsocietypublishing.org/content/8/4/609

In any case, the peppered moth example is only an illustration of the idea of natural selection.

Well done!

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

That's not implemented yet I'm afraid, I haven't figured out a good mechanism to timeout the messages.

Thanks for the confirmation.

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.

Polyglot as it is at the moment is an experiment, a prototype. Still fleshing things out, so feedback and contribution is always welcome :)

RabbitMQ was easier for me to develop a prototype to test out the idea.

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.

Nice! Thanks for sharing the project.

Thanks for the comments. The detailed benchmark data is in the perf/ directory, I just did some basic analysis.

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.

It's a cloud based service :)

Thanks for the feedback. It's a good idea and I'm on it.

Absolutely true :)

Thanks everyone for the upvotes and the positive comments! I'm the author of the blog post and the book.