“How much does a choice of language really matter? Are there good reasons to choose one language over another or does it all come down to taste?”

E sua resposta foi:

“I think it matters quite a bit. A good language is opinionated, and strives to make a particular style of programming easy and idiomatic. It only seems a matter of taste when you are comparing languages that are more similar than they are different, like Java/C# or Python/Ruby. Try something really different like Clojure, Haskell, or Erlang and the fact that it matters becomes readily apparent.”

Eu acho que concordo bastante com sua opinião. Discutir se Java é melhor do que C#, por exemplo, é inútil, porque as duas linguagens são muito semelhantes. Nesse caso, o que acaba pesando mais na hora da escolha é o ecosistema no qual cada linguagem está inserida, que pode agradar mais a um ou a outro programador. É puro gosto.

O mesmo vale para Ruby e Python, como ele mesmo cita.

Mundos diferentes

Mas e se a comparação for entre Java e Ruby, por exemplo, como é que fica? Na minha humilde opinião, fica no sense. Porque Java e Ruby não são liguagens de mesma proposta; e mesmo sendo ambas de propósito geral, ambas tem objetivos claramente diferentes.

Comparação entre mundos diferentes

Agora vou, propositalmente, contradizer um pouco o que eu disse à cima: faz sentido, sim, você comparar Ruby com Java; Erlang com Python; F# com PHP. Sim, faz sentido.

Faz sentido quando você está escolhendo a linguagem que oferece a melhor solução para um dado domínio de problema.

Super CRUD com Erlang? Não, acho que não.

Precisar de concorrência massiva, tolerância a falhas, processos distribuídos, downtime mínimo? Humm, não sei não, mas será que não é de Erlang que você precisa?

Entende? É nessa hora que a escolha de uma linguagem começa a pesar de verdade. Isso realmente importa.

Mundos diferentes se complementam

Tempos atrás, escrevendo programas Erlang/OTP, senti falta de uma ferramenta que me ajudasse a criar rapidamente a estrutura inicial do projeto e umas coisas mais. O que fiz? Criei uma ferramenta que faz isso: otp_kickoff. Em Erlang? Não, em Ruby. Fiz isso em poucas horas, usando Thor.

Pouco tempo depois, senti falta de uma ferramenta de build amigável. Novamente, o que fiz? Criei o ebuilder, usando Ruby/Thor.

Um outro exemplo de mundos diferentes que se complementam é o JSparrow, um cliente de JMS bem fluente, que fiz usando JRuby.

Essa é a ideia de tirar o melhor de cada linguagem!

Mesmo porque, dificilmente, você constroi um sistema de verdade – que não seja um super CRUD – com apenas uma única linguagem de programação. Na minha equipe mesmo, há sistemas desenvolvidos em C# .NET, que são buildados, testados e deployados com Ruby/Rake/Cucumber e usam Java/Ivy como repositório de assemblies. Isso sem falar em JavaScript, que também tem de monte.

Esse é o mundo real dos sistemas de verdade.

Moral da história

Isso me faz pensar que brigas de fanboys de linguagens – em frenéticas buscas por prosélitos – são uma verdadeira piada.

Demorei um pouco, mas cá está, subi minha apresentação pro SlideShare.

O que achei do evento?

Achei o evento muito arretado, como de fato era sua proposta. (háh!)

Bem, mas sendo um pouco mais especifico, deixo um destaque especial para a organização do evento, que foi impecável; muito acima da média mesmo; o pessoal da comunidade lá de Natal está de parabéns. Annaysa Melo, Paulo Fagiani, Maximiliano Guerra e todos os demais, muito obrigado pela receptividade!

Presença da Locaweb

Esse ano, um coisa peculiar que rolou foi que, além de mim, outros quatro locawebers também palestraram: Fábio Kung, Nando Vieira, Rafael Rosa e Daniel Cukier. Me senti em casa!

Palestras

A maioria das palestras que assisti foram muito boas, em especial a do Tapajós que, como já era de se esperar, mandou super bem falando de CouchDB. Queria muito ter visto também a do CV, mas infelizmente não pude, porque palestramos no mesmo horário. Fica pra próxima.

