O primeiro foi preparar e apresentar uma palestra-relâmpago sobre o cruzalinhas (slides aqui, vídeo em breve). Resolvi fazer isso na última hora, e me surpreendi com o interesse de pessoas de outras cidades (Manaus, Campinas, Florianópolis e da própria Porto Alegre) em fazer a mesma coisa, já que, segundo esse pessoal, a dificuldade em obter informações sobre o transporte público é a mesma.

O outro foi participar do Code Golf do iG, uma proposta inusitada, na qual são apresentados cinco problemas de programação. Eles são relativamente simples – o desafio é escrever o menor código-fonte que resolva cada um.

Claro que um código Python é bem menor que o seu equivalente Java, e por isso haviam categorias isoladas para cada linguagem suportada (Perl, Python, PHP, Java e Ruby). Fui o vencedor da categoria Java, com os códigos que estão no final do post.

Um aviso: NUNCA escreva código assim, a não ser que esteja participando de um Code Golf. O objetivo era sempre reduzir o tamanho e compensar a proibição de imports explícitos. Isso tem um custo: a performance quase sempre é horrível, a legibilidade é zero, é quase impossível modificar. Senti esse último lance na prática: tive que fazer uma gambiarra na questão 4 (o formato da entrada mudou, e o fix apropriado implicaria em reescrever tudo) – o tamanho dobrou e fui penalizado por isso.

Minhas soluções para o Code Golf (enunciados aqui)

1. public class c{public static void main(String x[])throws Exception{int a=0,b=1,c
   ,i;for(i=Integer.parseInt(x[0]);i>0;i--){System.out.print(b+(i==1?"":", "));b=b+
   a;a=b-a;}}}

2. public class c{public static void main(String x[]) throws Exception{char m,s[]=x
   [0].replace(" ","").toLowerCase().toCharArray(),i=0;int f[]=new int[255],c,l=s.l
   ength;boolean p=true;for(;i<l;i++){p=p&&s[i]==s[l-i-1];f[s[i]]++;}System.out.pri
   ntln((p?"":"Não é ")+"Palíndrome");while(true){m=0;for(i=0;i<255;i++){m=f[m]>f[i
   ]?m:i;}if(f[m]==0)return;System.out.println(f[m]+" "+m);f[m]=0;}}}

3. public class c{public static void main(String x[]) throws Exception{long a=0,m=0
   ,b,c,F=0xFFFFFFFF;int i,j=0;for(;j<2;j++){c=0;for(i=0;i<4;i++)c=c*256+Integer.pa
   rseInt(x[j].split("\\.")[i]);a=m;m=c;}a=a|(F-m);b=32;for(c=0xFF000000l;c>0;c/=25
   6){System.out.print(((a&c)>>(b-=8))+(b==0?" /":"."));}for(b=32;(m&1)==0;m/=2)b--
   ;System.out.print(b);}}

4. public class c{static int h=-1;static void w(int i){if(h!=i)System.out.print(i+"
    ");h=i;}public static void main(String y[])throws Exception{String[]x=(y[0]+",-
   ,"+y[1]).split(",");int m,l=x.length,n[]=new int[l],p=0,i=0,a=0;for(;i<l;i++)if(
   x[i].equals("-")){a=i;p=i+1;}else n[i]=Integer.parseInt(x[i]);for(i=0;(i<a&&p<l)
   ;){if(n[i]<n[p]){m=n[i];i++;}else{m=n[p];p++;}w(m);}for(;i<a;i++)w(n[i]);for(;p<
   l;p++)w(n[p]);}}

5. public class c{public static void main(String x[])throws Exception{int c,p,t=0,v
   []={1,3,3,5,10,50};while((c=System.in.read())>-1){p=("pcbtar".indexOf(c));t+=p>-
   1?v[p]:0;}System.out.print(t);}}

O livro foca no dia-a-dia dessas pessoas, em particular no momento em que estão criando código. Isso até é interessante: saber se um ninja desses depura código com um debugger ou com printf, quanto ele pensa antes de sair codando, se ele implementa código de forma top-down ou bottom-up e a visão deles de como o desenvolvimento de software evoluiu (ou não) nos dias de hoje sem dúvida dá uma nova perspectiva para o meu cotidiano.

