Nossa empresa está passando por várias mudanças e nas próximas semanas teremos algumas novidades, mas ainda não é esta a razão deste post. Este post é sobre os próximos cursos na Egenial que começam na semana que vem.

No ano passado nossa parceria com a Egenial se estreitou um pouco mais já que a empresa está voltando suas atenções em massa para a comunidade de software Brasileira. Eu (Daniel) acabei sendo convidado para dar uma mão nessa empreitada.

Nos últimos dias tivemos o mega sucesso que foi o RubyMasters, com mais de 270 inscritos e com 12horas de palestra (que também teremos um post a parte). Agora a novidade é que na semana que vem teremos 3 cursos iniciando e as matrículas ainda estão abertas.

Ruby on Rails

Ruby on Rails do Básico ao Avançado comigo como instrutor. Essa é a minha 12 turma na Egenial e a minha 8 só em Ruby/Rails. Ao longo dos últimos anos fui refinando os exemplos deste curso e acho que chegamos no ponto perfeito. São 22 horas de aula onde passamos desde o básico de Ruby e vamos construindo uma aplicativo real em Rails. O aplicativo é tão próximo de um projeto real que eu mesmo uso como referência várias vezes no meu desenvolvimento diário em Rails 3.0.

Neste curso eu tento cobrir tudo que é fundamental para o cotidiano de um Railer. Veja a grade detalhada no site: http://www.egenial.com.br/cursorails

GIT

Git revolucionou o mercado de desenvolvimento opensource e comercial. Chega a ser impossível pensar como era o desenvolvimento com equipe remota ou em projetos opensource antes do GIT. É o tipo de ferramenta que é praticamente impossível contestar seu valor mesmo trabalhando sozinho e sem equipe nenhuma.

Uma das coisas que mais me motiva em continuar envolvido com a comunidade Rails é que é um local onde as coisas novas sempre acontecem muito rápido e isso foi bem marcante com GIT. Boas práticas surgem e se tornam leis na comunidade Rails e GIT é uma dessas leis.

Sem exceção, todos os projetos opensource são versionados com GIT e a grande maioria dos projetos privados também. Isso ocorre por uma única razão: GIT é fantástico.

Uma tecnologia com dezenas de benefícios como sua organização descentralizada incrível para trabalho em equipes, um modelo de armazenamento que reduz drasticamente o tamanho dos repositórios e sua simplicidade que o torna acessível para qualquer pessoa.

Por essas razão a Egenial tem tentado levantar um curso de GIT realmente prático e aprofundado tem bastante tempo. Finalmente conseguimos. Em Março, Arthur Zapparoli vai ministrar um curso de 16h ensinando desde o básico da ferramenta até os detalhes mais profundos como Cherry Pick, Rebase, Object Model, Bisect, Gitosis e muito mais.

Essa é a sua chance de dominar o GIT: http://www.egenial.com.br/git

FlashPlataform – Flex4

Outro curso que também começa na semana que vem é o FlashPlataform Flex4. Um curso totalmente reformulado para cobrir as novas ferramentas criadas pela Adobe e o mais legal que o instrutor será Fábio Vedovelli. Figurinha carimbada do mundo Flex e com uma excelente didática.

Ultimamente tenho participado muito pouco da comunidade Flex o que não indica que ainda não utilizo e utilizarei estas ferramentas se for necessário. É preciso ser pragmático e para muito objetivos Flash/Flex ainda são imbatíveis e são as melhores soluções do mercado.

Soluções como o próprio TreinaTom ainda são impossíveis de serem implementadas da forma correta sem essas tecnologias. Jogos, interatividade que envolve gráficos 2D/3D de forma compatível com todos os browsers, multimídia, compatibilidade com API de escrita e leitura de arquivos pelo browser, desenvolvimento desktop usando o mesmo código web e muitas outras vantagens que só a Plataforma Flash consegue atender hoje em dia.

Se você precisa dessas soluções então esse curso é o que faltava para complementar o seu toolkit.

Não perca tempo e conheça: http://www.egenial.com.br/flashplatformweb

Talvez algumas pessoas não saibam mas no fim ano passado eu assumi uma parceria com a eGenial para colaborar mais na parte de cursos da empresa e principalmente ajudar em iniciativas para as comunidades de software (não apenas em Ruby).

E em 2011 teremos um primeiro semestre bem agitado, abrindo o ano com um evento de alto nível. A eGenial está promovendo o RubyMasters nos dias 25 e 26 através do Treinatom (a mesma plataforma usada para os cursos).

A idéia do evento surgiu a partir dos eventos beneficentes que a empresa realiza todos os anos. Nos eventos Rails For Kids e Flex For Kids toda a renda levantada é repassada para instituições de caridade, o que sempre deu muito certo e vamos continuar realizando estes evento em 2011. Mas também achamos que já é hora de agradecer, de forma simbólica, projetos da comunidade Ruby que são mantidos com tanto profissionalismo e que tornam nosso dia-a-dia bem mais divertido.

Assim criamos o RubyMasters com o objetivo de compartilhar conhecimento de alto nível e ainda repassar toda a renda levantada com inscrições e apoios para projetos OpenSource da comunidade Ruby.

Escolhemos dois projetos que são muito importantes para todos: RubyInstaller e Phusion Passenger. Ambos os projetos aceitam doações como forma de incentivo.

Nós não conseguiríamos fazer com que toda a audiência do evento escrevesse código, documentação e contribuísse ativamente mas conseguimos levantar fundos através das doações como um forma de agradecimento ao trabalho fantástico que essas pessoas fizeram. Então, toda a renda levantada será repassada para os responsáveis pelos projetos, ajudando a custear as necessidades que os projetos venham a ter.

