Desenvolvimento Ágil - Blog da Improve It

Vídeo da palestra feita no Encontro Locaweb de Desenvolvedores

Vinicius Manhães Teles — Fri, 11 Jun 2010 12:15:47 -0300

Acaba de sair o vídeo da palestra que fiz no 12o Encontro de Locaweb de Profissionais de Internet em maio de 2010. Conta um pouco da minha história como empreendedor, como a Improve It surgiu, o envolvimento com Extreme Programming, o desencanto com o mundo da consultoria, a criação do Be on the Net é outros assuntos.

Apelo: parem de "ensinar" Comp. I nas faculdades!

Vinicius Manhães Teles — Fri, 28 May 2010 09:03:00 -0300

Faço um apelo aos cursos universitários de computação: parem de ensinar "Comp. I". Ao invés disso, usem o horário que seria da aula para os alunos fazerem Dojo de programação. Essa é uma ideia que certamente será ignorada, mas, estou certo de que poderia elevar demais a qualidade da formação dos "calouros" de computação, se fosse adotada.

Todo curso de computação tem uma matéria introdutória para os alunos "aprenderem" a arte da programação. Em alguns lugares chama-se Computação I, em outros Introdução à Programação e assim por diante. Com raríssimas exceções, o aluno começa o semestre sabendo pouco de programação e termina sabendo tão pouco quanto, mas com a falsa sensação de saber um pouquinho mais. Em outras palavras, é tempo mal investido, tanto para os professores, quanto para os alunos. Em alguns casos, é o suficiente para o aluno abandonar a Computação.

Isso não reflete a falta de esforço do professor em fazer os alunos aprenderem. Mas, sim a ineficácia do método, em comparação a outros mais poderosos e prazerosos. Estou me referindo ao Dojo, naturalmente. E para mostrar o porquê, citarei o exemplo do que está acontecendo na UFF.

Ontem estive no Dojo de programação da UFF, que acontece toda quinta à noite e é aberto a toda a comunidade de desenvolvimento do Rio de Janeiro, Niterói e adjacências. Desde a semana passada, estamos contando com a presença de muitos calouros, o que é excelente. Só que ontem foi especial.

O problema escolhido foi o Jokenpo, ou Pedra, papel e tesoura. O enunciado do problema é simples, mas a solução tem uns detalhezinhos que deixam espaço para a galera pensar um bocado.

Como acontece em todo Dojo, os participantes programaram em par, em períodos de tempo bem curtos (4 ou 5 minutos).

O pessoal sempre começa fazendo um teste automatizado e, em seguida, a implementação mais simples que possa passar no teste recém projetado. Tudo no melhor estilo baby steps. E a linguagem escolhida para ontem foi Javascript, com o uso do framework de BDD JSSpec.

A solução começou simples, mas rapidamente avançou para um código que estava desagradando a todos. Em um certo momento, havia umas vinte linhas de código com inúmeros if-then-else pelo caminho. Os testes passavam, mas o código estava horrível de entender. Eu já não conseguia mais olhar para ele. Doía demais.

Foi quando parei de olhar o código e comecei a olhar o enunciado do problema novamente. Tinha que haver uma forma decente de fazer aquilo e comecei a criar alternativas na mente. Lá pelas tantas, tive uma ideia que permitiria limpar toda aquela bagunça e reduzir aquele monte de condições a uma única condição de exceção, aliada a uma outra estratégia de solução.

Quando chegou o momento da platéia se manifestar com sugestões, dei a minha ideia. A galera viu que fazia sentido, mas antes que pudessem começar a implementar, outra pessoa deu sua ideia. E a boa notícia é que era muito melhor que a minha. Seguindo a estratégia sugerida, não teríamos mais nenhum *if* e o código ficaria incrivelmente claro e fácil de compreender.

A nova estratégia foi explicada no quadro, não porque fosse complicada, mas porque envolvia o uso de um mecanismo que não era tão familiar a todos os calouros. Nada específico de programação. Apenas um recurso simples da matemática, que não vou mencionar aqui para não estragar o prazer de quem vier a participar de um Dojo com este tema. Feito isso, aqueles que estavam pilotando o computador começaram a alterar a implementação.

Minutos depois, a nova implementação estava pronta e rodaram os testes. Todos passaram gloriosamente! E nesse momento fez-se a luz. E o código antigo foi deletado. E o povo aplaudiu! De verdade! :-)

Rafael, o autor da solução, é aluno de Computação da UFF. Está no terceiro período e bolou uma estratégia que deixou todos nós, inclusive os mais experientes, estupefatos. No meu caso, por exemplo, devo ter mais tempo "mexendo" com computadores que o Rafael tem de vida. Mas, ainda assim, ele criou uma estratégia que nem eu, nem nenhum dos demais, foi capaz de bolar. E esse é o tipo de coisa que acontece direto nos Dojos.

E então a ficha caiu para mim. Comecei a olhar para os calouros com inveja. Por que não tive acesso a esta técnica (Dojo) quando eu era calouro? Aliás, nem em toda a graduação, nem durante o mestrado! Aí percebi quanto tempo foi investido em formas menos eficazes de aprendizado.

O Dojo é um ambiente de aprendizado impressionante. As pessoas aprendem em grupo, o que é sempre muito legal. O exercício é colaborativo, então, ninguém sai perdendo. Todos saem ganhando. Os participantes programam em par e aprendem a apreciar o valor dessa técnica. Além disso, têm que fazer testes automatizados antes de implementar cada funcionalidade, portanto, aprendem a trabalhar com TDD ou BDD. De quebra, aprendem a usar o framework de teste da linguagem que está em uso. Ah sim, eles eventualmente aprendem um pouco sobre a linguagem escolhida para a sessão do Dojo. Tudo isso é muito bacana, mas é só o começo.

Uma das coisas mais legais que acontecem em um Dojo é que os participantes são expostos a diferentes abordagens para resolver o mesmo problema. Portanto, eles têm acesso a inúmeras estratégias novas para modelar o problema. Se comparássemos o aprendizado da arte de programar com o aprendizado de um novo idioma, diria que estamos ampliando nosso vocabulário, toda vez que somos expostos a novas formas de modelar o mesmo problema, por mais simples que seja o problema.

