“Não existe almoço grátis”, diria Milton Friedman. A máxima tem um fundamento importante: mesmo quando as coisas não vêm com uma etiqueta indicando um preço, não quer dizer que elas deixaram de ter um custo. O software pode ter sido obtido de graça (seja software de código-livre, seja software pirata), mas o desenvolvedor deseja certamente ser recompensado pelo tempo que dedicou ao trabalho.

Essa recompensa pode até não ser monetária. Muitas pessoas trabalham em busca de reconhecimento, ou por desejarem resolver um problema que o incomoda, ou por hobby - um mero passatempo que agrada. Sempre há algum tipo de recompensa desejada em troca.

Entretanto, há uma coisa diferente em software: depois que o produto estiver pronto, ele pode ser infinitamente consumido a um custo irrelevante. Duplicar software tem custo marginal que é zero, se comparado ao custo do desenvolvimento. O mesmo pode ser dito de qualquer produto que possa ser digitalizável: músicas, filmes, informação em geral. Esse é um dos pontos-chave para falarmos da Economia Digital.

Baseado nisso, eu deveria me esticar um pouco para justificar a seguinte afirmação: “a melhor forma de garantir a produção de riquezas em uma sociedade cada vez mais baseada em uma economia digital está em buscar uma forma de fomentar e financiar os criadores, e buscar consumir apenas aquilo que possui um custo marginal de duplicação.”

Mas se eu esticar demais, deixo a coisa complicada. O que eu quero dizer é simples: se arrumarmos um sistema onde as pessoas que produzem tenham um sistema que incentiva a produção ao mesmo tempo que obrigue que o produto final seja livremente copiado, então toda a sociedade se beneficiaria mais do que numa sociedade onde há escassez artificial.

E o que é escassez artificial? Software proprietário. Música com proteção de DRM. Patentes sobre desenvolvimento de remédios. Livros que não podem ser copiados em universidades… qualquer coisa onde a tecnologia (ou a política) é usada para impedir o livre fluxo e consumo de bens e serviços.

Software as a Service

O crescimento e a adoção do modelo de desenvolvimento open source levou a uma reação a algumas das empresas que possuem a propriedade intelectual como pilar estratégico. Essa reação foi simples: “vamos deixar de pensar no software como um produto, e vamos transformar num serviço”. Os consumidores não pagariam um valor grande para comprar o (direito de uso do) software, mas passariam a usar a infra-estrutura dos provedores de serviço em um modelo pay-as-you-go. Ou seja: ao invés de ter que comprar o carro, o consumidor passou a andar de táxi. O consumidor consegue o que quer e o fornecedor arrumou uma maneira de receber uma recompensa pelo seu trabalho. Todos saíram contentes, certo?

Ainda não. Isso pode ser ótimo para quem não quer ter a dor de cabeça de dirigir o carro, mas é péssimo para aqueles que não querem depender do taxista. É péssimo para aqueles que querem um carro para exercer eles mesmos uma outra atividade econômica.

Mesmo que as empresas não estejam mais cobrando pelo produto, ainda falta um mecanismo para permitir a livre duplicação de um produto depois de acabado.

Por que não o Open Source?

Porque não funciona como estímulo para a inovação. Qual é o projeto que você conheça que foi a) desenvolvido desde o começo de forma aberta e b) razoavelmente original em sua concepção e c) capaz de recompensar diretamente o idealizador do projeto apenas?

Linux? Cópia do Unix, feito há mais de 40 anos. Apache? Servidores web já existiam. Pessoas que trabalham em projetos de linguagens de programação abertas fazem isso ou por hobby ou são projetos financiados por terceiros. Android? Não há nada de novo.

Nenhum. O modelo open source é ótimo para implementar idéias que já se provaram, mas não funciona como campo de laboratório. Para idéias realmente inovadoras e para empreendedores, as recompensas possíveis não são maiores do que os riscos envolvidos. E as pessoas só trabalham em coisas arriscadas quando a recompensa é proporcional.

Sem contar que é difícil de engolir o papo de que as empresas que produzem software open source podem viver de suporte. Se o produto for realmente de qualidade, é de se esperar que ele não dê dor de cabeça para o consumidor final. Software de qualidade (just works) e dependência de equipe de suporte são qualidades mutuamente exclusivas.

Uma alternativa: o mercado de futuros

Se você já tentou comprar um imóvel, você deve ter percebido que existe a possibilidade de comprar o imóvel “na planta”. Em miúdos, você fecha um contrato de um imóvel que ainda será construído. Obviamente, quem compra o imóvel na planta acaba pagando um valor menor do que os que compram o mesmo imóvel em etapas posteriores do empreendimento. Isso acontece por que um comprador de imóvel na planta está comprando não só o imóvel, mas está comprando risco. Não há nada que elimine a possibilidade de atrasos na execução, oscilações do mercado e até mesmo que o dono da construtora e sua secretária de 22 anos de idade fujam com o seu dinheirinho para alguma ilha remota do mundo.

Esse risco tem um valor a ser quantificado. Se para o comprador do imóvel o valor do risco é menor do que o desconto, certamente é vantajoso comprar o imóvel na planta. A empreendedora também vê vantagem. Ao ter clientes que compraram o imóvel na planta, ela pode arrumar recursos para iniciar as obras, garantindo a continuidade do empreendimento. Ela pode também não vender algumas das unidades e vender apenas com o imóvel pronto, obtendo assim uma margem de lucro maior.

Não creio ser tão difícil assim emular um modelo parecido para a Economia Digital. Nesse sistema, as pessoas que desejam algum software (ou música, ou livro, ou filme) compram um produto “na planta” daquele que for capaz de oferecer o produto ao menor custo, incluindo o risco. O vendedor, em troca, se comprometeria a disponibilizar livremente o produto do seu trabalho acabado. Dessa forma, temos o melhor dos dois mundos: o produtor só trabalha com a garantia de que será recompensado e o consumidor fica livre para usufruir do que comprou, como quiser.

Há ainda uma óbvia vantagem: se forem várias as pessoas interessadas em um produto similar, elas podem fazer o rateio do custo.

Já existem empresas que tentam levar o modelo adiante. Existe um site chamado Micropledge que atua como um mercado de projetos futuros. Consumidores se comprometem a pagar um pequeno valor em favor de um determinado projeto. Esses compromissos (pledges) são registrados no site e acumulados. Desenvolvedores podem “dar o seu preço” para que trabalhem no projeto. No instante que o valor acumulado em pledges é satisfatório para o desenvolvedor, o trabalho se inicia. O desenvolvedor só pode receber o dinheiro e as pledges só são cobradas depois que o produto é entregue de forma satisfatória pela maioria das pessoas que fizeram o compromisso.

Na teoria e na prática, é um verdadeiro exemplo de como funciona uma economia de mercado. Entretanto, para que funcione, é preciso que acumule uma massa crítica.

É aí que você entra.

Se o editor-chefe resolvesse hospedar este blog usando o Amazon Web Services, o custo mensal de transferência seria de R$0,46.

Contrariamente aos desejos do nosso editor-chefe, este blog ainda não é o seu ponto único de informação sobre tecnologia. Se fosse, você estaria perdendo muita informação interessante que foi produzida em outros lugares. Por exemplo: muitas pessoas estão passando a adotar software para gerenciamento distribuído de código e controle de versão. Tendo em vista que nosso editor-chefe é um usuário de CVS e SVN, não faz muito sentido para ele acompanhar as experiências das pessoas que estão adotando sistemas que se fundamentam em outra arquitetura básica, logo ele terá pouca oportunidade para escrever a respeito.

