Softa

Aplicações Web 2.0 com Ruby on Rails e Postgres 

Primeiro Coding Dojo de Ruby do Ano.

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.

Rel

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)

 

 

Posted by Diogo Biazus 

Comments [0]

Site novo

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.


Diogo
Leo
(making of das fotos do site novo)

Posted by Juan Maiz 

Comments [1]

Rails3 no Heroku

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.

 

 

Posted by Juan Maiz 

Comments [2]

Configurando a replicação nativa do PostgreSQL 9.0

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.

 

Filed under  //   9.0   beta2   escravo   hot standby   mestre   postgresql   replicação   tutorial  
Posted by Diogo Biazus 

Comments [1]

Cloud Computing: o que é e suas desvantagens

Cloud Computing é uma das grandes buzzwords dos últimos tempos. É vendido quase como a solução de todos os problemas: oferece grande potencial de escalabilidade e ao mesmo tempo é verde e preserva o meio ambiente, o pessoal do marketing ta forçando um pouco a barra. 

Nos últimos tempos fizemos vários testes no Mailee.me e optamos por parar de usar cloud computing e voltar pro bom e velho servidor dedicado (bare metal). Resolvi então fazer um post com as desvantagens do cloud já que todo mundo por aí só fala das maravilhas dele.

Antes disso vamos entender o que é e como funciona. Tecnicamente o cloud computing é o que antes era chamado de VPS ou Virtual Private Server (em português alguns chamavam de servidor virtual), sem diferença nenhuma. Isso vem da virtualização (ou mais precisamente paravirtualização), um vps é um grande servidor dedicado que roda várias máquinas virtuais que são alugadas para os clientes. Só isso.

A grande diferença do cloud, na minha opinião (até porque não existe uma definição teórica disso), é o modelo de negocios: cloud computing é cobrado por hora, enquanto VPS é cobrado por mês. Uma novidade inserida pelo cloud é o provisionamento rápido e a api para integração, mas ambos os recursos são possíveis em VPS.

Em termos de arquitetura um datacenter de cloud computing nada mais é que um monte de servidores rodando máquinas virtuais e um sistema que gerencia em qual servidor físico colocar cada máquina virtual para aproveitar bem todas as máquinas físicas.

Bom, agora que sabemos que uma instância de cloud computing é uma máquina virtual, podemos falar das suas desvantagens. Antes que alguém venha me crucificar quero deixar claro que acho o cloud computing uma tecnologia muito legal e que é uma ótima escolha para a maioria das situações. Só que o objetivo do post é mostrar justamente as situações em que essa tecnologia não se encaixa.

O primeiro fator que o cloud deixa a desejar é quando há uma grande necessidade de I/O, um volume grande de leitura/escrita em disco. Como se está em uma máquina virtual, a taxa de leitura/escrita da máquina física é dividida entre todas as máquinas virtuais. Então mesmo que a máquina física tenha vários discos em RAID 10 ou RAID 5, não será possível conseguir uma alta taxa. E não me venha com benchmarks pois na maior parte das vezes os valores vistos na máquina virtual não são reais, são os valores da máquina física, ou seja a soma do uso de todas as máquinas virtuais, e não o que a sua máquina virtual está usando. 

Para aplicações web se encaixam nessa categoria principalmente servidores de bancos de dados. Seu desempenho está totalmente preso à taxa de I/O (a menos que o banco de dados caiba inteiro na memória ram do servidor). Envio de emails também cai nessa categoria, MTAs fazem muito uso de filas em disco. Em geral qualquer tipo de aplicação que precise manipular arquivos que ficam no disco gosta muito de I/O, e portanto não é boa para o cloud.

Um outro ponto em que o cloud computing deixa a desejar são aplicações que usem um grande volume de memória ram. Existe um barramento chamado FSB (front side bus) que determina a frequência (e a velocidade) de transferência de dados do processador para o northbridge. Por exemplo: um processador e placa-mãe que funcionem com um FSB de 8 bytes de largura (64 bits) a uma frequência de 1066 MHz e com 4 transferências por ciclo, teriam um limite teórico de 34.112 MB. Esse seria o valor máximo de dados que pode trafegar do processador para a memória por segundo. Numa máquina virtual estamos dividindo essa taxa com todas as outras máquinas virtuais do servidor físico, e se tivermos algum vizinho usando bastante ram isso pode incomodar.

É claro que essas diferenças só começam a aparecer quando o uso dos recursos é grande. Para aplicações simples que não consumam muitos recursos o cloud computing ainda é uma ótima escolha. Pra ilustrar deixo o link para um post no blog do Github. Eles tinham a infra toda provida pela Engine Yard, que agrega serviços em cima da infra estrutura cloud da Amazon e nesse post explicam a decisão de mover toda a sua infra pra servidores bare metal na Rackspace.

Filed under  //   bare metal   cloud computing   escalabilidade   gargalos   hospedagem   infra   infraestrutura   servidor dedicado   virtualização  
Posted by Pedro Axelrud 

Comments [1]

Diversão com Álgebra Relacional e Haskell

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

Filed under  //   algebra   haskell   postgres  
Posted by Diogo Biazus 

Comments [4]

Comparando a performance de implementações do Ruby (1.8 x 1.9 x JRuby x Rubinius)

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)

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.

 

Filed under  //   benchmark   jruby   mailee   performance   rubinius   ruby   testes   threads  
Posted by Diogo Biazus 

Comments [0]

testes ruby paralelos com o parallel_tests (com benchmarks)

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.

 
Hoje resolvi instalar o parallel_tests. A idéia é muito legal, ele roda um processo para cada núcleo de processamento, e divide os testes entre os processos. Além disso, ele soluciona o problema de locks e transações no banco de dados usando um banco para cada processo.
 
Esse é o resultado de uns benchmarks que eu fiz usando os testes do Mailee rodando em um Core 2 Duo 2.33 GHz e 3.2 GB de RAM.
 
rake test:functionals
    Finished in 223.114332 seconds.
 
rake "parallel:test[functional]"
    Took 131.64845 seconds
 
rake test:units
    Finished in 43.222583 seconds.
 
rake "parallel:test[unit]"
    Took 36.4595 seconds
 
Os testes de integração eu omiti pois só temos um teste, aí não tira vantagem.
 
É bem simples de usar, precisam só algumas mudancinhas:
- mudar o config/database.yml
test: database: xxx_test<%= ENV['TEST_ENV_NUMBER'] %>
create database xxx_test2;
É preciso criar até o banco número 4, caso a máquina seja quad core. 
Agora sempre que houver modificações no banco:
rake parallel:prepare
E pra rodar:
rake parallel:test
Ou pra rodar parte deles:
rake "parallel:test[functional]"
As aspas são porque o bash incomoda com [].

Posted by Pedro Axelrud 

Comments [0]

irb colorido e com histórico

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

Achei o wirble, que junto com o histórico traz: melhoria no autocomplete do tab, terminal colorido e mais alguns detalhezinhos.

Pra instalar é só dar um gem install wirble, e depois editar (ou criar) o ~/.irbrc adicionando as seguintes linhas: 

Filed under  //   irb   ruby   ruby on rails   wirble  
Posted by Pedro Axelrud 

Comments [0]

GLTail

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:

 

Posted by Juan Maiz 

Comments [0]