O resultado inevitável disso é a refatoração. Os participantes aprendem uma nova estratégia ao longo da sessão do Dojo, refatoram o código e, com os testes, verificam se tudo continua funcionando. Portanto, refatoração é mais um tema aprendido. E ainda não acabou.

Sempre há uma retrospectiva no final de cada Dojo, na qual as pessoas avaliam o que funcionou bem e o que poderia ser melhorado. Retrospectiva é uma técnica aclamada em todos os métodos ágeis de desenvolvimento de software. Está presente no XP, no Scrum e em qualquer abordagem bem sucedida de desenvolvimento.

Para que não haja dúvidas, vamos fazer uma rápida revisão de tudo o que é aprendido no Dojo:

Programação em par
TDD e/ou BDD
Refatoração
Novas formas de modelar um problema
Aspectos de uma linguagem de programação
Como usar o framework de teste da linguagem adotada
Baby steps
Retrospectiva

E tudo isso em apenas 2 horas de Dojo, exatamente o mesmo tempo que dura uma aula convencional nas universidades. Compare o aproveitamento dessas duas horas com o aproveitamento de duas horas de uma aula tradicional de programação! A diferença é escandalosa.

Em muitos cursos de computação os calouros têm alguma matéria do tipo "Comp. I" com duas aulas por semana, cada uma com duas horas de duração. Imagine se não houvesse aula, mas apenas Dojo. Então, teríamos duas sessões de Dojo por semana, durante um semestre inteiro. Se isso fosse adotado, tenho absoluta certeza de que os calouros chegariam no final do semestre sabendo programar mais e melhor que 90% daqueles que se formam em computação. E não só isso, eles saberiam programar mais e melhor que a maioria dos professores universitários que "ensinam" programação!

Afinal, quantos professores dominam TDD e BDD, boas práticas de orientação a objetos, técnicas de refatoração, tudo isso em diferentes linguagens e ainda têm o hábito de programar em par e fazer retrospectivas? Garanto que poucos. E é aí que a minha ideia começa a ir por água abaixo.

Porque para que ela fosse adotada, seria preciso, primeiro, vencer uma barreira cultural que me parece intransponível. A ineficiência do "cuspe e giz" aliada à insanidade das "provas" que não avaliam absolutamente nada, compõem uma muleta atrativa demais para deixar de ser usada. Mas, ainda que fosse possível vencer essa barreira, teríamos que lidar com um mar de professores que simplesmente não sabem programar bem.

Quando penso em tudo isso, não consigo deixar de lembrar da Fábula dos Porcos Assados. E vejo o quanto as universidades "queimam florestas" para "ensinar" muito pouco, ao longo de muito tempo, quando há atualmente uma abundância de técnicas de ensino mais úteis, quase sempre envolvendo algum tipo de jogo.

Aliás, cada vez mais me dou conta da importância de trazer jogos para o processo de aprendizado. Eles são muito poderosos, tanto no sentido de transmitir a mensagem, como fazer com que ela fique gravada para sempre. Quando fazia consultoria de XP, costumava usar instrumentos como o Jogo da Comunicação, o XP Game, o Extreme Hour, entre outros. Todos eram muito eficazes, embora consumissem pouco tempo e fossem muito divertidos.

Seria fantástico se pudéssemos remodelar o sistema de ensino em torno de jogos como esses. Estou certo de que todos aprenderíamos muito mais, em menos tempo e nos divertiríamos demais no processo.

Participe de um dos muitos Dojos do estado do Rio. Acesse o site do Dojo Rio, entre na lista de discussão e apareça no Dojo mais próximo de você! De quebra você ainda vai ter a chance de curtir o pós-Dojo, que torna tudo ainda mais divertido.

Escrito por: Vinícius Manhães Teles (Twitter).

Obs: a maioria das fotos deste artigo são de autoria do Pedro Menezes que as disponibiliza como Creative Commons. O vídeo foi feito pelo Henrique Bastos.

Palestra: Fuja da escravidão antes que ela te alcance

Vinicius Manhães Teles — Mon, 24 May 2010 10:42:45 -0300

Tive o privilégio de fazer uma palestra na última PythonCampus no LNCC, em Petrópolis, RJ. Os slides estão aí embaixo:

Fuja da escravidão antes que ela te alcance

View more presentations from Vinicius Teles.

Ainda não sei se alguém filmou a apresentação. Mas, se tiver filmado e eu tiver acesso, irei colocar aqui.

Você também pode baixar os slides nos formatos a seguir:

Sinta-se à vontade para usar os slides como desejar. Você pode alterá-los e distribuí-los como bem entender. Eu não reservo nenhum direito sobre os slides. Portanto, são seus para fazer o que quiser com eles. Divirta-se! ;-)

MacRuby

Vinicius Manhães Teles — Thu, 10 Dec 2009 02:44:32 -0200

English version

Você gosta da interface gráfica dos Macs? Quem não gosta, né? Ela é um dos pontos altos da plataforma Macintosh, bem como do iPhone. Tudo viabilizado, em grande parte, por uma tecnologia chamada Cocoa.

No Mac, é possível criar interfaces gráficas em Cocoa, facilmente, utilizando o Interface Builder. Basta arrastar componentes de um lado para o outro, indicar ações e estabelecer conexões com o código. Ah sim, o código é implementado em Objective-C.

Objective-C é uma linguagem orientada a objetos que se aproxima bastante das características de Smalltalk. É uma linguagem com conceitos muito interessantes, porém bem verbosa. E pode representar uma barreira razoável para aqueles que gostariam de implementar aplicativos desktop no Mac, ou mesmo aplicativos no iPhone, especialmente se compararmos a outras linguagens como Ruby.

Pois Ruby é uma linguagem que foi feita com o objetivo de facilitar a vida do programador. É fácil, muito simples, extremamente expressiva e, de um modo geral, adorada por aqueles que a utilizam, incluindo eu mesmo. :-)

Então, de um lado temos uma tecnologia excepcional para interfaces gráficas, chamada Cocoa e de outro uma linguagem excelente chamada Ruby. Não seria ótimo se pudéssemos juntar as duas e ter o melhor dos dois mundos? Bem, isso já é possível há algum tempo usando, por exemplo, o RubyCocoa, que faz uma ponte entre Ruby e Objective-C. Entretanto, atualmente há uma opção ainda melhor chamada MacRuby.