Esse não é um texto para falar sobre as vantagens técnicas de usar sistemas distribuídos de versão (Distributed Version Control System - DVCS) como o Git, Darcs ou Mercurial. Já existe muito material que você pode encontrar por aí, como por exemplo uma apresentação em vídeo do próprio Linus Torvalds sobre o Git e suas vantagens. O que eu quero é justamente comentar sobre os princípios que levaram Torvalds a desenvolver um sistema completamente novo. De acordo com Linus, sistemas distribuídos não são melhores por questões tecnológicas ou de engenharia avançada, mas são melhores por princípios da arquitetura: “Com sistemas centralizados”, diz ele, “o desenvolvedor tem que lidar com questões que podem se tornar problemas políticos - saber quem pode ter acesso ao sistema; quem pode ter acesso de escrita; quem vai ser o responsável por determinados subsistemas, etc. Em sistemas distribuídos, isso não acontece. Cada desenvolvedor é dono do seu próprio repositório e decide livremente de quem ele irá puxar suas alterações. Não existe um repositório canônico, oficial. O meu repositório de código é tão bom quanto o dos desenvolvedores que estão trabalhando em repositórios de quem eu colaboro.”

Uma outra questão - fundamentalmente importante - é a questão da confiança. Diz Torvalds: “Eu não preciso mais ficar verificando a qualidade de cada patch que entra na minha árvore de código. Eu posso puxar qualquer coisa que venha da árvore de Andrew Morton (desenvolvedor principal da versão 2.6 do kernel do Linux) sem medo de causar prejuízo em meu código, pois eu confio em Andrew.”

Esse é um argumento estranho, mas muito poderoso: nós podemos confiar em uma, duas, dez pessoas. Mas não podemos confiar em centenas ou milhares de pessoas. Confiança não é escalável. Podemos até confiar em alguém desconhecido indiretamente (o amigo do meu amigo…) mas esse critério não resiste por muitas iterações. É esse o ponto que torna sistemas que se baseiam em arquiteturas distribuídas melhores.

Não importa o quão superior ou madura seja a implementação de um sistema centralizado, ele jamais terá “trabalhe apenas com as pessoas em que você confia” como uma feature. É impossível obter isso em um sistema centralizado, por design. A killer feature de um DVCS é a possibilidade de gerenciar seus projetos usando o seu grau de confiança nas pessoas.

Nosso editor-chefe tem planos de dominação mundial com o blog. Ele quer montar o primeiro blog de computeiros que recebe acessos de 10 milhões de visitantes únicos/dia. Depois de conseguir esses leitores, ele vai desenvolver um applet Java que forma imagens psicodélicas a uma taxa de 4,78 FPS, hipnotizando a todos e fazendo com que as vítimas enviem a senha do cartão de crédito para ele, por twitter.

Para executar esse plano diabólico, ele precisa de artigos interessantes que chamem a atenção do público. É só por isso que ele fica nos pentelhando por email, cobrando artigos e novidades. Quando ele fica sem material, ele começa a trabalhar em um site de vagas e empregos só para ter qualquer coisa para contar e chamar a sua atenção. Um porre.

Vendo a minha caixa de email, eu vi que tenho 987 mensagens suplicando para que eu volte a escrever meus textos inteligentes, provocativos, instigantes, filosóficos e que apresentam de forma clara e concisa a solução para todos os problemas do mundo - até o problema da defesa do Corinthians.

Infelizmente, 986 mensagens eram da mesma pessoa: o editor do blog; que só não me demite pelo fato do blog estar hospedado no meu servidor. A outra mensagem foi escrita por uma jovem russa que deve ter errado o destinatário do email, afinal “conciso” não é um adjetivo muito adequado para as minhas asneiras. Ela também me chamou de Boris Kaputtiev, mas o que realmente denunciou foi ter chamado meu texto de conciso.

O problema é que, para escrever, eu funciono na base do “Test Driven Development”. As idéias surgem na cabeça, mas eu só começo a colocar no papel depois que eu encontro uma forma de testar ou validar os princípios envolvidos (nem que seja um Gedankenexperiment). E isso envolve outros testes, outras idéias. Então, o produto final acabaria sendo uma massa verborrágica tão grande que daria inveja aos admiradores dos discursos de Fidel Castro.

Vou tentar um outro approach. Meu objetivo é escrever de forma mais consistente, ainda que a idéia não esteja completamente validada. Meus leitores serão os meus “compiladores”. Talvez, olhando para trás, o que eu venha a escrever sirva de material para um livro. Há também uma chance que o que eu venha a escrever sirva para que eu dê risadinhas envergonhadas e pensar comigo mesmo: “Cara, o que foi que eu bebi para ter a cara-de-pau de escrever um negócio ridículo desse?”

Vamos ver o que se dá nesse experimento. Usem a caixa de comentários para emitir os seus warnings, ok?

Se você perguntar qual é a melhor fórmula de sucesso a um produtor de cinema, ele certamente vai te falar sobre como arrumar os nomes dos atores, sobre quanto custa para ter um nome de peso na direção, sobre a importância de uma equipe de pré e pós-produção, do quanto vai te custar para ter uma equipe de ponta de efeitos especiais, de todos os mecanismos que devem ser evitados para evitar rejeição do público (linguagem inapropriada, temas controversos) e de elementos que podem e devem ser utlizados (você pode colocar a Jéssica Alba numa roupinha apertada e dizer que é “uniforme de super-herói”: vai agradar as crianças e aos adultos) para garantir a atenção do público.

Enquanto ele se finge de ocupado e vai em direção ao seu carro conversível, o executivo vai te contar que um bom filme, hoje em dia, não sai por menos de 100 milhões de dólares e fatura, quando muito, de 2 a 5 vezes esse valor. Nada mal, não é mesmo?

Pois bem. Ontem eu consegui fugir da frente do computador e me enfiei na frente de outra tela, desta vez para assistir Juno. Uma história simples, com personagens que resgatam meus fiapos de esperança na humanidade. Não foi nenhuma surpresa que o filme tenha recebido o Oscar de melhor roteiro, escrito pela talentosa Diablo Cody. O que realmente surpreendeu é que o filme foi feito com um orçamento de apenas US$ 2,5 milhões, e já tenha faturado mais de US$ 130 milhões. Um retorno de 5500% sobre o investimento. É o tipo de coisa que deve fazer com que o executivo ponha em xeque a sua própria fórmula de sucesso: “por que é que eu não consigo fazer algo tão bem sucedido?”

A resposta é simples: em qualquer área de negócio, compram-se todos os especialistas da indústria, mas não se compra talento. Não há como botar preço num roteiro como o que foi escrito por Diablo Cody.

Encontre e desenvolva seu talento. Expertise é secundária.

Já falei muito. Vamos começar?

Instalação

O web.py é um módulo escrito em Python. Você pode instalá-lo junto com os outros pacotes de sua instalação em Python, ou pode simplesmente copiar a pasta com o código para algum local que esteja dentro do seu Python Path.

A instalação direta pode ser feita pelos métodos já tradicionais. Usando easy_install, por exemplo. Há pacotes fornecidos pela Debian, também.

Se você quiser, você pode baixar no site o código da última versão liberada. Se fizer isso, você vai pegar a pasta “web” e colocar no na sua pasta de código, da mesma forma que você faria com um outro módulo desenvolvido por terceiros.

Aplicativo Mínimo

O que nós sabemos sobre HTTP?

• Que é um protocolo de aplicação, ou seja, é um protocolo para a transmissão de dados pertencentes a uma aplicação que se utiliza de arquitetura cliente/servidor.
• Que o servidor HTTP recebe requisições e deve fornecer respostas .
• Que cada requisição indica um método (uma ação) que deve ser tomado sobre um recurso disponível no servidor. Em outras palavras, se um cliente envia uma requisição GET /images/company_logo.gif, podemos entender que o cliente deseja obter (GET) o recurso /images/company_logo.gif.
• Que existem vários métodos: GET, HEAD, POST, PUT, DELETE… cada um sendo usado para indicar uma intenção diferente do cliente em relação ao recurso.

O web.py fornece um servidor web básico, indicado para a fase de desenvolvimento/debug/testes. Vamos colocar esse servidor pra funcionar. Vamos ver como fica um aplicativo mínimo, onde o servidor responde com um “Hello” para cada requisição GET que for feita, independente do recurso solicitado. Como fazer isso?

Para isso, o servidor do web.py precisa:

• De uma indicação de quais recursos ele deve prover uma resposta.
• Como responder, para cada método.

As 8 linhas abaixo fazem isso.

import web

urls = (

    '/(.*)', 'index'

)

class index:

    def GET(self, resource):

        print "Hello, dude. Are you really trying to GET /%s?" % resource

