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ão 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.

Contra a regulamentação da profissão de analista de sistemas

O Projeto de Lei 607/2007 chegou ao Senado com parecer favorável (e você pode acompanhar o processo neste link, se o servidor do Senado te ajudar). É um tema que já foi bem discutido em outros blogs, como o Não ao PLS 607/2007, dedicado a isso, pelo Professor Silvio Meira, e por colegas de profissão, como Phillip Calçado e Rodrigo Kumpera. Recomendo que leiam esses posts todos, que possuem muitos argumentos com os quais concordo.

Para resumir a história, o projeto de lei propõe a criação de um Conselho Federal de Informática e Conselhos Regionais espalhados pelo país, no mesmo molde do Conselho de Medicina. Também seguindo o modelo dos nossos amigos médicos, o projeto de lei quer tornar obrigatório que um Analista de Sistemas seja formado em uma faculdade de Ciência da Computação, Sistemas de Informação ou Processamento de Dados. E quem não tem nenhum desses diplomas? Quem possuir 5 anos comprovados trabalhando em TI, vai ter uma colher de chá, mas os outros serão considerados ilegais.

Muita gente olha para isso e pensa que essa lei vai botar ordem na casa. Afinal, médicos são fodões, e respeitados e ganham melhor que você que programa em Visual Basic. Finalmente, depois de tantos livros e cursos que você fez, vai poder andar na rua com muito mais orgulho, e blá, blá, blá.

Desculpem o balde de água fria, mas essa lei é um retrocesso, um atraso para o país. Não é um passo para trás, é praticamente um moonwalking. Eis os principais porquês:

Competitividade no cenário global: o Brasil já tem dificuldade para competir com outros países na hora de vender TI por causa da burocracia, dos impostos e da barreira da língua. Coloque mais uma coisa para dificultar, como por exemplo uma regulamentação da profissão de analista de sistemas, e veja investidores começando a olhar para o Kuwait ou Polônia como opções mais lucrativas que o Brasil. Pior, começa a valer muito mais a pena para as empresas brasileiras contratarem serviços de outros países, como a Índia. A regulamentação no Brasil não vai criar e nem proteger empregos. Ela faz os empregos migrarem.

Barreira ao empreendedorismo: no Brasil já é complicado abrir um negócio, porque a lei não te ajuda, os impostos comem todo aquele capital que você preferia transformar em mais empregos. A regulamentação da informática torna as coisas ainda mais complicadas, ainda mais hoje que toda empresa precisa pelo menos um pouco de TI. Obrigado a contratar pessoas com diploma e todos os outros detalhes exigidos pelo Conselho Regional, o empreendedor se torna refém dos preços tabelados causados pela falta de mão de obra.

Barreira à inovação: Países que são pólos efervescentes de inovação em tecnologia como os Estados Unidos e a Índia não criam esse tipo de barreira e é por isso que estão aonde estão. O Vale do Silício (de onde sairam as principais e mais famosas empresas de TI do mundo) não existiria com uma lei que torna mais complicada a captação de talentos. E como uma regulamentação pode definir o que é o mínimo que um profissional deve conhecer em uma área tão dinâmica como tecnologia? Isso acaba tendo o mesmo efeito que o vestibular, em que as pessoas vão investir nesse conjunto mínimo de habilidades, ao invés de se arriscar estudando coisas que poderiam gerar muito mais valor.

Baixa oferta de mão de obra qualificada: a gente já está cansado de ouvir as notícias de que está faltando mão de obra qualificada para preencher as vagas de tecnologia em empresas. Mesmo com a crise isso é verdade, como você pode ver nos sites de ofertas de emprego. Com a regulamentação você torna o número de possíveis candidatos ainda menor. O que começa a tornar interessante terceirizar ou contratar serviços em outros países. Ou fechar as portas. Ou engolir a qualidade baixa de qualquer jeito (você não acha que ter diploma seja sinônimo de qualidade, certo?).

Incentivo à mediocridade: não posso opinar sobre outras profissões que não conheço direito. Mas em informática, uma reserva de mercado só vai servir para proteger os medíocres, os caras que tem o diploma e pagam a mensalidade do Conselho Regional em dia, mas que são profissionais bem “mais ou menos”. Normalmente são os caras que se formaram em alguma Uniesquina do grupo Tabajara (se alguém se forma no seu curso sem saber programar, seu curso é picareta) por aí, em que o processo seletivo se tratava de assinar o cheque, e quase todo mundo se forma no tempo certo (se pagar direitinho). Esse cara pode ficar mais despreocupado ainda em tentar melhorar, já que a carteirinha de registro dele e a falta de mão de obra seguram o emprego dele. Se bobear, ele apenas assina os projetos. Os caras bons, diferentes dele, hoje já se diferenciam tanto que não tem problema para se colocar. Se souberem vender seu peixe até conseguem um bom salário. Os bons não precisam dessa lei para se proteger.

