Completamos recentemente, aqui na Caelum, a migração de todos os nosso projetos para git, o sistema de controle de versões distribuído criado inicialmente por Linus Torvalds para o desenvolvimento do kernel Linux. Esta migração, realizada pelo Cauê Guerra e pelo Jonas Abreu, foi motivada por algumas características do git que se mostraram úteis em alguns projetos internos e pessoais; em especial, a possibilidade de fazer commits locais (muito útil quando não há acesso à internet) e os branches locais baratos.

Em vez de mantermos nós mesmos nossos repositórios, optamos por hospedá-los no GitHub. Esse serviço oferece uma interface web bastante prática e nos permite, convenientemente, centralizar nossos projetos públicos e privados em um único serviço. Contudo, entre tantas facilidades, sentimos falta de uma forma de observar a atividade recente em todos os nossos repositórios de forma centralizada e de ter alguma medida da atividade de cada desenvolvedor em cada projeto - e vice-versa. E para atender a essa necessidade, eu e o Cauê Guerra escrevemos o Caelum git-reports, um pequeno projeto em Ruby.

O software gera, a partir de um conjunto de repositórios git, uma medida do impacto de cada desenvolvedor (discriminado por projeto), do impacto em cada repositório (discriminado por desenvolvedor) e um resumo de todos os commits recentes, apresentando o resultado em HTML. Adotamos a mesma definição de impacto usada pelo GitHub: a soma das linhas acrescentadas e removidas. De fato, uma medida bastante grosseira, mas que tem suas utilidades. O projeto é muito novo, e podemos facilmente adicionar novas funcionalidades, como critérios para verificação de atividade nos repositórios, além de gráficos.

Quem quiser saber mais sobre o git pode consultar o tutorial para preguiçosos como ponto de partida. Outros recursos úteis podem ser encontrados no site oficial e no índice de guias do GitHub. Quem prefere o formato de vídeos também deve conferir o GitCasts.

Um outro assunto que tem aparecido com cada vez mais frequência na lista interna da Caelum são as diversas linguagens que rodam sob a JVM. Sejam elas compiladas diratamente para bytecode Java, ou interpretadas através da Java Scripting API adicionada no Java 6.

O Fábio Kung fez no início do ano um acalorado post intitulado 2009 o ano do Ruby on Rails no Brasil, e podemos ir além: diversas linguagens que não fazem faziam parte do mainstream corporativo vem ganhando muita força por todos os lugares.

Martin Fowler fez um trabalho minucioso em suas considerações ao uso de Ruby pela ThoughtWorks (traduzido pelo Fábio Akita aqui). Fowler discorre a respeito das opiniões e sentimentos dos lideres técnicos de cada projeto que optou por Ruby, e poucos deles (5 de 41) disseram que Ruby foi a escolha errada.

Mas será que apenas o Ruby tem ganho toda essa notoriedade e força?

O Rafael Ferreira compartilhou comigo recentemente um excelente artigo que discute os diferentes paradigmas de programação, citando vantagens e desvantagens, culminando na importância do aprendizado de diferentes linguages, em especial para tirar proveito das que facilitam o desenvolvimento de sistemas com muita concorrência.

O Renato Lucindo me mostrou também o quão grande tem sido a repercussão do Scala em grandes ambientes, como é esse caso da Électricité de France Trading que trocou 300 mil linhas de Java por Scala.

Vale também citar a troca de linguagens num dos cursos mais famosos de computação do mundo: o Structure and Interpretation of Computer Programs, curso que inicia os graduandos de ciência da computação e engenharia elétrica do MIT. Este curso foi sempre famoso por ser ministrado em Scheme, e agora depois de uma série de debates e justificativas, foi reformulado usando Python, novamente sem usar uma das linguagens enterprisey.

Pedro Matiello, que trabalha aqui com a gente, é o lider de desenvolvimento da biblioteca python-graph, que implementa diversos algoritmos para grafos em python e possui colaboração dos mais variados países.

Aqui na Caelum, além de usarmos extensivamente Ruby e Rails em projetos e termos estendido o tempo do nosso curso RR-11 para 32 horas ja há algum tempo, há um pedaço de um sistema desenvolvido em Scala e ainda temos o curso de Lógica de Programação é realizado em grande parte com Groovy.

São muitos meus amigos e colegas de trabalho estudando LISP, Erlang, OCaml, Scala e outras linguagens, sem contar Ruby/Rails e Python/Django. Todas essas linguagens podem de certa forma rodar sobre a JVM. É um lugar-comum (e é uma das dicas do excelente Pragmatic Programmer) dizer que devemos aprender mais linguanges de programação para ampliar nossa visão e formas de ataque a um problema. Já disse Peter Norvig que é necessário 10 anos para que adquiramos fluência numa linguagem de programação, mas sempre há o momento de começar.

E você? Como está seu contato com essas linguagens? Sua empresa está usando algo “novo” em seus projetos?

A lista de emails interna de desenvolvedores da Caelum sempre foi muito ativa, e ultimamente anda aparecendo alguns dos clássicos Java Puzzlers para serem debatidos. O Márcio Hasegawa recentemente postou o problema mais recente da Java Specialists Newsletter:

Problema

Por que isso dá OutOfMemoryError? Repare que criamos duas arrays que gastarão mais da metade da memória que temos, porém a primeira pode (?) ser captada pelo garbage collector, já que seu escopo termina logo:

class JavaMemoryPuzzle {
  private final int dataSize = (int)
    (Runtime.getRuntime().maxMemory() * 0.6);

  public void f() {
    {
      byte[] data = new byte[dataSize];
    }

    byte[] data2 = new byte[dataSize];
  }