if __name__ == '__main__': web.run(urls, globals())

Praticamente auto-explicativo, não é mesmo? Define-se uma variável que contém uma lista, tomada aos pares. O primeiro elemento desse par é uma expressão regular e o segundo é o nome de uma classe. Essa lista é passada como parâmetro para o servidor web, que passa a usar a classe definida para atender as requisições que dão match entre a URL requisitada e a expressão regular declarada por você.

A nossa classe “index” possui um método GET, que vai responder com o “Hello, dude. E mostrar qual foi o recurso solicitado pelo cliente”. Salvando esse arquivo (chamado “code.py”, por exemplo), basta invocar o interpretador Python

$python code.py

e teremos um servidor rodando na porta 8080. Se quiser mudar a porta-padrão, é só passar como parâmetro na hora de iniciar o script.

Você vai ver que usamos o velho print para a parte de resposta. O web.py (na versão 0.22) altera o descritor de arquivo stdout, e faz com que qualquer coisa que seria normalmente enviada para o console seja enviada para o socket que foi aberto para o cliente. Se você desejar monitorar alguma coisa no console, a função a ser usada é web.debug().

Bem, se você conseguiu colocar o servidor para rodar e seu browser recebe a resposta, creio que está tudo bem com o seu setup do web.py. Podemos partir para o próximo passo e adicionar algumas funcionalidades para o nosso serviço.

Observação importante: Essa série não é um texto para aprendermos técnicas de análise ou de projeto de software. Portanto, não estranhe a forma que vamos montar o webapp, ou até mesmo a falta de “best practices” no desenvolvimento. Por exemplo, usaremos um único arquivo para todo o sistema, sem separar por classes ou funcionalidades. Vamos trabalhar de forma bastante iterativa e , para cada funcionalidade proposta que exercite algum novo conceito, vamos verificar quais são as mudanças necessárias no nosso código e adaptar o código para isso.

1) Criando a página para enviar links.

Poderíamos começar o nosso site criando a página principal, onde todos os links são listados. Mas precisamos ter um sistema inicial que permita que os links sejam incluídos, não é mesmo?

Vamos começar por aí, então. Vamos criar uma página onde o usuário preenche um formulário com um único campo de texto, representando um link. Esse link precisará ser salvo. Para tanto, vamos utilizar um servidor de banco de dados e criar uma tabela “Link”, na qual cada link possui um número de identificação, uma url e uma data de publicação.

CREATE TABLE Link (

	id serial PRIMARY KEY,

	url varchar(512) NOT NULL,

	date_published timestamp NOT NULL DEFAULT NOW()

);

Para a funcionalidade desejada, necessitamos:

• uma forma de apresentar um formulário com o campo de texto para o usuário.
• uma forma de processar o formulário.
• uma forma de fazer “sanitização de dados”. Qualquer dado que é enviado pelo usuário é potencialmente perigoso, ainda mais se for um dado que será usado para construir consultas SQL.
• ser capazes de inserirmos os dados no banco de dados.

Mais uma vez, o web.py pode nos ajudar com essa tarefa. O web.py contém um módulo para a manipulação de formulários. Nele, define-se uma lista de input fields (nos moldes do HTML: text, dropdown, radio, checkbox, etc) e uma série de atributos desses inputs (nome, tamanho, valores default), além de uma série de funções de validação desses campos de entrada.

Para ilustrar, vejamos o formulário definido abaixo:

SubmitForm = form.Form(
        form.Textbox('url',
                     form.Validator('Deve começar com "http://"', lambda x: x.startswith('http://')),
                     description='Link'),
        form.Button('Enviar!', type="submit")
        )

Temos um objeto Form, com um campo de texto e um botão. O campo de texto será obrigatoriamente uma string que começa com a substring “http://”.

Dois métodos importantes: Form.render() e Form.validates() . O primeiro retorna uma string que é a representação HTML de cada um dos inputs que ele contém, o segundo verifica se os valores contidos em um formulário satisfazem todos as funções de validação. Muito mais pode ser feito com isso, e você pode verificar isso na documentação de form em web.py.

Para a parte de banco de dados, precisamos apenas definir quais os parâmetros de configuração para a conexão com o banco de dados. Depois que a conexão estiver estabelecida, usaremos os métodos adequados para a construção de queries SQL: web.insert(), web.select(), web.update() e web.delete(). Esses métodos todos precisam apenas do nome da tabela e de eventuais parâmetros opcionais (colocar um “limit” no tamanho da lista de resultados de um select, por exemplo) .

Colocando tudo junto:

# -*- coding: utf-8 -*-

import web
from web import db, form

urls = (
     '/submit', 'submit',
 )

class submit:
    SubmitForm = form.Form(
        form.Textbox('url',
                     form.Validator('Deve começar com "http://"', lambda x: x.startswith('http://')),
                     description='Link'),
        form.Button('Enviar!', type="submit")
        )

    page_content = '<html><body><form id="new_link" action="/submit" method="post">%s</form></body></html>'
    def GET(self):
        frm = submit.SubmitForm()
        print submit.page_content % frm.render()
    def POST(self):
        frm = submit.SubmitForm()
        if frm.validates():
            i = web.input()
            web.insert('Link', url=i.url)
            print "Link enviado com sucesso."
        else:
            print submit.page_content % ("<p>Houve algo errado com o preenchimento</p>" + frm.render())

if __name__ == "__main__":
    web.config.db_parameters = dict(dbn  = 'postgres', # servidores aceitos 'postgres', 'mysql' ou 'firebird'
                                    db   = 'nome_do_servidor',
                                    user = 'usuario_do_servidor',
                                    pw   = 'senha')
    web.run(urls, globals(), web.reloader)

Preste atenção aos seguintes detalhes:

• Cria-se uma instância do formulário SubmitForm a cada requisição, seja para GET ou para POST. Se não fizermos isso, o formulário pode conter os valores de uma outra requisição feita por um outro usuário.
• validates() tem como parâmetro default o valor de web.input(). web.input() é um método que retorna um objeto do tipo Storage contendo os pares chaves/valores enviados na querystring. Um objeto Storage funciona como um dictionary, com a diferença que seus elementos podem ser acessados por d.foo ao invés de d[’foo’].
• Definimos o dict que contém os parâmetros necessários para o banco de dados, e colocamos logo antes da linha com web.run(). Parte do trabalho do web.run() é carregar o contexto do ambiente e inicializar a conexão com o banco de dados.
• Só pode ser feita conexão com um banco de dados. Essa é uma limitação grave da versão atual do web.py, que será corrigida na próxima versão.
• Adicionamos um parâmetro opcional ao web.run, chamado web.reloader. Essa diretiva permite que o servidor recarregue o código a cada requisição. Isso permite que você faça alterações no código e veja imediatamente o resultado, sem necessitar parar/reiniciar o servidor.

O app já é capaz de cadastrar os links. Amanhã (update: vai ficar pro ano que vem, pessoal. Mas prometo que isso essa série chega ao seu fim antes da sua decoração de natal, ok?) vamos ver como utilizar o esquema de templates do web.py para apresentar os links, além do sistema de autenticação de usuários.

Vamos dar uma olhada nos nossos requisitos, e apresentar algumas questões de tecnologia:

• O site tem que ser capaz de autenticar e identificar unicamente cada usuário que deseja cadastrar links.
• Deve ser capaz de manter uma lista de quem foi o primeiro a enviar um link, além da data que o link foi enviado.
• Deve ter um sistema que permita ao usuário indicar se gostou (aprovou) ou não gostou (rejeitou) um link enviado por qualquer pessoa que utilize o serviço.
• Deve permitir que cada link enviado possua um fórum de discussão.
• Deve permitir que uma pessoa possa iniciar um tópico de discussão, sem enviar um link. No caso, vamos fazer o seguinte: se o usuário preencher apenas os campos de título e comentário em um formulário de link, mas deixar o campo para a URL em branco, vamos criar um link para um item dentro do próprio site.
• Deve permitir ao usuário enviar um lote de links a partir de uma fonte que ele já conheça. Isso vai servir para que o sistema, no futuro, tenha uma grande base de links prévios para aprender rapidamente.
• Deve permitir que o usuário faça o seu voto (aprovado/rejeitado) sem sair da página que está. Para isso, vamos usar uma pitada de AJAX.

