Pequenas histórias de pequenas empresas milionárias

Eu já escrevi aqui que desenvolvedores tem vários recursos para se tornarem donos de seus próprios narizes e quem sabe mudar um pouco o mundo. Mas provavelmente muitos devem olhar para o que eu disse e se coçar para não postar um comentário como “ok amg, mas como é que eu vou brigar com o Google, IBM e Microsoft se nem sei fazer miojo?” ou “como eu vou montar uma equipe grande o suficiente para fazer um produto que alguém compraria? como eu pago esse pessoal? com o corpo??”. Por isso achei que era a hora de dar alguns exemplos, para quem sabe mudar a cabeça dos incrédulos e para inspirar os que já estão convencidos da idéia.

Resolvi pegar dois exemplos de empresas pequenas, que ficaram milionárias em um curto espaço de tempo, que não receberam nenhum investimento externo e que basicamente começaram como um empreendimento de uma pessoa só, empresas em que apenas o fundador fazia tudo no começo. Alguns podem dizer que U$1 milhão é pouco para uma empresa, e realmente é o que a maioria do pessoal que trabalha com Venture Capital iria pensar já que eles estão correndo atrás dos próximos Googles e Facebooks. Não sei vocês, mas eu já estaria bem confortável nessa situação, e principalmente orgulhoso de saber que aquele milhão fui eu que construí.

Tentei resumir ao máximo a história das empresas só para que o maior número de pessoas as conheçam, mas recomendo que os interessados se aprofundem, leiam as entrevistas completas, blogs e twitters dos empreendedores. E sem querer desmerecê-los, já que obviamente são pessoas muito competentes, pense se não poderia ser você contando essas histórias.

Twitpic

Em 2008, um sujeito chamado Noah Everett, na época um programador web, montou um site para ajudar a compartilhar fotos no Twitter, chamado Twitpic. Fez isso usando um único servidor, pagando do próprio bolso, desenvolvendo sozinho o serviço. Por um ano e meio ele era a única pessoa da empresa. Hoje a empresa tem quatro funcionários (Noah, seu pai, sua mãe e um programador contratado que ele nunca viu pessoalmente). Hoje o site é um dos serviços mais populares do Twitter, prestes a atingir a marca de 6,5 milhões de usuários e faturando aproximadamente U$1,5 milhões por ano.

Você pode assistir uma entrevista com Noah aqui (em inglês). E visitar o Twitpic aqui.

Balsamiq

Em março de 2008, o italiano Giacomo Guilizzoni fundou a Balsamiq Studios, para vender um software chamado Mockups, usado para fazer wireframes, muito úteis nas fases de prototipação de softwares e websites. Giacomo que já foi Engenheiro de Software Senior na Adobe, sendo um dos responsáveis pelo Adobe Connect por exemplo, gostava de desenvolver software, mas também se interessava muito por business e queria ter seu próprio negócio. Mesmo sendo uma empresa de um homem só (e ajudado pela esposa), ele conseguiu 5000 clientes em menos de 11 meses e só contratou o primeiro funcionário em 2009. Hoje a empresa é formada por quatro pessoas, contando com sua esposa e registrou lucro em 2009 de exatos U$1.139.919,59.

Você pode ler uma entrevista com Giacomo aqui. Outra mais recente aqui. O site da Balsamiq Studios é este aqui.

Se você conhecer mais histórias como essas, compartilhe conosco aí nos comentários. Me ajude a inspirar os próximos milionários.

Grails & Groovy: primeiras impressões

A maior certeza que você pode ter, se for seguir carreira como programador, é que você vai usar muitos frameworks e linguagens de programação diferentes. Alguns você vai odiar de coração, mas vai ser obrigado a usar. E quando um colega seu citar o nome dessa ferramenta, você provavelmente reagirá como se sua mãe tivesse sido xingada. Mas também haverá os frameworks e linguagens que você vai odiar menos, e que talvez, por comparação com o que você já usou no passado, você chegue até a gostar.

COBOL: não gostei

Alguns, como eu, nunca ficam muito satisfeitos e sempre estão a procura da solução perfeita. A resposta à pergunta mais levantada por quem precisa parir um projeto: “o que vamos usar?” Esses sujeitos estão sempre experimentando coisas novas, procurando alguma solução que não tenha os problemas que as outras tinham, e quem sabe um dia encontrar o cálice sagrado das soluções de sistemas. E eu TALVEZ tenha encontrado algo bem próximo disso e que por acaso tem o nome de Grails (se você não entendeu está na hora de entrar num curso de inglês – aí CCAA, olha a oportunidade que vocês perderam de fazer merchandising no blog).

Não vou dar o veredito final porque ainda usei muito pouco Grails, em um projeto pequeno, em que um dos maiores objetivos era aprender Grails e Groovy. Mas para vocês terem uma idéia, o projeto envolvia integração com uma interface Flex (o RIA da Adobe) e usava JMS (o padrão de Mensageria Java). E mesmo assim, escrevi muito pouco código, quase nada de configuração e nenhum SQL (sim, o projeto tem banco de dados). Acho que o fato de eu ter tido pouco trabalho fazendo isto já mostra um pouco o porquê de eu ter achado o framework tão bom.

Grails: o logotipo foi o que menos gostei.

Outro motivo para não bater o martelo é que ainda não parei para aprender Ruby on Rails. Está na minha lista de “coisas a fazer (ou não)”, mas da forma como é aclamado pelos rubistas, deve realmente ser muito bom. Bom, se bem que “Crepúsculo” é aclamado por muita gente e eu não estou a fim de ver um filme que mistura Malhação com vampiros emos. Mas o fato de Grails ter sido inspirado em Rails não me permite ignorar sua existência.

Minha experiência com o framework foi curta, mas espero poder usar eventualmente para outras coisas. Por enquanto ainda não usaria para um projeto principal, mas para algo menor não teria dúvidas. Seguem abaixo minhas observações sobre Grails:

• a linguagem Groovy: não gostava muito de linguagens dinâmicas, mas talvez isto tenha sido por conta do período em que usava PHP. Groovy é uma linguagem muito agradável de usar (pelo menos te garanto que é MUITO mais agradável que Java) e que da mesma forma que Perl, te dá diversas formas de se fazer a mesma coisa. E assim como Ruby, te dá a opção de extender a definição de qualquer classe (como adicionar métodos a uma classe da API padrão por exemplo) e de usar closures (que a grosso modo funciona como os ponteiros para métodos e funções existentes em outras linguagens). Me agrada muito a implementação da linguagem, que te poupa de fazer checagens bobas como verificar se o objeto é nulo, ou concatenação de strings, tornando o código mais legível e mais fácil de escrever.
• plataforma Java: isto é mais vantajoso para quem já trabalha com Java, mas de certa forma é vantajoso para todos pelo tamanho da comunidade Java. O Grails e o Groovy foram contruídos sobre a plataforma Java. Dessa forma, um código escrito em Java é aceito como código em Groovy, o que pode tornar o aprendizado um pouco mais fácil. Um código escrito em Groovy tem total interoperabilidade com código em Java, permitindo que você tenha um projeto com partes escritas em uma linguagem e partes escritas na outra. Tanto que você pode utilizar qualquer coisa que você já podia utilizar em Java (bibliotecas, frameworks, etc). Isso foi aproveitado pelos idealizadores de Grails, pois o framework tem como seus alicerces dois frameworks Java muito populares: Spring e Hibernate.
• GORM: é o responsável por mapear seus objetos para os registros no banco de dados (daí a sigla ORM – Object-Relational Mapping), e utiliza o Hibernate por baixo do capô. Este é o melhor ORM que já vi, pois de fato torna o trabalho muito mais fácil. Como eu disse, não escrevi uma linha de SQL e também não encostei em nenhum XML de configuração para fazer o GORM funcionar. Utilizar o GORM é basicamente como eu gostaria que fosse utilizar um banco de dados orientado a objetos. Se GORM fosse uma mulher eu casava. Ah, mulher gostosa, claro.
• plugins: Grails tem uma boa variedade de plugins para extender sua funcionalidade. O que mais me impressionou é a facilidade de se instalar um plugin em um projeto. É tão fácil quanto instalar algo usando apt-get, basta um comando (traduzindo para quem só usa Windows: é fácil pra caralho!). Em um projeto não Grails, normalmente acrescentar uma tecnologia nova, como funcionalidade de web-services ou um motor de busca, sempre gera um certo stress, a ponto de gerentes com mais experiência alocarem um bom tempo na agenda do projeto para a tecnologia ser incorporada sem problemas. Em Grails, você instala o plugin e usa o resto do tempo que seu gerente alocou para ficar pedindo convite para o novo Orkut! SE não fizerem um plugin para isso.
• ambientes: o framework já vem preparado para rodar sua aplicação nos ambientes de teste, desenvolvimento ou produção, facilitando a configuração para essa divisão por estágios. E não só isso, quando você faz o download do Grails ele já vem com um banco de dados (HSQLDB) e servidor web (Jetty) para que você possa sair escrevendo código sem se preocupar em montar o ambiente na sua máquina.
• testes: a parte de testes automatizados (tanto unitários quanto funcionais) faz parte do framework, o que faz com que ele reforce o uso dessas boas práticas.

Se você se interessou em aprender mais, a InfoQ tem um livro gratuito (gratuito de verdade) chamado Getting Started with Grails. Para mais conteúdo, eu recomendo um livro não-gratuito chamado Beginning Groovy and Grails: From Novice to Professional. E para trocar experiências, já existe um fórum de Grails e Groovy brasileiro: o Grails Brasil.

Todo mundo odeia pair programming

Pair programming (ou programação pareada) é provavelmente a prática mais polêmica de extreme programming. É um dos poucos elementos de XP que tem seu valor questionado até por muitos desenvolvedores (além de gerentes e clientes). Provavelmente esta seja a razão para pair programming não ser tão praticada, ou utilizada apenas em doses homeopáticas (ainda mais considerando que pode ser utilizada mesmo sem XP ou algum método ágil). Porque existem pessoas em todos os papéis envolvidos no processo, que odeiam pair programming.

Quando um não quer, dois não fazem pair programming

Muitas dessas pessoas conhecem as supostas vantagens de parear, mas torcem o nariz, mesmo que nunca tenha experimentado ou que tenham feito apenas uma tarde de experiência com o cara mais chato que conhecem no escritório. Mas na minha opinião, essa resistência não é criada por motivos muito nobres. Além do preconceito que já não é algo muito nobre, resolvi analisar algumas concepções erradas que as pessoas envolvidas tem sobre pair programming. Então venha comigo, de cabeça aberta.

Cliente

