Comunidade Ágil a todo vapor no Brasil

É muito animador ver o quanto a comunidade ágil tem crescido e se fortalecido no Brasil. A pouco recebemos a notícia do grande evento que acontecerá em outubro, o Falando em Agile 2008, promovido pela Caelum. Treinamentos e workshops acontecem todos os meses Brasil à fora – basta você acompanhar, por exemplo, o blog do Alexandre Magno e do Rodrigo Yoshima, pra saber quando acontecerá o próximo. E agora, mais recentemente ontem, o Manoel Pimentel, editor chefe da revista eletrônica Visão Ágil, postou no GUJ a notícia do lançamento do Blog Visão Ágil.

Iniciativas como esta mostram o quão notório já é o crescimento das agordagens ágeis de desenvolvimento de software no Brasil.

Pratico desenvolvimento ágil em meu trabalho diário há algum tempo, e sei o quando é bom trabalhar assim – sob todos os aspectos. Mas sei também que não é fácil vender essa abordagem; muito menos fazê-la acontecer como deve ser. Contudo, com a comunidade mostrando a cara, e mais ainda, mostrando seus próprios resultados e experiências reais, certamente mais e mais empresas darão a si mesmas a chance de ver o quanto ser ágil é bom!

Imagine o dia que todas as empresas adotarem abordagens ágeis.
Não é difícil, não.
Nada de gantt chart ou gerente alienado,
Nada de comando/controle, só a liberdade de programar, testar e implantar.
Imagine todos os programadores, clientes e empresas vivendo em paz.
Somente a paz!

Você pode me achar um sonhador,
Mas não sou o único.
Espero que você se junte a nós,
E o Mundo do Desenvolvimento de Software será um só.

Conhece esta canção? Nada mau para o momento… rsrsrs

Nested Classes: Use com consciência

Há situações em que precisamos de nested classes, seja para agrupar logicamente classes que apenas fazem sentido num determinado local, ou mesmo para melhorar o encapsulamento. A API Java padrão está repleta de bons exemplos. Mas é preciso algum cuidado para não fazer mal uso delas.

O que é uma nested class?

De maneira bem simples e direta, uma nested class é uma classe membro de outra classe – conhecida como enclosing class.

Java dispõe de dois tipos de nested classes:

1. Static Nested Classes, que são classes sintaticamente residentes em outra classe, mas que usa esta apenas como namespace.

Este tipo de nested class não tem acesso a membros de instância de sua enclosing class.

A sintax para instanciar este tipo de nested class é bem trivial:

StaticNestedClass obj = new EnclosingClass.StaticNestedClass();

2. Non-static Nested Classes ou Inner Classes, que além de residir sintaticamente em outra classe, também tem acesso a membros de instância desta – pois sua instância resite na instância de sua enclosing class.

Este tipo de nested class tem uma sintax bem exótica de instanciação, mas até que intuitiva, quando você entende o conceito de inner class. Veja:

InnerClass obj = objEnclosingClass.new InnerClass();

Por que intuitiva? Porque uma vez que uma instância de inner class está diretamente associada a uma instância de sua enclosing class – e só pode existir nela -, nada mais natural do que criar esta instância a partir da instância de sua enclosing class.

Por motivos óbvios, inner classes consomem mais tempo de processamento e memória que static nested classes.

Quando usar uma ou outra?

Sabendo quais são os tipos de nested classes possíveis no Java – estáticas e não estáticas – e suas naturezas, podemos ter uma idéia clara de quando usar uma ou outra.

  • Se sua nested class precisa de acesso a membros de sua enclosing class, opte por inner class;
  • Caso contrário, se o que você precisa, na verdade, é apenas de um namespace, opter por static nested class.

Simples, não?

Desenvolvimento Ágil na Web com Seam

Este é o titulo de um artigo bem legal que o Rodrigo Yoshima postou em seu blog ontem. Se você se interessa por desenvolvimento Web, vale a pena conferir.

Aliás, falando em JBoss Seam, a Caelum lançou um super curso, rápido e objetivo, que você pode conferir o conteúdo programático aqui. Como sempre, qualidade indiscutível.

Rails Summit Brazil 2008!

Esta foi a melhor notícia que recebi nos últimos tempos: Uma master conferência de Rails Brasuquíssima! OmG! Era tudo que eu queria!

Segundo o Akita:

