A W3C Brasil irá oferecer um curso de HTML 5 em São Paulo, entre os dias 21 e 23 de setembro.

Segundo um email que eu recebi ontem,

O programa do curso abrange as principais novidades da versão 5 da linguagem HTML até o momento e priorizará a apresentação dos novos elementos com o debate em classe da nova semântica. Alguns exercícios serão aplicados com o intuito de demonstrar as novas implementações. Nossa estrutura infelizmente não comporta a formação de diversas turmas do curso de HTML5 que nos permita atender o grande número de solicitações de interessados, inclusive para outras cidades. Por isso faremos uma seleção dos participantes segundo os critérios de compromissos:

• com a replicação do conteúdo do curso;
• com a publicação livre das aplicações geradas;
• com um projeto real de uso do HTML5;
• e com a participação efetiva em uma comunidade dedicada à melhoria da linguagem.

O propósito do W3C Brasil, mais do que treinar no uso da nova versão, é o de organizar uma rede de interlocutores, formadores e multiplicadores preparados para os debates em torno dos padrões web, gerando massa crítica na formulação das novas recomendações.

Para saber mais sobre o curso, acesse http://www.w3c.br/cursos/html5/

A 22a Olimpíada Internacional de Informática (IOI) ocorreu semana passada aqui em Waterloo, Canadá. É uma competição de programação para alunos de (no máximo) colegial. A olimpíada acontece anualmente e nessa edição contou com equipes de 83 países, incluindo o Brasil. Apesar de cada país poder enviar uma equipe de até 4 competidores, a competição é individual. Portanto, é bem diferente da competição da ACM ICPC, para equipes de universitários.

Eu tive o prazer de servir de guia para a delegação brasileira, novamente liderada pelo Prof. Anido da UNICAMP. Como o Canadá é um país de imigrantes, a organização tentou encontrar guias que falassem fluentemente a língua de cada país. Eles dizem que conseguiram, mas eu vi alguns guias que tiveram que se virar em inglês mesmo. Mas a idéia de ter um guia que conhece ambos os países é a de dar uma perspectiva mais compatível com os alunos sobre Waterloo e principalmente sobre o Canadá. Eu espero ter conseguido mostrar os lados positivos e negativos daqui, além de levá-los às compras, é claro. Ah, e o lado divertido da semana (pros guias pelo menos) foi “ter” que ir junto ao Canada’s Wonderland e ao  Maid of the Mist em Niagara Falls.

Mas voltando à competição, que imagino ser a parte divertida pros alunos, a primeira coisa que tive que aprender foi como funciona a premiação. Existem medalhas de ouro, prata e bronze, sendo que metade dos +/- 300 competidores recebem alguma medalha (1/12 ouro, 1/6 prata e 1/4 bronze). A equipe brasileira recebeu 1 prata e 2 bronzes, o que é bastante bom dado o nível elevado da competição.

E esse é o ponto principal desse post. Eu fiquei impressionado com o nível de conhecimento de algoritmos dos competidores. A equipe brasileira é jovem e 3 dos 4 competidores ainda tem idade pra voltar algumas vezes pro IOI. Esses meninos de 15, 16 anos manjam algoritmos e estruturas de dados que eu só fui aprender no 2o. ano de faculdade. E eles dominam o assunto! O campeão desse ano foi um bielorusso de 15 anos. Ele compete desde os 11 e já ganhou 1 prata e 4 ouros, sendo 2 vezes como campeão. Os dois pais do garoto são programadores, obviamente.

Se você duvida da complexidade das tarefas, tente resolver você mesmo, já que elas estão online. Cada dia de competição era uma prova com 4 tarefas pra serem resolvidas em 5 horas. Normalmente uma tarefa era bem fácil, só pra não desmotivar competidores menos treinados (tente fazer o Memory ou o Cluedo primeiro). Mas pra se ter uma idéia, a primeira submissão correta do Cluedo foi em menos de 3 minutos (eu nem consigo ler o enunciado nesse tempo!). Nesse ano algumas tarefas envolviam heurísticas (como Language) e algumas que pareciam triviais eram bem complicadinhas de resolver com pontos máximos (veja hotter/colder).

Parabéns ao time brasileiro e à Fundação Carlos Chagas que patrocina as seletivas, treinamentos e viagens! E toca preparar pra Tailândia ano que vem!

O Admin automático do Django é uma mão na roda. Já disse isso. Mas nada é perfeito!

Algo que me incomodava bastante era o fato da barra de filtros que aparece do lado direito da tela de listagem ser uma lista de links. Funciona muito bem quando a lista é pequena (10, no máximo 20 elementos). Mas quando a lista é muito grande, ou então pode ter tamanho variável, a coisa fica fora de controle. Meu sonho era poder colocar uma caixa de seleção.

Esta semana, resolvi fuçar um pouco e entender como funciona. E não é que é fácil?

Resumindo: o responsável por renderizar o filtro é um arquivo chamado filter.html, que fica na pasta de templates do admin (django/contrib/admin/templates/admin). O jeito então é substituir o arquivo, e o jeito elegante de fazer esta substituição é criar uma pasta admin dentro da pasta de templates do seu projeto e criar o arquivo filter.html lá.

Para aqueles que tem preguiça de pesquisar como colocar uma caixa de seleção, eis o código que eu usei:

{% load i18n %}
<h3>{% blocktrans with title as filtertitle %} By {{ filtertitle }} {% endblocktrans %}</h3>
<ul>
<select onchange='window.location=this.value;'>
{% for choice in choices %}
<option value="{{ choice.query_string|iriencode }}" 
{% if choice.selected %}selected{% endif %}>{{ choice.display }}
</option>
{% endfor %}
</select>
</ul>

O resultado final é esse:

Pra quem quiser aprender um pouco mais sobre customizações do admin do django, a fonte boa é esta: http://docs.djangoproject.com/en/1.2/obsolete/admin-css/

O comentário geral em relação ao meu post sobre OAuth foi: “Legal, mas FALTAM EXEMPLOS!”

Oks, oks, oks, ei-lo. Vou usar como caso de uso o envio de um status novo para o twitter (tweets para os íntimos) em Python. Para isso, vou usar a lib oauth2, disponível para download no GitHub em http://github.com/simplegeo/python-oauth2. Segundo o wiki do OAuth:

“OAuth 2.0 is the next evolution of the OAuth protocol which was originally created in late 2006. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.”

Para começar, criamos uma instância de token e consumer, usados para autenticar as requisições. Neste exemplo, eu uso o algoritmo SHA1 para gerar a assinatura da requisição:

import oauth2 as oauth token = oauth2.Token(token, tokensecret) consumer = oauth2.Consumer(consumerkey, consumersecret) signmethod = oauth2.SignatureMethodHMACSHA1()

Feito isso, temos que criar a url de requisição. No caso de envio de um tweet,  a url é http://api.twitter.com/1/statuses/update.json, o método de envio é POST, com apenas um parâmetro, status, contendo o conteúdo da mensagem. O protocolo oauth requer alguns parâmetros extras, como mostrado abaixo:

url = "http://api.twitter.com/1/statuses/update.json" params = { 'oauthversion': "1.0", 'oauthnonce': oauth2.generatenonce(), 'oauthtimestamp': int(time.time()), 'status': 'Enviando uma mensagem para o Tweeter' } request = oauth2.Request(method="POST", url=url, parameters=params) request.signrequest(self.signaturemethod, self.Consumer, token)

Com um objeto do tipo Request na mão, só me resta executar a requisição HTTP propriamente dita, usando a lib urllib2, nativa do Python:

import urllib2 opener =  urllib2.buildopener() encodedpostdata = request.topostdata() response = opener.open(url, encodedpostdata) opener.close()

No dia 31 de Maio do ano do Senhor de 2010, por volta das 15h, o meu caro amigo Lullis me mandou uma singela mensagem no GTalk dizendo algo como “Você viu que o sistema de Basic Auth do Twitter para de funcionar hoje né? E que daqui pra frente só com OAuth né?”. A frase, descontextualizada, pode parecer apenas mais uma curiosidade geek. O Twitter já vinha anunciando esta migração de modelo de autenticação há um certo tempo.

Mas no mundo de Miguel, isso caiu como uma bomba atômica.

Resumindo: o mecanismo de autenticação usado pelo Job4Dev e pelo SigaSeuTime simplesmente deixaria de funcionar em algumas horas. No caso do SigaSeuTime, isto era uma catástrofe de proporções enormes, já que boa parte do nosso público vem do Twtter. Uma longa noite me aguardava…até que percebemos que Lullis havia falado besteira, e que na verdade o prazo máximo era 31 de junho. Ufa.

Tive então tempo de estudar um pouco o protocolo, e fazer uma implementação usando algumas libs. Por sorte a documentação do próprio Wiki do Twitter é bem interessante. Gostaria de compartilhar alguns pontos aqui.

Basic Auth