Infelizmente, isso não impede que os capítulos se tornem repetitivos e maçantes ao longo do tempo – ao contrário do Founders, no qual cada entrevistado leva a reportagem para um lado diferente (e sempre interessante). Não sei se o quanto isso influenciou, mas o entrevistador, embora autor de um livro popular sobre Common Lisp e um dos primeiros funcionários da WebLogic, não é personagem de destaque no meio. Em contrapartida, a cicerone do Founders é co-fundadora do Y Combinator – uma credencial e tanto para quem quer falar de startups.

O Julio Daio Borges afirma em um review bacana do livro que “…a maioria dos programadores no livro são, basicamente, executores. Visionários são os empreendedores.” Não concordo plenamente com a afirmação – poucos ali são empresários, mas cada um deles empreendeu e inovou no seu campo – mas ela evidencia o fato: o livro anterior foca nesse lado empreendedor, este no lado pragmático/coder. Eu curto as duas coisas, mas em projetos editoriais desse porte, a primeira vai mais longe.

Esse tipo de humor auto-depreciativo mostra o diferencial do Munchkin: ao invés de vender a ilusão de que uma mecânica complexa demonstra algum tipo de superioridade intelectual dos participantes (como fazem tantos RPGs e jogos de carta/tabuleiro por aí), ele se baseia em um conjunto simples de regras. Os detalhes mais cabeludos ficam por conta de cada carta, facilitando muito o aprendizado e tornando-o divertido de imediato.

O jogo original deu origem a variantes temáticas – a que eu tenho, claro, é o Super Munchkin, na qual jogadores e monstros são, respectivamente, super-heróis e vilões. Assim como o original satiriza o gênero RPG medieval, esse não poupa os comics da ironia: a carta “erro de continuidade” anula tudo o que foi feito numa batalha (causando grande confusão), o nível do jogador sobe com cartas do tipo ”cueca pra fora da roupa”, e por aí vai.

Um pré-requisito é entender inglês – não apenas para interpretar as cartas, mas para apreciar o humor nerd em cada uma delas. A Devir lançou uma versão nacional do original, mas parece que esgotou e não se encontra mais em lugar nenhum. O melhor é importar (ou procurar um pouco por aqui) e encarar o idioma.

¹ Quem leu o livro-reportagem The Hacker Crackdown deve lembrar que o serviço secreto americano investigou de forma truculenta a empresa quando soube que um dos seus colaboradores (responsável pelo GURPS Cyberpunk) circulava no submundo hacker – pesquisa de campo é isso aí, o resto é resto.

Mas a proposta é outra: Malcolm Gladwell desconstrói alguns mitos sobre o que faz alguém se destacar nos negócios, esportes, artes ou qualquer outro campo. Ele ataca em particular aquela idéia comum de que o sucesso depende largamente do talento, em menor grau da dedicação e bem pouquinho da sorte.

Sem negar a influência desses fatores, o livro demonstra que o que entendemos por sorte tem muito a ver com as oportunidades e com estar no lugar e na hora certa. Também desfaz a lenda do “expert instantâneo”, chegando a postular que existe uma quantidade de tempo mínima que qualquer pessoa de destaque (dos Beatles a Bill Joy) dedica ao assunto de interesse antes ser considerada um expert: 10.000 horas.

São propostas ousadas – colocadas dessa forma, devem gerar muitas expressões de “ah, duvido”. E é isso que torna o livro interessante: após a sua leitura, todas elas se tornam no mínimo bastante plausíveis. Não sei se a tradução é boa, mas no original valeu muito a pena.

¹ Em Estatística, outlier é o nome que se dá àqueles dados completamente diferentes dos demais, os “fora da curva”.

O chato é que não apenas sou um zero à esquerda em GIMP/PhotoShop, mas também queria algo que pesasse menos no carregamento. Solução: programar.

O canvas do HTML5 viria a calhar, mas o suporte dos browsers ainda está longe do ideal. Resolvi, então, criar uma biblioteca minimalista para fazer desenhos nesse estilo usando elementos de HTML. E ficou minimalista mesmo: basta incluir ela e o JQuery no <head> da página, i.e.:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js" type="text/javascript"></script>
<script src="http://chester.blog.br/tilewriter/tilewriter-0.2-min.js" type="text/javascript"></script>