A palestra do Geoffrey – com aquela voz de peepcoder – foi no mínimo divertida; mas a do José Valim acho que ficou devendo um pouco – talvez porque, IMHO, soou um tanto quanto marketing da Plataforma. Já a do Akita me surpreendeu. Nem tanto pelo conteúdo – apesar de indiscutivelmente relevante –, mas mais pelo formato e desenvoltura. Bem legal mesmo.

Não gostei da palestra do Carlos Brando, achei muito auto-ajuda; mas deixo um ponto positivo pro trecho de Assembly e C que ele codou ao vivo. Aliás, falando em codar ao vivo, a palestra do Nando foi muito boa, com seus slides super descolados e coloridos, mas ele não codou ao vivo. Tadinho do Murphy e sua lei, não paparam essa.

Dessa fez o Kung também não codou ao vivo, como de costume, mas sua palestra foi legal, bem contextualizada, dinâmica e totalmente #devops. Aliás, ela fez tanto sucesso que, depois de terminá-la, ele ficou um tempão trocando idéia e codando com a galera no open space.

Não pude ver a palestra do Rafael Rosa, meu colega de Locaweb, porque estava na do Hugo Baraúna sobre Project Rescue. Não gostei muito, pra ser sincero, então acabei ficando meio frustrado.

O Henrique Bastos deu um show de humildade, numa palestra que, sinceramente, eu não esperava muito do tema. Foi excelente. Já a palestra do Daniel Lopes, não gostei não. Gostei do Steak, que eu ainda não conhecia, mas achei a palestra dele meio bala de prata no que diz respeito a testes de aceitação.

A palestra do Vinícius Teles foi legal, mas como eu já tinha visto ele palestrar nos dois últimos anos, na Rails Summit, não foi muito novidade pra mim. Mesmo assim, uma boa palestra.

Nessa linha de empreendedorismo – também seguida pelo Rafael Lima –, o Alê Gomes, cara muito gente fina, fez uma apresentação meio reworkeana, mas mega divertida. Casquei o bico com ele.

Vi também a palestra da Thaís, falando sobre seu dia-a-dia no trabalho, comprometimento e respeito aos colegas. Foi legal.

E por fim, rolou um Q&A com todos os palestrantes, quando foi revelado que somente eu, Akita, CV e Juan Bernabó não terminamos a faculdade. Aliás, falando nesse Q&A, rapaz, como tem gente que gosta de falar, hein? Teve palestrante que pegou o microfone e não quis mais largar. Fiquei impressionado.

Balanço final

Valeu bastante a pena ter participado dessa conferência, em especial pelas discussões e bate-papos informais.

Ano que vem, quem sabe, nos vemos por lá outra vez!

Se você estiver por lá e quiser ver uma palestra nada técnica, logo depois do coffe-break, às 16:00, na sala B, vou falar sobre “gerenciamento de times auto-gerenciáveis”.

Uma introdução ao assunto da minha palestra são os posts:

• Tchau, tchau gerente, agora sou Scrum!
• Rápidos conselhos para gerentes humanos
• Você ainda acha que programação em par é desperdício?

Bem, aos poucos temos escrito sobre o evento (review, palestras, etc) no blog da Locaweb e também coloquei uma porção de fotos no meu Flickr.

Divirtam-se!

Um pequeno review

O evento foi muito bacana, teva ótima organização, boas palestras, tudo muito legal mesmo. Parabéns ao Danilo Sato, ao Hugo Corbucci, à Mariana Bravo e aos demais organizadores.

Palestras

As palestras foram boas, mas em geral não trouxeram nada de muito novo. Mesmo o keynote do Martin Fowler, que tocou no assunto de deploy contínuo, não trouxe nada de muito novo. O Guilherme Silveira, da Caelum, havia blogado em março e feito uma apresentação em maio sobre esse tema no evento Maré de Agilidade, em BH.

Gostei bastante do tutorial do Paulo Caroli, da ThoughtWorks, sobre Agile Card Wall; da palestra do Franscico Trindade, também da ThoughtWorks, sobre Coaching de Guerrilha; achei interessante a palestra do Manoel Pimentel, da Visão Ágil, sobre Coaching para Liderança de Equipes Ágeis, mas fiquei um pouco entediado com suas dinâmicas; e infelizmente, não pude ver o workshop do Rodrigo Yoshima, da Aspercom, e do Phillip Calçado, da ThoughtWorks, sobre Modelagem Ágil, porque eles baleiraram a sala!

