Blog da Improve It

Bundles do Textmate

Publicado por Marcos Tapajós há 5 meses.

Acabei de publicar no Github um projeto chamado bundles onde fiz uma coletânia dos Bundles, do Textmate, que nós usamos aqui na Improve It.

Isso já existia no SVN interno mas toda hora que eu tinha que atualizar dava um certo trabalho pois utilizava um esquema de git-svn que não vou detalhar aqui pois o Akita já explicou isso no blog dele. Como era chato atualizar eu acabava fazendo isso com pouca frequência mas agora resolvi usar Git com o braid e tudo é bem mais simples.

O braid é um projeto com um objetivo parecido com o Piston só que bem mais novo e por ser um projeto com pouca colaboração ainda não está tão maduro quanto o Piston e possui alguns bugs.

O dono do projeto é uma pessoa bastante atenciosa e me ajudou muito com um bug que eu encontrei ontem. Se alguém quiser fazer algo muito útil para a comunidade Git a minha sugestão é colaborar com o braid. Infelizmente não estou com tempo para colaborar ativamente mas sempre que eu puder vou tentar.

Tags ,  | 2 comentários

The Idler

Publicado por Vinicius Manhães Teles há 5 meses.

Ontem tive que ir ao Detran buscar um documento e, na expectativa de gastar horas esperando pela boa vontade desta instituição tão "amada e eficaz", comprei uma "Super Interessante" para passar o tempo. Fazia tempo que não lia esta revista. Acabei me deparando com o trabalho de Tom Hodgkinson. Ele parece ser uma versão inglesa de Domenico de Masi, com a diferença de ser bem mais novo e, ao que parece, praticar o que prega. Domenico vem defendendo há anos que devemos mudar a forma como encaramos o trabalho. Deveríamos trabalhar menos, para começo de conversa. Mas, ele próprio, trabalha demais. Então, perde um pouco do moral. :-)

Voltando ao Tom Hodgkinson, ele defende a vagabundagem! E é bem sério a este respeito. Ele próprio está se tornando um vagabundo cada vez maior e diz trabalhar apenas três horas por dia. Segundo ele, "já tem muita gente fazendo coisas demais. Se você deixar de fazer tanto, já vai colaborar". O engraçado é que li isso pouco antes de entrar no carro e encarar DUAS horas para fazer o percurso de trinta quilômetros entre a minha casa e o projeto Lucidus (portanto, 15 km/h). Enquanto eu atravessava a Ponte Rio-Niterói e comentava com o Leandro sobre o vagabundo supracitado, me dei conta do quanto ele estava certo. Tem tanta gente fazendo tanta coisa que se algumas pessoas decidissem fazer menos, já ajudaria muito. Para começo de conversa, talvez elas ficassem mais tempo em casa e, com isso, parassem de colocar o carro na rua.

Vou ao Lucidus apenas uma vez por semana. O resto do tempo trabalho em casa. Ainda assim, cada vez que tenho que ir lá no Leblon, é um tormento. O transito piora a cada dia, a olhos vistos. No começo do projeto, talvez eu levasse uma hora, que já era muito. Como tempo, isso virou uma hora e meia e agora já estamos na casa das duas horas. Tudo isso em pouco mais de um ano!

Tem milhares de pessoas que fazem isso ou pior todo santo dia. Algumas têm o privilégio de trabalhar em um lugar legal. Enfrentam um trânsito do inferno, mas ao menos têm um trabalho digno e divertido. Mas, isto é a exceção. A maioria absoluta das pessoas faz este percurso infernal para chegar a um trabalho detestável.

Isso é uma questão que me intriga profundamente. Eu sei que todo mundo tem que defender o leitinho das crianças. Todo mundo tem contas para pagar. Todo mundo tem suas razões, mas, na boa, a situação atual nas grandes cidades chega ao cúmulo do ridículo. Será que isso realmente é o melhor que a gente pode fazer? Será que não há uma alternativa? Hoje já há várias pessoas aqui no Brasil trabalhando com desenvolvimento de casa. Tem tanta gente talentosa perdendo seu tempo em empresas idiotas e em engarrafamentos infernais. Será que não vale a pena procurar alternativas? Talvez não se consiga algo da noite para o dia, mas com um pouco de esforço e empenho na direção certa, muita coisa se torna viável.

8 comentários

Twitter

Publicado por Vinicius Manhães Teles há 5 meses.