Tendo os requisitos delineados, podemos ver que vamos precisar dos sistemas comumente usados em aplicativos web: um banco de dados, um servidor web, um sistema para geração de páginas dinamicamente. Além disso, teremos que usar alguma biblioteca para importar links e parsear RSS.

A parte de programação já foi definida no título: vamos usar Python. É o que estou usando ultimamente para meus outros projetos, é uma linguagem elegante, divertida (sim, diversão conta), dinâmica, com bibliotecas fartas e bem documentadas como parte da biblioteca-padrão. Se nada disso serviu como argumento, diga para o seu chefe que você vai aprender Python pois ficou sabendo que o pessoal do Google usa, e tudo que eles usam tem que ser bom, não é mesmo?

Para o servidor de banco de dados: PostgreSQL. Maduro, estável, bastante documentação. Outros bancos de dados serviriam, mas escolhi PostgreSQL por pura comodidade. Se você quiser portar os scripts SQL que eu colocar aqui para seu banco de preferência, creio que não terá dificuldades.

Para a parte de AJAX, vamos favorecer a prata da casa: Juice Lib é uma biblioteca pequena, mas com funcionalidades bem pensadas para a parte de comunicação assíncrona com o servidor. Eu tenho enchido um pouco o saco do Miguel na questão de manipulação de DOM (a juice faz isso através de extensão de métodos sobre string, o que pode vir a te causar dor de cabeça se o seu código Javascript começar a crescer muito), mas o resultado geral é poderoso o suficiente para que possamos ter o esquema de apresentação da votação em pouquíssimas linhas de Javascript.

Resta falar sobre qual sistema vamos usar para formarmos uma “Aplicação Web” propriamente dita. Controle de sessão, classes controllers, formas para acessar o banco de dados, apresentação de páginas construídas dinamicamente, etc, etc, etc.

Eu já disse que odeio frameworks. O que eu quero é algo que pudesse funcionar como um único módulo ou biblioteca, que pudesse ser importado a partir de um shell Python e me oferecer as funcionalidades necessárias para um webapp.

O que vamos usar, então, é um sistema que seja o anti-framework: esse sistema, para mim, é o web.py

O que diferencia o web.py dos outros frameworks para aplicações web desenvolvidas em Python?

Simples: a filosofia.

Muita atividade ocorreu na comunidade de desenvolvedores Python, buscando uma resposta para o sucesso do Ruby On Rails. Começaram então a pensar em implementar um framework que pudesse ser tão “pragmático” e “rápido” quanto o Ruby On Rails.

E isso levou a uma febre de grupos desenvolvendo frameworks para Python. Sistemas que fazem mapeamento OR. Que abstraem sua camada de dados completamente. Que abstraem a camada de apresentação completamente. Que abstraem a camada de controle completamente. Que escrevem elogios na tela enquanto eles fazem tudo automaticamente para você.

O problema: abstrações excessivas falham. Cada um dos grupos dos grandes frameworks (Turbogears, Pylons, Django) tinha o seu próprio dialeto para o desenvolvimento de aplicações web, alguma coisa parecida com Python, mas não exatamente Python.

Faltava uma solução que se propusesse a alavancar os conhecimentos tradicionais que as pessoas acumulam ao trabalhar com sistemas web.

O web.py tem essa filosofia. Por exemplo: ao invés de se preocupar em implementar um módulo que faça mapeamento OR para você, o web.py te dá um módulo que serve para facilitar o acesso ao banco de dados, diretamente e de forma segura. Ao invés de expor objetos em Python para uma camada de apresentação, o web.py facilita o trabalho de construir uma resposta HTTP. Ao invés de impor uma disciplina de trabalho, ele oferece as funcionalidades básicas para que você use seu conhecimento acumulado com outros problemas que você teve que resolver.

(Justiça seja feita: o Django parece ter aprendido parte dessa lição. Muito dos esforços recentes do Django para que ele chegue na versão 1.0 está sendo feito no sentido de retirar o que é chamado de “código mágico”.)

Isso não quer dizer que o web.py é perfeito. Não é. A última versão lançada possui algumas coisas no design que você pode até estranhar, e vou falar deles. Espero para ver se a próxima versão irá corrigir mesmo esses problemas. De qualquer forma, por se tratar de uma biblioteca de recursos auxiliares - ao invés de um framework - a ginástica necessária para contornar esses problemas é muito menor.

Chega de escrivinhar. Amanhã, vamos ao código.

Introdução

Sem dúvida, esse ano foi um ano interessante para quem participou da WWW. Se em 2006 a revista Time escolhou “Você” como pessoa do ano, nesse ano houve uma consolidação da idéia da “Web Social”.

Estamos só no começo. Estamos só agora descobrindo que a internet, antes do que uma rede de computadores, é uma rede de pessoas. O futuro da internet vai aprender a juntar essas ligações e formas de interação social (o “Grafo Social”) para trazer serviços mais inteligentes e mais adequados a cada um de nós.

Nesse espiríto, e aproveitando o fim de ano - onde todo mundo acaba diminuindo o ritmo de trabalho mesmo - eu pensei em fazer um pequeno passo-a-passo de um “Site Social”, para aqueles que pensam em oferecer um desses serviços.

A idéia

Uma das coisas mais comuns que vimos por aí foi a proliferação de sites onde os usuários mandam as notícias, e a audiência escolhe os textos que são “dignos de capa”, através de “votos” nos links. O maior exemplo para esse tipo de site é o Digg, site com muitos usuários no mundo todo.

Ainda que sites como o Digg até possam trazer eventualmente alguns textos interessantes, já se percebeu que é muito difícil ter um site onde o público seja o único responsável pela determinação do conteúdo relevante. Não por achar que as pessoas não sejam capazes de se gerenciarem, mas pelo fato de ser muito difícil de obter textos e notícias que sejam simultaneamente interessantes e agradem a um grande público.

O Reddit apresentou uma evolução nesse passo. Ele possui um filtro que aprende, através do seu histórico de votação, a te indicar quais links podem ser mais interessante para você.

Mas ainda falta alguma coisa: mesmo o filtro do Reddit não é capaz de me trazer links mais específicos, adequados para os meus interesses. Talvez, se ele puder saber quais os meus gostos, hábitos, idiomas que eu falo, comunidades das quais participo e outras informações gerais, talvez o filtro possa ser mais inteligente e aprender ainda mais.

Bem, eu vou ficar devendo a parte do filtro, por enquanto. Só vou dizer que o nosso site será capaz, quando você acabar, de cadastrar usuários, ver os links enviados, entrar num fórum de discussão para cada link e manter um histórico de votação.

O que eu passei fazendo nos últimos dois dias está aqui. Ao longo dos próximos dias, vou colocar os detalhes e o processo para o desenvolvimento de tal sistema.

Ah, sim. Isso é muito mais um exercício do que algo pra ser considerado software de produção. Trate com carinho. O que mais você queria em dois dias de trabalho?

Eu odeio frameworks. Não um ódio assim que faz pensar em mandar emails ameaçadores ao criador do ASP.NET, nem um ódio que me faça pensar colocar um vírus no computador de algum líder do projeto Jakarta que só permita que ele edite seu código usando Notepad (ou edlin) para o resto da vida. É um ódio de quem tem a sensação de que algo está fundamentalmente errado na forma como os desenvolvedores produzem e consomem frameworks de software.

Quando eu digo isso, a reação tradicional é: “Lullis, você quer o quê? Que todo mundo reinvente a roda? O que você sugere?”

Só posso responder com uma outra pergunta: você conhece o Método Socrático? Maiêutica?

Se você sabe, ótimo. Como eu não tenho como conferir sua resposta, vou tentar dar a minha explicação: o método socrático é um modo de tentar produzir novas idéias (complexas) a partir de um jogo de perguntas e respostas para conceitos mais simples que pertencem ao mesmo contexto.