Se o cliente estiver contratando um serviço de desenvolvimento de sistemas, o problema provavelmente está no contrato. Muitos contratam esse tipo de serviço pagando pela hora dos desenvolvedores. Logo, quando ficam sabendo que em cada estação de trabalho vão trabalhar duas pessoas, já pensam que estão pagando o dobro do que deveriam pagar. Isso se resolve mudando o contrato para alguma outra forma que não envolva contagem de cabeças. Que aliás, sempre achei um jeito muito estranho de se vender este tipo de serviço, como se o número de pessoas (e não a qualidade) fosse determinante para o sucesso de um projeto. Vendendo a hora do desenvolvedor é como se você terceirizasse os riscos do seu RH e ainda lucrasse alguma coisa quando algum cara ruinzinho fosse contratado.

Se o que você está vendendo é justamente a consultoria para melhoria dos processos de desenvolvimento (o que provavelmente envolve pair programming), então você vai ter que vender todos os benefícios dessa prática. Para isto talvez o resto deste post ou outras referências te ajudem.

Gerente

Para o gerente, provavelmente a maior objeção é a questão da produtividade. Se formos cronometrar o tempo que uma dupla leva desde o começo até a entrega de uma tarefa, muito dificilmente os programadores pareados terão mais que o dobro da velocidade de dois programadores sozinhos. O problema de medir a produtividade desse jeito é que ela não leva em consideração a qualidade do que foi produzido e nem a transferência de informação e conhecimento que acontece durante pair programming. De qualquer jeito, medir produtividade desse jeito seria muito simplista. Em engenharia de software, uma gambiarra pode te fazer terminar muito rápido uma tarefa, mas mais para frente a equipe ter uma dor de cabeça de manutenção e gastar muitas horas resolvendo a gambiarra.

Falando em gambiarras, esta é uma das coisas que se pode evitar com pair programming. Com um co-piloto te vigiando, é muito menos provável que o desenvolvedor aposte numa solução rápida mas feia, porque afinal ninguém quer passar imagem de ser desleixado. Por outro lado, ter um co-piloto também evita que o seu super-mega-engenheiro que gosta de comer design patterns no café da manhã crie uma solução super complicada só porque é mais bonita, já que ninguém está olhando (e que depois ninguém vai entender ou vão gastar um tempão desfazendo). Tanto a gambiarra quanto o over-engineering podem custar muito em manutenção nas próximas iterações.

E por último, mas não menos importante, pair programming é a forma mais orgânica de disseminar informações sobre o projeto, compartilhar conhecimento e formar a cultura de um time. É como se você tivesse coaching, treinamento, revisão de código, brainstorm e mini-reuniões o tempo todo, sem precisar parar a codificação. Se você faz rodízio dos pares muito dificilmente precisará se preocupar se seu programador McGyver sumir, porque provavelmente mais de um programador conhece aquele código. Sem falar na disseminação de boas práticas, truques e macetes específicos a bibliotecas e frameworks que só poucos conhecem. Essa dinâmica de trabalho também permite criar um processo de admissão de novos desenvolvedores muito mais realista. Algumas empresas colocam os candidatos para parear com programadores da empresa para sentir se aquele candidato se encaixa na equipe (avaliando tanto o perfil técnico quanto a compatibilidade da personalidade da pessoa com a equipe já existente).

Existem muitos que se empolgam com extreme programming e correm para aplicar, e que na verdade gostam mesmo é da promessa de que não vão precisar produzir pilhas de documentação, passar meses tentando adivinhar como deveria ser o design do sistema. Mas muitos desses caras aplicam XP deixando de fora coisas como pair programming (para não desperdiçar contagem de cabeças). É aí que a qualidade começa a cair, porque as duas principais formas de comunicação na equipe (documentação e pais programming) foram abolidas. Sem comunicação em uma equipe, você sabe o que acontece.

Desenvolvedor

Aqui eu vou assumir que estamos falando de um desenvolvedor que seja honesto e esteja compromissado com a equipe e com a qualidade do projeto. Por isso nem vou falar do carinha que preferia trabalhar sozinho só para poder ter mais tempo ao MSN, Twitter e Orkut e nem do programador que não está nem aí para a qualidade do que produz e só está preocupado em receber o salário e bater ponto. Esses não tem muita razão para gostar de pair programming (talvez não tenham razão nem para estarem empregados).

Mesmo para as pessoas honestas e esforçadas algumas das razões para odiar pair programming não são ditas em voz alta. Uma delas está relacionada ao ego, esta parte tão sensível de tantos programadores. Nisso se encaixam os dois extremos, tanto o cara que não confia muito no próprio taco e fica se perguntando se deveria refatorar tudo o que faz, quanto o programador rock star que tem muita experiência e se imagina capaz de escrever um software que faça seu trabalho. O primeiro vai preferir trabalhar sozinho para não ficar exposto ao julgamento de outra pessoa e o segundo por sentir que não precisa de ajuda e na verdade seu par só vai retardá-lo. Ambos seguem um raciocínio que ignora o fato de que um dos objetivos de pair programming é equilibrar a troca de experiências e de informações. O inexperiente aprende algo e o super experiente ajuda o time a se tornar melhor. Pair programming é um exercício de humildade.

Não quero ninguém atrapalhando meu trabalho diário de SER FODA!

