Softa

Esse post é para fazer uma retrospectiva do primeiro coding dojo de Ruby em Porto Alegre.

O dojo foi organizado pelo Cabral (@felipebcabral) aqui da Softa com o apoio do Carlos Villela (@cv) da ThoughtWorks Brasil e do Miguel Grazziotin (@Miguelgraz) do Dojo-POA (http://groups.google.com/group/dojo-poa). O problema foi escolhido e conduzido por este que vos escreve (@dbiazus).

Confesso que o problema escolhido não foi o mais adequado para um dojo, mas eu tive a melhor das intenções. A idéia era mostar para o pessoal uma estrutura clássica de implementação de linguagens de programação, a AST. A árvore abstrata de sintaxe (abstract syntax tree) é uma representação da estrutura sintática de código escrito em alguma linguagem formal.

O problema parece muito abstrato, mas foi inspirado por algo bem prático. A origem da idéia foi o post sobre a implementação do ARel, o motor relacional por trás da camada de banco de dados do Rails 3. O autor (@tenderlove) comenta que usando estruturas simples usadas em implementação de linguagens ele teve grandes ganhos no código utilizado. Então a idéia foi trazer parte desses conceitos para o dojo.

Imaginemos que queremos interpretar uma linguagem para manipular dados baseada em algebra relacional. Abaixo alguns exemplos de código:

Para interpretar o código faríamos um parser do zero, usando um pouco de expressões regulares. O resultado (para a primeira expressão do exemplo) deveria ser uma árvore em memória como a que está abaixo.

O pessoal que estava presente se saiu muito bem e chegamos a finalizar um analisador léxico e iniciar a parte de sintaxe, nada mal para um sábado de manhã. O código produzido está no meu perfil do github. Além disso fiquei muito contente pelo ambiente de desenvolvimento (com o meu editor favorito) ter ficado nos pontos positivos.

Abaixo os pontos positivos e nagativos levantados no final da manhã:

Pontos positivos:

• Café liberado pela TW
• Pãozinho de queijo show de bola
• Ambiente bacana
• Condução
• Autospec
• Ambiente de desenvolvimento (VIM)
• Horário
• Local de fácil acesso
• Bastante gente
• Almoço pós-dojo

Pontos negativos:

• Filtro de café pequeno
• Luminosidade da projeção
• O problema foi abstrato demais
• Ambiente de desenvolvimento (VIM)
• A quantidade de emails não lidos do Diogo
• Lembretes
• Notebooks (dispersão)

Olá! Hoje estamos lançando nosso site novo, agora mais informativo. Queremos mostrar um pouco mais o que pensamos e que tipo de empresa somos. O site será single page, com todas as informações na mesma página e cada parte com um visual diferente. O layout é do designer da casa, o Léo ‘no perdona errores’ Tartari.

O site celebra os 5 anos da Softa (na verdade contabilizados no início do ano, mas, sabe como é, o site fica sempre na parte de baixo da lista de prioridades =D). Quando começamos, éramos dois sócios: Diogo Biazus e eu, Juan Maiz. No início não tínhamos uma idéia específica do que fazer, mas sabíamos que era necessário empreender e criar uma empresa onde as pessoas fossem trabalhar motivadas. No nosso país o empreendedorismo ainda engatinha e a maioria dos profissionais busca trabalho no governo ou em grandes empresas, onde a grande quantidade de funcionários dilui as responsabilidades e a possibilidade de fazer a diferença individualmente. Nossas referências eram os textos de Paul Graham, E.F. Schumacher, Ricardo Semler e do pessoal da 37Signals, que recém havia lançado o Ruby on Rails.

Hoje somos 6 sócios, tendo entrado, nesta ordem, o Daniel Weinmann, o Pedro Axelrud, o Léo Tartari e o Felipe Cabral. Todos eles vieram agregar seus vastos conhecimentos em diversas áreas e estão ajudando a tornar a Softa uma empresa reconhecida pela qualidade, pelo atendimento primoroso e pela transparência e honestidade.

Nestes anos, desenvolvemos algumas dezenas de projetos, evoluímos bastante e lançamos nosso próprio produto, o Mailee.me, uma ferramenta de email marketing 2.0. Também contribuímos com a comunidade de tecnologia: organizamos o RS on Rails, apoiamos a PGCon e o FISL, fundamos o GURU-RS (Grupo de usuários Ruby do Rio Grande do Sul), palestramos em dezenas de eventos, realizamos um projeto no Google Summer of Code (através do Diogo, nosso expert em PostgreSQL), e agora estamos ajudando a organizar um grupo de Startups no estado.

O site irá ao ar ainda hoje. Fique atento ao hash tag #softa no Twitter.

Há algum tempo estamos colocando projetos no Heroku e estamos seriamente pensando em colocar novos projetos por lá, incluindo nosso novo site que está sendo produzido. Ocorre que para colocar uma aplicação Rails3, você precisa usar uma máquina virtual deles chamada "Bamboo". Veja os passos:

1. Criar sua aplicação Rails3 (suponho que você já tenha instalado o Rails3).

   rails new foo
   cd foo
   rails g controller Hello world

2. Cadastrar-se no heroku
3. Instalar o heroku

   gem install heroku    # Instala a gem do Heroku :D
   heroku list                # Lista suas aplicações lá. Isso só serve pra que você faça o primeiro login, pois ele vai te pedir email e senha.

4. Iniciar o repositório git e enviar

   git init                                                                     # inicia o repositório local
   git add .                                                                  # adiciona todos os arquivos. O Rails3 já gera um .gitignore :D
   git commit -a -m 'yo man!'                                        # comita tudo com a mensagem yo man
   heroku create --stack bamboo-ree-1.8.7 --remote foo  # cria um stack bamboo com ruby 1.8.7 com o nome "foo"
   git push foo master

5. Done.

   Aguarde a instalação da aplicação e copie o link que ele te apresenta. Acesse o link, mas com /hello/world

Feito! Se tiver dúvidas me contate via twitter no @joaomilho

Ah, no dia 4 de Agosto estarei falando sobre Rails3 (e se der tempo sobre Heroku tmb) na TargetTrust.

Como muitos já sabem o PostgreSQL 9.0 virá com um sistema de replicação nativo e as bases replicadas poderão receber comandos de leitura (hot standby). O interessante da replicação nativa é que ela é feita pelo log de transação, logo o custo para a máquina mestre é muito baixo, e o intervalo entre a efetivação das transações e a cópia destas é muito pequeno. Para ler em detalhes sobre como configurar a replicação já temos a documentação (em inglês) da nova versão. Mas aqui no blog vou mostrar um guia rápido (e em português) sobre como colocar no ar a replicação com o hot standby. 

Primeiro, baixar e instalar o segundo beta da versão 9.0. Os fontes podem ser obtidos em http://www.postgresql.org/ftp/source/v9.0beta2/. Para quem usa o MacPorts já existe um port chamado postgresql90. Para usuários de windows ou para quem preferir usar binários prontos a EnterpriseDB já disponibilizou o instalador de um clique em http://www.enterprisedb.com/products/pgdownload.do.

Após instalar o PostgreSQL 9.0 você vai precisar de duas instâncias do servidor para testar a replicação. Uma forma de fazer isso na mesma máquina é criando uma segunda pasta de dados e executando o serviço em uma porta diferente. Outra possibilidade é instalar em duas máquinas distintas e já testar pela rede mesmo. Nesse passo a passo vou fazer um exemplo com os dois serviços na mesma máquina.

Caso você queira repetir exatamente os passos que eu utilizei, disponibilizei abaixo um script de instalação do PostgreSQL 9.0 beta2 que pode ser executado diretamente na linha de comando com qualquer usuário que não seja o root. O script baixará os fontes e fará a instalação do PostgreSQL na pasta pgsql90 dentro da home do usuário que executá-lo:

Para informações sobre como configurar os serviços do PostgreSQL manualmente veja a documentação oficial (em inglês). 

Como já tenho um serviço do PostgreSQL escutando na porta 5432 vou usar as portas 5433 e 5434 para o mestre e para o escravo respectivamente. Antes de iniciar o mestre é importante configurá-lo para que ele possa enviar os logs de transação para o escravo. Para instalar e iniciar o serviço mestre já com as configurações necessárias criei outro script que pode ser copiado e colado no terminal:

Importante: os arquivos para replicar o log de transação são copiados para a pasta tmp, isso é uma configuração que só deve ser usada para pequenos testes na mesma máquina. 

O script irá bloquear o terminal e mostrar todas as mensagens na saída de erro padrão. Logo podemos manter esse terminal para ver as mensagens do servidor e abrir outro para prosseguir com o tutorial. Agora precisamos fazer uma réplica inicial do cluster de dados para usar como serviço "escravo".

Para iniciar a cópia devemos fazer usar o mecanismo de cópia que é utilizado para fazer o PITR, para mais informações veja a documentação em: http://www.postgresql.org/docs/9.0/static/continuous-archiving.html#BACKUP-PITR-RECOVERY

O script abaixo prepara a cópia escravo e já a inicia em modo de hot standby:

Pronto, se você chegou até aqui deve ter duas instâncias do PostgreSQL executando em sua máquina. As duas estão dentro da pasta pgsql90 na home do seu usuário. Uma na porta 5433 e outra na porta 5434. As duas aceitam conexões, mas a 5434 é somente para leitura. Se você conectar na 5433 e executar qualquer comando para modificar o estado do cluster o comando será quase imediatamente replicado para a instância na porta 5434.

Qualquer dúvida ou correção nos scripts podem deixar nos comentários.

Pessoal, a nova moda aqui na Softa é aprender Haskell. E tenho que confessar que a linguagem é bonita mesmo. Haskell foi mais fácil no começo do que eu imaginava (ok, eu imaginava um monstro). E logo consegui fazer algo bem divertido, um mapeamento de algebra relacional para SQL. Implementei duas operações, a projeção (projection) e a junção natural (natural join). O código é apenas um exercício de quem está aprendendo a linguagem, portanto críticas e sugestões são muito bem vindas, e até desejadas :)