Por exemplo, suponha que você esteja querendo ensinar cálculo de potências para uma criança. Como um matemático “formal” tentaria transmitir esse conhecimento? Apresentando uma série de colorários, princípios gerais e tentando mostrar todas as definições para a criança, até que ela consiga repetir todos os métodos utilizados pelo seu professor na obtenção de respostas para os problemas pré-estabelecidos.

Um professor que estivesse usando o método socrático certamente começaria fazendo perguntas para as quais os alunos já soubessem. “Usando notação matemática, como vocês fariam para escrever ‘quatro vezes quatro vezes quatro’”? “E se eu quisesse repetir a multiplicação 10 vezes?”. “E se eu quisesse multiplicar infinitamente?”. “E se eu quiser dividir repetidas vezes, ao invés de multiplicar?”. “Quanto é 1 multiplicado por 1?” “Quanto é 1 multiplicado por 1 multiplicado por 1… 100 vezes? E 1000 vezes? E 10?”. Ao deixar as crianças responder essas perguntas, elas mesmas passam a observar os princípios gerais por trás das fórmulas
matemáticas. Através da intuição, elas desenvolvem quase que por conta própria uma nova “unidade de conhecimento”, ao invés de tê-la transmitida através de um mestre. Um professor socrático atua muito mais como um guia, do que como uma bússola.

Qual sistema é melhor? Muito depende do seu objetivo. Alunos das duas escolas conseguirão responder que A^(-x) é igual (1/A^x). Um o fará quase que por instinto, condicionamento mental. O outro pode até não ter isso cravado em sua cabeça, mas chegará à resposta se tiver desenvolvido a habilidade de saber fazer as perguntas certas. “Se ao incrementar o expoente eu multiplico a base, o que aconteceria se eu diminuísse?”

Computadores são inúteis. Eles só sabem dar respostas.

No espiríto do Método Socrático, eu pergunto: o que acontece numa situação em que as perguntas não possuem uma resposta catalogada?

Provavelmente, o aluno de métodos mais tradicionais (digamos, alguém que passou tempo demais estudando Kumon) vai travar, ou voltar para o seu mestre, na esperança de obter as respostas que faltam. Ainda que ele seja capaz de responder por reflexo a equações derivadas de segundo grau, ele não saberá por onde começar caso tenha que jogar Petals around the Rose.

Certo. E o que isso tem a ver com frameworks?

Escreva “define: framework” no Google. Um dos termos que você encontrará é “sistema de regras, idéias ou princípios que é usado para planejar ou decidir algo.”

Olha só que interessante: ao tentar explicar para você sobre o Método Socrático, eu acabei achando uma das melhores formas de explicar o meu desgosto por frameworks de desenvolvimento.

Frameworks, em sua essência, acabam sendo um “pacote fechado” de soluções prontas para alguém que tem um problema a ser resolvido. “Se você está desenvolvendo um aplicativo e precisa de uma integração Web, use o framework XYZ que te dá autenticação de usuários, geração de código HTML a partir dos seus dados, servidor HTTPS e no fim do dia ainda te faz uma massagem nas costas”. “Se você quer desenvolver software para sistemas embarcados, use o nosso DevKit e você terá um emulador em seu computador, configuração de diversos setups em software, cross-compiler e no fim do dia ainda te daz uma massagem nas costas.”

Se ao menos as promessas de massagem fossem verdade…

O problema, ao meu ver, é que alguém (indivíduo ou grupo associado) que decide implementar um framework se coloca na posição de detentor de um pilha de conhecimento como se fosse “a única verdadeira solução”, quando na verdade esse alguém possui apenas uma compilação de regras e receitas usadas na resolução dos problemas dele. Ou, pior, é uma empresa que está tentando criar a solução definitiva. E, devemos saber, isso
não existe.

Outra coisa a se pensar - ao menos para os desenvolvedores web - é que a velocidade do surgimento de tecnologias é muito rápida. Mais rápida até do que a capacidade do grupo de assimilar e sedimentar qualquer forma de conhecimento que possa se transformar em um “pacote fechado.” Aí, logo depois que qualquer sistema começa a se consolidar, já haverá parte do grupo tentando forçar a adoção das novas tecnologias e paradigmas, levando ou a um sistema que é abandonado e preterido em favor da Próxima Grande Tecnologia, ou haverá um produto torto, sem identidade. Jack of all trades, Master of none.

E os desenvolvedores que são usuários desses frameworks, meu Deus? Passam tanto tempo aprendendo a lidar com os problemas, aprendem todas as formas de contornar as falhas de design, decoram tantos lotes de informação que, no fundo, acabam tendo que reaprender sistemas inteiros. Tornar-se verdadeiramente produtivo com o tal framework é quase tão trabalhoso quanto implementar você mesmo as funcionalidades prometidas. Que vantagem há nesse processo?

Qual a alternativa?

Seguindo a analogia, o nosso Software Socrático não é desenvolvido em cima de uma plataforma ou de um framework, mas utilizando pequenos componentes mais simples e que já são conhecidos suficientemente. Esses elementos menores seriam as unidades de conhecimento necessárias para que, através da intuição, possamos chegar a uma solução que produza o resultado esperado.

Um guia, não uma bússola.

“Occam’s Razor” (Navalha de Occam) é uma dessas coisas que a gente escuta por aí, cada um dando uma definição um tanto vaga, que costumam girar em torno de “idéias muito complexas costumam ser erradas” e “entre duas explicações para uma idéia, a mais simples é a correta”.

Pois bem. Se você procurar uma definição, vai ver que (William) Occam é um nome de um filósofo inglês do século XIV, e que “Occam’s Razor” é definido como uma expressão da “Lei da Parcimônia”, ou seja: “Entidades não devem ser adicionadas além do necessário”. Traduzindo: quanto menos conceitos você precisar para explicar e testar uma idéia, melhor.

Penso cá com meus botões - apesar de só ter usado camisetas ultimamente - que essa é uma idéia que não é totalmente assimilada pelos computeiros em geral. Para o nerd tradicional, é divertido quebrar a cabeça resolvendo problemas. Logo, pensa ele, quanto mais complexa a idéia, maior será a recompensa em resolvê-la.

Isso me veio a cabeça lendo o último texto do Steve Yegge, que trata do problema de lidar com grandes bases de código. Alguns trechos abaixo:

People in the industry are very excited about various ideas that nominally help you deal with large code bases, such as IDEs that can manipulate code as “algebraic structures”, and search indexes, and so on. These people tend to view code bases much the way construction workers view dirt: they want great big machines that can move the dirt this way and that. There’s conservation of dirt at work: you can’t compress dirt, not much, so their solution set consists of various ways of shoveling the dirt around. There are even programming interview questions, surely metaphorical, about how you might go about moving an entire mountain of dirt, one truck at a time.

Industry programmers are excited about solutions to a big non-problem. It’s just a mountain of dirt, and you just need big tools to move it around. The tools are exciting but the dirt is not.

Ah, você é daqueles que acredita que há a solução para todos os problemas da humanidade, se todo mundo aprendesse a seguir o manual? Dê uma olhada no que se diz a respeito de Design Patterns:

Interestingly, sales people didn’t get excited about Design Patterns. Nor did PMs, nor marketing folks, nor even engineering managers. The only people who routinely get excited about Design Patterns are programmers, and only programmers who use certain languages. Perl programmers were, by and large, not very impressed with Design Patterns. However, Java programmers misattributed this; they concluded that Perl programmers must be slovenly, no good bachelors who pile laundry in their closests up to the ceiling.

It’s obvious now, though, isn’t it? A design pattern isn’t a feature. A Factory isn’t a feature, nor is a Delegate nor a Proxy nor a Bridge. They “enable” features in a very loose sense, by providing nice boxes to hold the features in. But boxes and bags and shelves take space. And design patterns – at least most of the patterns in the “Gang of Four” book – make code bases get bigger. Tragically, the only GoF pattern that can help code get smaller (Interpreter) is utterly ignored by programmers who otherwise have the names of Design Patterns tatooed on their various body parts.