MacRuby é uma versão do Ruby 1.9, portada para rodar diretamente sobre tecnologias que formam o core do Mac OS X tais como o runtime do Objective-C e o garbage collector, entre outros. A ideia é poder criar aplicações desktop no Mac OS X, sem sacrificar o desempenho, usando todos os benefícios do Ruby. Ainda está em desenvolvimento, mas o que está pronto já faz muito e o projeto como um todo é extremamente promissor.

Nestes últimos dias implementei uma pequena funcionalidade usando MacRuby e Cocoa. É algo útil para nosso dia a dia, embora bem básico, com o objetivo de configurar novos domínios DNS do Slicehost, que é onde hospedamos nossos sites. Irei disponibilizar o código no GitHub em breve.

Achei muito fácil fazer a implementação usando Cocoa e MacRuby, de modo que pude comprovar que o propósito do projeto MacRuby está sendo cumprido, ao menos naquilo que usei até o momento. Estou muito empolgado com tudo o que é possível fazer usando MacRuby, sobretudo com a agilidade e a facilidade de desenvolver dessa forma. Sendo assim, gostaria de recomendar aos interessados que deem uma olhada nele com carinho.

Vale dizer que eu já tinha algum conhecimento de Cocoa e Objective-C antes de fazer esse aplicativo. Minha principal referência tem sido o livro Cocoa Programming for Mac OS X.

Gostaria de agradecer ao Matt Aimonetti, que gentilmente me falou sobre o MacRuby, no Hora Extra, quando esteve aqui no Rio recentemente. O que, além de tudo, demonstra a importância de participar sempre do Hora Extra. :-)

E se você ainda não tiver se empolgado pelo MacRuby, aí vão algumas informações adicionais. O projeto é patrocinado pela própria Apple que tem grande interesse nele. De fato, o criador do projeto MacRuby, o belga Laurent Sansonetti trabalha na Apple e atualmente é pago pela empresa para trabalhar basicamente no MacRuby. Por que?

Porque em um futuro próximo, poderemos desenvolver aplicativos para o iPhone usando MacRuby! E isso abre espaço para que uma enorme leva de programadores Ruby comecem a produzir aplicativos para o iPhone. Portanto, se você ainda não programa em Ruby, talvez esteja aí o empurrãozinho que faltava. ;-)

Palestra no Rails Summit 2009

Vinicius Manhães Teles — Mon, 19 Oct 2009 14:48:10 -0200

O Rails Summit 2009 foi um evento excepcional. Mais uma vez, gostaria de deixar meu muitíssimo obrigado ao Akita, à Locaweb, aos demais organizadores, aos patrocinadores e aos participantes por terem viabilizado essa conferência. Estão todos de parabéns. Foi fantástica.

O Hugo Borges gentilmente filmou várias palestras e colocou à disposição. Isso é bem legal e já vai adiantar as coisas até que os vídeos oficiais sejam liberados. A minha apresentação pode ser vista abaixo ou diretamente, no Blip.tv.

Veja também as as demais apresentações do Rails Summit 2009 filmadas pelo Hugo.

Durante a conferência, tive a oportunidade de reencontrar muitos amigos e fazer muitos outros. Depois, várias pessoas vieram aqui para o Rio e nos divertimos muito, com direito a Festa Framps no último sábado, encerrando com chave de ouro uma semana para lá de divertida. Já estou na expectativa para o Rails Summit 2010! :-)

Vídeo da palestra Marketing na internet, no mundo da abundância

Vinicius Manhães Teles — Sat, 03 Oct 2009 22:27:44 -0300

A palestra Marketing na internet, no mundo da abundância, realizada na última quarta-feira, 30/09/2009, foi gravada e pode ser vista abaixo. Também é possível baixar o PDF dos slides.

Na próxima quarta, estaremos de volta, com o Workshop: Como se destacar fazendo menos e colhendo mais.

Workshop: como se destacar fazendo menos e colhendo mais
Dia: Quarta-feira, 07 de outubro de 2009
Horário: das 14h às 18h (horário de Brasília)
Investimento: R$ 199,00
Onde: no seu computador através do TreinaTom
Instrutores: Patricia Figueira e Vinícius Teles

Veja o conteúdo completo. Faça sua inscrição o quanto antes e garanta sua vaga.

Palestra: marketing na internet, no mundo da abundância

Vinicius Manhães Teles — Mon, 28 Sep 2009 08:23:37 -0300

Na próxima quarta-feira, 30 de setembro de 2009, às 15h, nós teremos um bate-papo. Vamos conversar sobre como promover seu negócio na internet.

Por que falar disso? Porque talvez seja a habilidade mais importante que um empreendedor tenha que dominar atualmente.

Participe! É muito fácil, é de graça e você não precisará nem sair de casa.

Faça sua inscrição o quanto antes. Você receberá a confirmação por email, com as instruções necessárias para ter acesso à palestra.

Serão dois palestrantes, a fotógrafa Patricia Figueira e Vinícius Teles, autor de "O Mundo de Joana".

Inscreva-se já! E divulgue nas listas de discussão, no Orkut, no Facebook, no Twitter! Envie esse convite por email para seus amigos. Participe!

Palestra: Marketing na internet, no mundo da abundância.
Dia: Quarta-feira, 30 de setembro de 2009.
Horário: 15h (horário de Brasília).
Onde: no seu computador. Instruções para acesso no email de confirmação.
Palestrantes: Patricia Figueira (@patfig) e Vinícius Teles (@viniciusteles).

Faça sua inscrição agora!

Migrando o Brazilian Rails para Ruby 1.9

Marcos Tapajós — Wed, 23 Sep 2009 00:51:00 -0300

Algumas semanas atrás Fernando Luizão migrou o Brazilian Rails para funcionar no Ruby 1.9 mantendo a compatibilidade com o Ruby 1.8.X. Estou para divulgar isso tem alguns dias porém eu não tive muito tempo.

Ele explicou em detalhes no blog dele tudo que foi necessário fazer.

Deixo aqui registrado meu muito obrigado ao Fernando.

Entrevista com Luca Bastos no Dev in Rio

Vinicius Manhães Teles — Mon, 21 Sep 2009 14:19:30 -0300

Na semana passada estive no Dev in Rio. O evento foi excepcional! Já estamos na expectativa pela próxima edição.

No final do evento, entrevistei Luca Bastos, que está sempre presente no eventos mais bacanas. Há tempos que queria gravar um bate-papo com ele. O resultado está abaixo:

Entrevista com Luca Bastos from Improve It on Vimeo.

Ruby on Rails com CouchDB usando Couchrest

Vinicius Manhães Teles — Mon, 14 Sep 2009 11:07:30 -0300

No último sábado participei do Rails for Kids, um excelente evento organizado pela eGenial. Minha apresentação foi sobre como utilizar Ruby on Rails com CouchDB, com a ajuda da gem Couchrest. Para facilitar a apresentação e passar o máximo de informação nos trinta minutos disponíveis, optei por fazer um screencast, que mostra o básico dessa integração do Rails com o CouchDB.

Você pode ver o screencast abaixo.

Ruby on Rails com CouchDB usando Couchrest from Improve It on Vimeo.

O vídeo termina de forma um tanto abrupta, porque tentei me manter o máximo possível dentro do limite de tempo, deixando ainda alguns minutos livres para responder a perguntas. Seja como for, é possível fazer muita coisa com o CouchDB usando os conceitos básicos mostrados no vídeo.

Como gostei da experiência de preparar este, é possível que eu faça outros futuramente, inclusive dando sequência ao que está aí. Espero que seja útil.

Screencast no suporte: uma parceria que deu certo

Vinicius Manhães Teles — Thu, 10 Sep 2009 15:35:39 -0300

Foto de Bryce Johnson (CC)

A palavra suporte logo nos faz pensar em call center e todo o sofrimento habitual de conversar com pessoas que nunca conseguem resolver nosso problema. Ao criarmos o Be on the Net, passamos a ter que dar suporte também. A questão é como fazer isso de modo apropriado e economicamente viável.

A solução que encontramos foi investir pesadamente na criação de screencasts. Criamos um screencast para cada assunto que precisamos ensinar aos nossos usuários. Alguns tópicos nem têm a ver diretamente com o uso do Be on the Net, mas são questões que afetam a forma como nossos usuários apresentam seus trabalhos da internet. Então, nos interessa ajudar e orientar as pessoas, tanto quanto possível.

O investimento nos screencasts foi considerável. Foram meses de trabalho até alcançarmos a base de vídeos que temos hoje. São vídeos que tipicamente são vistos apenas por nossos clientes. Mas, resolvemos publicar um aqui, para que vocês possam ter uma ideia.

O vídeo abaixo mostra como colocar tags em fotos, usando o Lightroom. Na verdade é útil para qualquer fotógrafo, mesmo aqueles que não usam o Be on the Net. Por isso resolvemos publicá-lo.

O screencast permite que o cliente aprenda no seu próprio ritmo. Além disso, o cliente vê o que deve fazer, ao invés de apenas escutar as instruções por telefone e tentar interpretá-las.

Nós ainda atendemos algumas ligações de clientes, sobretudo quando ainda há algum assunto que não ficou suficientemente claro nos screencasts. Mas, sabemos que o volume seria muito maior se não tivéssemos investido na criação deles. De fato, esse investimento que fizemos é uma das coisas que tem possibilitado que continuemos tendo pouca gente cuidando do Be on the Net. Na maior parte do tempo, somos apenas eu e o Leandro cuidando de tudo. E a vida segue em paz, mesmo com a entrada de cada vez mais clientes.

Essa é uma estratégia que recomendo fortemente. Quanto ao software, usamos o ScreenFlow, no Mac. É excepcional e muito fácil de usar.

Formas de pagamento: boleto bancário

Vinicius Manhães Teles — Thu, 03 Sep 2009 11:33:00 -0300

Foto de Guilherme Augusto Oliveira (CC)

Para receber os pagamentos das mensalidades do Be on the Net, optamos pelo uso do boleto bancário. Uma empresa consegue emitir boletos facilmente, bastando para isso firmar um acordo com seu banco. Além disso, qualquer pessoa consegue pagar um boleto sem maiores dificuldades, em qualquer banco ou casa lotérica.

Primeiros passos

Há aproximadamente um ano conversei o pessoal do Banco do Brasil, onde temos conta e firmei com eles um contrato para utilização de boletos bancários. Optamos por utilizar o boleto mais simples que existe, que não tem registro (carteira 18-019). É também um dos mais baratos. E, naturalmente, negociamos uma redução no valor da taxa cobrada pelo banco para o processamento dos boletos.

O Banco do Brasil nos forneceu um programa, chamado BB Cobrança, que não é a maior maravilha do mundo, mas atende bem no primeiro momento. É fácil gerar boletos através dele.

O banco disponibiliza um arquivo de retorno que a gente baixa pelo internet banking. Esse arquivo é processado pelo BB Cobrança e assim a gente fica sabendo quem pagou boletos no dia anterior. O valor pago fica bloqueado por um dia útil, quando então o banco libera o crédito, diretamente na conta corrente e desconta a taxa que lhe cabe.

Além do BB Cobrança, também utilizávamos uma planilha para controlar os pagamentos. Não implementamos um sistema interno mais sofisticado para controle dos pagamentos, nem compramos nenhum pronto. A razão disso é simples. Para nós, não fazia sentido investir em algo assim sem saber se o produto realmente decolaria. Então, adiamos o investimento. Depois de algum tempo, começamos a preparar nosso sistema financeiro e ele vem crescendo e se aprimorando a cada dia.

Por que fizemos assim?

A principal razão foi a simplicidade. Decidimos ter apenas uma forma de pagamento porque era o mais simples a fazer no início. Boleto bancário foi a escolha natural porque é uma forma bastante universal e fácil de controlar.

Decidimos fechar um contrato diretamente com nosso banco porque também era algo simples e conseguimos negociar uma boa redução na taxa de processamento dos boletos. Na época, dei uma olhada em alguns sistemas web que ofereciam o pagamento através de boleto, mas as taxas não eram convidativas ou os serviços ainda eram muito incipientes. Um ano depois, a história é outra. Acredito que tais serviços estejam melhores e as taxas já sejam mais baixas. Portanto, vale um estudo.

O que aprendemos?

O pagamento através de boleto tem funcionado bem. Praticamente todos os clientes aceitam bem e estão habituados a essa modalidade de pagamento.

Vale dizer que nós só enviamos os boletos através de email. Isso também facilita a vida de todo mundo e reduz os custos. Só tem um detalhe que não deu muito certo no início.