Outro detalhe divertido é usar os operadores da Álgebra Relacional (com caracteres unicode), como no seguinte código no ghci (que assume a existência de uma base teste e dos drivers HDBC para o PostgreSQL):

Em primeiro lugar, nunca confie em testes de performance alheios por isso durante o post vou dar as ferramentas para que o leitor reproduza os testes no seu ambiente se assim o desejar. 

Em segundo lugar a minha intenção não era fazer um teste abrangente, mas sim detectar diferenças de performance em um recurso bem específico: threads.

Antes de simplesmente jogar os resultados dos testes na tela, vejamos o que me levou a eles.

Aqui na empresa o Mailee trabalha fortemente com execução concorrente de código. A versão atual do nosso software de entrega implementa a concorrência com threads. Já considerei diversas vezes a migração para uma arquitetura multi-processo, idéia que ainda não foi descartada. No entanto, atualmente o trabalho para migrar para processos parece maior que o benefício, o que me fez pensar em otimizar o código e procurar uma boa implementação de threads em Ruby.

Os testes e o ambiente:

Bom, aos testes. O ambiente de testes utilizado foi um MacBook com processador Core 2 Duo de 2.4 GHz executando o Mac OS X 10.5.8, os resultados são a média de 10 execuções.

Realizei um teste para multi-threading limitado pelo IO (I/O bound) e um para multi-threading limitado pela CPU (CPU bound). Cada teste foi executado inicialmente com apenas um thread, e depois aumentando a carga de trabalho linear e uniformemente até 10 threads simultâneos. Abaixo o código dos testes:

Resultados:

(download)

Click here to download:

comparando-a-performance-de-implementacoes-do-ruby-1-8-x-1-9-x-jruby-x-rubinius-GADbhEpyqpclkbwpdjbx.zip (104 KB)

Conclusões:

É curioso observar que embora o MRI 1.9.1 tenha melhorado drasticamente sua performance para os threads IO bound, quando o recurso é CPU ele fica parelho e um pouco pior comparado ao MRI 1.8.7.

A performance do jruby no teste de CPU me decepcionou, mas a lentidão pode ser relacionada a JVM do Mac OS X.

Pelos resultados apenas desses dois testes eu ficaria com o MRI 1.9.1 ou com o Rubinius. Mas é importante ressaltar que a versão 1.0 do Rubinius não é compatível com o Ruby 1.9, mas sim com o Ruby 1.8.

E não percam a seguir:

Ainda pretendo publicar um teste comparativo usando o conjunto de benchmarks diponível em http://github.com/acangiano/ruby-benchmark-suite, mas isso fica para um post futuro. No meu próximo post pretendo apresentar testes similares feitos com um código semelhante porém utilizando processos ao invés de threads.

O Mailee tem uma cobertura muito legal de testes, o que nos ajuda bastante na hora de refatorar código e implementar novos recursos. Mas estamos num ponto  em que os testes demoram muito pra rodar, e isso é bem chato.

test: database: xxx_test<%= ENV['TEST_ENV_NUMBER'] %>

create database xxx_test2;

rake parallel:prepare

rake parallel:test

rake "parallel:test[functional]"

Essa semana solucionei um detalhezinho que me incomodava um monte no irb, a falta de um histórico. 

Estamos testando a biblioteca gltail. Ela apresenta os logs da sua aplicação (rails, nginx, apache, postfix...) em uma interface unificada usando OpenGL. A implementação é bem fácil e ela consegue acessar os logs via SSH. Enjoy: