Softa

Há algum tempo estamos colocando projetos no Heroku e estamos sériamente 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.

Loading mentions Retweet

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.

Loading mentions Retweet

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):

Loading mentions Retweet

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:

   

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.

Loading mentions Retweet

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.

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

1 create database xxx_test2;

1 rake parallel:prepare

1 rake parallel:test

1 rake "parallel:test[functional]"

Loading mentions Retweet

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

Loading mentions Retweet

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:

Loading mentions Retweet

Para quem precisar publiquei no github o date range picker originalmente do filamentgroup traduzido. A diferença dele pro date picker do jQueryUI é que você pode escolher um período e não apenas uma data. Além disso ele tem uma série de atalhos, como "Hoje", "Ontem" e "últimos 7 dias".

O original está aqui:
http://www.filamentgroup.com/lab/update_date_range_picker_with_jquery_ui/

O traduzido aqui:
http://github.com/softa/Jquery-Date-Range-Picker-pt-br

Uso:
Olhe o arquivo demo.html que possui todas as dependências. O código é simples assim:

Veja em ação:

Loading mentions Retweet

Aconteceu em 15.12.09 mais um encontro do Coding Dojo. Para quem se pergunta o que é: dojo (do=caminho, jo=lugar da prática) é o lugar onde se prática a disciplina. Nesse caso, a codificação, o desenvolvimento de linguagens e a troca de tecnologia. Este é o caminho escolhido.

A idéia foi criada porque os desenvolvedores são focados em trabalho e pesquisa, mas não tem um espaço de prática e/ou troca entre pares. Utilizando a metodologia dos dojos de artes marciais (ou o modelo que eles deveriam seguir). Compreendendo a ausência de competição, apoio mútuo, colaboração e diversão no aprendizado. A inclusão é realizada através do recebimento de todos níveis de programadores, até de quem não programa. Todos são convidados a participar do randori ou kake, que são programações realizadas em duplas que trocam constantemente. Se você não sabe nada, terá apoio do Sensei/Senpai(responsável pelo dojo), colegas, platéia, co-piloto(aite),etc.

Se você é programador, vale a pena! Vale a pena a troca de experiência, conhecer pessoas, métodos, tecnologias, linguagens novas. Se você é não é, vale a pena! Pelo método, pelo ambiente, pela diversão, pelo aprendizado de coisas novas.

Aprender coisas novas ou apenas exercitar não é a única coisa que o dojo oferece. Também a oportunidade de se expor, colocar o ego de lado e ir até o pc e tentar, mais nada além do que tentar. Você pode não conseguir nada, mas isso será só em matéria de código. Sempre se aprende alguma coisa quando nós nos expomos e é melhor ainda em um ambiente completamente salutar como o tatame macio de um coding dojo.

E no final….PIZZA! Por conta da Locaweb, organizadora do evento.

Comunidade do RS : http://groups.google.com/group/dojo-tche?pli=1

Coding dojo, regras e princípios: http://codingdojo.org/

Locaweb: http://www.locaweb.com.br

Loading mentions Retweet