O keynote do Klaus Wuestefeld foi bem divertido – feito no Notepad! – e, como sempre, subversivo!

Networking

Mas apesar das boas palestras, a parte mais interessante mesmo, na minha opinião, foram os papos informais nos intervalos das palestras, almoço e final do dia. Papos informais são uma excelente maneira de trocar experiências, ter insights e conhecer pessoas talentosas. Rolou de tudo: liderança de times ágeis, auto-gerenciamento, débito técnico, desafio de lidar com sistemas legados, gerenciamento de iterações, Kanban, métricas, e por aí vai. Muito proveitoso.

Dicas de reviews

Sugiro fortemente que você leia os reviews feitos pelo Rafael Rosa, um dos meus colegas de Locaweb que também estiveram por lá.

Outra dica de leitura é o review que o Alan, também da Locaweb, fez do curso de CSPO que ele fez na prévia da conferência.

A deixa final

Como já disse algumas vezes aqui no blog, em meus times, além de alguns legados, lidamos basicamente com Ruby on Rails, C#/ASP.NET MVC e Git como DVCS. Então, além de um bom editor de textos e um terminal, precisamos também de um Visual Studio – com ReSharper, porque sem isso, ele não é nada – que, infelizmente, para usuários de Mac e Linux, só roda em Windows. Tentei resolver isso usando Mono, mas acabei desistindo – por enquanto, porque vai ter revanche!

Bem, resolvi então usar o Parallels Desktop 5 para rodar o Visual Studio 2010 no conforto do meu Mac e, de tabela, adicionar mais um monitor à minha área de trabalho.

Meu space de programação

Pra mim ficou fantástico! Porque no meu space de programação deixei o Visual Studio maximizado na tela grande (à esquerda), rodando no Windows, que por sua vez está rodando no Parallels Desktop, em tela cheia e com look & feel de Mac OS X; e na tela do Mac (à direita) – que eu adoro! –, deixei o terminal, onde posso interagir com o Git e tudo mais. Yay!

Visual Studio 2010 no Windows (à esquerda); Terminal no Mac OS X (à direita)

E tem mais: quando não precisar usar o Visual Studio por um longo tempo, tenho duas alternativas:

- desligar o Windows;
- ou simplesmente pausá-lo no Parallels Desktop.

E se for o caso, arrastar o TextMate pra tela grande.

Ficou muito bom isso, o Parallels Desktop é demais!

Meus outros spaces

Uma área de trabalho dessas não serve só pra programação. Hoje mesmo precisava editar um wiki enquanto olhava dados em uma planilha. Sem problemas! Planilha na tela grande e wiki sendo editado na tela do Mac. Fantástico!

Só faz um dia que estou com essa área de trabalho expandida e sinto que não posso mais trabalhar sem ela. hehehe

Bem, dessa brincadeira saiu o módulo system_info, que você pode conferir no meu GitHub, no projeto de estudo getting_system_info.

O que ele faz?

Basicamente, ele oferece informações de load da máquina, quantidade de processos rodando e uso de memória do nó atual ou do cluster. Você pode ter mais detalhes sobre o formato dessas informações dando uma olhada nos testes do projeto.

Qual a utilidade disso?

Como disse, escrevi esse código depois de me lembrar do post do Krzysztof Kliś sobre seu load balancer [de apenas 48 linha]. Escrevi por pura diversão.

Mas, sim, se amanhã ou depois eu precisar escrever algum load balancer ou aplicativo que monitore load, processos e memória do meu cluster, ele poderá me servir de helper.

Dá pra testar e ver se funciona?

Sim, a menos que você seja usuário de Windows. Não, não é preconceito, é que algumas funções que uso não estão disponíveis pra Windows, apenas pra sistemas operacionais Unix-like.

Você pode fazer isso de duas maneiras:

1- Rodando os testes

Clone o projeto – o único problema é que você vai levar uma porção de outros projetos de brinde. I’m sorry! – e em seu diretório raíz, compile e rode os testes.

$ ./compile.sh
$ ./test.sh

Só que dessa maneira você não consegue ver nenhuma informação útil. Vamos à segunda maneira.

