edit

Onde foram parar aqueles caras da Improve It?

Publicado por Vinicius Manhães Teles há mais de 4 anos.

Há pouco mais de dois meses nós decidimos mudar de rumos e deixar os serviços de consultoria de lado. De lá para cá, estamos bem quietos. Afinal, o que anda acontecendo por aqui? Resumidamente, resolvemos começar nossa jornada resolvendo um problema bem concreto, para então começar a trabalhar no nosso primeiro produto.

Problema

A gente acha que bons produtos são extraídos de projetos reais, que resolvem o problema de alguém e podem ser re-estruturados para resolver o problema de muitos. Sendo assim, ainda em dezembro, na mesma época que anunciamos nossa saída do mercado de consultoria, começamos a trabalhar para um cliente. Trata-se de um negócio pequeno, porém extremamente bem sucedido, que atua em um ramo que movimenta uma boa grana. Ou seja, o negócio é pequeno, mas há dinheiro circulando o tempo todo. Por enquanto, não iremos revelar nem quem é o cliente e nem qual é a área de negócio, mas, para facilitar a história que vem a seguir, vou dar um nome fictício ao nosso cliente. Vamos supor que chama-se Júlia.

Júlia tinha um site. Não era dos melhores, mas era tolerável. Era parecido com muitos outros de pessoas que atuam no mesmo ramo. Este ramo é interessante porque a maioria dos sites é horrível e partem de uma premissa que, na nossa opinião, é profundamente equivocada. Nossa missão era dar um novo site à Júlia. Mas, não apenas isso. Este site teria que ter algumas funcionalidades que poderiam ajudá-la a acelerar seus processos. Ou seja, há um aspecto institucional, de apresentar o trabalho e outro funcional muito forte e, tipicamente, mal resolvido. Resolvemos tratar deste último de maneira inovadora, mas não foi só aí que decidimos inovar. Também queríamos quebrar a premissa fundamental que rege a maioria dos sites deste ramo.

Primeiro Ato

Dividimos o projeto em duas partes, que vou chamar de primeiro ato e segundo ato. O primeiro ato foi implementado em pouco mais de um mês e colocado no ar por volta do dia 10 de fevereiro de 2008. Na equipe, eu, o Tapajós e o Leandro trabalhando nisso em torno de trinta horas por semana.

Durante o desenvolvimento, estivemos próximos da Júlia o tempo todo. Conversamos muito sobre cada aspecto do sistema e fizemos inúmeros experimentos, sobretudo com a interface do usuário. Além disso, tentamos simplificar tudo que podíamos. A premissa era: preguiça é bom! Sim, quando se trata de desenvolvimento de software, há um certo tipo de "preguiça" que nos alerta quando estamos fazendo algo de forma excessivamente complicada. Foi esta preguiça que nos levou, por exemplo, a não usar banco de dados para praticamente nada. A única exceção é o armazenamento de sessões. Devido a algumas características do aplicativo, não dava para usar sessões baseadas em cookie.

É possível fazer um software significativo sem banco de dados? Ou melhor, dá para fazer sem persistência? Neste aplicativo, em particular, não dava para fazer sem persistência, mas dava para ficar sem banco de dados. Quer dizer que usamos algo tipo prevalência de objetos? Não exatamente. Há muita informação persistida, mas nós não tivemos que cuidar diretamente desta persistência e isso nos poupou muito trabalho. Os detalhes eu vou ficar devendo, lamentavelmente. Mas, posso dar uma idéia de números para vocês. Os dados persistidos podem levar o site a ter uma grande quantidade de páginas internas. Neste momento, o sitemap contém 15.133 páginas. Entretanto, este número é menor que o número real de páginas que ele possui. Como ficaria muito custoso gerar um sitemap completo, nós decidimos fazer um corte. Em todo caso, isso dá uma idéia da quantidade de dados que são persistidos e usados no site, porém, surpreendentemente, não há banco de dados envolvido! :-)

Há um detalhe interessante nesta questão. Se há tantos dados, como a Júlia faz para cadastrar estes dados e mantê-los? Boa pergunta. Não dá para explicar aqui como isso é feito, mas basta dizer que sim, há uma área administrativa, onde ela manipula todos os dados com uma interface bacana. Mas, a melhor parte da história é que nós não tivemos que fazer isso, o que, considerando a sofisticação da aplicação, explica como fizemos tudo em pouco mais de um mês.

Qualidade

Linhas de código não indicam quase nada isoladamente, mas, quando usadas em certas comparações, servem para dar uma idéia de características do projeto. Até o momento, temos 742 linhas de código na aplicação e 1934 linhas de specs. Isso significa que temos 2.6 linhas de spec para cada linha de código da aplicação. Aliás, não há uma única linha de código da aplicação que não receba a visita de pelo menos um spec. Ou seja, nossa cobertura de código pelos testes é de 100%, como em todos os nossos projetos. Além dos specs, temos inúmeros testes de aceitação no Selenium que totalizam 2136 checagens. Estes últimos testes consomem, em média, de 5 a 8 minutos para executar e são executados sempre que fazemos uma integração (com o plugin integration). Estes números mostram que temos uma preocupação significativa com a questão da qualidade.

Além dos testes automatizados, nós também realizamos testes manuais em cinco navegadores: IE6, IE7, Firefox, Opera e Safari. Estes testes têm o objetivo de inspecionar visualmente a parte do design, já que este é um terreno ainda complicado para os testes automatizados. Qualquer mudança no site leva, inevitavelmente, a testes manuais nestes navegadores, além dos automatizados. Em todo caso, há um tipo de checagem automatizada que podemos fazer para a parte do design. Trata-se das validações da W3C. O aplicativo passa nas validações da W3C. Desde o início do projeto o Leandro, sobretudo, tem demonstrado muita preocupação em assegurar que o aplicativo respeite todos os web standards.

Os números relacionados aos testes são elevados, mas, quando o assunto é gestão de bugs, os números já não são tão expressivos. Para começo de conversa, não temos nem mesmo um sistema de gestão de bugs. Pois é, que desorganizados nós somos, né? Nenhum sistema para gerenciar chamados e controlar os bugs. A sim, agora lembrei o porquê disso. Não tivemos nenhum relato de bug desde que o sistema foi ao ar! E não foi por falta de uso. Então, acho que dá para continuar sem gestão de bugs. Mas, garanto que seria impossível fazer isso sem a relação quase paranóica que nós temos com os testes.

Sendo bem honesto, a falta de relatos de bugs não significa que eles não existam. Significa apenas que não foram descobertos ainda. De fato, havia alguns que nós próprios conseguimos detectar depois de colocar o sistema no ar. Nenhum deles era grave e talvez ninguém nem tenha chegado a passar por eles. Mas, nós corrigimos assim que identificamos. Em todo caso, já faz vários dias que não conseguimos detectar nada novo e continuamos sem nenhum relato de bug, apesar de termos uma utilização crescente da aplicação.

Hospedagem e Deployment

Estamos usando o VPS de 512MB da SliceHost. Até o momento, o serviço deles tem sido perfeito. A máquina é muito rápida e estável. De fato, ela é superestimada para as necessidades desta aplicação. Mas, preferimos que seja assim. Nós fizemos inúmeros testes de desempenho com o Httperf antes de lançar o site e eles demonstraram que o site tem um tempo de resposta excepcional, mesmo quando a carga é muito elevada. Parte disso, naturalmente, tem a ver com o trabalho cuidadoso que fizemos na parte de caching.

Este aplicativo tem a propriedade de não ter modificações muito freqüentes, embora tenha uma grande quantidade de dados. Em torno de 90% do site pode se beneficiar do cache mais eficaz que temos no Rails, que é o cache de página. Sendo assim, estamos usando cache de página na maior parte do site e o resultado não poderia ser melhor. Os 10% restantes felizmente representam as funcionalidades menos usadas, embora tenham sido as mais trabalhosas para implementar.