  public static void main(String[] args) {
    JavaMemoryPuzzle jmp = new JavaMemoryPuzzle();
    jmp.f();
  }
}

Já esse código, com um pequeno int i = 0 no meio, roda sem estourar a memória:

class JavaMemoryPuzzlePolite {
  private final int dataSize = (int) 
    (Runtime.getRuntime().maxMemory() * 0.6);

  public void f() {
    {
      byte[] data = new byte[dataSize];
    }

    int i = 0;
    
    byte[] data2 = new byte[dataSize];
  }

  public static void main(String[] args) {
    JavaMemoryPuzzlePolite jmp = new JavaMemoryPuzzlePolite();
    jmp.f();
    System.out.println("sem OutOfMemoryError");
  }
}

Solução

O Sérgio Lopes respondeu na lista de maneira muito apropriada. Utilizou o bytecode para justificar o comportamento do garbage collector. Vou parafrasea-lo a partir daqui:

Se você olhar o bytecode gerado dá pra ver a diferença (javap -c Puzzle). A versão sem declaração do int gera:

   0: aload_0
   1: getfield #24; //Field dataSize:I
   4: newarray byte
   6: astore_1
   7: aload_0
   8: getfield #24; //Field dataSize:I
   11: newarray byte
   13: astore_1
   14: return

Vemos que no 6 ele guarda a referência do primeiro array (astore) na variável local _1 e depois ele cria o novo array na 11 (newarray). O problema é que a variável _1 ainda se referência para a primeira array, impedindo que o GC colete-a! Apenas depoisde já ter instanciado a segunda array ele guardará essa referência na mesma posição de variável local (_1). Nesse caso já é tarde demais e o heap estourou.

O bytecode da versão que não estoura é parecido, porém mostra a variável local int i = 0 “reutilizando” o espaço da referência a primeira array e, portanto, liberando o objeto referenciado anteriormente naquela posição para uma possível coleta:

   0: aload_0
   1: getfield #24; //Field dataSize:I
   4: newarray byte
   6: astore_1
   7: iconst_0
   8: istore_1
   9: aload_0
   10: getfield #24; //Field dataSize:I
   13: newarray byte
   15: astore_2
   16: return

Reparem que em 6 ele guarda a referência ao array na variável de posição _1 e depois ele guarda int (que vale 0, valor empilhado por iconst_0) na mesma posição (linha 8), “reutilizando” o espaço da variável antes de criar outro array gigante. Nesse caso, a referência ao segundo array é colocada na variável local _2 (linha 15).

Moral da história: só teremos liberadas as variáveis locais quando o método acaba e não quando os escopos acabam, mas o compilador pode “sem querer” liberar algumas no meio do caminho caso vá usar mais variáveis, reutilizando espaços não mais utilizados. Interessante!

Este domingo aconteceu o Falando em Java 2009 com mais de 500 participantes, evento que nesta terceira edição trouxe o inglês Jim Webber, arquiteto global e diretor de serviços profissionais da ThoughtWorks. Jim falou de SOA e integração e encerrou o evento dando detalhes técnicos sobre restful webservices.

O próprio Jim postou a respeito do evento aqui, e suas palestras podem ser vistas neste link (Falando em Java Keynote e Caelum Tech Talk). Jim demonstrou-se um exímio palestrante, e foi o destaque do evento. Ele também participou de nosso evento interno, o Caelum Tech Day, que ocorreu na sexta feira dentro da empresa.

Tivemos importantes anúncios, como o livro de Arquitetura e Design de Software: uma visão sobre a plataforma Java, a futura Caelum Brasília, o novo curso de Flex em parceria com a pioneira DClick, além do estágio avançado do desenvolvimento do VRaptor3.

Já existe um post no GUJ discutindo como foi o evento e lá você pode deixar a sua opinião. Há também muitos posts em blogs comentando, criticando, elogiando e dando sugestões em relação ao evento, por enquanto temos nos seguintes blogs: Loiane Groner, Rafael Carneiro, Paulo Jeveaux,Alberto Leal, Alberto Souza, Eduardo Bregaida, André Pantalião e Rodrigo Ribeiro, Marcelo Madeira, Natanael Pantoja, Celso Martins, Valdemar Jr, Leandro silva, Rodrigo Lazoti, no blog da Go Now e da BlueEye

Confira também como foi o evento em 2007 e em 2008! Agradecemos aos nossos patrocinadores: a Globo.com, o grupo JBoss e a Locaweb. Agradecemos a todos vocês pela presença, e ficamos na certa de realizar o próximo evento ainda melhor, baseado na experiência e feedback de todos vocês!

A Caelum está lançando hoje o curso TV-61: Desenvolvendo com o Ginga, o middleware brasileiro de TV digital. Em parceria com a Overmedia networks, o curso é pioneiro no Brasil no ensino da nova especificação do Ginga-J oficial para TV Digital. Saiba mais na página do curso.

Assim como nossa aposta em Scrum tempos atrás, é com muita satisfação que a Caelum aposta nesse novo mercado que possui imenso potencial para a comunidade. O fórum do Sistema Brasileiro de Televisão Digital (SBTVD) acaba de aprovar as especificações do Ginga usando JavaDTV e todo o poder da plataforma Java - além do Ginga-NCL. A partir de agora, cria-se um mercado de novas oportunidades que deve ter seu auge em poucos anos quando todos os televisores brasileiros suportarem o Ginga.

O lançamento do novo curso acontece justamente no dia em que a comunidade Java apresenta o evento Java@TV Digital, a primeira de muitas oportunidades de divulgar o futuro da TV Digital no Brasil. A Caelum esteve presente no evento e inclusive, o Daniel Uchôa, da Overmedia, parceira da Caelum nesse novo curso, apresentou uma palestra sobre interatividade na TV Digital: