Blog da Improve It 
Publicado por Vinicius Manhães Teles há
6 meses.
Há alguns dias o Juan lançou a seguinte pergunta em algumas listas de Desenvolvimento Ágil: O mercado esta mudando ou é impressão minha?. Já respondi nas listas, mas acho que o assunto é suficientemente válido para responder aqui também. Esta é a minha impressão sobre o assunto:
Oi, Juan.
Minha resposta curta para a sua pergunta é: sim, o mercado está mudando. Ele está sempre mudando. :-) Mas, talvez não tanto assim quanto gostaríamos e, possivelmente, não na direção que desejamos. Uma das mudanças mais perceptíveis é que cada vez mais gente tem ouvido falar de desenvolvimento ágil. Mas, isso não quer dizer necessariamente que cada vez mais gente esteja adotando métodos ágeis. Certamente, cada vez mais gente DIZ estar usando métodos ágeis. Mas, a distância entre o DIZER e o FAZER é imensa, sobretudo nesta área. Acredito que, daqui por diante, veremos cada vez mais gente falando sobre desenvolvimento ágil, mas continuaremos a ver poucos usando. Há algumas razões fundamentais para isso.
Desenvolvimento ágil não tem a ver com Scrum, XP, FDD, Lean ou seja lá qual for o nome. Tem a ver, acima de tudo, com a maneira como encaramos desenvolvimento de software. Tem a ver com a compreensão da verdadeira NATUREZA do desenvolvimento de software. Os anos passam, mas a maioria absoluta das pessoas não consegue se livrar da idéia de que desenvolver software seja igual a construir prédio. As conseqüências desta dissonância cognitiva são infinitamente mais sérias do que a maioria de nós gostaria de acreditar. Escrevi exaustivamente sobre isso na minha dissertação (cápitulos 3 e 4), então, não vou me estender aqui. Apenas resumirei porque isso é tão prejudicial.
O que uma empresa produz é resultado de como ela está estruturada. Quem tem autoridade para dizer como deve ser a estrutura de uma empresa é quem está no topo. Então, a estrutura de qualquer é empresa é, no fim das contas, o resultado do modo de pensar, da mentalidade, de quem está no comando. A mentalidade da maioria dos empresários, diretores e gerentes no mundo inteiro é, com raríssimas exceções, arcaica e incompatível com o trabalho de desenvolver software. Quando o topo da empresa não entende o tipo de mentalidade necessária para se desenvolver software de forma bem sucedida, não há santo que possa fazer milagre. E eu garanto, a maioria absoluta das pessoas que estão no comando das empresas não entende uma vírgula do que significa desenvolver software. Isso inclui, certamente, a maioria absoluta dos CIOs. Não é à toa que eles buscam recorrentemente coisas como CMMI, PMBOK, MPS.BR, ITIL etc, todos absolutamente incompatíveis com a NATUREZA do desenvolvimento de software. A mentalidade por trás destas aberrações é inútil, quando o assunto é software, mas casa perfeitamente com a mentalidade da maioria dos gestores. E não pára por aí. Nas universidades, a situação é igual ou pior.
Veja o caso da UFRJ, por exemplo. Neste semestre, o professor de engenharia de software, percebendo a crescente movimentação em torno de métodos ágeis, resolveu gastar boa parte do seu tempo para mostrar aos alunos que métodos como o XP não funcionam. Afinal, se fôssemos fazer um prédio com XP, aconteceria mil e uma coisas horrendas. Nisso ele está certo. O problema, como sempre, é a maldita distinção entre construir prédio e desenvolver software, a qual, seria óbvia para uma criança, mas é impossível de ser percebida por um Ph.D(eus). Olha que loucura, em uma universidade do quilate da UFRJ, o cidadão, só porque é Ph.D.(eus), não precisa se dar ao trabalho de estudar sobre métodos ágeis, nem muito menos usá-lo, para já saber, desde criancinha, que não pode dar certo. E claro, um conhecimento destes, tão valioso, não pode ser mantido só para ele. Também é preciso passar adiante para os alunos, como se fosse necessário. Afinal, eles já estão todos estagiando em empresas entupidas de documentos e péssimas práticas de desenvolvimento até o último fio de cabelo.
Sempre fui muito otimista, em tudo. Mas, em se tratando de desenvolvimento ágil, acho que meu otimismo se foi. Foram precisos seis anos para isso acontecer, devo dizer, mas se foi. E a razão está lá em cima, no topo das empresas, no topo das universidades. Está lá onde a mediocridade e a incompetência imperam, ao menos em se tratando de desenvolvimento de software e gestão de pessoas. Percebi, com o tempo, que podemos fazer diferença na base, sim, mas é muito pequena e, freqüentemente efêmera.
Fiquei tempo suficiente nesta área para ver equipes adotarem XP, funcionarem super bem durante algum tempo e, mais a frente, serem impedidas de continuar porque a organização passa minar o andamento do grupo. É como um corpo estranho, que é expelido naturalmente pelas nossas células. Só para dar um exemplo. Em 2003, nós fizemos um projeto XP para a Vale do Rio Doce. Foi um projeto lindo, com tudo que se tinha direito. Até contrato de escopo negociável. As áreas de negócio amaram tudo o que foi feito. Adoravam os desenvolvedores. Depois que o sistema foi colocado no ar, foram encontrados apenas 3 bugs durante os seis meses seguintes. Isso é nada em um projeto de mais de um ano, com mais de dez pessoas envolvidas. O projeto foi um sucesso em praticamente todos os quesitos que se pudesse imaginar. Mas, aí é que estava o problema. A última coisa que alguém quer é um projeto de sucesso! Afinal, como ficam os demais? Quando o projeto acabou, tudo foi feito dentro da Vale para que nunca mais isso se repetisse. Acredite, não foi a única vez que vi isso acontecer. Em seis anos, eu vi muita coisa começar bem e, mais a frente, acabar. Por que?
Porque desenvolver software com a mentalidade ágil não é compatível com a mentalidade de quem manda. Isso é mais do que suficiente para limitar as mudanças na área de software. Acredito que vai levar muito tempo para que as empresas passem a ter gestores que compreendam não apenas o que é fazer software. Mas, o que é fazer um trabalho do conhecimento. A maioria absoluta dos gestores tratam seus funcionários como se fossem crianças. Fica parecendo que os piores imbecis são justamente os que mais freqüentemente são escolhidos para comandar as empresas. Não parece apenas, isso realmente acontece e dói ver o quanto isso é comum. Enquanto estes estiverem lá em cima, vamos ouvir falar muito sobre desenvolvimento ágil. Mas é só. Aliás, não é não. Tem coisa pior. Vamos ver pessoas fazendo barbaridades e dizendo que estão usando desenvolvimento ágil.
Para quem ainda estiver no ramo de consultoria, isso não é necessariamente ruim. Essa área vai bombar. Vamos ter cada vez mais espaço para cursos e consultoria em desenvolvimento ágil. O interesse só vai crescer daqui por diante. Não necessariamente pelos méritos, mas porque alguém ouviu dizer que agora o grande lance é fazer software com a _ (preencha com a metodologia ágil preferida).
O problema dos gestores não afeta apenas o desenvolvimento de software. Ele é muito mais sério e muito mais abrangente que isso. Entre em qualquer empresa grande e o que você verá é um bando de trabalhadores do conhecimento sendo tratados como pedreiros por um bando de incompetentes que não conseguem fazer nada melhor que jogar tempo e dinheiro na lata de lixo. O nível de desperdício de talento, tempo, dinheiro, oportunidades etc é tão colossal que eu realmente não consigo compreender como alguém consegue trabalhar em uma empresa grande atualmente. Claro, existem exceções. Pouquíssimas, mas existem. São apenas isso, exceções.
Desejo muita sorte e sucesso para quem continua lutando para mudar este panorama. Não tenho dúvidas de que as coisas irão melhorar ao longo do tempo. Mas, acho bastante improvável que uma mudança significativa aconteça no curto ou médio prazo. Enquanto as pessoas chegarem no topo das empresas com a mentalidade que temos hoje em dia, enquanto os professores universitários continuarem ensinando lixo, enquanto as empresas continuarem a ganhar dinheiro apesar das práticas de administração arcaicas que utilizam, enquanto nós aceitarmos trabalhar para estes idiotas, vai ser complicado.
Desculpa pelo pessimismo. Não foi sempre assim. Foram necessários seis anos, seis turmas de XP na UFRJ, literalmente centenas de apresentações de XP em todo o Brasil, um mestrado, não sei quantos cursos, vários mentorings, alguns projetos de desenvolvimento XP, algumas conferências no exterior, um livro e mais um monte de coisas que eu não lembro, para me dobrar. E antes que alguém pense que o problema era o XP e que tudo poderia ser diferente se tivesse sido Scrum, FDD, Lean etc, não se enganem. O buraco é mais embaixo. Se você conseguiu chegar até aqui e prestou atenção ao que estou dizendo, tudo se resume a uma coisa: mudar é difícil? É. Mas, ainda é a parte fácil. O difícil mesmo é mudar de vez.
O Kent Beck tem um exemplo ótimo. Segundo ele, parar de fumar é fácil. Tanto que tem gente que já parou várias vezes. :-) O problema é parar e nunca mais voltar a fumar. É a mesma coisa. Um monte de gente vai conseguir mudar para desenvolvimento ágil. Poucos conseguirão sustentar esta mudança. E eu adoraria estar falando isso de orelhada. Mas, é que eu vi as pessoas voltarem a fumar um número suficiente de vezes para saber que é ótimo ver mais movimentação atualmente sobre desenvolvimento ágil. Mas, acredito que seja ingênuo achar que isso implique em uma mudança significativa. Muitos tentarão e a maioria vai voltar às práticas antigas, simplesmente porque todos os incentivos nas empresas giram em torno delas e isso continuará assim por muito tempo.
Apesar de tudo o que disse, torço, profundamente, para estar absolutamente equivocado! No mais, redobrem seus esforços! O desafio é bem maior do que parece à primeira vista.
Tags agile | 6 comentários
Publicado por Marcos Tapajós há
7 meses.
Hoje o Brazilian Rails ganhou um site um pouco mais bonitinho com um design igual ao do nosso outro plugin.
Na verdade esse é um template, de autoria do Leandro, que será usado em todos os nossos plugins. Só não está mais bonito pois resolvi meter a mão e me antecipar ao Leandro.
Tags brazilianrails, plugin, rails, ruby | nenhum comentário
Publicado por Marcos Tapajós há
7 meses.
Como sempre estou atrasado e só hoje vi alguns patch no Brazilian Rails.
Patch #17896 - usar_como_dinheiro não funciona com audit.
O Sylvestre Mergulhão identificou uma incompatibilidade do plugin com o audit que não fazia log das colunas mapeadas com o usar_como_dinheiro.
O patch que ele enviou já foi aceito.
Patch #18822 - Criação de metodos para que o select_estado funcione com o form_for.
Esse patch foi enviado pelo Rafael Cardoso e é bastante pertinente só que não foi aceito ainda pois o patch foi gerado de forma incorreta.
Ele já fez contato comigo e vai enviar o patch correto em breve.
Queria agradecer aos dois pela colaboração constante. Já perdi a conta de quantas vezes aceitei código deles.
Tags audit, brazilianrails, rails, ruby | nenhum comentário
Publicado por Vinicius Manhães Teles há
7 meses.
Como havia explicado antes, estamos trabalhando no desenvolvimento de uma aplicação web para a Júlia. É um projeto dividido em duas partes, ou dois atos, como expliquei antes. O primeiro ato consumiu pouco mais de um mês para ser feito e foi colocado no ar em meados de fevereiro. Ontem concluímos o segundo ato e colocamos no ar. Tudo funcionando as mil maravilhas, cliente feliz da vida, elogios chegando por email, SliceHost e LiteSpeed funcionando melhor do que nunca. Cool! :-)
Com o deployment de ontem, encerramos o primeiro trecho na nossa nova jornada. Fizemos algo muito legal para a Júlia! Agora é hora de transformar isso em um produto que possa ser usado facilmente por outras pessoas. O feriado da Páscoa veio na hora certa. Vamos relaxar um pouco, deixar a Júlia seguir sua vida com sua belíssima aplicação e passar para a próxima etapa. Mas, só na segunda-feia. ;-)
Tags tags | 5 comentários
Publicado por Marcos Tapajós há
7 meses.
Agora a API do plugin Brazilian Rails está hospedada no RubyForge.org.
O endereço é: http://brazilian-rails.rubyforge.org/api.
Dentro de alguns dias teremos um site com uma documentação mais completa do plugin. Será uma página semelhante a do nosso outro plugin, o Integration.
Tags brazilian_rails, plugin, rails | nenhum comentário
Publicado por Vinicius Manhães Teles há
7 meses.
Este mês o projeto Lucidus está completando um ano. Uau, um ano! Como o tempo passa rápido.
Nós já falamos sobre o Lucidus várias vezes e fizemos apresentações sobre ele em alguns eventos. Algumas podem ser vistas em:
Hoje meu objetivo não é falar sobre o projeto, mas sim dizer um muitíssimo obrigado a todos os envolvidos pelo belo trabalho que foi feito até aqui. Começo pelo Felipe, que merece nossa profunda admiração e gratidão. O Felipe está envolvido no projeto, full time, desde o início. Participar de um projeto XP, com iterações semanais, por um ano, não é tarefa fácil. XP é exigente. Demanda da equipe um nível de disciplina e companheirismo raramente encontrados. No Lucidus então, nem se fala. A galera luta todos os dias para fazer melhor e isso inclui coisas difíceis de alcançar, tais como manter uma grande base de testes automatizados no Selenium (entre outros) e garantir que os testes unitários e funcionais tenham sempre 100% de cobertura. Isso é assim no Lucidus desde o primeiro dia. Não bastasse as exigências técnicas, o projeto também demanda do Felipe um tremendo esforço pessoal. Afinal, ele enfrenta uma distância colossal, no transito enlouquecedor do Rio de Janeiro, todos os dias. Não é o único. Ricardo, Luciano e Elmar também fazem isso. É admirável que vocês consigam seguir em frente apesar dessas e outras dificuldades. Felipe, muito obrigado por estar conosco até hoje e por continuar a exercer seu papel com tanto primor.
Ricardo, Luciano e Elmar, agora é a vez de vocês. Antes do início do Lucidus, vocês já conviviam com os desafios da distância e do trânsito carioca. E, quando chegavam no trabalho, tinham sempre uma jornada agitada pela frente. Considerando a importância do trabalho de vocês na Santa Isabel, era difícil imaginar que ainda encontrariam uma forma de participar ativamente do Lucidus. Não sei como vocês fizeram, mas uma coisa é certa: vocês não apenas conseguiram se envolver no Lucidus desde o início, como vêm tendo um papel primordial desde então. Impossível chegar até aqui sem o conhecimento e a colaboração de vocês. Algumas coisas jamais serão esquecidas, como a maneira que o Ricardo e o Elmar encontraram de eliminar o problema dos DBFs e o bom humor contagiante do Luciano. Para nós, é um privilégio e uma honra poder contar com vocês. Não sei o que fazem para conciliar o tempo com o projeto, mas seja qual for a magia negra, por favor, continuam fazendo-a. Muito obrigado mesmo!
Sylvestre, André e Marcelo estão no projeto há menos tempo, mas a participação de vocês não é menos importante. Ao contrário, tem sido essencial e excepcional. É raro encontrar desenvolvedores tão bem preparados e um privilégio tê-los por perto. Como se isso não bastasse, vocês são, no mínimo, muito divertidos. :-) Vocês entraram no projeto mais tarde, mas captaram o espírito da coisa rapidamente e têm colaborado para manter tudo de acordo com nossos mais elevados padrões. Muitíssimo obrigado!
Leandro, como sempre, é o responsável por tudo aquilo que é bonito nos nossos projetos e no Lucidus não poderia ser diferente. Sem a sua ajuda, dificilmente conseguiríamos ter feito as belas interfaces que vêm sendo produzidas. Isso é vital para o sucesso de um software. Se nós fizéssemos um trabalho técnico perfeito, mas com uma interface feia, confusa, o esforço seria inútil. Para o usuário final, a interface É o software. Então, em se tratando das telas, só há duas opções aceitáveis: maravilhosas ou excepcionais! Você é um dos principais responsáveis por fazer com que elas fiquem assim. Não é o único, naturalmente. O Felipe também é outro que tem um tremendo senso estético e uma preocupação permanente com a usabilidade dos sistemas. No fundo, todos nós temos isso por aqui, mas seria difícil não destacar o caso do Leandro e do Felipe. Leandro, obrigado por nos impedir de deixar nossos sistemas com cara de desenvolvedor. Muito obrigado!
O Tapajós esteve envolvido no início do Lucidus. Ele nos ajudou a fazer todo o setup do projeto e esteve presente no desenvolvimento das primeiras iterações. O início de um projeto é crítico, porque é quando nós tentamos deixar o terreno bem preparado para tudo o que será plantado em seguida. Sua participação foi essencial e, esteja certo, muitos dos frutos que foram colhidos pelo caminho, tiveram sua origem no terreno fértil que você ajudou a criar. Sua disposição incansável para disseminar o que sabe também foi de imensa valia. Muito obrigado mesmo!
Bernardo e Rafael também estiveram no Lucidus. Eles não deixaram apenas saudades. Deixaram também software de alto nível que é usado até hoje. Vocês partiram para novos desafios em grandes corporações, mas estejam certos de que nós, que ficamos, não nos esquecemos e somos gratos pelo imenso privilégio de trabalhar com vocês, pelo companheirismo e pelo belo trabalho que fizeram. Espero que vocês estejam muito bem e que consigam levar um ar de Agilidade a estas empresas gigantescas nas quais vocês trabalham atualmente. :-)
É importante falar da equipe técnica, mas seria uma ilusão achar que um projeto desses se faz apenas de nerds. A equipe operacional da Santa Isabel e seus gestores são as pessoas que realmente entendem do negócio. Então, se eles não estivessem envolvidos desde o início, dificilmente teríamos produzido alguma coisa útil. Quando muito, poderíamos ter produzido coisas tecnicamente bacanas que não fariam a menor diferença no negócio da Santa Isabel. Se isso não aconteceu, é porque a equipe operacional e seus gestores estavam lá para mostrar quais são as necessidades da empresa. A todos vocês, meu muito obrigado pela paciência com a equipe de desenvolvimento e pelas informações valiosas que vocês vêm compartilhando.
Todo projeto precisa de alguém que dê a direção e a última palavra. Alguém que tenha a visão do produto e lute por ele. Alguém que tenha autoridade para assegurar que as coisas sejam feitas. No Lucidus isso não é diferente. Aqui temos o privilégio de contar com o Alfredo, Diretor da Protel. Ao contrário do que é comum em quase todos os projetos de software, o Alfredo tem se mostrado um cliente ativo ao longo de todo este ano que passou. Ele está no projeto desde o primeiro dia e é ele quem dá as cartas. É ele quem rege o show e nos dá a direção. Quais as chances de o projeto dar certo sem ele? Ínfimas. Ter a melhor equipe de desenvolvimento e todo o suporte operacional, mas não ter quem diga para onde ir é como ter um o melhor carro do mundo, mas não saber para onde se deve ir. É raro encontrar um diretor que realmente se importe em participar de um projeto. Todos os diretores querem resultados, mas raros são aqueles que querem contribuir de forma útil para que os resultados apareçam. O Alfredo definitivamente contribui, e muito! O mais impressionante é que, como qualquer diretor, ele é uma pessoa ocupada. Mas, no caso dele, é muito ocupado mesmo. Afinal, ele tem inúmeras atribuições além da Diretoria da Protel. Ainda assim, ele conseguiu priorizar o tempo para participar de quase todas as reuniões de iteração (semanais) que aconteceram até hoje. Isto é notável! Possivelmente o fato mais notável deste projeto. Alfredo, não há palavras para agradecer o seu empenho e a sua paciência. É uma honra para nós poder contar com a sua presença! Ficamos todos muitíssimo gratos!
Por fim, mas não menos importante, o Novello. Ele e eu estudamos juntos, na UFRJ, há muitos anos. Novello é um autentico geek, adora tecnologia. Embora tenha uma origem técnica e seja extremamente habilidoso no lado técnico, ao longo do tempo conseguiu transformar-se em um excelente gestor. Ele é um dos principais responsáveis pela existência deste projeto, pela nossa participação e pelo sucesso que vem sendo alcançado até aqui. A Santa Isabel atua em um ramo mais tradicional e, portanto, tem uma cultura diferente daquela à qual estamos habituados nas startups, por exemplo. Não é o lugar onde mais esperaríamos encontrar um projeto ágil. Apesar disso, o Novello conseguiu criar uma ponte entre a cultura do desenvolvimento ágil e a cultura previamente existente na Santa Isabel. Aliás, desde que ele foi trabalhar lá, tem ajudado a promover inúmeras transformações. É notável a sua capacidade de transitar entre os dois mundos e estabelecer formas de conectá-los. É uma habilidade que eu, por exemplo, certamente não teria. Ele, por sua vez, parece ter de sobra, felizmente. Não fosse isso, este projeto não existiria, ao menos não da forma como vem sendo conduzido e certamente não com a nossa participação. Neste ponto, tenho que dar os parabéns ao Novello pela coragem de nos contratar. Desenvolvimento Ágil vem se tornando mainstream lá fora, mas no Brasil ainda é amplamente ignorado e mal interpretado. No caso do XP, ainda pior, costuma ser freqüentemente mal visto, sobretudo por conta do nome infeliz. Todo mundo diz saber do que se trata e, no fundo, poucos realmente o conhecem. Neste contexto, o Novello teve a coragem de apostar em nós e no XP para realizar um projeto de imensa importância para a Santa Isabel. Não é para qualquer um. Aliás, ele não estava sozinho. Ele e seu diretor, o Decacche, decidiram apostar em nós. Meu muito obrigado aos dois!
Antes de finalizar, tenho um ponto adicional para comentar sobre o Novello. Eu tenho uma visão extremamente negativa sobre gerentes de um modo geral. Com base em quase todos os que conheci ao longo da vida, tenho a tendência de achar que o gerentes, na área de TI, normalmente são completos imbecis que fariam um enorme favor a suas empresas se ficassem com a boca fechada o dia inteiro jogando Paciência. Devo ter conhecido uns três ou quatro que não eram assim. Pelo contrário. Eles conseguiam ser extremamente úteis e, o que é mais difícil, não representavam um obstáculo para que a equipe fizesse um bom trabalho. Com toda a certeza, o Novello é um destes poucos gerentes. No Lucidus, ele tem contribuído muito e, ao longo deste um ano que passou, deu à equipe de desenvolvimento o espaço que ela precisava para fazer um excelente trabalho. Isso não é pouca coisa. É uma enormidade e uma raridade. Parabéns, Novello! E muito, muito, muito obrigado!
Para os próximos meses de projeto, espero que continue sendo um sucesso e que os sistemas que estão em desenvolvimento ajudem o Grupo Santa Isabel e a Protel, em particular, a se tornarem cada vez melhores! Sucesso pessoal! Faltam palavras para expressar o quanto eu admiro vocês e o quanto eu sou grato!
Tags tags | 3 comentários
Publicado por Vinicius Manhães Teles há
7 meses.
Estava há pouco conversando no Skype com meu amigo Fábio Pereira. No início deste ano ele nos abandonou e foi lá para a Austrália para mostrar aos caras da ThoughtWorks com quantos bytes se faz software. Aqui a gente não fala sobre o que está fazendo para quase ninguém, mas como o Fábio é meu amigão, desde os tempos da Paggo, contei-lhe tudo. Na verdade, já queria fazer isso há muito tempo, porque, além do interesse técnico, sei que ele também curte o ramo de negócio em que estamos atuando.
Para mim foi muito legal receber todos os emails de feedback que a Júlia, nome fictício da nossa cliente (nada fictícia), nos repassou após o lançamento do site que fizemos para ela. Mas, melhor ainda é poder contar para um amigo que compreende as implicações técnicas e comerciais do que fizemos. O fato de o Fábio ter ficado admirado me deixa animado, porque o cara é sinistro, mesmo sabendo que eu tenho que dar um desconto de 90% no que ele falou, porque ele é suspeito. Valeu, Fábio! :-)
A propósito, conheçam o blog dele e vejam o que um brasileiro tem que aturar quando sai daqui. Ouvi dizer que estes dias o Fábio teve até que varrer o apartamento. Poor guy! :-)
Bom, hoje tive uma idéia, com base em um probleminha que alguns amigos meus andam enfrentando. Se a chuva me impedir de velejar amanhã, é bem provável que eu faça uns experimentos. Quem sabe o que pode sair disso. Ei, Tapa, agora é você que vai ficar curioso até a segunda-feira! :p
Tags produto | 2 comentários
Publicado por Vinicius Manhães Teles há
7 meses.
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
Publicado por Vinicius Manhães Teles há
7 meses.
Continuous Integration is a very important practice for us. The problem is that we never liked the way it's done most of the time, using a server such as Cruise Control. So we prefer to do what we call a synchronous continuous integration. James Shore wrote some time ago exactly what we've always felt about the Cruise Control approach.
All of our projects have a set of automations in place that help us on the integration process. Since our very first Rails project, we've been using some rake tasks to integrate our projects. They've been evolving so far and last week we decided to refactor them, polish and publish as a Rails plugin called Integration.
Integration is an almost paranoid set of integration tasks that will help you maintain your projects healthy and your repository clean. Once you've installed it, all you have to do is run the command below whenever you want to integrate some code:
rake integrate
Ok, let's be honest here. You'll probably need to configure a few things. Read the project page and you should be fine. If you manage to use all the tasks in your project, let us know. Somehow, we believe this won't happen very often... You'll see! :-)
Go ahead. Checkout the Integration plugin.
Tags continuous integration, plugin, rails, ruby | 1 comentário
Publicado por Marcos Tapajós há
7 meses.
Depois de muito tempo(ou falta de tempo) resolvi solucionar alguns bugs reportados no plugin.
Quem quiser saber de mais detalhes sobre os bugs pode dar uma olhada lá na página do projeto no RubyForge. Vou apenas listar as repostas que eu dei a cada um deles.
Bug 17663 - Inclusão da validação less-than-or-equal-to
Regis, realmente estava faltando essa messagem. Já foi adicionada.
Obrigado.
Bug 17664 - Pluralização correta para 'mail' e 'email'
Regis, realmente estava faltando essa regra. Já foi adicionada.
Obrigado.
Bug 17439 - Atributos possuem gênero, fazendo com que alguns erros apareçam com erros de concordância.
Lucas, não foi possível aceitar seu patch pois ele não está acompanhado de testes. Umas das nossas restrições com relação a patch e novas funcionalidades é que todas devem ser acompanhada de testes.
Entretanto o problema que você relatou é realmente relevante e por isso mesmo deixarei o bug em aberto para que, quando possível, algum dos desenvolvedores corrija.
Caso seja do seu interesse evoluir seu código para virar um patch que atenda as exigências do projeto a equipe estará a disposição para te ajudar no que for necessário.
Bug 18022 - Conflito de plugin.
Realmente confirmei que existe essa incompatibilidade. Não analisei mais a fundo o problema mas ao que me parece o plugin ActiveScaffoldLocalize modifica a forma como as validações são armazenadas e seus usos. Como apenas traduzimos, sem mudar nada, temos problemas sempre que o nosso plugin é iniciado após o ActiveScaffoldLocalize.
Estou analisando a melhor forma de solucionar esse problema.
Com relação ao link no Readme ele está correto. O segundo link nessa sua mensagem está errado pois o protocolo usado não é o http. O link correto é o do Readme (svn://rubyforge.org/projects/brazilian-rails/).
Bug 18077 - usar_como_dinheiro
O usar_como_dinheiro foi planejado para funcionar com o Active Record. Ele utiliza coisas específicas do Active Record, como, por exemplo, as validações.
Para utilizar em modelos que não tem herança do Active Record é necessário fazer uma nova implementação que no momento não está planejada mas quem sabe num futuro próximo possa ser feita.
Gostaria de agradecer a todos pelo feedback mas em especial ao Regis que mandou duas soluções prontas. Prometo tentar responder mais rapidamente.
Tags brazilianrails, plugin, rails, ruby | nenhum comentário