Dependency Injection is an example of a popular new Java design pattern that programmers using Ruby, Python, Perl and JavaScript have probably never heard of. And if they’ve heard of it, they’ve probably (correctly) concluded that they don’t need it. Dependency Injection is an amazingly elaborate infrastructure for making Java more dynamic in certain ways that are intrinsic to higher-level languages. And – you guessed it – DI makes your Java code base bigger.

E você acha que basta ter ferramentas para resolver esse problema? Diga-me, espertinho, como é que as suas ferramentas vão me ajudar a aprender e assimilar os conceitos desnecessariamente complexos empilhados em seu projeto/código?

Most programmers have successfully compartmentalized their beliefs about code base size. Java programmers are unusually severe offenders but are by no means the only ones. In one compartment, they know big code bases are bad. It only takes grade-school arithmetic to appreciate just how bad they can be. If you have a million lines of code, at 50 lines per “page”, that’s 20,000 pages of code. How long would it take you to read a 20,000-page instruction manual? The effort to simply browse the code base and try to discern its overall structure could take weeks or even months, depending on its density. Significant architectural changes could take months or even years.

In the other compartment, they think their IDE makes the code size a non-issue. (…) There are several problems with this perspective. One is simple arithmetic again: given enough code, you eventually run out of machine resources for managing the code. Imagine a project with a billion lines of code, and then imagine trying to use Eclipse or IntelliJ on that project. The machines – CPU, memory, disk, network – would simply give up. We know this because twenty-million line code bases are already moving beyond the grasp of modern IDEs on modern machines.

Vivemos num mundo acelerado.

Vivemos num mundo acelerado, fruto do trabalho de profissionais como nós. Responsáveis pelos gerenciamento e distribuição de informação e conhecimento. Conhecimento esse que é usado para gerar mais tecnologia, mais informação, mais eficiência, melhores resultados, maior produtividade, economias mais diversas e problemas mais complexos a resolver.

E, ironicamente, um desses complexos problemas que passam pelas cabeças dos executivos é: como encontrar mais profissionais para trabalhar e produzir soluções de qualidade? Quem contratar para ajudar a desenvolver mais soluções?

As tecnologias mudam, as empresas mudam, os projetos mudam. Mas a necessidade de profissionais qualificados e capazes de mudar permanece. Queremos encontrar uma solução para esses problemas. Queremos aproximar profissionais diferenciados e competentes com empresas que sabem qual o valor esses têm. Queremos oferecer um serviço para empresas que possuem um planejamento para a expansão dos seus quadros, e não as que tratam um profissional como uma peça substituível, um commodity que se obtém facilmente, que acha que profissionais que são
entusiasmados com o seu trabalho vivem apenas pensando nos números do Hollerith.

Sites que servem como imensos classificados para anúncios de oportunidades existem, e não são poucos. E esses já se mostraram falhos, não funcionam bem. As empresas que mereceriam destaque por ter políticas e ações honestas vêem seus anúncios diluídos no meio de toneladas de outros anúncios de empresas que apenas indicam “Vaga para Programador. Obrigatório conhecimento em XYZ.”

Profissionais competentes e que possuem boa formação tampouco utilizam esses serviços: eles já arrumaram uma forma de estabelecer alguns contatos e acabam indo trabalhar em empresas onde tiveram alguma indicação. O networking é muito mais valioso do que uma série de certificações e cursos que sirvam para mostrar que o potencial candidato realmente tem conhecimento em XYZ.

A solução parece estar, então, em encontrar algum equilíbrio entre “permitir uma visibilidade a um público refinado” e “alavancar o poder do networking”. Como fazer isso? Oferecendo espaço gratuitamente para empresas que possuem reputação no mercado. Provendo um meio onde profissionais que estejam trabalhando em uma empresa possam mostrar as vantagens de se trabalhar com ele. Permitindo que as pessoas discutam entre si, com sua rede de contatos e com outros, quais oportunidades podem ser interessantes, quais mercados estão mais aquecidos, quais empresas fazem jus a sua reputação. Filtrando a informação para que ninguém se afogue num mar de ruído.

É sabido que um profissional de qualidade só fica desempregado quando quer, ou por um grave acidente de percurso da empresa em que ele trabalha, pegando-o de surpresa. Não seria bom ter um sistema onde as empresas pudessem dispor suas vagas gratuitamente, e que apenas profissionais que estão buscando acompanhar as tendências de mercado?

É sabido que um profissional de qualidade busca saber quais são os benefícios extras que a empresa têm a oferecer. Cursos de especialização, oportunidade no exterior, empresas em rápida ascenção e com possibilidade de crescimento em curto tempo… não seria bom ter um serviço onde fosse possível saber mais da empresa (contado por quem trabalha nela), além da vaga e de um email de contato?

É sabido que um profissional de qualidade é capaz de se adaptar às novas tecnologias e adotar novos processos rapidamente. Não seria bom ter um serviço onde o profissional possa ter uma idéia de qual é o tipo de atividade da empresa e qual é a base da tecnologia utilizada, mas sem se sentir preso a requisitos burros, como “5 anos de
experiência em .NET 3.0″, ou “conhecimento avançado de ferramentas para XML”?

É sabido que um profissional de TI conhece e usa tecnologias e ferramentas modernas para comunicação. Não seria bom ter um sistema tivesse um sistema de RSS razoavelmente inteligente? Isso é bom para pessoas que estão buscando emprego, pois serão sempre notificadas de novas vagas; é bom para as empresas, pois a informação pode ser difundida rapidamente para os profissionais; e é bom até para outros bloggers que queiram replicar essas informações em seu site. Por exemplo: se você é um webdesigner que possui um site, você poderia oferecer uma funcionalidade extra, ao listar
apenas vagas que contenham “web” como palavra-chave. Não seria um recurso útil para levar a informação de uma forma filtrada, aprimorando o foco?

É com esse espírito e com esse design que estamos colocando no ar Job4Dev. É esse tipo de sistema que estamos colocando no ar, e pretendemos prosseguir seu desenvolvimento, acrescentando funcionalidade e inteligência.

O sistema é simples:

- Qualquer empresa pode publicar um anúncio em nosso site, gratuitamente. Basta acessar a página de cadastro e colocar as informações que são importantes para que um profissional que queira se candidatar a vaga: nome da empresa, uma descrição das atividades da empresa, qual o trabalho a ser desempenhado na vaga em oferta, etc.

- O anúncio será listado e ficará no ar durante 30 dias.

- Não vamos trabalhar com empresas que não indiquem o nome. Com isso, queremos evitar anúncios de consultorias e
headhunters. Queremos justamente eliminar as barreiras, não oferecer ferramentas para pessoas que atuam como intermediários no processo.

Achamos que a qualidade de um projeto começa com a contratação de profissionais de qualidade, que tem que ser encarados como peças chave no processo de desenvolvimento e não como digitadores de luxo facilmente substituíveis. E isto começa por um bom sistema de seleção.

Não pense que estamos trabalhando nisso por mera filantropia, ou porque gostamos tanto de tecnologia que gastamos até nossos fins de semana desenvolvendo aplicações web. Estamos trabalhando nesse serviço para que possamos também colocar em prática alguns dos princípios que defendemos no blog: a importância do design; tratar um computeiro como
muito mais que um digitador de luxo; a agilidade no processo de desenvolvimento de sistemas web; os novos mecanismos de trabalho numa economia digital; e buscar atenção às novas tecnologias mas não se deixar escravizar por elas e muito mais.

Sem contar que o mercado têm suas surpresas, e nunca sabemos quando vamos precisar de um emprego, ou quando vamos precisar contratar alguém, não é mesmo?

Se uma empresa produz sistemas operacionais e deseja que a sua plataforma domine o mercado, ela tem duas opções:

1. Colocar o seu CEO num palco de uma conferência, e pedir que ele fique gritando “developers, developers, developers” até perder a voz.
2. Prover um ambiente de incentivo econômico para que desenvolvedores utilizem a sua plataforma, no lugar de outras alternativas.

Imagino que o pessoal da Google tenha respeito por suas cordas vocais, pois eles optaram pela segunda opção. Foi anunciado o Android Developer Challenge. A “competição” prevê prêmios para pessoas que desenvolvam novos aplicativos para a plataforma Android, totalizando até US$10 milhões.