O BB Cobrança permite gerar um arquivo HTML e uma imagem do boleto (JPEG). Começamos enviando o arquivo HTML para os clientes, mas nem sempre eles conseguiam ver o boleto adequadamente. Então, experimentamos enviar arquivos PDF e o problema foi eliminado. Desde então, todos conseguem ver os boletos normalmente. Para trasformar os arquivos HTML em PDF, nós fizemos um script.

O fato de ser uma única forma de pagamento não tem sido um problema para os clientes. Entretanto, alguns escolheriam débito em conta, se essa opção estivesse disponível. Por enquanto, nós preferimos não seguir por esse caminho, pois temos outras prioridades. Mas, passamos a dar ao cliente a opção de receber boletos de meses futuros antecipadamente. Assim, o cliente pode agendar o pagamento desses boletos uma única vez, de modo que o efeito final, ao longo dos meses, é semelhante ao do débito em conta. Aproximadamente um quarto dos clientes adotou essa opção.

Se você estiver criando uma aplicação web, minha principal recomendação é que você simplifique ao máximo no início. Procure compreender a natureza do que você está oferecendo como serviço e avalie qual seria a melhor modalidade de pagamento. Se puder se limitar apenas a uma no início, talvez seja válido, como forma de simplificar. Em todo caso, analise também os sistemas web disponíveis atualmente para pagamentos online. Se encontrar algum que seja fácil de usar e cobre um valor aceitável, use-o.

No início, invista apenas o mínimo necessário nos controles internos. Dedique-se a colocar o serviço na rua e vender. Se tudo correr bem, aprimore os controles internos.

Se você puder colocar nos comentários um pouco de sua própria experiência sobre esse assunto, vai ser muito bacana. Alguma recomendação especial sobre sistemas web que possam facilitar o recebimento de pagamentos?

Cofrinho e fluxo de caixa

Vinicius Manhães Teles — Tue, 01 Sep 2009 11:59:48 -0300

Cada vez mais as pessoas se convencem de que é possível montar um negócio e ser extramamente bem sucedido com ele. Não é para menos. Os exemplos de quem tentou e deu certo aparecem por todos os lados. Alguns são tão emblemáticos que quase parecem irreais, como o citado nas matéria Quem disse que preguiça é pecado?, da Pequenas Empresas & Grandes Negócios.

A vontade de montar um negócio é ainda maior na nossa área. Todo o sucesso da 37signals e outros tantos negócios bem conhecidos na área de tecnologia, nos atraem cada vez mais. A questão é: por onde começar?

Foto de Endless Studio (CC)

Fluxo de caixa

Fazer um negócio dar certo envolve um grande conjunto de fatores. Mas, afundá-lo rapidamente é simples. Basta errar na administração do fluxo de caixa!

Para entender o conceito, imagine o cenário abaixo, que reflete as contas de um empreendedor em um dado mês:

Dia 1 - R$ 1.000,00 na conta
Dia 5 - pagamento a fazer de R$ 8.000,00
Dia 20 - pagamento a receber de R$ 20.000,00

Parece que este vai ser um mês bom, certo? Afinal, você começa com um saldo de mil reais e termina com um saldo de treze mil reais:

   1.000,00 
-  8.000,00
+ 20.000,00
-----------
  13.000,00

Se você faz contas desse jeito, você está em apuros. Além de olhar para os valores monetários, você precisa entender como as datas afetam essa história. Seu problema acontece no dia 5, quando você tem que pagar 8 mil, mas só tem mil no banco. O fato de você ter previsão de receber vinte mil alguns dias depois não ajuda muito.

Isso significa que você, ou não poderá pagar seus compromissos pontualmente (no dia 5), ou precisará pegar dinheiro emprestado. Agora acredite no que vou te contar: você não vai querer pegar dinheiro emprestado. Não no Brasil! Sobretudo sendo um pequeno negócio.

Reserva

O problema que descrevi acima é o mais corriqueiro que existe em qualquer negócio. Infelizmente as datas de recebimento frequentemente não combinam com as datas de pagamento.

Isso é ainda mais grave no início de uma empresa. Em um negócio já estabelecido e bem sucedido, existem receitas para cobrir as despesas. É preciso ter atenção ao fluxo de caixa, mas pelo menos há receita para pagar as contas. Por sua vez, um negócio recém-criado tipicamente só tem despesas. Leva tempo até que as receitas sejam capazes de cobrir os investimentos iniciais e os gastos diários do próprio negócio.

Para lidar com o problema de fluxo de caixa e a falta de receitas no início de uma empresa, é preciso haver reserva financeira. Ou seja, antes de abrir um negócio, é essencial ter dinheiro guardado no cofrinho. Durante a condução de uma empresa, idem!

Nos primeiros meses da empresa o dinheiro vai sair quase exclusivamente do cofrinho, então é essencial calcular os custos mensais que você espera ter e multiplicar pelo número de meses que imagina que se passarão sem que a receita seja suficiente para cobrir os gastos. No geral, sugiro que você reserve no mínimo o equivalente a um ano de desespesas (sendo bem otimista).

Depois que os negócios já tiverem decolado, você deve manter o máximo de atenção na sua reserva financeira. Procure fazer com que ela seja capaz de cobrir pelo menos alguns meses das despesas da empresa. Acredite, você vai precisar usar a reserva de tempos em tempos. Há flutuação nas receitas de qualquer empreendimento. A reserva nos permite segurar as pontas nos eventuais períodos de vacas magras.

O papel da reserva no início da Improve It

Quando comecei a Improve It, tinha reservas para pouco mais de um ano. Mas, no primeiro ano, as despesas foram acima do previsto e as receitas abaixo do desejado. Conclusão, as reservas foram consumidas mais rápido do que o imaginado. Não seria possível alcançar o décimo mês. Felizmente, fechamos nosso primeiro negócio de porte por volta do nono mês. Mais um mês de espera e a empresa teria fechado as portas.

Antes de nos dedicarmos exclusivamente ao Be on the Net, também montamos uma boa reserva financeira. Uma parte dela foi usada na primeira parte deste ano, até que as receitas do produto fossem capazes de compensar as despesas.

Conclusão