2- Rodando as funções no Eshell

Depois de devidamente clonado e compilado, crie um cluster com três nós. (Se não souber como a arquitetura de cluster de runtimes Erlang funciona, tenho um post introdutório pra você.)

Na raíz do projeto:

a. Inicie três nós, um em cada terminal

$ erl -sname n1 -pa ebin/

$ erl -sname n2 -pa ebin/

$ erl -sname n3 -pa ebin/

b. No n1, estabeleça conexão entre os nós

(n1@codezone)1> net_kernel:connect('n2@codezone').
(n1@codezone)2> net_kernel:connect('n3@codezone').

Agora, todos os três nós estão conectados uns aos outros, já que, por padrão, os nós compartilham suas conexões uns com os outros.

c. Ainda no n1, verifique as informações de system_info

(n1@codezone)3> system_info:node_load().
(n1@codezone)4> system_info:cluster_load().
(n1@codezone)5> system_info:node_processes().
(n1@codezone)6> system_info:cluster_processes().
(n1@codezone)7> system_info:node_memory().
(n1@codezone)8> system_info:cluster_memory().

Agora, sim, você tem informações a valer!

Gostou?

Espero que sim, porque system_info pode te dizer coisas legais. =)

O mais simples do mundo

Pra começar, vamos ver o exemplo mais simples de computação distribuída que se pode fazer e aprender alguma coisa com ele. Ele é como um simples chat. Pois muito bem, vejamos!

Fazendo o setup

No terminal, inicie um Eshell com o seguinte comando:

$ erl -sname jose

E num outro terminal, inicie outro Eshell com:

$ erl -sname maria

Agora vá no primeiro terminal, no Eshell do José, e execute o seguinte comando:

(jose@codezone)1> register(console_jose, self()).

E no segundo terminal, no Eshell da Maria, faça o mesmo:

(maria@codezone)1> register(console_maria, self()).

Tudo bem, setup feito, hora do bate-papo!

Jogando conversa fora

“Ei José, diga oi…”

(jose@codezone)2> {console_maria, 'maria@codezone'} ! "Oi Maria, tudo bem?".

Veja o terminal da Maria. O que aconteceu? Nada? A mensagem não chegou? Chegou, chegou sim. Vejamos:

(maria@codezone)2> regs().

Na primeira coluna, procure pelo processo console_maria. Achou? Agora veja na última coluna desse processo. Que número tem aí? 1? Pois é, isso nos indica uma coisa. Ainda nesse Eshell, execute o seguinte comando:

(maria@codezone)3> flush().

Opa! E agora? Shell got “Oi Maria, tudo bem?”, certo? Taí a mensagem que a Maria recebeu do José.

Agora, que tal a Maria ser gentil com o José e responde-lo cordialmente?

(maria@codezone)4> {console_jose, 'jose@codezone'} ! "Vou bem, e voce?".

Se você quiser, pode ver o registro de processos no Eshell do José, como fez anteriormente com o da Maria. Ou pode simplesmente:

(jose@codezone)3> flush().

E receber a mensagem Shell got “Vou bem, e voce?”.

Entendendo tudo isso

Por sorte, não há muito o que explicar até aqui – já que fizemos o exemplo mais simples do mundo. Uff!

Que tal começar do começo? Vamos entender os passos de setup?

1- A primeira coisa que fizemos foi iniciar dois Eshell que, na verdade, tornaram-se dois nós do nosso cluster de runtimes Erlang.

Todas as vezes que você inicia um Eshell com a flag -sname, o que você está fazendo é criar um nó de runtime Erlang na sua rede. Na verdade, isso pode ser feito também com a flag -name.

Qual a diferença entre elas?

-sname cria o nó e dá a ele um “short name”: nome_do_no@host;
-name, pelo contrário, cria o nó dá a ele um “long name”: nome_do_no@ip_address ou nome_do_no@host.local, no caso de rede local.

Você pode perfeitamente iniciar diversos nós em uma mesma máquina, como fizemos a pouco. No entanto, você não pode duplicar os nomes dos nós, uma vez que estes são usados para identificá-los no cluster e torná-los comunicáveis uns com os outros.