Confirmei as presenças do próprio David Hansson (somente ele será via video online, ele estará na Europa nesse dia, os outros serão presenciais); o grande Chad Fowler ; os mantenedores do JRuby, Charles Nutter e Thomas Enebo ; diretamente da Holanda, da Phusion teremos Ninh Bui e Hongli Lai ; o mantenedor do RSpec, David Chelimsky ; o criador do Github, Chris Wanstrath ; ninguém menos que Dr. Nic Williams ; o escritor do livro The Rails Way, Obie Fernandez ; também Jay Fields, da ThoughtWorks.

E também muitos grandes Railers brasileiros como Manoel Lemos, da Brasigo ; Carlos Eduardo, da e-Genial ; Fabio Kung, nosso JRuby-man, da Caelum ; o grande Vinicius Teles da Improve it ; George Guimarães do Pagestacker.

A notícia completa está aqui.

JRuby ou Groovy?

[Novo endereço: leandrosilva.com.br.]

Não, não quero começar nenhum flame war em torno de JRuby e Groovy.

O que ocorre é que ontem um cara que tem um blog legal, o Diego, fez um comentário num de meus posts que me fez pensar a respeito… Até agora…

Na hora, sinceramente, não tive nada de muito substancial para responder, porque ainda não havia pensado a respeito. Mas tenho que confessar que isso ficou martelando a minha cabeça o tempo todo… Existe alguma vantagem de se usar Groovy invés de JRuby?

Bem, lendo e pensando a respeito, cheguei a algumas simples conclusões:

Se você tem familiaridade com Java e quer permanecer 100% no ambiente Java, sem a perspectiva de migrar, Groovy é a melhor opção pra você.

Porque a sintaxe de Groovy é muito parecida com a de Java; Groovy traz consigo uma porção de vantagens de uma linguagem OO moderna e dinâmica, como meta-programação, duck type, e closures; e você ainda pode programar usando objetos Java e Groovy numa mesma classe, de forma totalmente transparente (já que .groovy ao ser compilado se transforma em um .class qualquer).

Só que, mais uma vez: Não há qualquer possibilidade de se rodar código Groovy fora de ambiente Java, porque Groovy foi especificamente criada para ser uma “alternativa” à linguagem Java.

Se você quer que seu código seja portável para outras plataformas de runtime, tal como .Net, por exemplo, JRuby é o melhor pra você.

Acho que este é um dos fatores primordiais na escolha de JRuby invés de Groovy. Porque o fato da sintaxe de Groovy ser próxima à de Java, sinceramente, pra mim não quer dizer nada – aprender uma nova sintaxe não é coisa de outro mundo; e é até legal. Agora, portabilidade, isto sim faz a diferença – quando necessário, claro.

Você pode escrever, por exemplo, uma aplicação Ruby on Rails comum e coloca-la para rodar em um web container Java, sem muito esforço. Aliás, se você estiver usando o NetBeans, ele faz isso pra você em um ou dois cliques. E se num dado momento decidir rodar, sei lá, num Mongrel, tudo bem, você pode fazer isso sem problema algum. Isto é fantástico!

Se você quiser se manter 100% compatível com a MRI, isto é totalmente possível, porque JRuby é uma implementação completa de Ruby para a plataforma Java. E se você quiser aproveitar algum código escrito em Java, você também pode fazer isto – mas neste caso, claro, sacrificando a portabilidade.

Outro fator primordial que vejo é “comunidade”.

A comunidade JRuby tem crescido a cada dia – claro que por conta do próprio Ruby/Rails. E a indústria de software tem investido nisto, aja vista o ótimo suporte do NetBeans a Ruby/Rails; e a própria contratação de membros chaves do JRuby pela Sun há algum tempo.

E a comunidade Groovy? Bem, acho que Grails tem ajudado a levanta-la. Mas o seu barulho ainda não é dos maiores não. (Espero que isto mude.)

E o fim deste pensamento, qual é?

Use JRuby. Use Groovy. Use o que melhor atender aos seus próprios requisitos e aos de seu cliente. Porque não há apenas uma linguagem de programação, nem uma única solução pra tudo!

Atualmente estou propenso a usar tanto JRuby [on Rails] quanto Groovy [on Rails]. O que vai me fazer decidir entre um e outro serão os requisitos do momento – e a expectativa futura.

Então, seja JRuby ou Groovy, o que importa é desenvolver o software certo, no tempo certo, com a qualidade certa.

(Valeu Diego, por me fazer pensar um pouco sobre isto.)

Até a próxima!