Provavelmente o fato dos desenvolvedores estarem confortáveis com a forma de trabalho atual seja a maior barreira para adoção de pair programming. Claro, você poder ficar no seu canto e fazer as coisas do seu jeito, no seu tempo é muito agradável. Também acharia super agradável trabalhar na praia, sem computador nenhum e podendo dormir o quanto eu quisesse. A grande questão é o quanto a predominância desse trabalho individual ajuda o trabalho em equipe, principalmente quando falamos de comunicação. Claro que a adoção de trabalhos em pares não significa que as pessoas não possam ter seus momentos de trabalho solitário, que em alguns casos são necessários (coisas que necessitem de muita concentração, como uma leitura por exemplo).

Talvez como complemento você se interesse por ler o excelente post de Obie Fernandez sobre o assunto “10 reasons pair programming is not for the masses” (em inglês), que apesar do nome é uma defesa da prática. Esse post foi escrito logo após o New York Times publicar uma matéria sobre o tema: “For Writing Software, a Buddy System“.

Google Wave: É de comer?

Foi em maio, no evento Google I/O, que o Google apresentou seu novo projeto Google Wave. Desde então, tem sido declarado por muitos como uma revolução da Internet que irá acabar com e-mail, instant messaging, Twitter e todas as formas de comunicação conhecidas até hoje. Parte desse barulho vem da demonstração, que provavelmente bateu algum recorde de funcionalidades por minuto, e parte pelo fato do Google estar por trás do projeto, o que obviamente não aconteceria se o projeto se chamasse Armarinhos Fernando Wave por exemplo.

O que é mais interessante é que aparentemente ninguém sabe responder muito bem o que é o Google Wave, mesmo as pessoas que tem acesso a ele desde a metade do ano. Pelo menos eu tenho visto muita gente que consegue um convite e fica se perguntando o que fazer com a aplicação e porque ela ficou tanto tempo mendigando pedindo convite pros outros (não sei se você sabe, mas para ter acesso ao Wave você precisa ser convidado). E isso acontece mesmo com as pessoas que tem algum traquejo com tecnologia. Mas o que é então o Google Wave? A maioria das pessoas não sabe responder e nem vou ser eu a fazê-lo, não é verdade?

Mas graças a meu amigo Márlon Brum eu consegui acesso à ferramenta e vou mostrar algumas coisas que não são muito óbvias para quem acessa o sistema (pelo menos eu não ia descobrir olhando só para o Wave). O objetivo aqui não é um tutorial, já que acho que o básico seja muito parecido com Gmail, por exemplo. O objetivo é mostrar que o Google Wave tem umas coisas legaizinhas e não serve apenas para jornalistas usarem trocadilhos horríveis (“entre já nessa nova ONDA” ou “um novo jeito de SURFAR na web” – ARGHHHH).

Bots

Uma das coisas mais legais e que diferencia bastante o Wave de outras ferramentas são os bots. Bots são mostrados como contatos normais, como se fossem pessoas, mas na verdade são softwares que podem agir sobre o que você e seus amigos estão escrevendo. Por exemplo, se por acaso você virou seu monitor de cabeça para baixo e não sabe como reverter (juro que já vi um caso desses no Orkut), você pode querer escrever todo seu texto de cabeça para baixo para que você consiga ler. Para isso você pode usar um bot chamado Flippy. Na parte de contatos, digite flippy-wave@appspot.com e adicione o Flippy aos seus contatos. Crie uma wave e adicione o bot para participar. Tudo que você digitar opıʇɹǝʌuı ɹǝɔǝɹɐdɐ ıɐʌ.

Twitter

Uma das coisas que você pode fazer é utilizar o Wave como cliente de Twitter. Para isso basta adicionar o Tweety (tweety-wave@appspot.com) a uma wave. Ele vai pedir que você forneça usuário e senha e pronto, você já vai ver sua timeline e poderá postar pelo formulário no topo.

O que é bem decepcionante é que você não consiga postar utilizando blips do próprio Wave (um blip é mais ou menos a unidade de uma wave, algo parecido com cada comentário num blog ou um post num tópico de um fórum). Você é obrigado a usar o formulário no topo. Sem falar que não vi uma forma de atualizar a timeline. O que torna o Tweety o pior cliente de Twitter que já vi, ou seja, por enquanto apenas uma curiosidade, ou uma forma de provocar as pessoas que ainda não tem Wave. Ou eu não saquei como usar e você pode me contar como se faz nos comentários.

Tradutor

Na apresentação do Google I/O fizeram a demonstração de um bot chamado Rosy Etta, que era capaz de fazer a tradução simultânea do que você estava escrevendo (em francês ou português por exemplo) para o inglês. O legal é que era realmente em tempo real, com a tradução sendo realizada a cada palavra digitada. Tentei utilizar Rosy (adicionando rosy@appspot.com a uma wave) e pelo jeito o bot não está funcionando no momento. Dizem que ela foi trabalhar com um vestido curto demais e foi hostilizada aos gritos de “Puta!”. Não mentira. Essa foi outra história. O que dizem é que ela está em desenvolvimento ainda.

Mas não fique triste, porque desenvolveram um bot que faz exatamente a mesma coisa, chamada de Aunt Rosie (ou tia Rosie, que pode ser adicionada com o endereço aunt-rosie@appspot.com). Basta escolher seu idioma e digitar, que a tia Rosie traduz para você.

Gadgets