Farinha do mesmo saco?: O projeto de lei trata todo profissional de TI como Analista de Sistemas ou Técnico de informática. Inclusive diz que pessoas que vão gerenciar projetos ou fazer auditoria precisam ser profissionais com diploma na área. Tudo bem que acho meio complicado lidar com gerente de TI que entende pouco de informática, mas acho um exagero dizer que alguém precise de um diploma na área para entender o suficiente para gerenciar o projeto. Desenvolver um sistema e gerenciar pessoas são competências muito diferentes, e acredito que uma pessoa que se formou em Ciência da Computação não morra de amores por gerenciar um projeto, da mesma forma que alguém que se formou em Administração não deve achar muito legal desenhar a arquitetura em camadas de um sistema web de alta performance. Acho besteira desperdiçar o tempo dos professores e desses alunos que acham mais legal gerenciar, com aulas sobre árvores rubro-negra, por exemplo. Sem falar que os cursos de TI normalmente não tem quase nada voltado a planejamento, coordenação e etc. (ainda bem, porque se tivessem iriam deixar de fora partes importantes do currículo).

Mais uma taxa para machucar seu bolso: Essa é fácil de justificar. Você, trabalhador honesto, acha legal pagar uma taxa anual (ou mensal, sei lá) para poder continuar trabalhando honestamente? E os impostos que você já paga?

Diploma como um fim: a regulamentação parte do pressuposto de que o diploma é um fim, e não um meio para que o sujeito se torne um bom profissional. Como se ao receber o diploma ele se tornasse um ser iluminado, saindo de seu casulo dourado para se tornar um super mega fodaço analista de sistemas. Acredito que todo mundo que trabalha na área já conheceu gente que tem o diploma e mesmo assim é um zero à esquerda como profissional. Todo mundo da área sabe que existem muitas faculdades que não se preocupam com a qualidade do curso, e sim com a lucratividade do negócio do diploma. A regulamentação ajuda as pessoas que vêem o diploma como um fim a se tornarem mais acomodadas ainda. Porque elas sairam do casulo dourado.

Contra-argumentos comuns e esperados

Reservei este espaço para já deixar meio respondidos os principais contra argumentos (alguns meio idiotas) que vejo por aí quando este assunto é discutido.

“Você está reclamando porque não tem diploma“: Falso. Eu sou formado em Ciência da Computação. Mesmo assim, acho idiota esse argumento. Discussões se fazem com idéias, não com credenciais.

“Você deixaria uma pessoa qualquer que não fosse formada em medicina te operar numa sala de cirurgia?“: Dã! Esse contra argumento assume que essas duas profissões são muito parecidas, o que não é verdade. A medicina não avança na mesma velocidade que a tecnologia. A medicina é uma profissão em que o diploma está muito mais próximo da finalidade a que se propõe (vide metáfora do casulo dourado), mesmo que no decorrer da profissão o profissional precise se atualizar. E principalmente, em uma mesa de cirurgia uma pessoa pode morrer. Como você vai saber se aquele cara que vai te operar (cruz-credo, bate na madeira) pelo menos tem uma idéia do que está fazendo? Um jeito de testar é deixar ele fazer, mas você pode não estar lá para dar o veredito depois. Em informática, você pode e deve levar um tempo para avaliar a competência de alguém. Se você tem um cara muito ruim no seu projeto, você vai notar depois de um mês. Você não tem um mês para avaliar um médico.

“Sem a regulamentação a área fica cheia de oportunistas que aprenderam a programar com um livrinho de banca de jornal e oferecem o serviço a preços muito baixos.“: Oi, conhece capitalismo? Se o serviço que esse garoto fornece, com conhecimento de banca de jornal, atende o que esse suposto cliente está querendo, qual é o problema? E se o que o cliente queria era realmente algo muito simples, possível de se fazer com conhecimento de banca de jornal? Esse cliente também tem que ter na cabeça de quem ele está comprando, e está assumindo esse risco. Muitos vão preferir um profissional graduado para não arriscar e vão pagar mais por isso. O mercado tem diferenças gritantes de salário, e na minha opinião é muito mais questão da pessoa saber se vender (no bom sentido).

Conclusão

A regulamentação só gera mais dinheiro para donos de faculdades picaretas, para as pessoas que vão fazer parte desses conselhos e vai passar um bom tempo contando o dinheiro das mensalidades dos profissionais registrados e para os profissionais mais acomodados. É uma lei que beneficia poucos e prejudica o crescimento do país. Enquanto isso, países que levam a tecnologia e desenvolvimento a sério nem cogitam criar uma lei como essa.