Coloca-se na página um <div> (ou outro container HTML) no qual o "desenho" será montado, e aí é só brincar de JavaScript:

tilewriter.drawRow("#div_teste", "      X");
tilewriter.drawRow("#div_teste", " XX    ");
tilewriter.drawRow("#div_teste", "X  X  X");
tilewriter.drawRow("#div_teste", "X  X  X");
tilewriter.drawRow("#div_teste", " XX   X");

Isso produz o mosaico abaixo (que pode não aparecer num leitor RSS - o que é esperado, é só decoração - nesse caso, abra o post original):

Também é possível configurar a palheta de cores utilizada, o tamanho de cada "azulejo" e o espaçamento entre eles, o que permite várias possibilidades interessantes. Por exemplo, esse encanador familiar:

é produzido pelo script:

tilewriter.reset();
tilewriter.spacing = 0;
tilewriter.size = 8;
tilewriter.colors = ["", "#EA590C", "#AC7C00", "#FFA440"];
tilewriter.drawRow("#div_mario", "   111111    ");
tilewriter.drawRow("#div_mario", "  1111111111 ");
tilewriter.drawRow("#div_mario", "  22233233   ");
tilewriter.drawRow("#div_mario", " 23233323333 ");
tilewriter.drawRow("#div_mario", " 232233323333");
tilewriter.drawRow("#div_mario", " 22333322222 ");
tilewriter.drawRow("#div_mario", "   33333333  ");
tilewriter.drawRow("#div_mario", "  2232222    ");
tilewriter.drawRow("#div_mario", " 22212212222 ");
tilewriter.drawRow("#div_mario", "2222111122222");
tilewriter.drawRow("#div_mario", "3321311312333");
tilewriter.drawRow("#div_mario", "3331111113333");
tilewriter.drawRow("#div_mario", "3311111111333");
tilewriter.drawRow("#div_mario", "  1111 1111  ");
tilewriter.drawRow("#div_mario", " 2222   2222 ");
tilewriter.drawRow("#div_mario", "22222   22222");

Para usar mais do que 10 cores, basta passar a palheta como um objeto do tipo {"caractere" : "cor"}, usando qualquer cor CSS válida. Espaços e caracteres não-mapeados ficam sem cor, i.e., com a cor do fundo.

Isso bastava para o que eu queria, mas me empolguei: já que a idéia é logotipos e afins, por que não automatizar a escrita de textos? Para isso bastava ter uma fonte bitmap que fosse compacta e legível - tal qual tínhamos nos micros de 8 bits - e aí veio o estalo: ao invés de criar uma fonte, era mais fácil pegar uma direto da ROM de um deles!

A escolhida foi a fonte do TK90x (ZX Spectrum), que não apenas está prontinha na ROM, mas tabmém é fácil de encontrar salva na web. Ela é 8x8, o que significa que se eu guardar como texto hexadecimal, cada "imagem" de caractere ocupa 16 bytes (mais o payload do JavaScript), e fica bem fácil de converter para binário.

O resultado é que pra escrever o "oi", agora basta programar:

tilewriter.drawText("#div_teste_2","oi");

e temos:

Como de costume, dá pra melhorar bastante, e o código-fonte é livre para quem quiser brincar. O chato é que eu queimei o tempo que ia usar no update do layout com esse brinquedo, mas valeu a pena - a lib ficou com menos de 4K minificada (incluindo a fonte). Olha como dá pra se empolgar na nostalgia:

tilewriter.spacing = 0;
tilewriter.size = 1;
tilewriter.drawText("#div_tk90x_cima", "TK90X - Color Computer");
tilewriter.spacing = 0;
tilewriter.size = 8;
tilewriter.colors = ["white", "yellow", "cyan", "green", "magenta", "red", "blue", "black"];
tilewriter.drawRow("#div_tk90x_baixo", "000111222333444555666777");

O esforço foi patrocinado e liderado por gente do Google, Yahoo!, Microsoft, NASA e do Banco Mundial, e eu não só tive a oportunidade de participar da primeira edição de São Paulo, que aconteceu aqui na Fundação Getúlio Vargas (FGV), mas também tive a alegria de ter o projeto do meu grupo, o Urban Fact, premiado com o segundo lugar.