Basicamente são aplicações que vocë pode inserir em uma wave e então vocë e seus amigos podem interagir com ele. Para adicionar um gadget você precisa ter o endereço dele, e quando estiver editando uma wave clicar no botão da peça de quebra cabeças verde que aparece na barra de ferramentas. Forneça o endereço do gadget e se ele estiver funcionando direito vai aparecer na sua wave.

Botão para adicionar gadgets: peça de quebra-cabeças verde ali à direita

Xadrez

Para inserir um tabuleiro de xadrez utilize o endereço http://gerculanum.appspot.com/gadgets/com.example.chessgadget.client.ChessGadget.gadget.xml . Você vai poder então convidar um amigo e se divertir tentando comer a rainha dele.

Tabuleiro de xadrez - o único lugar em que cavalos andam em L

Existem outro gadgets de games, mas não vi por exemplo algum de War, ou de Imagem & Ação ou batalha naval. Ou mesmo aquele jogo que as meninas te obrigavam a jogar quando era pequeno: STOP.

SAP BPM

Um exemplo de uma aplicação mais séria está neste vídeo da SAP, onde fzaem umas pequena demonstração de um protótipo de software de modelagem de processos (mais conhecido como Business Process Management) em que todos podem participar e editar os diagramas ao mesmo tempo, praticamente uma rave da modelagem de processos.

Para mais extensões e bots de Wave, deixo aqui este link (nem todos estão funcionando, mas a lista é boa) e a página do Google Labs.

Enfim, se o Google Wave vai se tornar algo revolucionário, vai depender muito de alguém criar algum plugin que seja revolucionário, já que os que estão por aí são apenas os primeiros passos e exemplos do que se pode ser feito com a plataforma. O Google Wave crú, sem nada, que o pessoal encontra logo que recebe seu convite é como pão francës, é muito melhor com um requeijão, Amendocrem ou Nutella. E você programador, não está a fim de criar a próxima Nutella da Internet?

Obs.: Eu não tenho convite para o Google Wave, não adianta pedir. Nem todo mundo que tem acesso ao Wave tem convites.

Desenvolvedor de software: esta é a sua era!

Houve um tempo em que você precisava encontrar um poço de petróleo para ficar rico. Em um passado mais recente, você precisava ter as manhas (e os nervos de aço) de Wall Street para isso. Mas hoje, mais do que nunca, estamos vivendo a era do desenvolvedor de software, do programador, do engenheiro!

Provavelmente muitos estão pensando que eu cheirei uma mistura de 7 drogas alucinógenas para escrever isto, porque trabalham na área e, apesar de não ganhar um mau salário estão longe de poderem se declarar milionários ou algo do tipo. Muitos provavelmente acham que poderiam ganhar mais e alguns até migram para outros países para ter um rendimento melhor.

Mas acreditem em mim quando digo: nunca antes esteve tão próxima a possibilidade para uma pessoa esperta, com um computador conectado à internet, de fazer muito dinheiro, de gerar um império e de posar tomando champagne na ilha de Caras.

Pode ser você na próxima capa!

Então quais são os fatores que tornam o presente tão especial assim para quem escova bits? Em nenhuma ordem em especial, eis a pequena lista:

• Software de código aberto e de graça: hoje podemos dizer que software livre é uma realidade madura, não apenas um sonho de programadores barbudos. Tanto que existem empresas que se baseiam em open source e não precisam vender seus rins para continuar funcionando (ou podem ganhar algumas centenas de milhões como no caso da SpringSource). Hoje uma pessoa pode iniciar um negócio sem precisar gastar fortunas com software ( e normalmente desenvolvedores são bons o suficiente para lidar com esse tipo de software). Além disso, como estamos falando de desenvolvedores de software, código aberto pode servir como blocos de construção para partes de seu produto ou serviço, diminuindo radicalmente seus custos de desenvolvimento.
• Computação em nuvem: esta é uma tendência bastante recente e que ainda está amadurecendo. Graças à computação em nuvem você não precisa ter um CPD só seu, ou comprar uma porrada de servidores que você nem sabe se vai precisar e ainda ficar mantendo. A computação em nuvem permite que alguém tenha à sua disposição uma enorme quantidade de poder computacional a um custo muito baixo,  proporcional à sua necessidade. Se você é um desenvolvedor, esta é a forma mais barata de disponibilizar algum produto/serviço para um grande público e poder aumentar seu poder conforme a demanda aumenta. É uma tecnologia que foi um presente dos céus (ok, esta foi muito infame).
• Internet e redes sociais: nem a internet, nem as redes sociais são novidade, mas o amadurecimento desse conceito de interconectividade das pessoas amadureceu muito (Twitter e Facebook que o digam). Hoje conhecendo a rede, uma pessoa pode divulgar seu produto/serviço com um custo muito menor e com um alcance muito maior, sem precisar gastar fortunas com uma consultoria de marketing. Hoje você pode lançar serviços para o mundo todo, com clientes que você nunca vai encontrar cara a cara, mesmo que você trabalhe de um pequeno escritório com 10 pessoas (contando com a tia do café). Além disso, hoje você pode aprender qualquer coisa relacionada à tecnologia e programação utilizando a Internet, sem depender de cursos e livros, e de graça.
• Baixo investimento inicial: os itens acima ajudam muito a diminuir o investimento necessário. Mas se você parar para pensar na idéia de algumas pessoas em uma garagem, com um computador conectado à Internet, deve concordar comigo que existem poucos tipos de negócios que podem ser criados com um investimento tão baixo mas com capacidade de gerar tanto retorno, quanto trabalhar com software. Você não precisa se preocupar com matéria-prima, fornecedores, estação do ano, cotação do dólar (em geral). Tudo vêm da sua cabeça! Pense na poesia disso: você pode construir coisas poderosíssimas a partir do nada! Você é praticamente um deus!