A Improve It, fundada em 2001, é hoje uma empresa de oito anos. O que significa que ela é uma raridade. A maioria das empresas morre em menos de cinco anos de vida. Há vários fatores que explicam porque estamos com as portas abertas até hoje, e cada vez melhor. Porém, como fundador, posso garantir que o fator número um sempre foi o mesmo: ter reserva financeira para ajudar na administração do fluxo de caixa. Isso é o feijão com arroz de qualquer negócio, mas infelizmente é um dos assuntos mais negligenciados pelos empreendedores. Portanto, se quiser montar um negócio, pense bem nessa questão: você tem reserva financeira? Lembre-se: a grande maioria das empresas fecha as portas por falta de capital.

Para saber mais sobre o assunto, veja este ótimo livro: 10 anos de monitoramento da sobrevivência e mortalidade de empresas (PDF). Lute pelo seu próprio negócio, se esse é seu sonho. É algo magnífico! Mas, estude o assunto e atue responsavelmente. Acredite, é preciso mais do que apenas Ruby, XP, Rails, CSS e outras tecnologias para criar um negócio sustentável.

Templates CSS

Vinicius Manhães Teles — Tue, 25 Aug 2009 09:08:10 -0300

Foto de Bill Bradford (CC)

Os sites do Be on the Net utilizam templates CSS criados por designers externos. Nos primeiros dias, bem no início de janeiro de 2009, havia uma meia dúzia de templates. Cada template consistia em um conjunto de arquivos de imagens e de CSS.

Quando um novo cliente contratava nossos serviços, o que fazíamos era bastante simples. O cliente escolhia o template e a gente copiava os arquivos de CSS e de imagens para a conta dele. Pronto, problema resolvido. Era a abordagem mais simples e óbvia que poderíamos usar e foi a que usamos. Mas, naturalmente, não era nem de longe a mais adequada. Afinal, a palavra duplicação sempre vem acompanhada de dor e sofrimento. Ambos bateram em nossa porta logo depois de colocarmos os primeiros sites de clientes no ar.

Falhas

O uso real dos templates no dia-a-dia mostrou que cada um deles possuía pequenas falhas. Por mais que revisássemos cada template no momento da compra dele, sempre havia uma ou outra falha que nos escapava, mas ficava bem fácil de enxergar uma vez que o template estive em uso no site de um cliente.

Quando encontrávamos uma falha, corrigíamos, naturalmente. Mas, espere, estávamos duplicando os templates. Então, ao fazermos a correção no original, tínhamos que replicar em cada uma das cópias. Mas, não pense que bastava copiar e colar a correção.

Cada site tem um layout que usa, como base, o código CSS de um template. Mas, normalmente há pequenas alterações no CSS que são pertinentes exclusivamente àquele site. Portanto, não apenas tínhamos um código CSS duplicado, como também modificado.

Colocar as correções nestes arquivos CSS era um tormento. Foi nesse estágio que sofrimento e dor passaram a nos visitar diariamente. Também pudera, tanto tempo desenvolvendo software e caímos no mais básico de todos os erros: duplicar.

A solução

Durante o mês de janeiro, sofremos muito com essa questão, aprendemos bastante e fizemos o que precisava ser feito. Alteramos completamente o funcionamento do sistema para que ele passasse a ter uma forma de utilização de templates mais racional.

A partir daí, cada site passou a ter um parâmetro de configuração onde informávamos o nome do template adotado. Por sua vez, cada site poderia ter um conjunto de arquivos CSS e de imagens específicos para particularidades dele. Então, o HTML de cada página gerada para o site do cliente passava a ficar assim:

Primeiro carrega todos os arquivos CSS do template.
Em seguida, carrega todos os arquivos CSS específicos daquele site, os quais, eventualmente, alteram ligeiramente o funcionamento do template original.

No momento em que essa alteração foi feita, as coisas ficaram bem mais simples. Continuamos a corrigir eventuais falhas nos templates, mas agora, podíamos corrigir em um único ponto e todos os sites que usavam o template corrigido recebiam a correção automaticamente.

Lição do dia: não duplique! O "copiar e colar" de hoje realmente significará a dor e o sofrimento de amanhã. E o pior: este amanhã sempre chega muito mais rápido do que imaginamos.

Monetização: pagamento de uma aplicação web

Vinicius Manhães Teles — Mon, 24 Aug 2009 09:00:17 -0300

Hoje começo a descrever algumas das lições que aprendemos até o momento com o Be on the Net. E começarei logo por uma das mais importantes, pois envolve a parte mais sensível do corpo humano, o bolso.

Foto de Mike Schmid (CC)

No Be on the Net os pagamentos são mensais e adiantados. Porém, no início, nos deparamos com a seguinte questão: quando um cliente contrata nosso serviço, qual deve ser o momento a partir do qual devemos começar a cobrar?

Devemos cobrar imediatamente? Ou primeiro colocamos o site no ar e depois fazemos a primeira cobrança?

O que nos pareceu mais razoável, inicialmente, foi colocar o site no ar, avançando até certo ponto, quando então enviávamos o primeiro boleto de pagamento. Chegar neste ponto, envolvia algumas tarefas executadas por nós e outras pelo cliente.

O problema

Logo descobrimos que esse modelo não funciona. As pessoas que nos contratam normalmente têm um pequeno negócio e são muito ocupadas. Querem um site porque acreditam no retorno para os negócios. Mas, ele trará mais trabalho. É inevitável. A pessoa precisa colocar seu conteúdo no ar, bem como fazer outras atividades relacionadas ao site.

Então, o que acabava acontecendo é que nós executávamos nossas tarefas rapidamente, enquanto o cliente frequentemente demorava para fazer a parte dele. E nós demorávamos para começar a receber pelo site.

Analisando superficialmente, pode-se ter a impressão de que apenas nós saíamos perdendo. Mas, isso não é verdade. O cliente também perde por não avançar com o site. Frequentemente, ele perde até mais, pois o site ajuda a trazer novos negócios. Então, cada dia que o cliente passa sem o site no ar, é mais um dia em que ele deixa de captar novos negócios.

No nosso lado, além de termos de enfrentar a demora de alguns clientes, também tivemos que lidar com outros que nos deram todo o trabalho inicial e, quando chegou a hora de fazer o primeiro pagamento, sumiram. Portanto, trabalhamos à toa.

A solução