Os participantes podem escolher quanto querem pagar para assistir as palestras (entre R$35,00 e R$55,00) e após o evento terão acesso as gravações além de concorrer a bolsas de estudo da eGenial e outros brindes do Peepcode e PragProg.

O evento será executado em dois dias começando as 9:00 e terminando por volta das 16:00 com 12 palestrantes falando dos temas mais atuais do mundo Ruby. Você pode conferir a grade palestras no site do evento

Estamos contando com a sua participação e também com seu apoio na divulgação. Nesta página do evento você encontra como pode ajudar na divulgação .

Desenvolver software e aplicações web é mais do que apenas escrever código. Por isso, a Locaweb e a e-Genial fecharam uma parceria para que você possa aprimorar suas qualificações profissionais.

Em mais uma edição do curso Imersão Sys Deploy, você vai aprender o que precisa para se tornar um sys admin: desde configurar um servidor web do zero até colocar uma aplicação Ruby on Rails em produção. Tudo isso através de exemplos práticos, aplicados em um Cloud Server Pro exclusivo por aluno.

O curso é 100% online. Você aprende e pratica em tempo real, sem sair de casa ou da empresa, em uma sala de aula virtual, que permite total interatividade entre o instrutor e os alunos exatamente como um treinamento presencial.

Ficou interessado e quer participar? Confira mais detalhes sobre o curso no site da e-Genial

Aproveite para seguir a @egenial e a @locaweb no Twitter – você pode ganhar uma inscrição para este curso! Fique ligado nas promoções desta semana.

Nesta semana que passou estive na RubyConf Brasil. Um excelente evento, sinceramente eu não tenho nada a reclamar, só tenho elogios para o Fábio Akita e a Locaweb (na verdade 2 palestras me incomodaram, mas isso não tem relação com a organização).

Apesar do evento ter sido fantástico sempre existem reclamação. E este ano a reclamação ficou em dois pontos, wifi inexistente e projetores.

Reclamando do WIFI

A primeira reclamação eu acho totalmente sem sentido, já que o único motivo para eu ir aos eventos é assistir palestras e conversar com as pessoas. Internet eu tenho no escritório e para urgências o 3G do meu iPhone atende perfeitamente.

Eu não consigo prestar atenção em duas coisas e notebook/ipad durante as palestras me distrai. Por isso já nem levo notebook mais quando não vou palestrar. Então não dou a mínima para internet e sinceramente acho que os eventos já deveriam anunciar que não vai ter internet, assim ninguém reclama.

Reclamando dos Projetores

Os palestrantes reclamarem dos projetos acho que faz um pouco de sentido, mas só um pouco.

Seria muito legal a organização deixar tudo regulado mas qualquer palestrante sabe que organizar um evento é um trabalho colossal e se você quer que sua palestra corra bem não é bom depender de pontas que a organização pode ter deixado passar (isso é totalmente aceitável e esperado).

Mais uma vez: não culpe a organização pelo projetor, culpe a si mesmo. Em um evento o mais importante é ter gente na platéia (quanto mais melhor) e o projetor é uma coisa mínima. Você se propôs a palestrar, então deve ter um plano de contingência para essas situações.

Acho que nos últimos 3 anos acumulei algumas horas de palestras e também umas 300 horas de aula. O legal (ou nem tanto) é que deu tempo para muita coisa dar errado e algumas darem certo.