Mas se esses fatores estão aí, são de conhecimento de todos, porque não temos programadores se tornando milionários toda semana (aqui no Brasil pelo menos)? Lembre-se que eu mencionei que o desenvolvedor que tem potencial de tudo isso deve ser um pouco esperto. Na verdade, não só esperto, porque iniciar um negócio, principalmente envolvendo inovação tecnológica, sempre exige uma dose de sorte e perseverança. Se isso não te assusta, o que mais você precisa levar em consideração:

• Você precisa entender um pouco de negócios: quando digo isso não quero dizer que seja necessário que um cara apaixonado por Lisp precise se tornar o Jack Welch. Mas você precisa começar a considerar o que é mercado, concorrência, receita, fluxo de caixa e principalmente: produto. Comece a estudar casos de sucesso e fracasso que se pareçam com o que você tem em mente. E mantenha foco no mais importante e mais simples: o que eu posso oferecer como produto é algo bom o suficiente para alguém se interessar?
• Idéias estão por todos os lados: acho que até existe muita gente que tem vontade de começar um negócio, mas a desculpa mais usada é que não tem uma idéia. Acho que quando você começa a dar mais ouvidos para seu chato interior, você começa a ver que falta de idéias não é uma boa desculpa. Sabe aquele produto/serviço/software/sextoy/whatever que tinha algum problema, algum detalhe, alguma coisa que realmente te irritou, e que você queria que fosse diferente? Você pagaria por isso se fosse diferente do jeito que você imaginou? Então está aí, o seu produto. Se mesmo com meu processo de criação você não conseguir pensar em nada, delicie-se com a lista de idéias que o Paul Graham da YCombinator disponibilizou um tempo atrás: http://ycombinator.com/ideas.html
• Não tente ser perfeito: não sei se é algo que eu posso realmente generalizar, mas acho que na cabeça altamente lógica dos programadores, eles procuram o negócio perfeito, da mesma forma que gostariam de construir software sem bugs. O negócio que vai deixá-los ricos e famosos com o mínimo de trabalho, e vai funcionar de forma perfeita quase como mágica, fazendo o Google se sentir humilhado. Mas isso é perda de tempo. Foque em conseguir fazer algo bom o suficiente. Tentar alcançar o perfeito é simplesmente caro demais. Olhe para as empresas que prosperam, e verá que elas não são perfeitas, nem seus produtos (às vezes, bem longe disso). As melhores são as que focam em fazer algo bom o suficiente.
• Diminuindo os riscos: você não precisa largar seu emprego para começar um negócio. Vai te custar algum tempo que antes era livre para outras coisas, mas pode ser seu bilhete para um pouco mais de liberdade, em troca de um pouco de stress que o medo do incerto iria te gerar (principalmente se você tem família para sustentar).
• Obtendo investimento: infelizmente no Brasil não temos tantos casos de investimentos quanto um Vale do Silício, em que você acaba esbarrando com investidores nos restaurantes locais. Mas eles existem. Tente focar no simples: se eu fosse um cara com um bocado de dinheiro para investir e fazer mais dinheiro, eu apostaria no meu negócio? Escreva um plano de negócios e mostre que não investir em você pode ser uma oportunidade desperdiçada.

Eu sei que eu falei muito de dinheiro, mas acho que a regra de ouro é você fazer algo que você vá gostar. Começar um negócio porque você acha que qualquer emprego que te ofereçam ou que você consiga por aí não vai satisfazer seu potencial. Porque se você parar para pensar, tudo que falei dá um trabalho animal, maior do que provavelmente você encara no seu emprego. Se você vai ter muito trabalho, é melhor que seja com algo que você goste (provavelmente se você não gosta, você nem vai aguentar muito tempo tentando). E que a médio ou longo prazo vai te dar alguma satisfação pessoal. Porque o fator mais incerto disso tudo é o retorno financeiro.

E o que vou falar agora vai soar como coisa de livro de auto ajuda, mas é algo em que eu realmente acredito (além do Paul Graham e Guy Kawasaki). Se for fazer algo, faça algo para mudar o mundo para melhor. Sério, soa meio idealista e romântico, mas eu não acho que a promessa de retorno financeiro seja um motivador o suficiente para trilhar esse caminho tão difícil. Quando você faz algo que torna a vida de algumas pessoas melhor, você está mudando o mundo para melhor. Quando você dá o exemplo do que é agir corretamente e com valores, você está tornando o mundo melhor. Você conhece algo mais motivador do que mudar o mundo para melhor?

Faça história!

Algoritmos genéticos – um resumo e um exemplo

Quando você tem um problema com um número muito grande de candidatos a solução (mas muito grande mesmo), o que você precisa é de um algoritmo de busca. Não de busca no sentido Google, mas de busca de solução. Hoje em dia, em tempos de guerra de “search engines” o nome talvez confunda um pouco, mas algoritmos de busca são fundamentais em computação. Basicamente o que você quer com um algoritmo de busca é navegar pelo mar de possíveis respostas, de preferência de uma forma esperta para te ajudar a encontrar a melhor solução.