Enquanto não há nenhum handset fabricado e pronto para o mercado, os prêmios serão pagos para as melhores propostas e idéias mais promissoras que possam fazer uso da tecnologia oferecida pelo Android. Até o começo de março de 2008, serão aceitas propostas de aplicativos. As 50 melhores propostas receberão um prêmio de US$ 25 mil. Depois disso, quando os celulares começarem a entrar no mercado e os aplicativos já puderem ser testados em campo, serão premiados os 20 melhores (entre os 50 qualificados), com prêmios de US$ 100 mil e US$ 275 mil.

A iniciativa é um reflexo dos tempos. Numa época em que aparelhos celulares são oferecidos de graça por operadoras de telefonia e que esses aparelhos são capazes de rodar sistemas operacionais livres, gratuitos e de qualidade, é difícil conseguir penetração em um mercado maduro. A alternativa, então, passa a ser fomentar desenvolvedores e criar um ecossistema de inovação na sua plataforma.

Alguém aí quer participar? Entre em contato.

Nóis é pobre, mais nóis é bom de pesquisa, mané!

Um relatório publicado pelo The Times Higher Education Supplement mostra o resultado de uma pesquisa feita entre os acadêmicos, empregadores e estudantes para avaliar a qualidade das universidades. Esse ano, percebe-se o notável crescimento das universidades da Inglaterra e uma agradável surpresa para os nativos da Banânia: a USP e a Unicamp aparecem listadas.

Reportagem sobre o assunto, e a lista de todas as 200 melhores universidades que eu puxei do site do THES.

Enquanto boa parte da molecada por aí que ainda não aprendeu a pensar por conta própria ficou triste com o anúncio da Google que encerrava as especulações sobre o gPhone, ficando sem imagens que pudessem copiar para os seus (spam-)blogs, e por tabela sem assunto para entupir os agregadores de conteúdo com notícias idênticas, o “velhaco” aqui parou para pensar no impacto e no potencial futuro da Open Handset Alliance. Eu vi, e gostei. Um plano como esse é uma lição clara de quem aprendeu com o Passado para pensar o Futuro.

Se você não entendeu o que estou falando, fique tranquilo. Vamos por partes.

Computação Pessoal

Computeiros, tautologicamente, têm suas vidas focadas no computador. Ficamos com o tocador de música ligado o dia inteiro, com nossas coleções imensas de canções nem sempre obtidas legalmente. Resgatamos contato com nosso amigo que se mudou para o Curdistão para popularizar o futebol de botão. Mantemos nossas memórias, vídeos, fotos, cartinhas de amor que queríamos enviar para a nossa musa mas ficamos com vergonha de mandar, já que você, no fundo, no fundo, sabia que não era muito romântico declarar algo como “você é tão bela quanto a Lara Croft no Tomb Raider 2″. O computador é o meio, começo e o fim de boa parte de nosso cotidiano.

Para nós e para os profissionais que já estão fazendo parte diretamente ou indiretamente da Economia Digital, a linha que separa o computador-pessoal do computador-ferramenta-de-trabalho é tênue, cada vez mais imperceptível. Entretanto, há muitos outros que olham o computador como uma besta indomável, complexa, para não dizer supérflua.

Isso não quer dizer, entretanto, que eles estão livres da evolução tecnológica. Mesmo aqueles que se recusam a sentar na frente de um monitor estão fazendo parte da revolução que começou nos anos 80, da Computação Pessoal.

Vou tentar simplificar: Computação Pessoal é tudo que envolve o uso de um computador, cuja finalidade principal não é o trabalho. Aquela viagem chata que você levava o Game Boy? Computação Pessoal. O seu primeiro Discman? Computação Pessoal. O seu decoder de tv a cabo? Câmera Digital de 32 Gigapixels? Tudo é Computação Pessoal.

O ponto mais interessante. Mesmo os tecnófobos, estes que não sabem nem mexer em um mouse, provavelmente têm o seu “Computador Pessoal”. À diferença de nós, estes fazem uso da tecnologia através de outro dispositivo. Para eles, o PC é outro e cabe no bolso: é o telefone celular.

Acho que o que eu escrevi acima não é nenhuma novidade. A velocidade do ciclo de desenvolvimento dos aparelhos celulares, as toneladas de funcionalidade presentes nos aparelhos mais básicos, as inúmeras apresentações de executivos falando sobre a questão da convergência digital, etc, etc. Você não precisa de mais um blogger chato querendo dizer “Eureka! Celulares vão se tornar tão poderosos quanto computadores”, não é mesmo?

Padronização do Desktop: um pouco de História.

Computadores, hoje, são quase oni-presentes e aparentemente são bastante diferentes. Mas, por baixo de marca, gabinete, ou até mesmo sistema operacional, todos acabam sendo muito parecidos. Todo mundo (e por todo mundo, entenda “mais de 99,99% dos consumidores normais”) tem um computador que usa um chip com arquitetura x86 (ou alguma extensão dela, como a x86-64). Placas auxiliares são instaladas em slots padronizados (AGP, PCI ou PCI-x). Periféricos se comunicam através de USB. Comunicação sem fio é predominantemente feita por Wi-Fi (802.11*).

Tudo isso não acontece por acaso. São padrões determinados pela indústria, com o propósito primário de facilitar o desenvolvimento e a fabricação de componentes para um sistema complexo. Assim, subsistemas desse sistema complexo podem ser trocados com razoavel segurança. Assim como eu sei que eu posso colocar qualquer motor elétrico de 110V na tomada aqui de casa, eu sei que eu posso comprar qualquer Pen Drive USB para o meu computador, e sei que vai funcionar.

É claro que essa padronização não surgiu de uma hora para outra. Os primeiros mini-computadores e computadores que pretendiam ser de uso doméstico tinham arquiteturas completamente diferentes entre si. Um computador como o Altair rodava apenas programas feitos para ele, e era arquiteturalmente diferente de um TRS-80. Um usuário entusiasta de um computador aprendia a programar para uma máquina e assim ficava, pois não havia necessidade de portar seu aplicativo para outra arquitetura.

Isso é muito comum, se analisarmos o progresso e a evolução de inventos humanos. Traçando um paralelo com a teoria de evolução de Darwin, uma nova tecnologia pressiona o surgimento de novos produtos (assim como uma mudança no ambiente causa um aumento no número de mutações genéticas em espécies já existentes), e desses novos produtos sobrevivem os que se mostram mais aptos ao ambiente (o produto que satisfaz melhor o público é o que acaba sendo mais copiado e prospera), determinando qual será a tendência de design de produtos. Veja como os aparelhos de TV e os primeiros aviões eram diferentes entre si, e vejam o quanto eles são similares hoje em dia. Dá pra sacar que, até com memes, existe o que é chamado de “survival of the fittest”?

No fim de 1970, as apostas de todos provavelmente seriam na Apple, com o Apple I e com o Apple II. Seus computadores poderosos e fáceis de usar começaram a ganhar momento. Empresas passaram a desenvolver aplicativos para ele. O sucesso do Visicalc serviu como um efeito bola de neve. Mais pessoas queriam o Apple por conta do Visicalc, que aumentava o interesse dos desenvolvedores pela plataforma Apple, que fazia da Apple a arquitetura com uma coleção de software mais interessante. Darwin trabalhava, enquanto a concorrência padecia. Por mais simples que fossem as arquiteturas da época, era trabalhoso portar software. Muitos programas ainda eram desenvolvidos em linguagem de máquina. Compiladores BASIC eram caros e para profissionais. A Apple parecia a grande vitoriosa.

Parecia. A Apple passou a ter concorrência da IBM e do padrão PC. Aproveitando a explosão do mercado de computadores para uso doméstico, a IBM deu a sua tacada: um padrão livre, que pudesse ser seguido por qualquer que quisesse montar um computador compatível. Dessa forma, uma empresa que quisesse entrar no mercado de desktops poderia fornecer apenas um componente do produto, ao invés de ter que desenvolver todo um computador (e ainda ter que tentar competir com a Apple). Isso também serviu para incentivar a concorrência, o que levou a uma redução acelerada dos custos.

