Na primeira palestra da qual participei (e a primeira que dei num evento público), falei, junto com o grande Fabio Kung, sobre Seaside, um arcabouço para desenvolvimento de aplicações para a Web escrito em Smalltalk. O Kung, é claro, falou de Rails.

O objetivo da palestra era mostrar que Seaside é muito melhor que Rails, mas o Kung não deixou (brincadeira!). Na verdade, o objetivo da palestra era mostrar coisas que são legais em ambos os arcabouços, e que um poderia aprender com o outro. É claro que nem tudo poderia ser copiado, já que as raizes dos dois tem algumas fortes divergências, como a aceitação do protocolo imposto pela Web (stateless) versus a subversão total dessa ideia (stateful, implementada pelo Seaside). Existem motivações para ambos: stateless, para respeitar a Web e ser mais escalável; stateful, para ser mais fácil de desenvolver e mais reutilizável.

Mostramos muito pouco de cada um dos arcabouços. A ideia era mostrar tópicos bem mais avançados. No fim, quase que não deu tempo de mostrar como criar um componente do Seaside.

Fiquei devendo uma resposta no meio da palestra. Quando falei que Seaside era baseado em componentes, inspirado no desenvolvimento para desktop, o Diego Plentz me provocou falando que era que nem VB; aliás, que VB era melhor porque, pelo menos, tinha uma interface gráfica para desenvolver componentes. Eu, com toda minha sagacidade, não consegui responder na hora :P. Mas a resposta é: VB não é linguagem o Seaside é baseado em componentes porque é fácil programar a interface pensando assim (senão o VB não era a linguagem inicial de tantos programadores por aí) e o Seaside melhora isso usando uma linguagem muito legal no lugar de VB.

As críticas que ficam a cada um dos arcabouços:

• Rails: tem muita complicação no sistema de arquivos; para quê tantos arquivos e diretórios? Para que tantos arquivos de configuração? Por que a dependência do banco de dados, por padrão? Tudo bem, o escopo de Rails é bem pequeno, mas talvez as convenções estejam um pouco complicadas demais.
• Seaside: faltam pacotes para acrescentar algumas tarefas comuns ao Seaside. Faltam, também, arcabouços de teste mais atualizados e com melhor documentação (não há um “Cucumber” e a documentação do SSpec). Por fim, o Smalltalk praticamente impõe uma IDE para você e impede o uso dos recursos utilizados em outras linguagens (SVN, pastebin, etc.)

Bom, é isso. Eu espero que as pessoas que compareceram a palestra tenham gostado e que eu tenha a oportunidade de dar novamente uma palestra no FISL. Foi uma experiência muito legal.

Posts Relacionados:

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.

Recentemente escrevi um post sobre como migrar seu repositório svn para o git. Em um dos passos falo pra você criar uma lista de mapeamento dos seus usuários do svn para os do git. O único problema disso é descobrir quem são eles. Aqui vai um one-liner de bash que resolve isso :)

svn log | grep "^r[0-9]" | \\
sed -E "s/^.*\|(.*)\|.*\|.*$/\1/" | \\
sort | uniq > seu_arquivo_com_os_usuarios

Explicação da bizarrice acima:

1. svn log: Exibe todo o log de commits feitos naquele repositório.
2. grep “^r[0-9]“: Pega todas as linhas iniciadas com r seguido por um número (header de cada commit do svn)
3. sed -E “s/^.*\|(.*)\|.*\|.*$/\1/”: Roda o monstro chamado sed em modo estendido e captura o nome dos usuários (conte o número de pipes)
4. sort: Ordena a lista com os usuários que comitaram.
5. uniq: elimina todas as duplicatas deixando apenas uma cópia de cada usuário (só funciona em listas ordenadas. Por isso o sort anterior).

Tentei fazer usando o comando cut no lugar do sed, mas o cut desistia no meio do caminho por causa de caracteres estranhos.

Posts Relacionados:

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.

Sei que tem um monte de tutoriais por aí de como migrar de svn para git, mas não achei nenhum com tudo que eu precisasse e em português. Então aqui vai o meu :)

WARNING!!!! Se você tem um repositório svn público e vai migrar para o github, use o script de migração que ele te oferece quando você cria um repositório lá.

1. Primeiro você deve instalar o git-svn. Não sei como instalar via apt, mas com o macports é um simples sudo port install git-core +svn (talvez você precise desinstalar o git-core antes de conseguir instalar. Se for o caso, sudo port uninstall git-core)

2. Crie um arquivo mapeando os usuários do svn para os do git. Algo como:

   jonas = Jonas Abreu <jonas@vidagek.net>
   usuario_svn = Nome Usuario <email@usuario.net>
   

   Dê o nome que quiser para o arquivo.

3. Faça checkout com o git svn

   mkdir repo_temp
   cd repo_temp
   git svn init URL_DO_SEU_REPOSITORIO_SVN --no-metadata
   git config svn.authorsfile ARQUIVO_DE_MAPEAMENTO
   git svn fetch
   

   É bem importante não esquecer do –no-metadata. Isso vai evitar que ele traga um monte de lixo (.svn, se não me engano) para sua máquina.

4. Limpe a sujeira que o git svn colocou no seu repositório git local clonando ele.

   cd ..
   git clone repo_temp repo_final
   

5. Altere a url da origem do seu repositório local:

   cd repo_final
    .git/config
   

   Troque a url:

   [remote "origin"]
         url = repo_temp
   

   pela url do seu repositório git:

   [remote "origin"]
          url = URL_DO_SEU_REPOSITORIO
   

6. Envie os dados para o seu servidor remoto:

   git push origin master
   

Pronto. Seu repositório acabou de ser migrado de svn para git. Simples, fácil e rápido (a não ser que você tenha uns 10k commits. Aí vai demorar bastante. No meu caso demorou cerca de 4 horas o processo completo.)

Posts Relacionados:

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.

Em mais uma post da série que tem feito programadores Java perderem o sono, Java’s Signal of Failure (JSF).

Hoje o problema é bem leve, mas envolve um mal que persegue muitos programadores. Documentação.

A classe de hoje é java.awt.Container. Logo no início dela, existe a declaração de um atributo do tipo int. Aqui está o trecho de código:

/**
 * The number of components in this container.
 * This value can be null.
 * @see #getComponent
 * @see #getComponents
 * @see #getComponentCount
 */
int ncomponents;

Normal, não fosse um pequeno detalhe. “This value can be null”. Como assim? É um int. Obviamente não pode ser null. Tipos primitivos não aceitam null. O que deve ter acontecido é que ncomponents (nome bonito para uma variável, não?) deveria ser um java.lang.Integer, mas trocaram para int posteriormente. Pena que não viram o comentário perdido por ali.

Mais uma razão para valorizar a expressividade ao invéz dos comentários.

Posts Relacionados:

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.