“E que problemas eu resolvo com essas bagaças? Resolve minha dívida no bar do bigode?” Os algoritmos de busca em geral são bem genéricos, então podem resolver um número muito grande de problemas. O trabalho do computólogo (ou computeiro, sei lá) é modelar o problema para que ele possa ser resolvido pelo algoritmo, o que geralmente não é um trabalho muito simples. Você não paga sua dívida no bar do bigode diretamente usando esses algoritmos, talvez, mas você pode escrever um algoritmo para calcular quais são as melhores jogadas que você deve fazer nas partidas de dominó para tirar um troco. Ou você pode criar um algoritmo para gerar projetos mais econômicos de circuitos eletrônicos, vender para uma IBM da vida, e comprar o bar do bigode com esse dinheiro.

A situação ideal é quando o algoritmo te dá uma solução sem levar muito tempo computando e a solução é a melhor possível (ou quando você passa um final de semana com a Megan Fox). E existem diversos algoritmos que são capazes de fazer isso (encontrar uma solução, não a parada da Megan Fox), mas isso depende muito do problema específico e de seu tamanho. Mas e quando você precisa mesmo da solução e esses algoritmos não são capazes de computar algo em um tempo razoável? É aí que você pode usar um algoritmo heurístico de busca, como por exemplo algoritmos genéticos. E por coincidência, este é o título deste post.

Heurística? É de comer?

A grosso modo, uma heurística é um chute mais esperto, um critério ou estratégia que pode te ajudar a encontrar uma solução boa. Pode ajudar, às vezes não vai te ajudar. Você pode por exemplo bolar uma estratégia para pegar a Megan Fox (de novo?) e de vez em quando isso funcionar. Mas de vez em quando você acabar com a Amy Winehouse. Enfim, no mínimo com este artigo você aprendeu uma palavra nova para usar na “night”.

Algoritmos genéticos

Algoritmos genéticos são algoritmos heurísticos de busca inspirados na teoria da evolução, seleção natural e nos processos biológicos envolvidos. Se você ainda lembra de conceitos como meiose, mutação, cross-over, vai ver que o algoritmo praticamente simula a idéia de como as coisas ocorrem com os cromossomos e DNA, mas utilizando os dados do problema que você quer resolver. Se você gosta muito de computação E de biologia, a ponto de ter um pôster do Richard Dawkins no seu quarto, vai ter um orgasmo cerebral de saber que um negócio desses funciona.

Eu não tenho um pôster do Richard Dawkins

Vou tentar explicar rapidamente a idéia do algoritmo, mas provavelmente você entenderá melhor olhando para o exemplo mais abaixo. Mas já deixo claro que esta explicação abaixo tem como objetivo ser uma introdução rápida, por isso não vou ficar me desculpando no meio do texto por causa de detalhes técnicos e outros “poréns”.

A primeira coisa que você precisa ter é uma forma de representar os candidatos de preferência como uma sequência de elementos, assim como o DNA é uma sequência de bases (lembra, adenina, guanina, citosina e timina? Eu não lembrava, procurei no Google). E da mesma forma que na natureza, os primeiros patos tinham sua sequência de DNA, você precisa de um primeiro conjunto de candidatos a solução do seu problema. Esses primeiros candidatos você gera à vontade, afinal, como no caso dos patos, os primeiros não precisam ser muito bons. A seleção natural é que vai transformá-los nos super patos que existem hoje, e te ajudar a encontrar uma boa solução para o seu problema.

A natureza desempenha a seleção natural para os patos. Para o seu problema, você vai ter que bolar um critério de seleção, criando uma função de fitness que possa calcular o quanto aquele candidato a solução é um bom candidato. Esse é o seu trabalho, que depende bastante do seu problema. E usando essa função, você decide na sorte quais indivíduos sobrevivem para a próxima fase, dando mais chances para os que tiveram uma boa nota na sua funçaõ de fitness. É mais ou menos como o programa Tentação do Silvio Santos, onde só os melhores e mais sortudos passam para a próxima fase.

Depois é a hora de misturar DNA. A forma como os patos fazem isso você deve saber: ao som de Barry White ao lado da lareira. E pegando um teco de material genético do papai e misturando com o da mamãe, o que a gente chama de crossover. E isso é o que você vai fazer para ajudar a resolver seu problema, pegar um pedaço de duas das soluções sorteadas na etapa anterior e misturar para gerar uma nova solução. E aí você faz isso para gerar diversas soluções filhas, para usar no próximo passo do algoritmo.

Por último entra um processo muito conhecido pelos X-Men: a mutação. Graças a isso você pode ter características novas nas populações existentes, como patos que atiram laser pelos olhos. Ou uma solução melhor para seu problema. Também podem surgir patos de duas cabeças ou soluções piores para seu problema. Por isso é uma etapa em que você não realiza muitas mudanças, podendo muitas vezes nem mudar nada. Sorteie um ou mais dos pedaços do seu candidato a solução e dê uma mudadinha nele (ou não). Pronto, você tem uma solução mutante.

Pato após mutação

Depois é só aplicar todos esses passos (fitness, crossover e mutação) várias vezes, gerando várias soluções, que se tudo estiver direitinho e se sua modelagem do problema for boa, você pode encontrar uma solução para seu problema. Você pode definir algum critério para esse algoritmo parar, como por exemplo rodar até encontrar uma solução boa o suficiente de acordo com a sua função de fitness, ou rodar 1000 vezes.