Um dia a ficha caiu para mim. Nós estávamos simplesmente fazendo a coisa errada e a solução era a mais simples de todas. O cliente deve pagar a primeira mensalidade imediatamente, assim que fecha o contrato. E nós só devemos começar a preparar o site dele quando o pagamento puder ser identificado na conta corrente da empresa.

Isso é bom para nós por razões óbvias: a gente recebe logo e só trabalha para quem realmente paga. Quem nos procura na empolgação, mas não paga por qualquer razão que seja, simplesmente não recebe o serviço, o que é perfeitamente coerente.

Isso também é bom para o cliente. O fato de ele ter pago logo no início, faz com que ele priorize o site. Esse é o ponto principal. Por já ter pago, a pessoa dedica tempo e esforço para fazer a parte que lhe cabe, o quanto antes.

Essa é uma mudança que parece óbvia olhando em retrospecto. Mas, levou uns bons dois meses até nos darmos conta de que tínhamos que fazer isso.

Quando as coisas estão no início, a gente ainda não sabe ao certo se alguém vai contratar o produto. Temos medo. Então, tentamos adiar os pagamentos ao máximo, para que seja possível mostrar um pouco do nosso trabalho ao cliente, antes que ele tenha que abrir a carteira. Com o tempo, a gente ganha confiança. E essa confiança foi necessária para que passássemos a cobrar logo no início, antes mesmo que fizéssemos qualquer preparação do site do cliente.

De lá para cá, temos respeitado esse modelo e os resultados não poderiam ser melhores. Quem paga leva, quem não paga, não leva e, portanto, não nos gera nenhum trabalho.

Dev in Rio 2009

Vinicius Manhães Teles — Fri, 21 Aug 2009 11:41:06 -0300

No dia 14 de setembro de 2009 você tem um compromisso. Chama-se Dev in Rio 2009. Uma conferência super bacana que vai dar o que falar.

Será um evento raro, pois não é sempre que várias tecnologias diferentes dividem o mesmo palco. Teremos o privilégio de assistir:

A abertura será feita pelos meus amigos, Guilherme Chapiewski e Henrique Bastos, os organizadores do evento. Grandes amigos, dos quais me orgulho muito e aos quais agradeço por trazer um evento tão legal para o Rio. Parabéns por essa brilhante iniciativa!

Também estarei presente, no final do dia, para ajudar a organizar um bate-papo entre os palestrantes e a comunidade de desenvolvimento de software presente ao evento.

Dentre os assuntos tratados, temos o Joomla!, Java, Ruby, Ruby on Rails, Python, Django e Desenvolvimento Ágil. E como se não bastasse, o evento será encerrado com chave de ouro, em uma #horaextra que certamente vai entrar para a história. :-)

Veja informações adicionais sobre o evento nos blogs dos organizadores:

http://gc.blog.br

http://henriquebastos.net

Faça logo sua inscrição! Este vai ser um daqueles eventos em que as vagas vão acabar rapidinho. Pode ter certeza.

Fiquem ligados no evento, acompanhando todos os acontecimentos no Twitter, seguindo o @devinrio e a busca #devinrio! Vejo vocês lá!

História da criação do produto

Vinicius Manhães Teles — Thu, 20 Aug 2009 12:14:41 -0300

Foto de thinkpublic (CC)

No final de 2007 escrevi um artigo no qual me despedia da consultoria em desenvolvimento ágil e indicava um novo caminho para a Improve It: o desenvolvimento de web apps comerciais. Um ano depois, no final de 2008, a Improve It encerrou seu último trabalho de consultoria. Foi o fim da participação no projeto Lucidus.

Neste mesmo mês de dezembro de 2008, lá pelos últimos dias, lançamos o Be on the Net como um produto comercial. Agora ele já está no ar há pouco mais de um semestre e chegou a hora de contar o que se passou e onde estamos neste momento.

Onde estamos?

No momento, temos em torno de 100 clientes no Be on the Net (muitos ainda não estão apresentados na página de clientes). É claro que gostaríamos de já ter um número maior, porém, 100 clientes é um número bem maior do que poderíamos esperar em tão poucos meses. Não, não me refiro a tão poucos meses como valor absoluto. O que quero dizer é que a vida comercial do Be on the Net tem pouco mais de seis meses, o que é muito pouco para um produto. E, apesar disso, já são 100 clientes. Uau! Isso é melhor do que poderíamos imaginar.

O que rolou?

O Be on the Net de hoje não é muito diferente do que era em dezembro do ano passado. A essência permanece a mesma, as funcionalidades são praticamente as mesmas e o código sofreu poucas alterações. Fizemos alguns ajustes finos ao longo do caminho, corrigimos alguns poucos bugs, mas no geral, continua sendo o mesmo código de seis meses atrás. Então isso quer dizer que ficamos de bobeira durante todo esse tempo?

De forma alguma. Ter o software funcionando foi só o começo. No momento em que ele foi lançado comercialmente, tivemos que passar a lidar com os outro 95% que realmente fazem o software deixar de ser apenas um software e efetivamente se transformar em um produto desejado pelas pessoas.

Operacional

Nós montamos uma fila de espera durante o desenvolvimento do Be on the Net. Com isso, várias pessoas contrataram o serviço logo nos primeiros dias. O que nos fez perceber rapidamente que precisávamos criar toda uma infraestrutura operacional que simplificasse nosso trabalho.

Quando um novo cliente nos contrata, há várias pequenas ações que precisamos fazer aqui e outras que o cliente tem que fazer por lá. Por exemplo, emissão do contrato, geração de boleto de pagamento, configuração de DNS, aplicação do template escolhido etc. Individualmente, cada tarefa dessas é simples, mas quando tomadas em conjunto, podem consumir um bom tempo, sobretudo se não estiverem bem otimizadas.

Essas são algumas das questões que mais geraram aprendizado para nós:

Templates
- Correções
- Duplicações
- Template x conta
- Be on the Net estático
- Designers externos
Pagamento (sobretudo o primeiro pagamento)
Screencasts
Comunicação com os clientes
Logotipos
Infraestrutura
Marketing
Decisões de projeto

Ao longo dos próximos dias, tentarei escrever sobre cada um desses pontos. A ideia é tentar revelar, ao máximo, os bastidores dos primeiros meses do funcionamento do Be on the Net como um produto comercial. Fique ligado!

Organizando a casa

Vinicius Manhães Teles — Wed, 19 Aug 2009 09:54:15 -0300