Argh! Tentei resistir enquanto pude, mas me rendi a tentação de entender por que tantas pessoas inteligentes (e outras nem tanto) utilizam o Twitter. Até hoje não consegui "captar" a utilidade do treco. Em todo caso, vamos dar uma chance. Então, até que eu consiga provar para mim mesmo que se trata de algo completamente inútil, também terei uma conta no Twitter. No mínimo será uma tentativa de compreender o que torna uma aplicação tão utilizada.

6 comentários

Kluster

Publicado por Vinicius Manhães Teles há 5 meses.

Pessoal, alguém aí conhece e está usando o Kluster? Li sobre ele na Época Negócios, entrei para conhecer e está parecendo interessante. Confesso que ainda não entendi completamente o funcionamento do sistema. Mas, estou pensando em abrir um projeto por lá, nem que seja para buscar ajuda em coisas mais simples, como revisão de textos em inglês e outros tópicos relacionados ao que estamos fazendo.

1 comentário

Call for Help

Publicado por Vinicius Manhães Teles há 5 meses.

Este post é mais voltado para o próprio pessoal da Improve It, mas se alguém mais puder e/ou quiser ajudar, já adianto meu muito obrigado.

Galera da Improve It que está no Lucidus, sei que vocês já trabalham pra caramba por aí, mas se vocês chegarem em casa à noite e não tiverem nada mais divertido para fazer, tenho uma proposta divertidíssima. :-) Estamos precisando de ajuda para levantar informações sobre alguns assuntos críticos para o desenvolvimento do nosso produto.

Colocarei abaixo uma série de tópicos que precisamos conhecer melhor. Junto a cada um deles há uma lista de perguntas essenciais, cujas respostas serão de grande utilidade. Caso algum de vocês se interesse por um destes assuntos, por favor indique o assunto adicionando um comentário a este post. Se você decidir pesquisá-lo, o que eu peço é que você escreva as respostas e me envie até a próxima segunda-feira. As respostas nos ajudarão a tomar decisões sobre o desenvolvimento e o ferramental a ser usado. Também serão colocadas aqui no blog para que outras pessoas possam se beneficiar da pesquisa.

Para qualquer assunto que você venha a pesquisar, faça o seguinte:

Abaixo segue a lista de assuntos e perguntas específicas para cada um deles. Tais perguntas deverão ser respondidas de forma detalhada apenas para as duas soluções que você selecionar como melhores. As que não forem escolhidas apenas deverão ter seus nomes e links listados, mas não é preciso entrar em maiores detalhes.

Galera, como disse antes, sei que vocês já têm um monte de coisas para fazer no dia-a-dia. Mas, se tiver uma horinha que seja na parte da noite em que vocês estejam de bobeira, por favor, dêem uma olhada em algum destes assuntos. Acreditem, vai ajudar pra caramba! Mas, se não der, não tem problema. Mais importante que isso tudo é continuarmos fazendo um bom trabalho no Lucidus.

Tags  | 8 comentários

Improve It 2.0

Publicado por Vinicius Manhães Teles há 5 meses.

DISCLAIMER: não tente ler o post até o final, é grande demais. Não esquenta. Eu estava apenas pensando alto. Volta a cuidar dos seus afazeres antes que o chefe descubra que você está perdendo tempo.

É pessoal, a brincadeira acabou. Esta semana eu completo 32 anos. Destes, quase sete foram dedicados à Improve It. Foram bons anos, repletos de aprendizado e boas realizações. Mas, acredito que estamos encerrando nossa primeira etapa e está na hora de começar a próxima: a Improve It 2.0. Ok, eu sei que isso é pra lá de clichê, tipo Web 2.0 ou XP 2.0. Mas, já passa da meia-noite. Dá um desconto! :-)

No fim do ano passado nós anunciamos o fim dos nossos serviços relacionados a desenvolvimento ágil. Esta parte foi fácil. De lá para cá, colocamos três aplicativos no ar. Um vocês já conhecem, o just-remind.us, enquanto os outros dois ainda não. Fiquem tranqüilos, isso mudará em pouco tempo.

Apesar da mudança no fim do ano passado e dos aplicativos que entraram no ar nos últimos meses, diria que nós apenas encerramos a Improve It 1.0. Ainda não começamos a 2.0. O que fizemos nos últimos meses foi, digamos assim, um processo de transição. Agora isso chegou ao fim. Hora de começar a Improve It 2.0 para valer. O que a caracteriza?

Na Improve It 1.0, nós éramos uma empresa lucrativa, cujo faturamento tinha origem na prestação de serviços especializados, para um pequeno grupo de empresas. A Improve It 2.0 deverá ser uma empresa igualmente lucrativa, porém com faturamento proveniente do pagamento de assinaturas pelo uso de produtos. Ao invés de um pequeno grupo de empresas, o objetivo é ter um grande grupo de pequenas empresas e profissionais liberais, cada um pagando valores reduzidos pelo direito de uso de um ou mais dos nossos produtos.

Sair da 1.0 para a 2.0 é moleza, no discurso. Na prática, tudo indica que seja muito mais complicado. Se eu disser para vocês que sei como fazer esta transição, estarei mentindo. No máximo, posso dizer que tenho algumas pistas, mas é só. A única coisa que eu tenho certeza é de que vale a pena tentar. Vale muito a pena, porque se der certo, poderemos atingir resultados que seriam bastante difíceis de serem superados fazendo consultoria.

A questão que me aflige neste momento é: por onde começar? Desde o fim do ano passado, temos a idéia do que será nosso primeiro produto. Na semana passada, demos a ele um nome e criamos um logo. E agora? Qual o próximo passo?

Resolvi fazer um mind map para tentar identificar os inúmeros tópicos que teremos que levar em conta para criar, promover e operar o novo produto. Os tópicos que identifiquei estão longe de cobrir tudo o que precisaremos tratar, mas, compreendem itens tais como:

É tanta coisa que não sei nem por onde começar. E o pior é que eu tenho certeza de que o descrito acima não é nem a pontinha do iceberg. Nessas horas é que a gente precisa daqueles ditados famosos de auto-ajuda. Tipo, "toda grande jornada começa pelo primeiro passo." Ufa, agora me sinto aliviado. :-)

Mas, de novo, qual é o raio do primeiro passo? A minha suspeita inicial é que o primeiro passo é o marketing. Sim, eu sei que o produto ainda não existe. Praticamente ainda não escrevemos nenhuma linha de código dele. Ainda assim, tenho a forte sensação de que a primeira providência é tentar promovê-lo. Aliás, acredito que esta deverá ser uma das nossas maiores prioridades até o dia do lançamento (e depois dele também). Pouco vai adiantar fazer o melhor produto do mundo, se ninguém ficar sabendo dele.

Os anos de consultoria e desenvolvimento, bem como as aplicações que desenvolvemos desde janeiro, me deixam relativamente tranqüilo com relação à parte do desenvolvimento. Sei que nós temos a habilidade técnica para fazer o que desejamos. O que eu ainda não sei é se seremos suficientemente habilidosos para promover o que vamos fazer.

Nosso foco principal é o mercado externo. Embora isso englobe o mundo inteiro, é óbvio que nosso alvo principal começa pelos EUA. Isso tem inúmeras implicações. Primeiro, tudo o que fizermos terá que ser, no mínimo, em inglês. Segundo, temos que dar um jeito de fazer os americanos conhecerem a Improve It e seus produtos. A primeira parte é fácil. A segunda nem tanto. Neste sentido, o just-remind.us está sendo um experimento interessante.

Em XP, no Getting Real e em inúmeros outros métodos de trabalho, há uma máxima: tente falhar cedo! É uma das melhores formas de aprender. O just-remind.us está indo para duas semanas no ar. Pelas estatísticas de acesso, percebemos que há um bom número de pessoas usando-o no Brasil (apesar de ser apenas em inglês) e um número insignificante de acessos de outras partes do mundo. Veja o mapa abaixo:

Acessos Justremindus

Há acessos proveninentes de 36 países, mas a maior concentração é, disparada, no Brasil. Oooppsss, temos um problema! Até aqui, o just-remind.us não passa de uma falha estrondosa, quando pensamos em utilização em escala mundial. Sim, a aplicação não resolve os problemas mais graves da humanidade. Não é ela que vai resolver o problema da fome no mundo, nem vai reverter o aquecimento global. Mas, sejamos francos, ele resolve um problema real de um monte de gente. Um problema simples, mas real. Portanto, a falta de uso não tem a ver apenas com falta de mérito. Tem a ver também e, sobretudo, com a falta de conhecimento das pessoas sobre a existência da aplicação.