Quanto ao application server, inicialmente pensamos em usar o nginx com o Mongrel. Mas, antes de tentar esta alternativa, lembrei da apresentação que considerei a mais interessante no Minas on Rails e no Rio on Rails. Foi a do Eduardo Rocha, do O Curioso. Uma das coisas que me chamou a atenção foi que ele disse que usava um tal de LiteSpeed e que recomendava. Até então, eu jamais tinha ouvido falar do LiteSpeed. Conversei com o Eduardo antes de colocar a aplicação no ar e ele reforçou a preferência pelo LiteSpeed e a recomendação. Resolvemos experimentar e não poderíamos estar mais felizes. O LiteSpeed cuida de tudo e é muito fácil de usar. Atua como WebServer, Application Server e ainda distribui a carga para várias instâncias do Rails. No nosso caso, está configurado para usar até dez instâncias simultaneamente.

O LiteSpeed é muito estável, leve e rápido. No lado web server, é mais rápido e mais leve que o Apache. A integração com o Rails, através do LSAPI gera um desempenho superior ao do Mongrel. A única coisa que ainda não entendi é por que tanta gente usa o Mongrel quando poderia usar o LiteSpeed que é melhor em todos os aspectos que vimos até o momento. A sim, ele não é open source, mas não é necessário pagar por nenhuma licença, a menos que o site tenha que responder a um número superior a 150 requisições por segundo, o que ainda não é o nosso caso.

Fizemos testes de desempenho com Httperf e conseguimos simular até 4000 requisições por segundo para páginas em cache. Infelizmente não sabemos o limite real que o servidor agüentaria porque acima deste valor, a máquina que simula os acessos passa a operar com 100% de consumo de CPU, devido à grande quantidade de threads que são criadas para o teste. Até 4000 requisições por segundo, o servidor não chegava a consumir sequer 50% da CPU.

Segundo ato

No momento, estamos trabalhando na segunda parte do projeto que deve ser colocada em produção na próxima semana. A partir daí, a Júlia segue seu caminho e nós seguimos o nosso. Passaremos a trabalhar para generalizar o aplicativo que fizemos para ela. O objetivo, naturalmente, será permitir que o outros pequenos negócios, no mesmo ramo, possam fazer uso do mesmo aplicativo.

Resultados

Assim que o novo site da Júlia foi ao ar, ela começou a receber inúmeros comentários de clientes e pessoas do mesmo ramo elogiando o trabalho. Houve pouquíssima crítica. As apostas que nós fizemos se revelaram certeiras. Agora, inúmeros colegas dela, da mesma área de negócio e correlatas, perguntam-lhe quem fez o site e querem ter um igual. Que legal! :-) É claro que nós queremos atender a todos eles, mas ainda não é o momento. Não queremos fazer um site para cada pessoa. Queremos que todos usem um produto bem definido, que seja fácil para eles usarem e, sobretudo, que nos permita incorporar novos clientes com rapidez e facilidade. Por conta disso, a Júlia tem um acordo de sigilo conosco que a impede de dizer quem fez. Como não queremos ninguém nos fazendo perguntas sobre o site dela antes da hora, nem ela conta quem fez, nem eu conto para vocês o que nós fizemos. E assim nós vamos ficar por mais alguns meses, beleza? :-)

Uma das coisas que nós mais gostamos de saber é que o novo site está rendendo bons frutos para a Júlia. Duas coisas nos chamaram a atenção em particular. A primeira é que ela relatou que o número de pedidos diários de orçamento para seus serviços cresceu mais de cinco vezes desde que o site foi colocado no ar. Ela agora gasta muito mais tempo respondendo emails, mas este não é um problema assim tão ruim, né? :-) A outra coisa legal é que ela disse que agora os clientes já chegam respeitando-a muito mais. Eles olham o site e concluem que estão lidando com uma profissional de altíssimo nível, o que é mais do que verdade.

Estamos animados e continuamos trabalhando bastante. Por isso que não tem dado tempo para escrever muito. Felizmente, ontem conseguimos publicar o plugin integration e tem um outro que está no forno. Espero que possamos lançar em breve. Tem muita coisa legal vindo por aí.

Tags produto, rails | 4 comentários