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.