Vá lá: tudo que a IBM acertou com o padrão-PC, ela errou ao ter dado uma licença de fornecimento exclusiva do Sistema Operacional para uma empresa pequena, chamada Micro-soft-com-hífen. Mas a estratégia do padrão aberto funcionou. A Apple, que manteve-se verticalizada (oferecendo hardware e software) acabou perdendo terreno para os milhares de concorrentes horizontais que trabalhavam no padrão IBM-PC.

Fale com o Miguel, se quiser mais detalhes da história da Apple. Mas vou resumir: eles teimaram um bom tempo em manter-se verticais, e só recentemente abriram mão disso, e foram obrigados a admitir que a estratégia vertical não deu certo. O hardware de um Macintosh é, hoje, virtualmente idêntico ao de um computador da HP ou da Dell. Para desgosto de muitos fanáticos, hoje é um Intel que roda em Macs. Até mesmo software para o mercado de DTP tem menos features em suas versões para Mac OS, comparada com a versão para Windows. Muito do charme some quando se tira o teclado com backlight.

Pois bem. Não é de hoje que o mercado de desktop é chato, sem grandes surpresas. Como eu já disse antes, POSIX já ganhou, e boa parte do pacote de soluções que gerou bilhões para a Microsoft-sem-o-hífen já é “good enough” há uns bons 6 anos.
Se é que existe alguma coisa que ainda é sexy para desenvolvedores, isso está em aplicativos que fazem uso da Internet e dos avanços de telecomunicações.

O Mercado de Mobile

Entra o mercado de mobile. Acho que foi em 1999 que meu pai chegou em casa com um StarTac, da Motorola. O que tinha de especial? Pouca coisa, além de um desenho moderno e o fato de ser um dos primeiros modelos no Brasil que foram trazidos para as linhas digitais. De qualquer forma, podemos ver o quanto mudou em apenas 8 anos. Celulares hoje em dia mandam mensagens de texto, mensagens multímidia, possuem câmera integrada, mp3, possuem jogos, conectam à internet, fazem cafezinho e até pagam suas contas - inclusive aquela conta absurdamente cara da sua última fatura de celular.

Tudo muito legal, tudo muito divertido. Mas ainda falta alguma coisa. Por exemplo: e se eu quiser trocar a minha câmera digital? Ou como faço para adicionar um HD ao meu smartphone? E se eu quiser usar outra bateria, ou adicionar uma placa que me permita usar dois chips GSM no mesmo aparelho?

Mudanças em hardware, nem pensar. Software deveria ser um pouco mais flexível, mas ainda está longe do satisfatório. Diferentes sistemas operacionais, diferentes versões, diversos padrões de rede (GSM, CDMA, iDen, entre outros) e - mais importante - diferentes plataformas de desenvolvimento de software fazem com que planejar um produto para o mercado mobile seja tão fácil quanto atirar em um grilo usando uma escopeta numa sala pequena, depois de tomar meia garrafa de tequila. Chamar de “mercado dinâmico” é um eufemismo. É um mercado caótico.
Quer adicionar uma outra variável na brincadeira? A penetração de aparelhos celulares é muito maior que a de computadores domésticos. No Brasil, já passamos há tempo a marca de 60 milhões de aparelhos ativos. Isso passa (em muito) o número de computadores. Na Itália, mais de 90% da população possui telefone celular. Os números de usuários de Internet não chegam à metade. O celular é, sem dúvida, o Verdadeiro Computador Pessoal.

E aí apareceu a oportunidade de ouro para a Apple e o iPhone. Do mesmo jeito que fizeram com o Apple I e com o Apple II, a estratégia para o iPhone é reduzir o número de subsistemas (poucos aplicativos de terceiros, sistema operacional próprio, software próprio) e lutar para manter controle sobre cada uma das partes. Quem melhor que Steve Jobs, com seu senso de design, para delimitar o melhor ponto para atender todos os requisitos conflitantes que existe num mercado caótico como o mobile?

Enquanto todos batem cabeça e não se entendem, a Apple usa a sua vantagem como fabricante de hardware e espera neutralizar as operadoras de telefonia futuramente, apostando no crescimento do Wi-Fi e pensando que o seu iPhone poderá ser um telefone (VoIP) e, principalmente, como um dispositivo para a distribuição de conteúdo digital. Só depois, e quando for do seu interesse, ela precisaria abrir o iPhone para terceiros. Ela nem mesmo precisaria ter um “Visicalc”, pois ela já se encarregou de fazer isso antes: chama-se iTunes Music Store.

Do jeito que se vê hoje, a Apple tem tudo em mãos para se tornar a força dominante do mercado de mobile computing. A vingança de Steve Jobs, tardia, seria em sua dominação do Verdadeiro Computador Pessoal.

Android: estamos de novo em 1981

Not so fast, Steve. Você acreditou mesmo que todo mundo ia ficar assistindo você ficar com todo o bolo? As operadoras de telefonia ainda querem briga. E aqueles que desenvolvem software também precisam ter um ambiente onde eles sabem que seu sistema rode sem que eles tenham que pedir permissão para ninguém.

Qual a melhor maneira de garantir isso? Ora, lançando um padrão de referência para quem quiser desenvolver dispositivos móveis! Foi exatamente isso que a Google fez essa semana. Ao invés de lançar um aparelho de celular, foi anunciado o Android. O Android é uma plataforma aberta de desenvolvimento, com especificação de sistema operacional, middleware e aplicativos finais. Quem quiser desenvolver um aplicativo para um celular que seja Android, basta trabalhar de acordo com a spec.

Os fanáticos por Java vão apontar para o JavaME, como forma de ter uma plataforma de desenvolvimento livre e definida. Eu vou dizer “Nice try, but no.” Do mesmo jeito que acontece no desktop, aplicativos JavaME acabam limitados pela qualidade da implementação das bibliotecas que funcionam “embaixo”. Por exemplo: assim como um toolkit como o SWT tem que ser um mínimo denominador comum entre os ambientes gráficos subjacentes (GTK, MFC, Cocoa), uma implementação de JavaME é, no máximo, tão poderosa quanto o pior sistema usado atualmente nos aparelhos celulares. O padrão do Android é a partir do zero, não fica obrigado então a fazer nenhum tipo de compromisso por conta de limitação tecnológica.

Em suma: Android é a versão mobile do padrão IBM-PC. Não importa se você for um desenvolvedor de aplicativo ou de componentes para celular, você poderá ter um pouco mais de segurança na hora de começar o seu investimento. Isso levará a muita inovação no mercado, pois teremos mais empresas tentando arriscar algo novo, sem medo de ver seu investimento sendo jogado fora por alguma reorientação tecnológica. Isso levará a redução ainda maior de custos. De comoditização total de hardware. Até mesmo podemos pensar em maior integração entre serviços que hoje só são pensados para web. Um celular Android poderá, efetivamente, tornar-se o PC 2.0.

Apple vs o resto. Dessa vez, até pode ser diferente.

Cabe a Apple decidir se vai querer que o iPhone se torne um sucesso como o Mac ou como o iPod. Usuários (e lucros) ela terá em qualquer hipótese. Entretanto, a insistência da Apple em manter todo o controle da arquitetura se mostrou falha na guerra dos desktops. Até hoje, com geeks tietando a Apple da mesma forma que adolescentes tietavam Britney Spears, o mercado da Apple não passa de magros 3%. Será que ela vai se posicionar, de novo, para manter apenas um nicho ou pretende ir para as cabeças?

Dois fatores pesam a favor, dessa vez. O primeiro: é muito difícil que o Google faça por alguma empresa o que a IBM fez pela Microsoft, o que levaria a uma grande procura por celulares com o padrão Android e a um possível monopólio de algum serviço dentro dele. O outro: o mercado de mobile business está bem mais maduro, hoje, do que o mercado de computadores era em 1981. Quase metade dos habitantes do planeta usa um celular, e a imensa maioria já está acostumada a mudar de aparelho a cada 18 meses. Não há nada que impeça que eles resolvam fazer a mudança.

De um jeito ou de outro, é uma época bem interessante para trabalhar com o desenvolvimento de aplicações para o Verdadeiro Computador Pessoal.