Meu amigo Carlos Eduardo da e-Genial sabe como a minha primeira aula de Flex em 2007 foi ridícula, um fiasco total (obrigado por não ter me demitido de imediato .

Então aprendi algumas coisas que tento seguir em meus cursos e palestras. Talvez isso possa ser útil para você também.

Palestras/Aulas Online

Uma palestra presencial é completamente diferente de uma palestra online.

Online você tem mais controle do seu ambiente e não depende de microfone e projetor. Assim você pode usar qualquer cor nos seus slides e tudo vai aparecer perfeito (isso se a ferramenta for boa como o Treinatom).

Por outro lado aprendi quem em eventos online você tem que falar bem mais e com muito menos pausa que eventos presenciais, do contrário as pessoas começam a ficar cansadas (nesse caso, é melhor você ficar cansado do que a platéia).

Não cometa erros online. Um erro online tem uma proporção muito maior e sua credibilidade vai pelo espaço muito mais rápido. Cinco minutos encontrando um bug ao vivo não parece nada, online é uma eternidade.

Palestras Presenciais em Eventos

Ao presencial as coisas são bem diferentes e como não é possível ter controle nenhum do ambiente sempre tomo alguns cuidados.

A primeira coisa é a resolução, raramente encontro projetores com resolução de 1024 ou superior, então sempre uso 800×600 nos slides.

A segunda coisa é a calibragem do monitor. Sempre que plugo meu Mac no projetor vou em System Preferences/Displays/Color escolho o sugerido pelo S.O. (as vezes ajusto manualmente o perfil também).

A terceira coisa é em relação ao contraste dos slides. Como você não tem controle da iluminação é bom criar seus slides com bastante contraste entre o conteúdo e o fundo. Não precisa tirar os efeitos e usar slide branco com texto preto, só cuidar do contraste. Sempre uso dezenas de transições, efeitos e as vezes desenho meu próprios ícones para os slides mas fico atento para que o conteúdo contraste bastante do fundo.

A quarta coisa que sempre tomo cuidado é com a centralização. Nunca espero que o projetor esteja alinhado (nunca está), então coloco tudo centralizado. Se vai ter código coloque-o em um box mais para o centro do slide. A mesma coisa para vídeos, deixe-os centralizados.

Use fontes grandes no seu código, com fundo branco e texto com muito contraste. Eu também uso o Copy as RTF no Textmate para colar código no Keynote.

Outra coisa é que não importa o que aconteça, em um evento grande eu não passo do tempo de forma alguma. Acho uma falta de respeito um palestrante atrasar o evento todo porque não preparou sua palestra direito (a final de contas foi você aceitou o convite ou enviou uma proposta).

Para evitar problemas com tempo eu sempre uso o “Presenter Display” do Keynote do Mac. Nele você vai ver o próximo slide e o tempo gasto (acho isso fundamental).

Caso você plug seu Mac e não apareça “Presenter Display” basta ir em System Preferences/Displays e “des-espelhar” os monitores. Se os monitores ficarem trocados bastar arrastar o menu para o que você deseja que seja o primário (como abaixo).

Live Coding

Live Coding é um caso a parte pois é uma fonte gigante de problemas. Parta do princípio que você vai errar tudo ao vivo, mesmo que seja o criador do Rails você vai errar uma demo com ele!

Nas aulas online eu sempre tenho um guia para seguir. Em aulas presenciais normalmente levo um papel e coloco em cima da mesa, não tem nada de errado em levar um cola. Mas não escreva uma bíblia na cola pois você se “ferrar” da mesma forma, a cola é para você saber a ordem do que fazer e não para aprender as coisas ao vivo.

Abaixo a minha cola para o curso de 6h do Fisl:

Se for uma palestra de 50 minutos então não faça live-coding, prefira um vídeo. Você não vai querer atrasar o resto da sua palestra se demorar de mais em algum ponto do código.

Para gravar os vídeos eu uso o ScreenFlow e gravo com voz. Depois removo a voz e refaço o vídeo algumas vezes, dessa forma vou saber exatamente a ordem das coisas no vídeo.

Caso você não tenha como gravar um vídeo então treine o que será mostrado várias vezes. Não tem nada mais frustrante do que cometer um erro para um auditório que não te conhece.

Palestras são diferentes de aulas e a por padrão a platéia é totalmente cética com você e com o seu tema. Você precisa ser convincente, se passar um bug e não conseguir resolver (rápido), vai pairar aquele pensamento de “hehehe, se F*eu” ou “iiih, isso não é lá grandes coisas”.

Outra coisa que é muito importante em live-coding é o tema do seu editor, como eu já disse anteriormente. Use sempre fundo branco mas caso você tenha feito um vídeo e mesmo com fundo branco e fonte grande não tiver dado certo tente inverter as cores com Ctrl+Option+Command+8.

Síndrome da Faculdade

Em computação não tem nada mais comum do que pessoas tendo se mostrar inteligentes. Ninguém vai assistir uma palestra querendo saber como você é inteligente e “bomzão”. Ninguém quer saber se você sabe 20 linguagens ou sabe “zilhões” de termos técnicos. Você não tem que se mostrar inteligente para um professor.

Não digite “zilhões” de coisas rápido de mais, não faça scroll do código para cima e para baixo, não grite ou fale correndo de mais. Se vai digitar algo ao vivo explique cada coisa que está digitando e com bastante calma, a final de contas você sabe o que está fazendo mas as pessoas não.

As pessoas assistem uma palestra para aprender algo e não estão nem aí para o que você é. Então foque em ensinar alguma coisa.

Nessa última RubyConf a palestra do Norman Clarke me deixou de queixo caído como ele conseguiu explicar um tema complexo como encoding como se fosse um “Hello World”. Parecia que ele tinha conseguido abrir a minha cabeça e colocar as palavras no local correto. Uma aula de como priorizar os ensinamentos.

Você não precisa falar dezenas de termos técnicos difíceis para ser convincente. Assuma que as pessoas sabem muito pouco do que você está falando, assim os que já sabem algo vão entender e o que não sabem também.

O que é mais agradável e convincente?

• Nosso MP3 Player vem com 2gb de RAM e sincroniza com seu computador via USB
• “O mais legal do iPod é que sua playlist inteira cabe em seu bolso.” – Steve Jobs 2001

Treine Antes

Não importa o quanto você domine o tema, pratique antes. Várias vezes, eu normalmente ensaio uma palestra de 50 min umas três vezes. Essa é a única forma de saber quanto tempo você gasta com esses slides e como pode enxugar as coisas para ajustar o tempo, caso seja necessário.

Não me venha com o papo de que treinar não dá certo para você. Se Steve Jobs treina seus Keynotes exaustivamente e Michael Jackson ensaiava suas próprias músicas centenas de vezes não caia no erro de achar que você não precisa ensaiar.

Conclusão

Meu checklist:

• Não confie no projetor
• Não confie na iluminação
• Não confie em mic’s (as vezes vai ter que ser no gogó mesmo)
• Leve sua própria garrafa d’água (as vezes não tem)
• Centralize o conteúdo dos slides
• Use conteúdo bem contrastado do fundo
• Ajuste o perfil do projetor
• Use código com fundo branco e fonte grande
• Prefira vídeos ao invés de live-coding
• Em cursos faça muito live-coding mas tenha um rascunho
• Ensaie antes várias vezes
• Use “Presenter Display” do Keynote
• Explique as coisas com calma e fale devagar se forem coisas técnicas

Eu não sou nenhum expert e nem um Steve Jobs mas essas coisas tem me ajudado a fazer minhas palestras e aulas não serem um completo fiasco. Talvez possam te ajudar.

E da próxima vez não reclame da organização, esteja preparado para tudo dar errado. Se estiver tudo perfeito então melhor ainda.

Illustration by Roctopus

Jeffry Degrande, one of my mate’s in the Rails Rumble team wrote a blog post about our experience with continuous integration and automated building.

Read it below:

Continously Integrating Awesomeness

Very early on, during our initial conversations in preparation of 2010′s Rails
Rumble our team decided we would use a build system and continuous integration.
I ended up beign the one who was going to set it all up and take care of it
during the competition.

Initially I was going to use Hudson on a real box. Since we didn’t actually
have one available, plan B was to run it in a virtual machine on my mac. That
turned out to slow my mac down too much. Additionally configuring a new project
too longer, even after practicing it a few times than I wanted to spend on it.
So we settled on the excellent CI Joe by Chris Wanstrath.

CI Joe is beautifully simple: clone the repo, configure cijoe.runner to run ‘rake spec’
and point a github web hook to post to your mac. Use tunnlr.com if you’re stuck behind
a firewall.

We also had it posting to campfire which we were running in a browser on a
laptop connected to a huge plasma TV.

some stats

Just for fun, here are some stats:

• I counted 134 builds in the campfire logs
• 88 builds were successful; the highest number of builds we went without breaking it was 21
• About halfway through the rumble we went on for a while without fixing the build but we
  really broke it about 12 times
• The ssh tunnel kept disconnecting so not all commits triggered a build

Why fixing the build is your number 1 priority

I want to close with a small anecdote.

My first hours of the rumble were spent adding test coverage to everything
involving users while Daniel was working on the design for the app. In order
to make those tests pass doing the absolutely simplest thing that could work, I
added something like this to the layout:

<% if usersignedin? %>
Welcome back dude
<% end %>

That was all I need to make my integration tests pass, knowing that they would break as
soon as Daniel started working on implementing the designs. So I refactored those tests
to remove duplication and moved on.

Fast forward a couple of hours: Daniel had finished the design and had started work on
the layout. The tests started failing as expected. Yet, I continued work on other things.
We all ignored the build for about 2 hours, adding functionality while 9 specs were failing.

When I finally sat down and updated the tests to reflect the now implemented layout, the
specs were still failing. In fact, no matter what I tried I couldn’t get them to pass.
The flash message I was expecting and testing for was not even there. What happened
was that we had introduced a bug at some point and it was hiding behind a hand full of
tests we temporarily allowed to fail. Had we waited until close to the end to fix
those tests; we probably would not have been able to find & fix that bug.

When the build breaks, fix it immediately

Os envolvidos com Rails já sabem que no domingo passado terminou o Rails Rumble. Uma competição onde equipes de até 4 pessoas criam aplicações
dentro de um período de de 48h.

As aplicações são julgadas nos critérios de Inovação, Aparência, Utilidade e Acabamento. E neste ano 300 equipes estão competindo nestes pontos e concorrendo a vários prêmios legais.

Neste ano eu tive o imenso prazer de participar da competição e vou contar um pouquinho como foi essa experiência.

Preparação

Montamos nossa equipe bem antes do evento, formada por: eu, João Vitor, Jeffry Degrande, Bruno Alves.

Logo que todos toparam encarar essa maratona a tarefa foi decidir o que ser feito.

Como todo a equipe está em Belo Horizonte decidimos que a melhor forma de colocar as coisas na mesa seria através de reuniões presenciais. A primeira delas foi para a decisão do tema.

Antes da reunião cada pessoa levantou uma série de idéias e no dia fomos descartando o que era complexo de mais ou que não tinha interesse. Ficamos com 3 idéias principais mas no final o que escolhemos foi a idéia do Superfolio

A idéia

Basicamente a ferramenta é uma forma de resolver a criação de site profissionais. Como assim? Toda pessoa precisa de um curriculum, no entanto eles são trabalhosos de serem feitos, ficam desatualizados e para várias profissões não significam muito (ex.: para um desenvolvedor Ruby seu github pode fazer mais diferença que seu CV).

Por outro lado todo profissional precisa de um site na internet com informações bem parecidas com a de um CV, no entanto um site abre um mar de possibilidades. Possibilidades como facilidade de atualizações, anexar imagens e principalmente links para redes que possam interessar seus contratantes e clientes (ex.: um desenvolvedor Ruby pode linkar seu Github e seu Blog). Outro ponto que conta muito em qualquer contratação são sua recomendações, este também é um ponto que um site pode resolver e um CV não.

A idéia é bem simples, permitir que qualquer profissional interessado em criar seu site possa acessar um painel administrativo e definir sua biografia, experiências, fotos de projetos, links externos e aceitar recomendações.

Como a ferramenta é para criação de um site de verdade também é necessário que exista a possibilidade da customização completa do layout, ter um domínio próprio e poder monitorar os acessos (via Google Analytics).

Ficou curioso? Acesse o meu superfolio e veja tudo que pode ser feito: http://daniellopes.me/

Planejando a execução

Com a idéia levantada começamos a fazer encontros semanais na Dito Internet.

Diferente de um projeto de software convencional, desta vez nós sabíamos todas as features e não tínhamos a opção de ir criando o sistema e recebendo feeback. Por essa razão a opção de várias reuniões longas foi tomada ao invés do modelo Agile de reuniões.

Eu fiquei responsável pela interface, então antes mesmo do evento eu fiz todos os mockups necessários para termos a visão completa da aplicação. Com os mockups detalhamos algumas dezenas de tickets no Pivotal Tracker.

Dividindo tarefas

Alguns pontos precisavam ser estudados antes do evento já que no dia não poderíamos aprender nada, apenas executar.

Como dito anteriormente, eu fui o designer então além de todos os mockups também fiz uma grande pesquisa de referência para o layout, pois não haveria tempo para “inspiração”. Com base nos mockups também foi possível identificar quais pontos do HTML seriam complexos então achei solução para estes pontos e também bibliotecas de JS que deveriam ser usadas (jQuery, facebox, jquery-tools e etc).

Bruno ficou responsável por configuração dos servers então ele montou uma receita do que precisaria ser seguido no dia do evento. Também contratou uma VPS para os testes e estudou o Base-App, que automatiza o deploy.

Jeffry ficou com a parte de customização do layout e temas, ele optou pelo Liquid e se especializou neste ponto. Também cuidou de estudar a melhor alternativa para integração contínua (escolhido foi o CI Joe).

No site também temos uma busca complexa na home que pesquisa por qualquer termo no site dos usuários. Para isso João Vitor ficou a cargo das pesquisas e por final usamos o Solr.

Logística

Antes do evento também fizemos a organização do que precisaríamos no dia e quais tipos de refeições deveriam ser feitas para evitar o cansaço.

Para o local do evento o Bruno cedeu o escritório da Dito que conta com uma infra-estrutura muito boa e cercado de restaurantes.

Foi decidido que as principais refeições seriam feitas nesses restaurantes e ali faríamos as reuniões de retrospectiva dos mini-sprints.

Tudo foi muito bem planejado e a único complicador foi a falta de um chuveiro na Dito

Execução

Uma coisa já era fato. O prazo é curto mas todos os membros da equipe são profissionais e nós não sacrificaríamos as boas práticas por causa do tempo.

Ficou definido que usaríamos métodos ágeis, pair pogramming quando necessário, deploy contínuo, integração contínua e principalmente Test Driven Development.

Jeffry montou um server de integração contínua com CI Joe que ficava ligado ao televisão de 42 polegadas da Dito. Todos os pushs para o github do projeto e builds ficavam visíveis e com um som diferente tocando para cada fato. Assim sabíamos ao certo quando os testes paravam de funcionar.

Para deploy usamos o famoso Capistrano. Mas antes do evento fizemos um tunning do meu template de app Rails, o Base-APP. Com ele o Capistrano já fica muito bem configurado além de várias outras coisas que melhoramos nele mas que são comuns para qualquer app (o projeto é open-source e MIT). Também foi usado o Hoptoad para monitoração de exceptions em produção.

Pair programming foi essêncial para achar os erros mas não para planejamento pois tudo já havia sido planejado antes. Também usamos pair programming para evitar o sono.

Para TDD decidimos pelo Rspec com Steak. Uma boa cobertura é essencial, principalmente em um ambiente tão apertado como o Rumble e testes de aceitação fizeram toda a diferença.

Tendência ao amadorismo

Nós, seres humanos, gostamos de colocar a culpa do nosso amadorismo em vários fatos mas nunca em nós mesmo. No Rumble a maior desculpa para a “tosqueira” é o tempo.

Já fui questionado várias vezes se deve ser feito TDD quando o tempo é apertado e vou compartilhar um pouco dessa experiência no caso mais extremo: Rails Rumble.

Não seguimos TDD a risca no projeto mas seguimos desenvolvimento com testes o tempo todo.

Na madrugrada de domingo, já extremamente cansados, estávamos fazendo vários push’s para o Github simultaneamente e em um certo momento alguns testes começaram a quebrar.

Não corrigimos isso na hora e ficamos com 9 testes quebrando. E nesse momento eu estava no HTML e o Bruno e Jeffry implementando novas features não relacionadas aos tests quebrados. Até que o Jeffry largou tudo para consertar os tests. Mas o Jeffry era o único da equipe com conhecimento do Liquid então o Bruno resolveu assumir o “pepino”.

Alguns dos testes foram corrigidos com meu HTML mas o mais complicado era um teste que estava falhando por algum motivo estranho que não era simples de achar. No fim, Bruno descobriu uma falha grave no nosso algoritmo de redirecionamentos que permite a usuário ter seu próprio domínio (daniellopes.me ao invés de de superfolio.net/daniel).

O resumo é que se não tivéssemos testes não teríamos conseguido achar esse bug e se a equipe tivesse deixado o caos tomar conta o sistema teria ido para o ar com este bug grave. Atualmente o sistema está rodando bem e sem notificar nenhuma exception.

Lições aprendidas

O Rumble serviu para colocar a prova todos os nossos conhecimentos de Ruby e desenvolvimento de software. Eu, pessoalmente, pude tirar várias lições (e acho que meu amigos de equipe vão concordar).

Amadorismo

Primeiro, o tópico anterior: Falta de tempo não é desculpa para amadorismo.

Equipe

Outro fator marcante foi a importância da equipe. Mais do que em qualquer projeto, no Rumble, pessoas são mais que processos e manter a comunicação, a amizade e pensamentos na mesma linha em 48h, sem descanso, é um mega desafio.

No nosso caso a equipe se deu muito bem, como eu nunca tinha visto antes. Apesar de nunca termos trabalhado todos juntos houve uma coesão muito grande.

Todos os membros trabalharam como loucos e suaram a camisa pelo projeto. Foi a melhor definição de uma equipe auto-gerenciável que já vi (kudos para o Jeffry, Bruno, João e eu mesmo ).

Descanso

Outra lição é que sempre é preciso haver descanso, não importa o quão apertado é o deadline você não pode entrar no modo “Hero” (como dito no Rework). O estado onde resolver o problema se torna questão de honra, não importando mais nada.

Se você fica muito tempo olhando um problema você nunca vai resolve-lo se não descansar um pouco ou pedir ajuda. Toda vez que a coisa agarrava compartilhávamos o problema com a pessoa mais próxima e um olhar externo resolvia rapidamente.

Design

Outro ponto que ajudou muito foi ter uma equipe de Railer’s experts junto com um designer com conhecimento de Git, HTML, JS e testes. Ou seja, alguém focado no frontend mas com visão geral das tarefas. (depois farei outro post sobre o verdadeiro papel do Design em Software)

Em vários momentos quando eu passava do photoshop para o html nossos testes de aceitação quebravam no protótipo já existente. Conseguir resolver essas coisas sem precisar chamar outro desenvolvedor ajudou muito.

Também foi importante o designer conseguir “baixar” e trabalhar corretamente com o código usando o Git, então o fluxo e forma de compartilhamento era igual entre toda a equipe e eficiente.

A parte do design também guiou as funcionalidades, fazendo que conseguíssemos identificar problemas graves antes de implementarmos.

Refactoring

Ficou bem claro que o mais importante é colocar funcionando e que depois haverá tempo para ajustes. Pensando dessa forma é muito importante manter um bom suite de testes para que você possa voltar e refatorar depois e manter a confiança do funcionamento.

O sistema possui vários pontos que podem ser melhor arquitetados mas o que importa é que ele está online e com nosso suite de testes podemos fazer essa refatoração nos pontos que importam.

Conclusão final

Apesar do cansaço (e da falta de banho eu saí do evento extremamente motivado e satisfeito com o resultado. A equipe foi extraordinária e a competição uma experiência que não tem preço.

Não importa o resultado (bem… importa um pouco a verdade é que conseguimos entregar em 2 dias um CMS relativamente complexo e mantendo a qualidade do trabalho.

Agora é conseguir os usuários que vão fazer uso do sistema de fato. Passando o efeito que chamo de “Onda Sapo” (usuários curiosos que só entram no sistema para sapear e não para usar mesmo acredito que o sistema poderá evoluir para algo bem funcional. O exemplo é o meu próprio site em daniellopes.me .

Também decidimos manter a equipe e fazer encontros frequentes para melhorar o Superfolio como um time.

Com certeza ano que vem participarei novamente e caso passemos para final vamos precisar da ajuda de vocês

A e-Genial está movimentando mais um evento on-line, será um mega evento de Ruby e desta vez eu também estou ajudando a dar uma mão na organização.

Para nós acertarmos o máximo possível e agradar o maior número de interessados precisamos da sua ajuda. Por favor respondam o rápido questionário abaixo, os resultados nos ajudaram a definir a grade, horário e etc.

http://bit.ly/eventoruby

E ajudem a divulgar para o máximo de pessoas também. Obrigado

Neste post vou compartilhar um pouco dos meus experimentos para tornar o suite de testes do Cifras mais rápido.

No atual estado do serviço eu tenho por volta de 800 testes automatizados usando Rspec 1.3 e Rails 2.3.9.

Estes testes cobrem o sistema praticamente todo e a são única forma ter a confiança necessária para trabalhar em novo recursos, correções de bugs e etc.

Este número de tests tem crescido consideravelmente desde que comecei a utilizar o Steak para testes de aceitação. Testes de aceitação possuem um papel muito importante em certificar que a funcionalidade é aceitável para o cliente em faz os testes em estado mais macro. Desta forma tenho coberto o sistema praticamente todo usando o Steak nas últimas semanas.

No entanto eu me vi em uma situação que já era perceptível mas começou a se tornar insuportável. Meu suite de testes (ainda com 800) estava demorando por volta de 4.5 minutos para ser executado. O mais estranho é que 800 testes é muito pouco para poder demorar tanto.

Arquitetura de um Saas

Cifras é um Saas que envolve pagamentos e múltiplos usuários dentro de um conta. Eu já trabalhei em vários outros Saas’s e todos que envolvem algum tipo de assinatura e vários usuários acabam tendo uma arquitetura muito parecida nos models.

Normalmente você possui os seguintes models: conta, usuário, assinatura, plano de uso, preferências e o uma associação para proprietário da conta. Além destes 5 models também existe um processo que insere alguns dados iniciais como categorias assim que uma conta é criada.

Fica claro que qualquer signup vai disparar uma criação em cadeia de uma conta com uma assinatura que possui um propietário (que é um usuário) e depois preencher as categorias e etc. Este processamento é bem rápido mas multiplicado por 800 (ou mais) acaba sendo um problema.

Eu não quero reduzir o número de models reunindo tudo no model de conta pois acredito que seria uma arquitetura bagunçada além de uma alteração que envolva tanto o banco de dados ser extremamente perigosa.

Eu não queria tocar em nada do código da aplicação apenas para fazer os testes se tornarem mais rápidos. Do contrário acredito que estaria ocorrendo um inversão das responsabilidades, fazendo os testes guiarem o desenvolvimento mais de uma forma errada.

1º passo: Logger

Comecei o trabalho de otimização analisando o log de test. Para ter certeza de onde cada query vinha e o tempo gasto, adicionei um plugin chamado query_trace.

É um plugin bastante antigo mas ainda funciona muito bem. Assim que instalei, fiz algumas anotações de todas as queries que ocorriam com frequência em meus tests e de onde elas vinham.

Mas o mais interessante que ao instalar o plugin a performance dos meus testes caiu drasticamente. A única razão para isto é que o plugin escrevia toneladas de textos no meu log, ou seja, operações que envolvem muito IO.

O que fiz foi anotar as coisas que me interessavam e remover o plugin, no entanto uma otimização que já poderia ser feita é alterar a estratégia de log do ambiente de tests para :info ao invés do padrão.

Apenas esta alteração tornou meu suite de testes quase 50 segundos mais rápido.

No arquivo config/environment/test.rb:

1
    config.log_level = :info

2º passo: Evitando consultas

Analisando o resultado do query_trace não havia nenhuma consulta extremamente lenta que ocorresse com frequência. Como eu já utilizava bibliotecas como SlimScrooge, Oink e NewRelic eu já tinha encontrado estas queries e resolvido a mais tempo.

No entanto, uma coisa que muitas vezes não nos lembramos é que qualquer validação de unicidade e associação do Rails vai disparar um consulta. Sim, uma micro consulta que normalmente gasta 0.3 ms e não incomoda em nada em ambiente de produção. Mas nos tests isso pode significar muito.

Como eu utilizava apenas factories (com FactoryGirl) cada spec acabava precisando de um before ou um let do Rspec que fazia uma chamada a Factory account que consequentemente criava todas outras factories associadas e ainda executava as validações.

As criações associadas não me incomodavam ainda pois eu estava atacando apenas as validações. A melhor alternativa que encontrei para remover os 0.3ms de cada validação foi usar fixtures.

Fixtures são carregadas apenas uma vez e não passam pelas validação, então em todos os momentos que eu precisava dos dados base como conta e usuário para fazer os outros testes eu passei a usar fixtures.

Por exemplo, nos testes de categorias eu precisava criar uma conta antes para associar uma categoria a ela. Este processo rodava em um before o que tornava os testes bem mais lentos, a partir de agora tudo é previamente carregado por fixtures.

No final, terminei com uma fixture para cada model base e criei helpers para o Rspec. Algo assim:

1
2
3
4
5
6
7
8
9
10
11
    def account

      accounts(:apple)

    end



    def subscription

      subscriptions(:apple)

    end



    def user

      users(:sjobs)

    end

E meus specs passaram a ficar assim:

1
2
3
    let :bank_account do

      Factory :bank_account, :account => account

    end

A desvantagem é que novos desenvolvedores terão que entender que o account é um helper já que ele é incluído pelo spec_helper.

Outra coisa que fiz foi incluir as fixtures base como globais para evitar ter que carrega-las manualmente nos specs.

1
2
    Spec::Runner.configure do |config|

      config.global_fixtures = :users, :plans, :accounts, :settings ...

Em vários casos o uso de fixtures para a base do sistema eu tive ganhos de mais de 100% em velocidade. Então a partir disso toda a base do sistema (5 models) utilizam fixtures nos models associados e factories em seus próprios models.

Por exemplo, no model User eu faço os specs usando a Factory user mas a sua conta é trazida de uma fixture e vice versa com os outros models base. No caso de Transações eu carrego usuário, conta, plano, assinatura e preferência através das fixtures enquanto as transações são criadas com factories.

3º passo: Evitando chamadas remótas

Uma coisa irritante da comunidade Rails são as modinhas. Por um lado é bom, pois as coisas se atualizam MUITO rápido por outro lado fixtures se tornaram diabólicas de um dia para o outro, também ocorreu com attachment_fu por exemplo e etc. O mesmo vale para mocks.

Se você vai fazer uma integração com uma API, você DEVE usar um mock para não fazer o request, essa é a regra. Eu simplesmente descordo!

Se sua aplicação depende da API para existir, eu considero totalmente errado fazer um mock disso pois você nunca saberá se por algum motivo a API mudou ou parou de funcionar, ou mudou de endereço.

Apesar de óbvio que uma API deve ter versões e não mudar dessa forma, nem sempre isso ocorre, ainda mais as API’s brasileiras.

Por esta razão os testes do Cifras executavam requests para o sandbox do MOIP, o que fazia eu ter a segurança que o meu código continuava funcionando com a API deles. Eu NÃO iria fazer um mock dessa parte e ponto final.

Isso causava uma demora de mais ou menos 1 min nos testes. Mas era um preço que eu preferia pagar.

Com uma dica do meu amigo Jeffry Degrande conheci uma ferramenta que resolve isso. O ephemeral_response faz o request para a API e armazena um cache com o retorno por um prazo pré-determinado. Defini que este prazo no Cifras seria de um dia.

Com este passo reduzi mais um minuto do meu suite.

4º passo: Trabalho de formiga

O último passo seria de fato passar spec por spec e olhar o que poderia ser otimizado. Em alguns pontos stubs faziam mais sentido, outros apenas um Factory.build ao invés de create tornava o test mais rápido.

Outras duas técnicas muito boas é utilizar Factory.attributes_for :meu_model e Factory.stub :meu_model.

Este passo não reduziu muito o tempo pois eu já utilizava desta forma, mas em alguns pontos eu tinha deixado passar então tive uma pequena melhoria.

Conclusão

O resultado final foi que de 5min eu consegui reduzir para 1.5 min. Ainda existe espaço para otimizações, mas por enquanto isso deixo de ser prioridade e será melhorado usando aos poucos seguindo The Boy Scout Rule.

A minha conclusão é que fixtures são excelente para alguns casos e factories também, então não existe nenhum motivo para este ódio contra fixtures. Você pode usar tanto fixtures quanto factories no mesmo projeto e tirar o melhor dos dois mundos.

Outra dica é quanto ao log e o ephemeral_response e sempre ficar atento para usar Factory.build e Factory.stub quando possível.

Se você tiver alguma outra dica, compartilhe nos comentários.

Como já comentei aqui em no post anterior, este sábado para começaremos mais uma turma do Imersão Ruby on Rails. Na verdade a última turma do ano.

E como quase sempre fazemos, a E-Genial está sorteando uma bolsa para esta turma e parceria com o Ruby Inside Brasil. Para saber como ganhar este prêmio leia este post.

Quem fizer este curso além de sair um melhor Rubista também sairá um melhor desenvolvedor.

AkitaCasts

Ambos os cursos que ministro na E-Genial são longos e possuem entre 16 e 22 horas de duração. Nestes cursos mais longos conseguimos passar os pontos mais importantes da linguagem Ruby e framework Rails. Mas existem várias outras tecnologias e boas práticas associadas a um bom desenvolvimento que não cabem, por exemplo, em um treinamento de 20 horas.

Para ajudar nestas tecnologias temos a excelente iniciativa do Fábio Akita na produção de screencasts que cobrem diversos temas variados e que com certeza vão complementar os seus estudos.

Eu sempre senti falta de uma versão brasileira de algo como Railscasts ou Peepcode, agora esta lacuna esta preenchida

Este ano, na Egenial, foram abertos vários cursos voltados ao mundo Ruby.

Um destes cursos foi Imersão Ruby on Rails. Como já trabalho em parceria com a e-Genial a mais tempo, o Carlos Eduardo (proprietário da empresa) me convidou para ser o responsável por criar este novo curso e a partir de então ficar apenas com esta nova turma.

Depois de pensar bastante, cheguei a conclusão que a melhor opção seria eu ministrar tanto o curso do básico ao avançado como o imersão. Apenas desta forma eu teria controle total de tudo que é necessário para um interessado em Rails entrar com pé direito na tecnologia e em seguida entender com precisão as internas da linguagem Ruby

Como é um curso intensivo com apenas 4 dias com 4 horas por dia (nos sábados), depois que o material estivesse pronto, eu não ficaria sobre-carregado administrando duas turmas e os iniciantes de Rails poderiam seguir a mesma linha de aprendizado deste o início, com o primeiro curso, e se aprofundarem nas internas da linguagem com este segundo. Por estes motivos, atualmente, sou instrutor do curso do Básico ao Avançado e do Imersão.

Durante a preparação da grade e do material eu tentei agrupar todos os temas que considero essenciais para um Rubista. Mas temas que não são tão triviais de se aprender.

Tentei compilar o conhecimento que não aprendemos em blogs ou palestras de 50 minutos. Assuntos como Object Model da linguagem que não vemos em muitos livros mas que são fundamentais para aplicar da forma correta metaprogramação ou para entender, de verdade, técnicas simples como “class << self”.

Outros temas importantes que tentei abordar neste novo curso são por exemplo a influência de dsls no cotidiano (e como criar dsl’s), refactoring (na prática melhorando um pequeno projeto em Ruby puro coberto com MiniTest), boas práticas de Rails como arquitetura rest para organização ao invés de criar API’s, design SOLID e criação de Gems.

Grade com detalhes

É bem provável que esta seja a última turma deste curso para 2010 então corra e faça sua matrícula. A grade do curso detalhada você pode ver abaixo (ou no próprio site do curso):

1. Ruby Object Model
   1. A verdade sobre programação orientada a objetos
   2. Os segredos para identificar o “self”
   3. Method Lookup
   4. Superclass e Metaclass
   5. Eigen Class ou Ghost Class
   6. A verdade sobre o que são classes
   7. Métodos de classe não existem
   8. A verdade sobre os módulos
   9. Usando módulos da forma correta
2. Metaprogramação
   1. Mágica é para os fracos, entenda o que é metaprogramação
   2. Importância da reflexão
   3. Compreendendo o que são e as diferenças entre blocos, proc e lambda
   4. Entendendo corretamente o escopo e como alterar o self
   5. Família “eval”
   6. Classes Abertas
   7. Criando métodos em runtime
   8. Criando classes em runtime
   9. method_missing
   10. Hooks do Ruby
   11. Exemplos reais sobre metaprogramação
3. Ruby DSL’s
   1. Entendendo o que são DSL’s
   2. DSL’s internas em Ruby
   3. Importância de DSL’s para melhor o design do software
   4. Técnicas mais comuns para criação de DSL’s
   5. Exemplos práticos de DSL’s (ex.: Whenever, rotas do Rails, delayed_job e etc)
4. Ruby best pratices
   1. Como diferenciar um bom design e de um ruim
   2. Evitando erros comuns em manutenção
   3. Aprendendo conceitos de um design S.O.L.I.D)
   4. Refactoring na prática (usando Ruby 1.9 e MiniTest)
   5. Forwardable
   6. Delegate
   7. Comparable
   8. Enumerable
   9. Parâmetros nomeados
   10. Expressões condicionais
   11. Convenções do Ruby
5. Rails Best Pratices
   1. Boas práticas em desenvolvimento Rails
   2. Como organizar sua aplicação pensando no futuro
   3. Restful como ferramenta de design e não apenas para API’s
   4. Refatorando controllers
   5. Refatorando Views
   6. Refatorando Models
6. Rails Best Pratices
   1. Controllers magros
   2. Models gordos
   3. Single Responsibility em Models
   4. Princípio do menor conhecimento
   5. R.E.S.T para arquitetura de software
   6. Rotas saudáveis
   7. DRY com metaprogramação
   8. Módulos para repetição
   9. Composição
   10. Callbacks em Observers
   11. Índices em Migrations
   12. Alimentação do banco com Seeds
   13. Sempre mantenha um rollback em Migrations
   14. Separação de lógica das views
   15. Técnicas avançadas com partials e layouts
   16. Refatorando forms com FormBuilders
7. Gems
   1. O que são realmente Gems
   2. Erros graves ao escolher uma Gem
   3. Como ler uma Gem
   4. Importância de se criar Gems
   5. Criando uma Gem na prática