Se estamos tendo dificuldade para fazer as pessoas conhecerem e usarem uma aplicação "di gratis", imagina o tamanho do problema que teremos quando lançarmos alguma coisa paga! Putz, cadê aquela ponte que mencionei mais cedo? Vou me jogar. A menos que ............ (por favor, se você souber o que eu ponho aí do lado, pelamordedeus, me avisa).

Um pouco de XP para ajudar novamente: baby steps. O que podemos fazer hoje, que está sob nosso domínio, que vai nos ajudar a seguir em frente? Acho que a primeira providência é a gente se livrar do peso do passado. Neste caso, estou me referindo especificamente ao site da Improve It e este blog. Eles foram concebidos para dar apoio aos nossos serviços de consultoria. Honestamente, eles não ajudam em nada, ou quase nada, para o que queremos fazer na Improve It 2.0. Então, precisamos nos livrar disso e construir uma nova identidade. Precisamos, com urgência, de um site e um blog em inglês, com conteúdo que reflita nossos novos rumos.

Então, o que penso em fazer nos próximos dias é jogar tudo, ou quase tudo que temos hoje no site e no blog para outro domínio, o desenvolvimentoagil.com.br. Este é um domínio que já temos há tempos, mas não vinha sendo utilizado. O objetivo é tão somente manter os artigos, podcasts, fotos etc no ar. Feito isso, passaremos para a construção de uma nova identidade para a Improve It.

O segundo passo provavelmente será revelar ao mundo o que nós estamos fazendo. Isso representa uma mudança em relação à forma como eu imaginava tocar o desenvolvimento. Há pelo menos duas formas de se desenvolver um produto: uma fechada e outra aberta. A fechada é a maneira como a Apple (e a maioria das grandes empresas) faz as coisas. Eles passam um tempo trabalhando em segredo e um dia, bum, lançam um produto que o mundo inteiro transforma em necessidade absoluta quase que instantaneamente. :-) A segunda forma, a aberta, deve ser mais comum no desenvolvimento de softwares livres, por exemplo. Você lança uma idéia, busca pessoas interessadas e tenta criar uma comunidade em torno do produto. Esta comunidade, por sua vez, além de colaborar com o desenvolvimento, também ajuda a evangelizar o produto.

Inicialmente, pensei em usar a primeira abordagem, a da Apple. Acho que ela é a mais intuitiva para qualquer empreendedor, porque um dos nossos maiores medos é que alguém roube a idéia e acabe lançando o produto antes da gente e ficando bilionário da noite para o dia. :-) Pensando na Apple, acho que ela faz bem em manter segredo. Afinal, há uma multidão de consumidores e concorrentes olhando cada passo dela. Qualquer informação que vaza, pode e será usada pela concorrência para tentar superá-la. O detalhe importante nesta história é o mais óbvio de todos: nós não somos a Apple e estamos muito, muito, muito longe de ter os mesmos problemas dela. A chance do que estamos fazendo chamar a atenção de algum concorrente grande, significativo, é ínfima. Pode acontecer? Pode. Mas, acredito que este não é nosso principal problema, ainda. Por enquanto, nosso principal problema é o total desconhecimento sobre o produto que fizermos.

Na segunda abordagem, nós compartilhamos com vocês o que pretendemos fazer. Vocês passam a ficar sabendo o que é o produto, o que ele se propõe a fazer e mais uma série de coisas. Assim, a gente pode começar a receber feedback mais cedo. Se vocês gostarem da idéia, é possível que se interessem suficientemente, ao ponto de querer usar o produto e, quem sabe, falar sobre ele para os amigos. Talvez vocês possam até nos ajudar a colocá-lo no ar mais cedo. Nós acreditamos no produto. As pessoas que conhecem o que fizemos para a Júlia querem o mesmo para elas. Até eu quero este produto! Vai resolver vários dos nossos problemas. :-)

Ainda não sei descrever completamente a razão pela qual acredito que revelar o produto desde já será a melhor alternativa. Por enquanto, é mais um sentimento apoiado por alguns argumentos ainda frágeis. Com o passar dos dias, talvez eu compreenda um pouco melhor. Uma coisa é certa, entre correr o risco de ser copiado e o risco de fazer um produto que ninguém conheça, prefiro lidar com o primeiro. Para mim, a pior coisa que pode existir é fazer um trabalho que ninguém venha a usar, sobretudo por desconhecimento.