O evento abriu com apresentações de especialistas nos setores de engenharia, arquitetura e urbanismo – pessoas que lidam com esses problemas no dia-a-dia, e em seguida os programadores foram liberados para formar grupos e propor/desenvolver idéias. No final os projetos foram avaliados por um júri, havendo premiações para o primeiro e segundo lugar – embora o importante mesmo (em particular, o que me levou a pular o descanso e a Parada do Orgulho LGBT no fim-de-semana) fosse fomentar essas idéias, divulgar a iniciativa e ajudar a colocar em contato pessoas que têm sintonia com a idéia de usar o software e a Internet como ferramentas de apoio ao exercício da cidadania.

O merecidíssimo vencedor foi o Shelter Me – um software que permite o cadastro voluntário de abrigos (shelters) disponíveis em situações de emergência – desde um abrigo da prefeitura até um canto que você possa oferecer na sua casa durante uma crise. O diferencial é que o sistema permite que uma pessoa envie um SMS e receba, como resposta, o endereço do abrigo mais próximo.

Tradicionalmente, um sistema desses exigiria o apoio da operadora de telefonia no rastreamento da posição do aparelho e um servidor dedicado, mas a criatividade do pessoal superou isso: o protótipo apresentado solicita o CEP do local para fazer a busca, e foi implementado diretamente num celular Android (que já faz o rastreio no servidor e envia a resposta). Genial.

O segundo lugar ficou com o projeto apresentado pelo meu grupo (eu, o Marcos Diez, o Daniel Cukier e a Bani – esta última foi quem me apresentou ao evento): o Urban Fact (ou Fato Urbano, já que ele é bilíngue, detectando o idioma do navegador). A inspiração surgiu quando uma das palestrantes salientou a influência das atitudes individuais na solução (ou criação) dos problemas – os assuntos ali eram enchentes e ocupações irregulares, mas o conceito é geral.

Pensando no efeito educativo que o auê online causa em casos como quando o cachorro de uma moça fez cocô no metrô sul-coreano, imaginei que se tivesse uma maneira fácil de mostrar as coisas erradas que acontecem (por exemplo: quando as pessoas jogam lixo na rua, fomentando problemas como algamentos, ou quando danificam patrimônio público), esse tipo de atitude poderia ser coibida.

O grupo evoluiu o conceito: boas atitudes também poderiam ser colocadas em evidência, já que o reforço positivo opera milagres. O importante é dar ao cidadão que testemunha o fato a possibilidade de capturar e compartilhar o mesmo de forma simples. Entra em cena o Twitter: o sistema monitora os tweets com as tags #urbanfact e #fatourbano que tenham links para fotos. Esses tweets podem ser vistos na forma de lista ou mapa, e cada um deles pode ganhar nota, receber comentários e ter isso tudo redistribuído em outras redes sociais.

Fugimos um pouco do foco em desastres naturais, mas ainda ficamos dentro do conceito de cidadania e de captura e divulgação da informação sobre problemas urbanos em tempo real. A principal limitação é que ainda são poucas as pessoas que usam o Twitter no celular – situação que deve mudar em breve.

Além disso, essa versão ainda precisa ser bastante melhorada antes de ser considerada “produção” (é um hack desenvolvido do zero em menos de 16h). Mas demonstra bem o espírito do evento: viabilizar, de forma rápida e focada, idéias e soluções melhoráveis e reutilizáveis (o código é 100% aberto).

Os outros projetos (de São Paulo e das outras cidades onde o evento ocorreu) podem ser conferidos no wiki. A organização mandou muito bem em termos de infra-estrutura e alimentação. Não houve a “virada” do sábado para o domingo, comum em eventos desse tipo – mas a natureza local das edições pressupõe participantes na mesma cidade, então o pessoal voltou no dia seguinte e tudo correu bem.

Nesse sentido, talvez edições futuras possam privilegiar outras cidades – muitas vezes mais próximas de alguns dos problemas que os fundadores se propõem a resolver – mas se voltar a acontecer em São Paulo não vou reclamar!

Este último resolve bem a minha vida, mas às vezes tudo o que eu quero é saber quais ônibus passam por um determinado local. Ou ainda: quais, dentre eles, passam por um segundo local, e quais passam entre este e um terceiro, i.e., quais minhas opções para ir do ponto A ao ponto B, e dele ao ponto C, e por aí em diante.