Foto de Adam Rifkin (CC)

Fizemos um blog para o Be on the Net recentemente, onde iremos postar informações e relacionadas ao Be on the Net, bem como dicas para nossos clientes. Com isso, deixaremos de usar este blog para assuntos específicos do Be on the Net e voltaremos ao foco inicial dele, que são informações relacionadas à Improve It, bem como questões técnicas na área de desenvolvimento ágil, Rails, entre outras.

Além disso, criamos uma conta no Twitter tanto para a Improve It, quanto para o Be on the Net. Tem várias pessoas que me seguem no Twitter com interesses específicos na Improve It, ou no Be on the Net. Agora elas poderão seguir o Twitter certo para se manterem informadas sobre o que mais lhes interessam.

Finalmente, temos também o blog da Improve It em inglês, que voltaremos a utilizar mais ativamente para tratar especificamente de assuntos técnicos, que devem ser compartilhados com a comunidade como um todo e não apenas com aqueles que falam português.

Resumo da história:

Be on the Net

Improve It

Nós aprendemos muita coisa na primeira metade deste ano conduzindo o Be on the Net. Foi um aprendizado especial em termos de negócios, marketing, tecnologia, infraestrutura e vários outros assuntos. Estamos fazendo essa organização justamente porque desejamos compartilhar o que aprendemos ao longo dos próximos meses. Mas, queremos fazer isso de forma organizada, direcionando a informação corretamente, para cada público interessado.

Edição e publicação de vídeos

Vinicius Manhães Teles — Tue, 18 Aug 2009 12:00:00 -0300

Desde que lançamos os Be on the Net, no início deste ano, estive bastante atarefado com o produto, de modo que tenho me dedicado pouco ao blog. Além disso, temos publicado pouco conteúdo útil, embora tenhamos aprendido muito desde que demos início ao produto. Isso tem me deixado frustrado.

Para piorar, há muito material que nós criamos ou coletamos ao longo do último ano e meio, sobretudo em forma de vídeo, que está "enferrujando" em nossos computadores. O que queríamos mesmo é publicar tudo o quanto antes, pois tem muita coisa legal. Mas, não tem dado tempo. Em particular, não dá tempo para editar os vídeos.

Foto de Rakka (CC)

Edição é o nosso gargalo. Consome muito tempo e esforço. Então, não apenas deixamos de publicar os vídeos que já gravamos, como também evitamos criar novos, já sabendo que não teremos tempo para editá-los.

Parando para pensar melhor, me dei conta de que o problema não é exatamente de falta de tempo. O problema é cuidarmos da edição sozinhos.

Foto de Stacy A (CC)

Foi quando percebi que compartilhar pode ser uma via de mão dupla. Podemos compartilhar não apenas o material que criamos, mas também o esforço para finalizar a produção deles. Ou seja, podemos e devemos buscar ajuda na parte de edição. Assim, quem sabe, os vídeos podem ser lançados em menos tempo, com menos esforço individual de cada envolvido. Por que nos restringimos a open source, quando podemos ter também open editing?

Foto de Toban Black (CC)

Lancei essa questão no Twitter. E, para minha surpresa, várias pessoas responderam! :-)

Nosso principal desafio é colocar no ar uma série de vídeos que fizemos nos últimos tempos. Existem outros materiais também, mas a prioridade inicial são os vídeos. Os assuntos são diversificados. Gostaríamos de colocar esses vídeos no ar e, então, começar a produzir material novo.

Foto de Enric Teller (CC)

Criei um grupo no Google Groups para tratarmos dessa questão. As pessoas que manifestaram interesse já se encontram por lá. Se você quiser ajudar, por favor, entre em contato conosco para que possamos adicionar seu email ao grupo.

Estamos começando a organizar o trabalho. Sou usuário de um sistema de compartilhamento de arquivos chamado Dropbox. Alguns de vocês talvez o conheçam. É bem bacana.

Nele, tenho uma conta paga na qual posso colocar até 50GB de material. Consigo compartilhar alguns diretórios com pessoas específicas.

É possível abrir uma conta lá, sem custo, com direito a 2GB de armazenamento. Quando alguém for editar um vídeo, eu compartilho o mesmo apenas para a pessoa e ele sempre será um arquivo abaixo de 2GB. Com isso, você poderá usar seu Dropbox normalmente, sem custo.

Fiz uma garimpada nos principais vídeos ao longo da tarde de ontem. No momento, estou fazendo o upload dos últimos para o Dropbox.

A ideia é que cada pessoa escolha um vídeo para editar e depois coloque o resultado final no seu respectivo Dropbox. Nós iremos baixar, apenas para fazer a revisão, e, estando tudo em ordem, iremos publicar no site da Improve It, bem como no YouTube.

Foto de Jonathan Maus (CC)

Quem fizer a edição pode e deve ter seu crédito citado tanto no vídeo, quanto na página que o contiver. Isso é o básico que imaginei até o momento, mas outras ideias ou formas de publicar os vídeos são absolutamente bem-vindas.

Quem tiver empresa, poderá colocar uma breve propaganda no início ou final do vídeo, indicando que patrocinou a edição do mesmo. Acho que o material terá utilidade para a comunidade, mas quero que traga retorno para as pessoas que colaborarem no processo. Elas devem se promover de alguma forma. É essencial que todos ganhem algo com isso. O que queremos construir aqui é um processo de troca que seja bom para todo mundo: a comunidade, os editores e os criadores do conteúdo.

Finalmente, os vídeos serão liberados como Creative Commons Atribuição. Assim, qualquer pessoa poderá usá-los, para qualquer fim, bastando para isso que cite os autores e editores. Como implicação direta disso, todos poderão veicular o vídeo em seus respectivos sites/blogs, sem nenhuma restrição. Além de poderem usar comercialmente, se assim desejarem.

Se você tiver interesse em nos ajudar nessa iniciativa, por favor, entre em contato.

Falando sobre CouchDB

Marcos Tapajós — Sun, 19 Jul 2009 14:41:00 -0300

Algum tempo atrás eu publiquei um post sobre CouchDB em inglês e fiquei de traduzir e nunca fiz isso. Resolvi escrever um post novo, com mais detalhes e dessa vez em português.

Porém dessa vez publiquei no meu blog pessoal em:

http://tapajos.me/2009/7/19/falando-um-pouco-sobre-couchdb