Não entendi. Desenha pra mim?

Acho que o problema mais simples para usar como exemplo é o problema das N-Rainhas. Se você não sabe, no xadrez a rainha é a peça mais poderosa, que pode se movimentar em qualquer direção, incluindo diagonais, e qualquer número de casas. Ela é ferrada. E normalmente, em um jogo normal, você tem só duas rainhas, uma para cada adversário. Mas no problema das n-rainhas, você tem n rainhas e um tabuleiro com n linhas e n colunas (por exemplo, no problema das 4-rainhas você tem um tabuleiro de 4×4 e 4 rainhas). O desafio consiste em posicionar as n rainhas no tabuleiro sem que nenhuma delas esteja se atacando. Para um n pequeno, o problema é meio bobo, mas se você tiver um n como 4378564378543, aí a coisa complica. Óbvio que resolvendo isto você não vai comprar o bar do bigode, mas acho que te ajudará a aprender como funcionam os algoritmos genéticos.

Exemplo A: aqui o problema não foi resolvido, porque as rainhas das duas últimas colunas podem se atacar pelas diagonais.

Exemplo B: Uma solução para o problema.

Pelos dois exemplos acima você já deve ter sacado que é uma coisa esperta você tentar não colocar mais de uma peça por coluna por exemplo. E isso nos ajuda a modelar a forma como podemos representar esses candidatos a solução. Lembra quando falei que seria legal se o candidato a solução pudesse ser representado por uma sequência de elementos? Podemos representar os exemplos acima, com um vetor de números, em que a primeira posição do vetor indica a linha em que colocamos a rainha da primeira coluna, a segunda posição no vetor a linha da rainha da segunda coluna, e assim por diante. Com isso, o exemplo A seria representado por (1, 4, 2, 3) e o exemplo B por (2, 4, 1, 3). Essas representações são como o DNA do seu problema.

Com essa representação, você está pronto para começar o algoritmo, gerando alguns candidatos a solução que vão ser a primeira geração. Como gerá-los e quantos gerar fica a seu critério. Você pode ter por exemplo uns 20 candidatos gerados de forma aleatória (sorteando cada valor em cada posição).

Agora o que a gente precisa é uma função de fitness, que vai ser usada para fazer a seleção dos candidatos para a próxima fase. Você quer que a função de fitness dê uma probabilidade maior para uma solução quase resolvida do que para uma solução com muitas rainhas se atacando. Neste problema, podemos dizer que o melhor candidato é aquele com menor número de rainhas se atacando e usar isso para construir a função de fitness. Então você pode por exemplo estabelecer que se um candidato a solução tem 4 rainhas se atacando, a probabilidade dele passar para a próxima fase seja de 10%, se tiver 3 rainhas se atacando seja de 30%, e assim por diante. Então para cada candidato a solução você calcula seu fitness e joga o seu dado de 100 lados para cima para ver se esse candidato sobrevive para a próxima fase. Se o dado gerar um número menor que a probabilidade dada pela função de fitness, deixe o candidato continuar.

Chega a etapa de crossover, de misturar as soluções. Primeiro agrupe os candidatos em pares (papai e mamãe). Você pode sortear um número para saber o tamanho do pedaço inicial da solução papai que será substituída no candidato mamãe, e fazer essa substituição para gerar um novo candidato. Por exemplo, se você tiver um papai (2, 3, 4, 4) e uma mãe (1, 3, 2, 1), você pode decidir pegar as duas primeiras colunas do pai e as duas últimas da mãe para gerar o novo (2, 3, 2, 1). Continue com essa orgia de candidatos até gerar o mesmo número de candidatos que você tinha inicialmente.

A mutação também é uma etapa simples. Primeiro decida aleatoriamente se vai ocorrer mutação para aquele candidato (de preferência com uma probabilidade baixa, para que isso não seja tão frequente). Se for decidido que deve haver mutação, sorteie uma das colunas do candidato e mude esse valor para um valor aleatório. Por exemplo, o candidato (1, 4, 3, 3) pode sofrer uma mutação na última coluna e se transformar em (1, 4, 3, 1), por exemplo.

Daí em diante repita, até conseguir um candidato sem nenhum conflito.

Gostei, vou usar para resolver todos os meus problemas!

Calma, algoritmo genético não é a solução para todos os males (apesar de alguns pesquisadores com fome por número de publicações acharem que é). Ele não vai funcionar tão bem para alguns problemas, e isso você só descobre depois que teve todo o trabalho de implementar e rodar. Você pode precisar das respostas dentro de um certo tempo, e o algoritmo pode precisar rodar por muito tempo para chegar em alguma resposta razoável (o que é um problema de muitas buscas heurísticas). Ele pode não chegar a uma resposta boa o suficiente. E modelar o problema e gerar uma boa função de fitness não é um trabalho simples, e o desempenho do algoritmo depende muito do seu modelo.

Mesmo com essas restrições, existem diversas aplicações (e tentativas de aplicação) de algoritmos genéticos na indústria, no mercado financeiro e (ironicamente) em bioinformática, além de ser uma ferramenta auxiliar no ambiente acadêmico. Se duvida disso, dê uma olhada nos resultados do Google.

Espero que algum dia um algoritmo genético possa te ajudar a evoluir na resolução de um problema.