Objetiva Software

Nasce Objetiva Software

2011-04-07T00:00:00Z

No começo de 2007 eu (Daniel) fiz a escolha de trabalhar por conta própria ao invés de continuar na estabilidade de um emprego. Desde o inicio, minha intenção era poder experimentar mercados diferentes, conhecer novas tecnologias, aprendizado e também retornos financeiros.

Assim comecei a Área Criações em sociedade com a Designer Tânia Azze. A empresa correu muito bem durante os anos que trabalhamos juntos e sempre fizemos desenvolvimento de sotware em paralelo com design em geral.

No entanto, apesar de também trabalhar como designer em nossos projetos o meu maior interesse sempre foi a área digital e no campo de design de interface com foco em desenvolvimento de software.

Tenho me especializado o máximo possível nessas áreas nos últimos anos e por essa razão, eu e minha antiga sócia, optamos por interromper as atividades da Área Criações e cada um voltar suas atenções para seus campos de maior interesse.

Objetiva Software

Eu ainda contínuo com os mesmos objetivos de 2007 e ainda não pretendo trabalhar como contratado em um futuro próximo.

Em 2010 tive a oportunidade de trabalhar novamente com o meu amigo Jeffry Degrande. Um excelente desenvolvedor com bastante experiência em Agile e Ruby, com quem eu já tínhamos trabalhado em projetos no passado e em 2010 fizemos parte da mesma equipe do Rails Rumble.

A partir dos bons resultados dos nossos trabalhos em equipe e dos interesses semelhantes, eu e Jeffry, resolvemos juntar nossa vontade em criar software de qualidade e fundamos uma nova empresa chamada Objetiva Software.

Nosso foco é unir a experiência que temos em desenvolvimento de software e design de interfaces para criar produtos que possuam alta qualidade em todos os aspectos, desde o código, testes, infra-estrutura até o posicionamento dos elementos na tela e aparência do sistema.

Seja através da criações de produtos para startup, coaching, treinamento ou desenvolvimento de projetos já existentes, o nosso objetivo é sempre manter os princípios que acreditamos na indústria de software e fazer o melhor trabalho possível.

A parte boa de tudo isso que apesar de apenas alguns meses de vida, nosso novo negócio tem corrido muito bem e já estamos alocados para vários projetos nos próximos meses, então aguardem algumas novidades em pouco tempo.

Nosso blog

No antigo site da Área Criações, eu era o responsável pelo blog, que movimentei com assuntos técnicos desde 2007. Muito do material que escrevi ainda é válido, principalmente os posts relacionados a Ruby e desenvolvimento em geral.

Por essa razão nós resolvemos importar alguns dos posts que condizem mais com as atividade da Objetiva e evitar a perda de todo esse material que ainda possui bastante utilidade. Nos próximos dias o site da Área Criações sairá do ar mas grande parte do material já está importado para o novo blog da Objetiva.

Novos cursos na Egenial

2011-03-10T00:00:00Z

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

Rubymasters

2011-01-07T00:00:00Z

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.

Pomodoro Certfied

2010-11-18T00:00:00Z

Começou um certo barulho na comunidade de desenvolvedores brasileiro em volta do plano de certificação Pomodoro. Isso não é novidade mas só agora crio um certo barulho.

Já há a bastante tempo venho usando a metodologia e em todos os casos que uso por completo o benefício é gigante.

O benefício real do pomodoro não está na idéia ridícula de ter um timer de 25 minutos. O intervalo na verdade pode ser qualquer tempo, contando que você consiga passar esse tempo todo sem distração.

A grande vantagem está no planejamento e revisão dos seus resultados. A medida que vai trabalhando com Pomodoro, começa a conhecer com mais precisão quantos pontos consegue fazer por semana. Outra vantagem é poder analisar seus resultados e ver porque na semana X você foi mais lento que na semana Y.

Estas análises tem me ajudado a perceber que trabalho melhor sem música, na parte da manhã e com skype/ichat fechados. Também passei a abrir o email apenas 3 vezes ao dia com base no que aprendi com os meus Pomodoros.

Na prática, eu não vejo diferença nenhuma de Pomodoro e métodos ágeis. Ou seja, releases menores, feedback, review, foco e etc. No meu ponto de vista as únicas diferenças são que o Pomodoro é aplicável em qualquer coisa, é individual e mais antigos que Agile.