Então é isso, agora é para valer! A Improve It 2.0 está começando. Que Deus nos ajude e que a gente consiga fazer isso dar certo! Porque se não der, só me restará uma alternativa: largar a computação. Fechar a empresa e voltar a trabalhar neste mercado de malucos não vai rolar. Se não der certo, eu saio desta área e vou fazer qualquer outra coisa. Aqui, no meio desde bando de aloprados corporativos é que eu não vou ficar! :-)

Tags  | 12 comentários

Fanfarrão Certification Process

Publicado por Vinicius Manhães Teles há 6 meses.

Pessoal,

Sei que sempre fui contra certificações de todos os tipos na área de desenvolvimento. Sei que sempre rejeitei coisas como CMMI, MPS.BR, PMI e até mesmo as certificações estapafúrdias do mundo ágil, com o CSM e tal. Mas, tenho que admitir. Certificar é o caminho. Não tem jeito.

Pensando nisso, eu e alguns amigos que estavam no FISL resolvemos criar uma nova certificação, algo que vai revolucionar o mercado de software mundial. E tudo começará com o lançamento da FanfAlliance.

Indo para Porto Alegre, escrevi este post onde acabei chamando a maioria dos desenvolvedores de software de fanfarrão. Lá em Porto Alegre, dei uma palestra onde basicamente chamei todo mundo que estava presente de imbecil. Expliquei que mais imbecil ainda eram os chefes dos que lá estavam. Por causa desta bobeirinha, fui chamado de Capitão Vinícius "nascimento" Teles. Pode?

Juntando o post e a palestra, concluí que tem muito fanfarrão nesta área e que eles precisam ser certificados! Isso mesmo. Vamos certificar essa galera.

A FanfAlliance está surgindo e precisamos da sua ajuda para criar as regras da certificação. Abaixo algumas idéias que emergiram durante o último dia do FISL:

Nós adoramos coisas simples, como a certificação CSM. Achamos que o CSM foi um passo importante na direção da simplicidade, ao demandar que você apenas esteja presente em um treinamento de dois dias para ser certificado. Para que prova? Para que outras verificações, quando estar presente (acordado ou não), já resolve o problema? Nós queremos ir além e mais, queremos democratizar.

As "Certificações Fanfarrão" são expressas, simples e acessíveis. Você entra no site e já está certificado! Isso mesmo, simples assim. E o melhor, você já recebe o nível mais alto de certificação: CFG - Certified Fanfarrão Guru! Alegre-se, pois estás em boa companhia. O primeiro a receber esta honraria foi ninguém menos que Bill Gates!

Por outro lado, se você respeita certas práticas dos métodos ágeis de desenvolvimento, seu título pode ser revogado e você pode acabar sendo rebaixado para CFMU - Certified Fanfarrão Masters of the Universe. Ok, eu sei que não é tão high level quanto um CFG, mas já é alguma coisa, né? Para aqueles que sempre invejaram as palavrinhas "Certified" e "Master" do CSM, temos excelentes notícias. Fomos além, adicionamos o "Universe"! Agora, eles que tratem de arrumar algo mais marketeiro que o nosso!

Algumas empresas merecem ser certificadas como um todo, por isso criamos a CFC - Certified Fanfarrão Company. Alegre-se mais uma vez, pois até prova em contrário, sua empresa já está certificada nesta categoria! E, claro, não podemos nos esquecer dos CFP - Certified Fanfarrão Partner (por favor, não insista em confundir com Certamente um Filho da Puta). Esta categoria é reservada para as distintas empresas de consultoria que espalham o espírito de desenvolvimento Fanfarrão pelo mundo a fora. Normalmente têm três letrinhas e são um exemplo a ser seguido por todo Fanfarrão que se preze!

Finalmente, não poderíamos deixar de homenager os CFT - Certified Fanfarrão Trainer. São aqueles queridos professores que ensinam o jeito fanfarrão de desenvolver software. Professores de engenharia de software, de um modo geral, já ganham a certificação sem nem entrar no site. Eles já estão certificados, só não sabem disso ainda!

Por fim, há aqueles que envergonham o mundo fanfarrão, ao disseminar e, sobretudo, utilizar, práticas ágeis de desenvolvimento de software. Estes serão sumariamente des-certificados (shame on them), pois não seguem princípios canônicos do Manifesto Fanfarrão, tais como:

Fanf Principles

  1. Infernizar a vida dos usuário é nossa maior prioridade.
  2. Código sem testes é nossa principal ferramenta.
  3. POG é nossa filosofia de vida.
  4. Quanto mais featues, mais próximos ficamos do Nirvana (especialmente se elas tiverem muitos bugs).