Misturando essa demanda com um desejo de colocar as informações de itinerário do transporte público de São Paulo nas mãos da população, desenvolvi o cruzalinhas. A aplicação ainda precisa de muitas melhorias (eu diria que é “beta”, mas o que não é?) mas já permite responder às perguntas acima.

Como de costume, o código-fonte é livre (licença MIT), e esse post vai falar um pouco sobre o funcionamento do mesmo.

O back-end da aplicação é escrito em Python e hospedado no Google App Engine. Ele disponibiliza um par de chamadas AJAX/JSON para o front-end: uma página HTML que usa o JQuery para acessar tanto esse back-end quanto a API do Google Maps (usada para desenhar os mapas/trajetos e buscar endereços).

Obter os dados de itinerário não foi trivial, mas o principal desafio mesmo era fazer buscas geográficas. Explico: eu tenho, para cada linha, os pontos (latitude e longitude) que compõem a sequência de segmentos de reta que, conectados, representam seu trajeto. Uma busca consiste em descobrir quais dessas figuras cortam um determinado ponto (idealmente com alguma tolerância).

Calcular a distância entre o ponto e cada um dos segmentos de reta já estaria fora de questão se estivessemos falando de geometria euclidiana simples (e não estamos). Já que a idéia era ter alguma tolerância mesmo, eu poderia verificar se o ponto está na caixa que contém o segmento de reta (reduzindo a questão a uma quadra de comparações de desigualdade). Infelizmente, 4 comparações x cerca de 620 mil pontos ainda é muita coisa.

A salvação da lavoura foi o geohash – essencialmente uma representação de uma área geográfica com precisão mais-ou-menos arbitrária (consulte o link para detahes, é um conceito genial). A biblioteca de geohash que eu usei permite “somar” dois geohashes e retornar o geohash da menor caixa que contém os dois pontos originais.

Limitando essa caixa em 6 caracteres, ficamos com um erro menor que 1 Km – e esse erro é exatamente a margem de manobra que eu precisava. Observe que muitos dos segmentos caem na mesma caixa, logo, uma linha típica (que era composta de várias centenas de pontos/segmentos) acaba “participando” apenas de umas poucas dezenas de geohashes de caixa desse tipo.

Quando o sistema precisa procurar quais linhas passam perto de um ponto geográfico, ele calcula o geohash desse ponto, corta nos 6 caracteres e simplesmente busca as linhas que possuem segmentos cuja string de geohash bata com esse valor calculado. Trocamos aquelas 4 x 620 mil comparações de desigualdade (que o App Engine não iria conseguir combinar mesmo, por estarem em dois campos diferentes – latitude e longitude) por uma única comparação de igualdade (ok, numa string, mas bem curtinha) feita sobre universo de pouco menos de de 2000 hashes distintos – uma bela otimização.

Esse tipo de busca é muito rápida em um banco de dados relacional corretamente modelado e indexado – e me surpreendi quando a performance inicial foi tão ruim que as buscas geralmente davam timeout! O fato é que a maneira com que o App Engine expõe o BigTable para aplicações Python/Java pode levar o desenvolvedor a tratá-lo como um banco de dados relacional, e foi o que eu fiz: tinha uma entidade Linha, uma entidade Ponto, e em cada ponto eu tinha o geohash do segmento que ele formava com o anterior.

Para a coisa dar certo, foi preciso desnormalizar um pouco: fiz a entidade Hash armazenar, para cada geohash de 6 caracteres (que tenha surgido em algum segmento) as chaves primárias de todas as linhas que passam por ele. Com isso, a busca ficou suficientemente rápida.

Uma segunda desnormalização foi armazenar em cada entidade Linha todos os hashes pelos quais ela passa, e retornar essa informação junto com o nome/URL da linha. Isso permite que o próprio JavaScript determine as linhas que ligam dois pontos: ele já tem a lista das linhas que passam em cada um deles, basta ver quais delas têm pelo menos um geohash em comum.

O uso do memcache melhora ainda mais a performance dessas chamadas. A cada busca, guarda-se em cache a lista de linhas para um geohash (beneficiando outros pontos que estejam na mesma “caixa”, cujo resultado é o mesmo) e os meta-dados de cada linha (em separado da lista, já que outros pontos podem retornar a mesma linha e aproveitar esse outro cache).

