You’ve been asking for it, we’ve even joked about it – now it’s here (for real): for the one year anniversary of Bitbucket joining Atlassian, we are happy to announce Git support.

All your source, all in one-place

Whether you are using Hg or Git, you can now keep all of your code in one place with your preferred DVCS format. If you have existing code you would like to migrate, you can easily import your Git, Mercurial or Subversion source code. We have added a new importer for GitHub to our existing site importers which include SourceForge, Google Code and Codeplex.

Mas daí você me pergunta: “Porque usar o Bitbucket para armazenar meus repositórios Git em vez de usar o tradicional GitHub?”

Bom, se você está desenvolvendo projetos Open Source, provavelmente o GitHub seja uma opção mais apropriada, já que ele se tornou referência. Muitas empresas pedem que candidatos adicionem o seu endereço GitHub nos currículos. Já BitBucket eu nunca vi.

Em compensação, se você está desenvolvendo projetos fechados, aí o Bitbucket é vantajoso. Em todos os planos, o número de repositórios privados é ilimitados. Na conta gratuíta, a limitação fica por conta do número de usuários: 5 no máximo, o que é mais do que suficiente para 99% das startups (o SIGA é uma delas). Já para empresas maiores, por 80 dólares por mês você tem direito ao plano UNLIMITED: repositórios ilimitados e usuários ilimitados! No GitHub o maior plano custa 200 dólares mensais, e dá direito a no máximo 125 repositórios privados.

Não funciona!

Fazendo uma rápida pesquisa na internet, descobrimos que o Twitter implementou um Javascript que impede a página de login de ser exibida caso esteja dentro de um iFrame (pode tentar, o resultado final será uma página em branco). O motivo: questões de segurança.

Portanto, ou exiba a página na janela principal do seu navegador, ou use um popup.

E tenho dito.

Dos vários aspectos que me impressionaram e agradaram na minha curta passagem pelo Apontador, um que me agradou muito foi a concentração de pessoas boas que tinham projetos pessoais interessantes e funcionando, com pinta de sistema profissional. Corroborou mais uma das minhas teorias sobre empresas PONTOCOM: atraem pessoas diferentes, que gostam de criar e resolver problemas.

Eu gostaria de citar dois destes projetos, que eu usei e que realmente me ajudaram.

O primeiro é o Cruzalinhas, desenvolvido pelo Chester. Parafraseando o site, o Cruzalinhas permite que uma pessoa “saiba quais linhas de ônibus, trem ou metrô passam perto de um lugar em São Paulo”. A interface não poderia ser mais intuitiva: clique em um ponto do mapa da cidade, e veja todas as linhas de ônibus e metrô que passam por perto. Clique em um segundo ponto, e veja todas as linhas que podem potencialmente levá-lo de um lugar para o outro.

O segundo é o Encontre Seu Pacote, criado pelo Thiago Ganzarolli, colega de UNICAMP. O sistema permite rastrear os pacotes enviados por SEDEX em um mapa, por RSS ou via Direct Message do Twitter. O screencast deles, plagiado abaixo, explica melhor o funcionamento.

Problema a ser resolvido: gerar uma sequência aleatória de digitos e caracteres ASCII para criação de senhas automáticas.

Solução:

''.join(random.choice(string.asciiuppercase + string.digits + string.asciilowercase) for x in range(8))

Programação orientada a linguagens é um termo pra descrever a idéia de usar várias linguagens específicas de domínio (domain specific languages, DSLs) para desenvolver software. DSLs são linguagens criadas com um escopo limitado, o “domínio”. A vantagem de uma DSL é que ela contém abstrações bem próximas ao domínio, então em teoria usuários conseguem se expressar mais facilmente do que em uma linguagem de propósito geral (general purpose language, GPL). Por exemplo, lex e yacc são DSLs para descrever lexers e parsers, respectivamente. Você não vai escrever o compilador inteiro com elas, mas são ótimas, concisas, pra descrever aquele domínio específico. Se você fez um curso de compiladores sabe muito bem o trabalho que daria pra escrever o lexer e o parser “na mão”.

Um problema de se usar várias DSLs pra desenvolver um sistema é que nem sempre os domínios de cada DSL são tão bem separados como no caso de lexers, parsers e o backend do compilador. Muitas vezes as linguagens precisam interagir mais. Por exemplo, imagine que você tem um programa em Java e em alguma parte precisa definir uma máquina de estado. Um jeito é implementar a máquina de estado direto em Java. Outro jeito é criar uma DSL pra máquinas de estado, vamos chamar de SML (state machine language), que você pode reusar em vários projetos e que esconde detalhes da implementação Java. Mas então o código fonte teria que conter código Java e código escrito em SML. O problema é que as duas linguagens interagem, e escrever um compilador que entenda Java e SML é complicado.

É aí que entram projectional language workbenches. A idéia principal, a meu ver, é que o sistema é apresentado e desenvolvido por intermédio de projeções. DSLs são utilizadas pra descrever projeções do sistema e elas são compostas como meta-modelos. Por exemplo, você pode ver e manipular a sua máquina de estado usando uma projeção em Java ou uma projeção em SML. A sintaxe concreta usada pra cada projeção é definida por editores e você pode ter diversos editores pra uma linguagem. Por exemplo, SML pode ter uma sintaxe textual pra máquinas de estado, ou pode ter uma linguagem visual que mostre os estados e as transições como nós e setas. O que importa é que quando se manipula os conceitos no editor, se está manipulando o sistema através dessa projeção.

E qual é a vantagem? A principal, eu acho, é que se elimina o frontend do compilador e com isso vários dos problemas de se combinar linguagens. Ou seja, não existem mais lexers ou parsers, tudo o que existe é a abstract syntax tree (AST). O editor de Java não é um editor de texto, é um editor estruturado que permite manipular a AST diretamente. Dessa maneira, editores de diferentes linguagens podem ser compostos. Por exemplo, no seu editor de Java você pode visualizar a máquina de estados com o editor de SML.

E as desvantagens? Bom, eu acho que ainda existem muitos problemas. Não está claro ainda se desenvolvedores vão ser produtivos em editores estruturados. O fonte do sistema fica dependente de uma certa ferramenta (não se tem mais texto que pode ser compilado por diferentes ferramentas, se tem a descrição do sistema usando o meta-modelo específico daquela ferramenta). Além disso, ainda não está claro que tipo de problemas vão ocorrer agora que estamos compondo linguagens em um nível mais alto de abstração.

E onde pode-se ver esses conceitos em ação? Eu aconselho dar uma brincada com MPS. MPS é uma implementação bastante sólida de projectional language workbenches sendo desenvolvida pela Jetbrains (que faz o IntelliJ IDEA). Em MPS você pode criar DSLs e combinar com Java e outras DSLs. O Markus Voelter criou também uma implementacão em C pra desenvolver sistemas embarcados, num projeto chamado mbeddr.

Será que projectional language workbenches vai ser o jeito de se programar no futuro? Não sei (provavelmente não), mas vale a pena observar o que está sendo experimentado, pois com certeza é um paradigma interessante e que pode trazer bons insights. E se tudo o que eu escrevi aqui parece abstrato demais, dê uma lida nos textos do Martin Fowler pois ele entra em detalhes. E também não hesite em fazer perguntas (eu tenho um pouco de experiência com MPS e posso tentar ajudar).

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.

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>

Filtro de listagem com Caixa de Seleção

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/

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

OAuth – Idéia básica

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.

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?

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.

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.