A FanfAlliance precisa da sua ajuda. Precisamos de idéias para melhorar a descrição das categorias. Queremos colocar um site no ar para que possamos iniciar o processo acelerado de certificação em massa. Finalmente uma certificação livre! Você não precisa pagar nada. Só precisa ser um tremendo Fanfarrão.

Estamos planejamento o lançamento de Primeira FanfConf. Ela deverá ser realizada por volta do dia 30 de fevereiro do próximo ano, em algum lugar perto de Redmond, a Meca do movimento Fanf! O Call for Papers deve ser lançado em alguns dias, mas sinta-se à vontade para começar a enviar propostas de palestras.

Para aqueles que precisarem de ajuda para obter melhores colocações no mundo Fanfarrão, estamos preparando as Fanf Scholarships. Afinal, não podemos admitir exclusão social no Movimento Fanf.

RECORTAR AQUI XXX-------------------------------

Ok, para quem chegou até aqui, já deu para ver que trata-se de uma tremenda zoação! :p

Como vocês sabem, cansei de vender idéias ágeis pelos métodos tradicionais. Embrace change! Agora estou partindo para iniciativas não-convencionais, como esta. Quem me conhece sabe que isso é um protesto contra a babaquice generalizada em que a nossa área está se transformando há um bom tempo. E as certificações exercem um papel enorme nesta idiotice geral. Não apenas as que citei aqui, mas inúmeras outras como as do mundo Java e tal.

Quero lançar o site da Fanf Alliance para que outras pessoas também possam protestar, nem que seja zoando este mundo ridículo que estamos criando para nós. O que está aí são algumas idéias lançadas em um pedaço de papel, em um almoço no FISL, onde três pessoas riram até não poder mais criando estas siglas.

Ajude-nos a dar continuidade. Olhe para o lado e nos envie idéias. É possível que o seu ambiente de trabalho atual possa nos fornecer material farto para criar o processo de certificação mais democrática e abrangente do mundo: o Fanf Certification Process.

Contamos com a sua ajuda e com o ódio generalizado de todos aqueles que levam adiante esta porcariada toda!

Tags  | 16 comentários

Brazilian Rails no github

Publicado por Marcos Tapajós há 6 meses.

Acabei de terminar a migração do plugin Brazilian Rails para o github. Achei que ia ser bem mais complicado do que foi ! :-)

Nós decidimos manter o SVN como um espelho (por um tempo) para facilitar a instalação nas versões anteriores a Rails Edge. Agora existem duas formas de instalação que estão detalhadas na página do plugin.

Para quem quiser acompanhar o projeto a url no github é:

http://github.com/tapajos/brazilian-rails

Tags , , , , ,  | nenhum comentário

Novidades no Brazilian Rails

Publicado por Marcos Tapajós há 6 meses.

O Tino acabou de publicar no blog dele as últimas mudanças do Brazilian Rails.

Tags , ,  | nenhum comentário

O desenvolvimento do Just-remind.us

Publicado por Vinicius Manhães Teles há 6 meses.

Enquanto estou de castigo aqui em São Paulo, aguardando o vôo de conexão que me levará ao FISL, achei que seria uma boa comentar um pouco sobre o desenvolvimento do Just-remind.us.

A idéia original era fazer um "projetinho" de uma semana. Mas, um "projetinho" nunca é um projetinho, estão, acabamos gastando três semanas. A equipe de desenvolvimento era composta por três pessoas: Tapajós e eu na programação, e o Leandro no design. Eu e o Leandro trabalhamos full-time, quatro dias por semana, enquanto o Tapa foi part-time.

O protótipo básico da aplicação, com a tela dos cartões e o formulário de edição, ficou funcional ao final do primeiro dia. Afinal, o sistema não poderia ser mais simples. Então, com um pouquinho mais de trabalho, poderíamos ter colocado o sistema no ar em dois ou três dias certo? Depende. Queríamos passar um tempão corrigindo bugs após o deploy, ou a idéia seria terminar este projeto e começar outro sem se preocupar com bugs no Just-remind.us? Definitivamente a gente prefere a segunda opção.

Odeio corrigir bugs e morro de vergonha quando encontram um bug em algo que eu fiz. Então, só há uma opção, óbvia por sinal: testar freneticamente. Mas, parece que tudo que é óbvio tem uma tendência incorrigível de ser negligenciado. Mas, não aqui.