A outra chamada que o cliente tem que fazer é a lista de pontos da linha em si, para desenhar o trajeto. Ao invés de retornar isso na lista de linhas, achei melhor deixar que ele faça uma nova chamada para cada linha, quando e se precisar dela. Nnovamente o memcache tem a mesma granularidade, fazendo com que o desenho de uma linha seja cacheado independente do ponto utilizado na busca.

Com isso tudo arrumado, a aplicação ganhou corpo suficiente para ir para o ar, e a repercussão me fez ver que não era só eu que sentia falta dessa funcionalidade. Ainda falta uma boa versão mobile, e outros sites bacanas poderiam ser feitos com esses dados. Será que se eu disponibilizar uma API (via YQL, por exemplo) alguém se habilita?

Foi-se o tempo em que a interface de uma aplicação web se resumia a um punhado de páginas web. Em muitos contextos, você vai lançar mão de diversas bibliotecas e plugins, bem como escrever seus próprios módulos de código JavaScript.

O problema que isso acarreta é que as chamadas necessárias para carregar isso tudo aumentam o tempo geral de carga da sua página. Pior ainda: uma dessas chamadas pode segurar o carregamento do restante da página, atrasando todo o processo. Era o que rolava no meu último projeto, e o ricbit me chamou a atenção para o fato.

Uma solução geral que minimiza esse problema é colocar os scripts indispensáveis para a exibição inicial da página (e apenas eles) dentro do seu próprio servidor, minificá-los (i.e., reduzir o tamanho sem alterar a funcionalidade) e juntá-los num arquivo só – que o seu servidor, bem configurado, deve servir comprimido.

Só que fazer isso “na mão” toda hora é muito chato. É possível ter uma página dinâmica que executa essa tarefa, e outra idéia é inserir o procedimento no processo de build (se houver um). Ambas funcionam, mas a primeira gera uma preocupação adicional com cache (num conteúdo que até então era estático), e a segunda tira o dinamismo de salvar e testar imediatamente.

Eu precisava de um caminho intermediário, para o qual não escaparia de criar um script que automatiza o trabalho. Como já estava com a “mão suja de graxa Python”, eu chamei esse port do JsMin num script bem simples, e troquei no HTML vários scripts externos por um só, que carrega em paralelo com outros elementos da página, reduzindo bastante o tempo de carga inicial.

(Isso não é regra. Nunca assuma, sempre meça. Existem ótimas ferramentas para fazer isso, sendo as minhas prediletas a aba net do Firebug e sua equivalente embutida no menu “Developer” do Chrome.)

A questão é: quando chamar esse script? Idealmente, eu queria que ele rodasse quando eu salvasse um dos scripts envolvidos (e só quando eu fizesse isso). Felizmente o Eclipse/Aptana possibilita isso, e é fácil:

1. Certifique-se de que o seu script funciona na linha de comando;
2. Com o botão direito na pasta do projeto, escolha Properties;
3. Selecione Builders no menu da esquerda;
4. Clique em New, selecione o tipo Program e dê Ok;
5. Na aba Main, especifique o script no campo Location e o diretório onde ele vai rodar (Working Directory);
6. Em Build Options, deixei as opções conforme o screenshot abaixo (clique para ampliar):

O pulo-do-gato (alguém ainda fala isso?) é acionar o Specify working set of relevant resources, e, usando o botão ao lado, marcar apenas os scripts que serão colados/minificados – caso contrário ele vai ficar rodando o script o tempo todo.

Se você fizer direitinho, sempre que salvar um script ou der um clean, build, etc., o minificador vai rodar em background, e você vai poder testar no browser imediatamente, como fazia antes dessa brincadeira toda. Pra mim foi uma mão na roda, e espero que para você também seja!

Produzido por uma editora do Kuwait, o gibi é co-escrito pelo seu idealizador, o médico humanista Dr. Naif A. Al-Mutawa e pelo americano Stuart Moore. Esta combinação (aliada ao trabalho visual de vários artistas populares dos comics Marvel/DC) dá ao quadrinho o tom multi-cultural que o diferencia.