É o maior lixo já inventado para autenticação. Basicamente, você adiciona no header da sua requisição um campo cujo valor é o seu username e a sua senha simplesmente codificados em Base 64. Resumindo, senha em claro. Mais básico e inseguro que isso, impossível.

OAuth – Idéia básica

A idéia do OAuth é permitir que o provedor de um serviço permita o acesso a certos recursos a usuários sem precisar dar a senha principal. No caso do Twitter, isto é bem útil, já que a grande maioria dos usuários interagem com o sistema usando aplicativos externos.

Com este protocolo, seria possível permitir que por exemplo o Job4Dev atualizasse a sua timeline, de forma segura e autenticada, sem que eu precisasse guardar a sua senha na minha base de dados. Conveniente!

OAuth – O protocolo

Vou tentar tornar esta descrição a mais simples possível.

OAuth usa um mecanismo de pares de chaves públicas e privadas para gerar assinaturas, permitindo uma identificação inequivoca da origem de cada requisição. Simples demais?

Ok

Vamos supor que o usuário @mgalves queria que o Job4Dev publique vagas na sua timeline, usando um app que algum dia será criado. Este app possui duas chaves, geradas pelo @job4dev: um consumer key e um consumer secret (que como seu nome diz, deve ser guardada de forma secreta). O passo a passo seria mais ou menos o seguinte:

• O app gera uma requisição especial HTTP, usando as duas chaves citadas acima, para obter um token de request temporário.
• Com este token em mãos, o app gera uma requisição HTTP de autorização de acesso para o Twitter. Esta requisição passa como parâmetros o token, o consumer key e uma assinatura gerada a partir de um hash (SHA) de uma string composta pelo token, pelo consumer key e pelo consumer secret key. Portanto, é única, e apenas o app do Job4Dev é capaz de gerar (comprovando assim a procedência da chamada).
• O Twitter já sabe, a partir da assinatura, que quem está pedindo permissão de acesso é o Job4Dev. Falta saber qual usuário irá autorizar o acesso: para isso o site pede que eu, @mgalves, efetue o login e explicitamente autorize o acesso.
• Autorizado o acesso, o Twitter envia para o app um novo par de chaves que serão utilizados para assinar as demais requisições, e que mapeiam de forma única a permissão de acesso do app job4dev aos recursos da conta de @mgalves. Caso eu resolva REVOGAR o acesso, basta invalidar estas novas chaves.

Melhorou? Espero que sim.

Um ponto importante deve ser ressaltado quanto ao último passo. O retorno do novo par de chaves pode ser feito de duas formas: callback e PIN code. Callback é a forma padrão descrita no protocolo do OAuth, e simplemente consiste em definir um callback HTTP no app que está pedindo acesso, que será chamado pelo provedor (no caso o Twitter) ao final do processo passando as chaves por parâmero POST.

Mas isso apenas funciona se o app em questão for web, e puder responder a uma requisição HTTP. Caso isto não aconteça (como no Tweetdeck por exemplo), o Twitter exibe na tela um código numérico único chamado PIN CODE: o app deve receber este PIN code (copy & paste) e gerar uma nova requisição passando o token, o pin code e a assinatura, cujo retorno é o par de chaves.

E o TweetDeck?

Depois de ter lido e entendido o tema, a seguinte dúvida me veio a cabeça: e o TweetDeck, como faz? E nenhum momento eu autorizei o acesso aos meus recursos, e ainda assim, as coisas funcionam. Será que no final de junho ele para de funcionar?

Fucei a documentação do Twitter e achei uma extensão ao protocolo chamada de XAuth, uma pequena variação que permite que as chaves de acesso sejam obtidas através de uma requisição especial contendo username e senha do usuário. Isso evita a necessidade do protocolo definido acima, e funciona bem em casos onde quem vai acessar os recursos é o dono da conta.

Mas segundo o Twitter, para que um app que queira usar este protocolo deve entrar em contato diretamente com eles, explicando a real necessidade.

Ontem aconteceu o primeiro StartupMeetup em São Paulo, no Bar Wallstreet. O evento, organizado pelo pessoal do ReadWriteWeb Brasil, pela Sambatech e pela Aceleradora, tinha como objetivo promover o encontro de empreendedores e investidores.

Fui representando o Job4Dev e o SigaSeuTime (que aliás prestigiou o evento com todos os seus sócios presentes), com o intuito de conhecer gente, projetos e possíveis oportunidades.

Bati bons papos com o Diego Gomes e o Edmar do RWW-BR, o Yuri Gitahi da Aceleradora, com o pessoal da Confrapar, com os sócios da Indike, do Canal do Crédito e outros.

Saí de la com algumas idéias novas.