“Lembrando que o nome dos nós são sempre sufixados pelo nome/ip do host, não há problema algum em ter o mesmo nome de nó em máquinas diferentes.”

Uma outra coisa interessante de aprender aqui é como os nós se comunicam. Toda comunicação entre nós é feita por um daemon chamado epmd. Este programa faz parte do sistema de runtime Erlang e tem um papel fundamental em sua arquitetura de clusters, porque sempre que “o primeiro nó” é iniciado numa máquina, automaticamente, ele também é iniciado, caso ainda não tenha sido, e passa a escutar mensagens na porta 4369 e rotea-las para o nó apropriado.

“Independente de quantos nós estejam rodando numa máquina, sempre haverá apenas uma instância do epmd rodando.”

Por fim, ainda sobre o setup dos nós do cluster, há uma outra flag que não demonstrei no exemplo acima, mas que é bem interessante e você depois pode pesquisar a respeito.

-setcookie define um “secret cookie” que serve como um tipo de token para autenticar a comunicação entre os nós do cluster. Isso quer dizer que, somente os nós iniciados com um mesmo cookie podem se comunicar. Por outro lado, sempre que um nó é iniciado sem especificar um cookie, o runtime Erlang toma a liberdade de cria um e gravar no arquivo ~/.erlang.cookie. Nestes casos, todos os nós não iniciados com um cookie compartilharão o mesmo cookie guardado nesse arquivo.

No caso do nosso exemplo ultra simples, um cookie poderia ser usado para criar uma sala de bate-papo, onde: se um nós é iniciado informando um cookie, ele entra na sala equivalente; no entanto, quando não informado, vai para uma sala genérica.

Interessante? Pois é… E esse assunto acaba puxando o da flag -hidden, que você pode aproveitar e pesquisar também.

2- A segunda coisa que fizemos no setup foi registrar um processo alvo de nossas mensagens.

Como a idéia aqui é explicar – um pouco, porque ainda há uma porção de coisas que poderiam ser faladas, mas isso deixaria esse post imenso! Dê uma olhada na documentação oficial – como funciona a arquitetura de cluster de runtimes Erlang e mostrar como este provê uma maneira simples de programação distribuída, preferi não escrever um programa de chat, mas apenas usar o próprio Eshell para isso.

Com este pré-requisito em mente, o que fiz foi apenas registrar o próprio processo do Eshell – usando self(), que você entende como funciona – com um nome especifico em cada nó do cluster (console_jose para um e console_maria em o outro) para fazer a troca de mensagens entre eles.

E o bate-papo, como é que rolou?

Essa é a parte mais fácil da coisa, na minha opinião. Se você já lidou com processos em Erlang, vai tirar de letra.

1- Trocamos mensagens entre os dois processos de maneira bem semelhante ao que fazemos normalmente com processos contidos num único runtime.

A única diferença aqui é que, em vez de simplesmente codarmos algo como console_jose ! “Show de bola”, codamos {console_jose, ‘jose@codezone’} ! “Show de bola”. Ou seja, além no nome do processo, informamos também em que nó do cluster ele está, tudo em uma tupla.

Um exercício legal de você fazer é o seguinte…

a. No Eshell da Maria execute:

(maria@codezone)5> console_maria ! "Show de bola".
(maria@codezone)6> flush().

b. Depois, ainda no Eshell dela, execute:

(maria@codezone)7> console_jose ! "Show de bola".

O que aconteceu? Na primeira execução, o Eshell da Maria recebeu uma mensagem, correto? Mas na segunda execução, o Eshell “crasheou”. Por quê? Porque ele não reconheceu o átomo console_jose como sendo o nome de um processo, uma vez que o processo registrado como console_jose está em outro nó do cluster. Aliás, como o Eshell da Maria crasheou, se você tentar enviar mensagens a ele novamente, como fez anteriormente e havia funcionado, ele vai crashear novamente, porque a referência ao processo que havia sido registrada tornou-se inválida.

Você precisa ficar muito atento a isso, porque quando você manda um mensagem para um processo que está em outro nó, mesmo que ele não exista, você não receberá erro – exatamente como acontece com envio de mensagens pra processos locais inexistentes.

Quer ver? Faça o seguinte teste:

(maria@codezone)8> {console_jose_123, 'jose_abc@codezone_xyz'} ! "Nao vai crashear".