Nós fizemos muitos testes no Just-remind.us. Para começar a explicá-los, vejam a imagem abaixo:

Stats do Justremindus

A primeira parte da imagem mostra o resultado de um rake stats no projeto. Como se pode ver, são 548 linhas de código Ruby, contra 1419 linhas de código de Specs, ou seja, 2.6 vezes mais linhas de Specs que linhas de código da aplicação. Nos Specs, nós temos 223 exemplos que cobrem 100% das linhas de código do projeto (segundo o RCov).

A segunda parte da imagem mostra a execução de um rake stats_with_selenium. Mais, hein? Pois é, nós usamos o Selenium exaustivamente para fazer testes funcionais. Na boa, não dá para fazer uma aplicação web sem usar algo assim. Sério, não dá! Se você acha que dá, me desculpe, mas você é um fanfarrão! :p

Uma coisa que sempre me incomodou no rake stats é que ele não diz nada sobre os HTMLs e o Selenium. Mas, eles também representam uma parte significativa do projeto. Então, pedi ao Tapa que fizesse uma nova versão rake stats que contabilizasse também o Selenium e isso é justamente o que está na segunda parte da figura.

Note que só de Selenium nós temos 1311 linhas de código. A contagem total agora considera 865 linhas de código da aplicação e 2730 linhas de código de teste. Agora, são 3.2 vezes mais código de teste que da aplicação. Nada mal! O Selenium executa 1243 validações através de 58 cenários de teste.

Agora vem a pergunta: faz sentido todo este esforço para uma aplicação tão pequena? Essa pergunta está incorreta, para ser honesto. a pergunta certa é: faz sentido não fazer este esforço? Minha resposta para esta última é, definitivamente, não.

A quantidade de problemas que nós detectamos com estes testes e, sobretudo, a gravidade destes problemas, é surpreendente. Mesmo em uma aplicação ridiculamente pequena como esta, a quantidade de detalhes é inacreditável. Um aspecto que nos preocupou muito era a segurança dos dados dos usuários. Descobrimos vários problemas de segurança fazendo os testes. Obviamente corrigimos todos bem antes de colocar o sistema em produção. Agora eu pergunto: e se nós não tivéssemos feito os testes? Você ficaria feliz de saber que seus dados estão registrados em um sistema que mais parece um queijo suíço, de tanto furo de segurança que tem?

Bem, o sistema está no ar há dois dias. Até aqui, tivenos, no total, 839 visitantes únicos, 1044 visitas e 5069 page views. Não é muito. Mas, é interessante notar que ainda não houve nenhum bug reportado. Provavelmente deve existir algum problema ainda, porque a quantidade de detalhes realmente é grande. Mas, até agora está tudo bem. Exatamente o que nós queríamos que acontecesse. A única bobeira que nós demos (e já sabemos) foi de design. Ontem à tarde nós colocamos uma nova versão no ar, que tinha um errinho de CCS, bem visível na primeira página. Mas, isso foi corrigido pouco tempo depois. A propósito, se vocês detectarem algum problema, por favor, nos avisem.

Desenvolver software sem testes não é apenas coisa de fanfarrão. É coisa de irresponsável. É impossível uma atividade tão complexa quanto desenvolver software ser conduzida sem testes automatizados, em uma quantidade absurda. Quer dizer, possível é, mas não é aceitável. Nem mesmo para um sistema simples como esse.

Todo mundo diz que não tem tempo para testar. Mas, isso é a maior mentira do mundo. Todo mundo acha isso porque conta o tempo errado. O que importa em desenvolvimento de software não é o tempo de desenvolvimento, mas sim o tempo de vida da aplicação. Ou seja, ao longo do tempo de vida da aplicação, quanto tempo você vai ter que dedicar a ela? O desenvolvimento original da mesma é apenas uma parcela do problema. Normalmente a parcela maior vem depois, durante todo o restante do tempo de vida do aplicativo. Você vai ficar corrigindo bugs nele todo dia, ou vai estar liberado para desenvolver outra coisa?

A visão tradicional de que não dá tempo é míope. Não enxerga a grande verdade: o tempo de desenvolvimento é o menor dos problemas!

Semana que vem, vida nova. Vamos tocar nosso primeiro aplicativo comercial, aquele outro segredo que ainda vai levar um tempo para ser revelado. ;-)

Tags  | 7 comentários

Artigos antigos: 1 2