E bastante animado com este cenário razoavelmente novo e bem ativo, de gente jovem querendo construir coisas novas.

Estou testando o sistema de criacão de widgets html com informacão sobre empresas cadastradas no banco de dados do job4dev.

Provavelmente, não vai funcionar em leitores de RSS como o Google Reader, já que é necessário o uso de Javascript. Mas quem estiver acessando o site diretamente vai poder ver um resumo com informacões sobre o job4dev, logo abaixo.

Basta adicionar o código:

<div class="j4d_widget"> <script src="http://job4dev.com/company/scripts/job4dev/widget" type="text/javascript"></script> </div>

Para termos:

Eu já twittei sobre isso, e já salvei no del.icio.us do Log4Dev. Mas dada a qualidade do material, acho que vale a pena comentar rapidamente aqui. O Joel Spolsky escreveu um excelente artigo/tutorial sobre o Mercurial, sistema de controle de versão distribuído (DCVS para os íntimos) que anda na moda ultimamente.

O endereço é http://hginit.com. O conteúdo serve tanto para aqueles que já se convenceram da utilidade e precisam entender o modus operandi (que foi o meu caso), como para os céticos que não deram muita bola e precisam ser convencidos.

E acreditem: o texto convenceu até The One Who Can’t Be Named.

Não é pouca porcaria não….

Faço minhas as palavras de Lullis: ando calado porque ando ultra atolado de coisas, e sem tempo para o ócio criativo. Muitas coisas estão acontecendo tanto no SigaSeuTime e no Job4Dev, e a boa notícia é esses acontecimentos estão sendo acompanhados pelo reconhecimento.

Hoje, o SigaSeuTime foi tema de uma matéria no site de Economia & Negócios do Estadão, intitulada “Redes sociais dão oportunidade de negócio ao pequeno empreendedor”. A matéria usa o projeto como case de como redes sociais como o Twitter servem de motor para novos empreendimentos e idéias.

Acho que posso dizer sem medo de errar que na lista de dores de cabeças que meus projetos pessoais e startups me trouxeram, a questão da codificação de strings está tranquilamente entre os TOP 3. E quando eu achei que tudo nesta área estava resolvido, eis que me apareceu um novo bug do nada que me fez perder algumas horas de mal humor. Porque coisas que funcionam por meses e de repente param de funcionar sem motivo aparente em geral me tiram do sério.

O SigaSeuTime (cujo novo site acaba de estrear, se me permitem o autojabá) possui dois bots IM, GTalk e MSN, que fazem parte do conjunto de plataformas para distribuição de contéudo. Ambos os bots são escritos em Java, e a plataforma é escrita em Python. Para fazer a comunicação entre os subsistemas eu uso ou REST ou comunicação via UDP. No caso das notícias em tempo real, acabei optando por UDP para evitar pooling desnecessário. E isso funcionou perfeitamente nos últimos 6 meses: um agente se encarrega de puxar as notícias, processar, filtrar e gravar na base de dados. Outro agente lê as notícias novas e manda pros bots via UDP, para envio aos usuários online. .

Até que de repente, as mensagens começaram a aparecer tanto no MSN quanto no GTalk  com a acentuação totalmente errada. Típico resultado de strings codificadas de um jeito e interpretadas de outro (tinha que existir um jeito fácil e direto de se descobrir a codificação de uma string sem a necessidade de metadados)! Olhando para o histórico do meu SVN vi que as últimas modificações em códigos relativos aos componentes envolvidos neste processo datavam de no mínimo 3 meses.

Ou seja, só podia ser culpa do meu servidor, ou do alinhamento planetário, ou então do Bush! Não não…a culpa, obviamente era minha. Sempre é, por mais que a gente lute contra isso.

A causa do problema estava em um script SHELL que eu criei recentemente cujo objetivo é de reiniciar os bots em caso de falha de comunicação com os servidores. Até então, o processo de reboot era manual, feito por mim mesmo via shell SSH, e a função deste script é de automatizar o processo, matando e executando novamente o bot.

Inofensivo certo? Nem tanto. O script é executado periódicamente pelo crontab do sistema operacional, e foi aí que o problema nasceu: as variáveis de ambiente do cronjob são diferentes das variáveis de ambiente do SHELL SSH, e em particular o segundo possui a variável LANG=en_us.UTF-8, que é justamente a codificação usada internamente pelo sistema. Vivendo e aprendendo: isto influi diretamente na JRE, e a falta da variável fez com que o sistema assumisse outra codificação (provavelmente ISO Latin 1). A solução foi exportar a variável no meu script.