Ruby 3.0 an Pipes

I just watched the awesome talk of Yukihiro "Matz" (bellow) about the future of Ruby.
There are lots of things to learn from there, please watch.

He talks about SSS (Second System Syndrome - when you try to rewrite software from scratch) and how to avoid the problems of doing it. In summary: "don't". ^_^

If you are going to do a big rewrite do it piece by piece and keep compatibility. That's what he and the Ruby team are going to do for Ruby 3.0.

"No promises", he said, but he gave some general directions for Ruby next steps:

1. Better interaction man ->machine and back. Actually, better errors (smart errors?) and a sort of static type checking, but not the way we are use to it. He called it "soft type checking", and it resembles more an static code analyser than a language feature :)
2. Performance. They're trying JIT compilation alternatives,
3. Concurrency (or should I call "parallelism") ^_^

Part 3 is by far the most interesting. The plan is to remove GIL (Global Interpreter Lock) in a compatible way.

How? Basically 3 steps:

1. Introduce a better concurrency model than threads (I couldn't agree more).
2. Give warnings on using threads directly.
3. Remove GIL (and threads).

He's experimenting on some concurrent models like actors and... wow... PIPES! I just gave a talk in RubyConf Brasil about using Ruby and pipes (good old linux pipes) as a good concurrent model :P

A little toy language called Streem was created to test the concept. And by the time of this writing (sep/2015), Matz is pretty active on it.

I wonder if he had some contact with the work of J. Paul Morrison. As far as I know, Paul is working with this kind of thing, Flow Based Programming, for a couple of decades. His book is really comprehensive on the concept.

I really hope we go that way, my little experience with some of the FBP concepts were amazing. I found it easier and a less error prone approach to concurrency than all other alternatives I tried.

Testando ZeroMQ - PUSH PULL Clean Shutdown

Estou testando o ZeroMQ (ØMQ) esses dias para incorporar no DeadlySerious (meu projeto de "flow based programming" para processar dados em massa).

A ideia do projeto é só incorporar coisas conforme a necessidade. No caso, estou precisando da algo melhor para paralelizar workers. Seguindo a sugestão do Mereghost, dei uma olhanda no ZeroMQ a fiquei agradevelmente impressionado.

Ao invés de um sistema "faz tudo" de mensageria, encontrei uma biblioteca que se propõe a ser apenas um socket on steroids para facilitar a comunicação inter-processos (e inter-threads). Para o que eu precisava, é perfeito (e rápido que dá medo)!

O maior problema é que precisava de algo que avisasse os workers que o trabalho acabou, mas que não os matasse no meio do processamento. Procurei aqui e ali, mas não achei um modelo que servisse. Mãos à massa e comecei a experimentar coisas, cheguei ao resultado aí embaixo.

A coisa toda ainda precisa de mais testes e acho que a ideia também carece de um certo amadurecimento, mas achei que ficou legal, e ainda por cima, funciona! :D

Esse é o cara que vai receber as mensagens. Ele verifica se a mensagem recebida é uma string "EOF", indicando que o sender já enviou tudo. Se sim, ele pára e avisa o sender que já terminou (usando outro canal). 



Esse é o cara que envia as mensagens. Depois de mandar tudo ele envia uma string "EOF" para cada worker que disse que trabalharia com ele. Como não sabe quem é quem, ele manda um "EOF" e espera alguém responder, quando recebe a resposta ele desmarca esse worker da lista e manda outro "EOF". Assim continua até a lista de workers estar vazia.



Funciona bastante bem, a coisa só não é melhor porque o ZeroMQ manda um bolo da mensagens de cada vez, então, se por algum motivo um dos workers está mais lento que o resto, ele empaca todo mundo até terminar sua cota de mensagens.

Pelo que testei, quanto maior a mensagem, menor esse problema pois o "bolo" que ele manda contém menos mensagens. Mas, convenhamos, esse não é um grande problema.

O ponto mais grave é que se um worker morrer (ou for interrompido), as mensagens que estavam com ele vão pras cucuias.

Acredito que tem como contornar essas coisas, mas por enquanto, ainda não achei jeito :)

Acentos em expressões regulares (Ruby)

Já tentou fazer expressões regulares para dar match em letras acentuadas?

Desagradável...

É comum chegar em algo do tipo:

/[\wáéíóúâêôç...]+/

Mas não se desespere, pequeno gafanhoto. Existe um meio MUITO mais fácil! \o/

/[[:word:]]+/

Não é tão elegante quanto um simples "\w" (que não pega caracteres acentuados), mas é muito mais curto ^_^

Testa aí no IRB, e depois procura por POSIX bracket expressions na documentação do Regex do Ruby, tem mais coisas úteis lá (gosto muito do [[:upper:]]).