E agora, o que aconteceu? Nada!

2- Outra coisa que fizemos foi usar os truques de flush() e regs(), mas esses já são bem conhecidos.

Se você costuma usar o Eshell, com certeza, já deve ter usado flush() e regs(). Caso ainda não tenha usado, aqui vai um resumo:

- flush() descarrega as mensagens contidas na caixa postal do Eshell (que como você sabe, nada mais é do que um processo Erlang qualquer);
- regs() lista os processos registrados do runtime em execução.

Só o gostinho

Como disse em algum canto nesse post, ainda há bastante o que falar sobre programação distribuída com Erlang. Só pra variar, esse post foi só pra dar o gostinho. Ainda há muito mais!

Bem, quem sabe qualquer dia desses não perco o sono novamente e escrevo um pouco mais sobre o assunto. Quem sabe?

Qual a idéia dessa palestra?

Bem, nem só de acertos vive um agilista – os contadores de “case”, sim; os agilistas, não. Aliás, pelo contrário, frequentemente aprendemos mais com nossos erros do que acerto. Porque muitas vezes nossos acertos são frutos de pura sorte e sequer conseguimos reproduzi-los novamente.

Dito isto, minha palestra não é sobre “dar carrinho” nos amigos que estiveram comigo nessa experiência, nem apontar culpados ou citar nomes. Não! Minha palestra é sobre apontar erros que cometemos – óbvio, querendo acertar; é sobre lições aprendidas – boas e ruins.

Essa apresentação é a visão e opinião de todos?

Não sei exatamente. Vou falar única e exclusivamente da minha visão e opinião sobre os fatos.

Que mais?

Nos vemos lá, ué! \o/

“Ela sugere que todo e qualquer código produzido no projeto seja sempre implementado por duas pessoas juntas, diante do mesmo computador, revezando-se no teclado.

À primeira vista, a programação em par parece ser uma prática fadada ao fracasso e ao desperdício. Afinal, embora possa haver benefícios, temos a impressão de que ela irá consumir mais recursos ou irá elevar o tempo do desenvolvimento. Entretanto, não é exatamente isso o que ocorre.”

Não, não é isso mesmo!

Nossa experiência

Há quatro meses decidimos, de uma vez por todas, levarmos realmente à sério esse negócio de programação em par aqui nos times de desenvolvimento dos sistemas centrais da Locaweb. De imeditato, optamos pelo caminho mais eficaz: reduzimos pela metade o número de máquinas dos times. Sim, quase que do dia para a noite, passamos a ter apenas e  tão-somente uma máquina para cada dois desenvolvedores.

Estações de pareamento: como é que é isso?

Desde que fizemos a redução de 50% de nossas estações de trabalho, passamos a ter as chamadas estações de pareamento, máquinas destinadas exclusivamente para trabalho.

Estações de pareamento precisam ter:

- usuário genérico para login;
- script para settar no git o dupla atual;
- configuração padrão de desktop, diretórios e ferramentas;
- apenas o instante messager de trabalho;
- apenas o cliente de e-mail de trabalho;
- acesso total à Internet;
- idealmente: 2 teclados, 2 mouses e 2 monitores (grandes!).

Mas não devem ter:

- arquivos pessoais;
- programas de distração.

Bem, não está diretamente associado ao modelo de estações de pareamento, mas é bem importante também que as duplas tenham ao seu lado o monitor da integração contínua de seu time, para ter sempre à vista o feedback dos builds. No nosso caso, temos monitores suspensos como o que pode ser visto na foto ao lado – de preferência, sempre verdinhos!

Estação de relax: tem isso, é?

Junto com a idéia das estações de pareamento também adotamos a idéia de estação de relax. Atualmente temos apenas uma, dado o tamanho de nossa equipe.

A estação de relax é uma máquina com acesso total à Internet para a galera relaxar um pouco durante a jornada de trabalho, acessar e-mail pessoal, redes sociais, internet banking, enfim, o que quiserem e bem entenderem. Acesso total à qualquer hora do dia!

O que temos colhido com isso?

Até agora só ganhamos! Ganhamos produtividade, qualidade, propriedade coletiva de código, padronização, e por aí vai.

Desperdício isso? Não, acho com certeza não.