De fato coisa é bem mais complicada que um timer bobo. Se você trabalha em um escritório com 10 pessoas, como deve proceder para a metodologia continuar tendo benefícios? Como você evita distrações em escritórios? Se você não usou um dia será quer perdeu suas métricas da semana toda? E se um cliente te liga para explicar uma funcionalidade, isso quebra o Pomodoro?

Essas perguntas só tem boas respostas quando respondidas por quem já usa há bastante tempo. Razão pela qual sempre achei interessante os cursos e material sobre Pomodoro do Francesco Cirillo.

Na prática eu vejo a aplicação do Pomodoro algo tão discutível como emprego de métodos como Scrum e principalmente Kanban. A diferença é que o foco é no indivíduo.

Também é importante lembrar que não adianta nenhum método ágil se o membro da equipe, sozinho, não for ágil o bastante para administrar o seu dia e cumprir suas tarefas.

Quanto a cerfiticação, é claro que sou contra. Mas sou contra por motivos diferentes do que as pessoas tem falado.

Percebi pessoas dizendo que isso é ridiculo mas no sentido da técnica ser simples de mais para caber algo como uma certificação. Se o raciocínio é este então eu descordo completamente e acho que faltou bastante pesquisa antes de formar uma opinião qualquer.

A razão pela qual sou contra a certificação é a mesma que me faz ser contra certificações Scrum, Ruby ou quem sabe, um dia, Kanban. Pelo simples motivo de não garantir nada e de que para ser produtivo uma pessoa pode usar vários métodos, Pomodoro é um deles.

Curso online de Imersão Sys Deploy

2010-11-10T00:00:00Z

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.

Dicas para palestras

2010-10-31T00:00:00Z

Nesta semana que passou estive na RubyConf Brasil. Um excelente evento, não tenho nada para 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ções. E este ano ficaram em dois pontos, wifi e projetores.

Reclamando do WIFI

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

Não consigo prestar atenção em duas coisas ao mesmo tempo e notebook/ipad durante as palestras me distrai. Por isso já nem levo notebook mais. 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 projetores 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 você 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/palestras e 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, em eventos on-line, você tem que falar bem mais e com muito menos pausa que presencialmente, 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

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 800x600 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, basta cuidar do contraste. Sempre uso dezenas de transições, efeitos e as vezes desenho meus próprios ícones mas fico atento para que o conteúdo contraste bastante do fundo.

A quarta coisa que sempre tomo cuidado é com 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 como 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 uma cola. Mas não escreva uma bíblia na cola pois você se “ferrar” da mesma forma, a cola é para 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 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 ao vivo usando 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 esperto. 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 para ganhar nota 10.

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

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.

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.

Treine Antes

Não importa o quanto você domina o tema, pratique antes. 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 ao vivo, 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 várias vezes antes
Use o “Presenter Display” do Keynote
Explique as coisas com calma e fale devagar se forem coisas técnicas

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

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

Continously Integrating Awesomeness

2010-10-22T00:00:00Z

Jeffry Degrande, my partner in Objetiva and 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 user_signed_in? %>
  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

Retrospectiva Rails Rumble

2010-10-20T00:00:00Z

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”:http://www.dito.com.br/.

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

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 de Sapos” (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.

Pesquisa sobre evento de Ruby

2010-10-12T00:00:00Z

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 ;–)

Agilizando seus testes

2010-09-27T00:00:00Z

Neste post vou compartilhar um pouco dos meus experimentos para tornar o suite de testes do Cifras (meu projeto paralelo)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 novos 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 pois faz os testes em um nível mais alto.

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 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 proprietá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 do mais, uma alteração que envolve tanto o banco de dados é 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 mas de uma forma errada.

1º passo: Logger

Comecei o trabalho de otimização analisando o log de test. Para ter uma visão melhor das queries, 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 e de onde elas vinham.

Um fato 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 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 era alterar a estratégia de log do ambiente de testes 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:

  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:

def account
  accounts(:apple)
end

def subscription
  subscriptions(:apple)
end

def user
  users(:sjobs)
end

E meus specs passaram a ficar assim:

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.

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, principalmente 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 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 teste 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 deixou de ser prioridade e será melhorado 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.