A história não é radicalmente original: uma tentativa de evitar a destruição de uma biblioteca em Bagdá (nos moldes da Biblioteca de Alexandria, só que na Idade Média) por um ataque bárbaro transforma o conhecimento ali contido em 99 artefatos místicos, que se perdem durante a guerra. Na nossa época, o Dr. Ramzi dirige uma operação humanitária da UNESCO em zonas de guerra, enquanto busca estas relíquias, na esperança de que o conhecimento ali contido possa trazer a paz ao mundo atual.

Os artefatos começam a ser localizados por pessoas comuns, que descobrem que o conhecimento contido neles transformou-se em fonte de poderes especiais, levando o Dr. Ramzi a ajudá-los a controlar este poder e ajudá-lo em sua missão pacifista. Claro, ele não é o único com uma agenda, e a partir disso a história se desenrola.

Pode parecer, à primeira vista, uma versão islâmica dos X-Men. Mas o blend (ao menos nas três edições que li) é mais interessante que isso: mesmo sem o (justificado) rancor contra a autoridade islâmica de um Persépolis, ele tem em comum com a autobiografia de Satrapi a apresentação de valores humanistas e pacifistas nos quais uma parcela significativa do mundo árabe/islâmico acredita, mas que são mascarados por regimes retrógrados e violadores dos direitos humanos fundamentais.

Tudo isso vem embalado num quadrinho divertido que, nos moldes de suas contrapartes ocidentais, vai virar desenho animado em breve. Ele também já conta com um parque temático, e não vou me espantar se virar filme, na esteira dos blockbusters da Marvel dos últimos anos. A história tem todos os ingredientes necessários, só é preciso encontrar uma produtora com os culhões que faltaram ao Comedy Central – que, à revelia dos autores, censurou episódios de South Park por conta de referências a Maomé.

Mas a inovação não pára por aí: como a edição em papel tem alcance limitado, o mesmo site que disponibiliza a edição “Origins” gratuitamente para download, permite comprar qualquer uma das edições pela bagatela de US$ 1.99. Isso mesmo: por míseros R$ 3,55 você pode ler uma edição completa no seu computador, sem sair de casa. O pagamento é via PayPal, ou seja, 100% seguro – se você já tem PayPal, é clicar, autenticar, comprar e baixar. E o melhor de tudo: é um arquivo .PDF sem qualquer tipo de DRM. O gibi é seu, exatamente como os de papel.

Já comprei os dois primeiros e pretendo continuar lendo (cadê o genérico do iPad, hein?) – e acho que nesse aspecto da venda online as editoras americanas é que deviam se inspirar nos caras…

Primeira temporada:
Assim.. um aviao caiu numa ilha…. e uh… essa ilha tem umas pessoas… e uh…. essas pessoas vao tentar atacar os caras do aviao.
nota da producao: JURAMOS q as pessoas nao estao mortas, vcs vao adorar essa serie!

Segunda temporada:
Uh… as pessoas da ilha sao malvadas e andam descalco.. eles tem um lider q nunca aparece
nota da producao: a trama esta apenas comecando, teremos 15 temporadas, action figures e canecas de cafe

Terceira temporada:
Uh…. agora as pessoas da ilha nao tem computador, internet e satelite….. e o lider na verdade nem existe.. eh tudo invencao..
Mataram o Santoro com apenas 2 falas em 3 temporadas…
nota da producao: eles nao estao mortos…tudo sera explicado, no seu tempo.

Quarta temporada:
Tem um cara q consegue sair e voltar da ilha… acho q precisamos trazer aquele lider de volta hein?
nota da producao: precisamos comecar matar os personagens caros ( tipo o Michael ), CGI esta mais barato q filmar em Ibiza

Quinta temporada:
Vamo leva todo mundo pra fora da ilha, dar um final feliz, e rezar pra NBC cancelar a gente pra nao precisarmos explicar a farofa q fizemos nas temporadas anteriores
nota da producao: precisamos dar um tempo…. ( entre quinta e sexta, teve quase 1 ano de espera )

Sexta temporada:
Fodeu galere… vamos ter q explicar tudo!
O lider existe, vamo mata ele, colocar um outro malvadao na historia.
E agora a grande sacada do show……. eles estao mortos.
nota da producao: se o final nao colar, a gente ainda consegue fazer um dvd com uns extras e tal….. AH, e ainda temos algumas daquelas canecas pra vender!