Fragmental

Ainda durante o STD2007 tive a chance de participar de um bate-papo
entre alguns convidados e Rich Green, VP de Desenvolvimento de
Software da Sun Microsystems. A Sun tem um zilhão de problemas na
maneira como lida com o desenvolvimento de software mas se tem algo
que deveria ser copiado é este contato entre as pessoas que mandam e a
comunidade.

Durante este bate-papo foram debatidos diversos assuntos sobre o
futuro da plataforma, seu posicionamento no mercado nacional, o papel
dos JUGs e etc. Acabou que não tive a chance de falar sobre um assunto
que considero importante, por isso enviei um e-mail ao Rich comentando
este fato.

O problema é que o mercado de desenvolvimento de software é dividido
historicamente em uma grande massa de programadores de medianos para
não-funcionais e uma pequena minoria de bons programadores. As
ferramentas da Sun (netbeans, Glassfish, java, etc) focam na grande
massa de programadores, uma opção economicamente interessante. As
ferramentas são todas gráficas, com drag-and-drop para até o que não
deve (mais sobre isso em outro post), mas demoraram anos para colocar
funcionalidades básicas no editor de código (prometidas para a versão
7, creio).

Deste modo os programadores da minoria (exceto os que trabalham para a
Sun ou outra empresa que te jogue uma IDE pela guela) não vêem
proveito na IDE a criam um estigma com ela. Todos tivemos péssimas
experiências com geração de código na vida e s mais experientes vão
sempre olhar torto para ferramentas mágicas. O Matisse, por exemplo, é
algo interessante porque depende de uma infra-estrutura de software
flexível, com geração de código mínima (EJB3 segue esta linha). Gerar
uma interface em matisse é cool, mas gerar 15 toneladas de um
XML para Java EE não é, pelo menos não para este
público.

Mas quem liga? Estamos falando de menos de 10% dos programadores do
mundo! O problema é que são estas pessoas que inovam.
Quando você não está integrado com a comunidade de inovação de
software você tem um problema muito grande. Pense se você já não viu
isso acontecer com a Microsoft (outra que sofre com estigmas, não desmerecidos) algumas vezes:

1. Fulano lança algo cool fora da plataforma (como
   Hibernate, Spring, AOP, JGoodies, Rails…)
2. A empresa dona da plataforma diz que essa inovação é
   desnecessária, é ruim, não é padrão, dá cárie nos dentes ou qualquer
   outro argumento desesperado
3. Um tempo depois a nova versão da plataforma suporta essa
   funcionalidade

.

A inovação ocorre fora da plataforma e a empresa teme que correr atrás
do prejuízo a cada versão. Quando as coisas são inventadas elas não
podem ser utilizadas na plataforma sem um enoooooorme trabalho de
adaptação, configuração, criação de adaptador, etc.

Para mim, a solução é algo que a MSFT está fazendo, como comentamos
aqui outro dia, que é criar dividir as coisas em Camadas. Dê todo o
poder de trabalhar com o core da plataforma aos desenvolvedores da
minoria e crie uma camada de abstração para a maioria dos
programadores, que vão adorar lidar com ferramentas gráficas e não se
preocupar com a qualidade do que é gerado.

Não basta haver um editor de código melhorzinho, um profiler e um
debugger. É preciso criar uma plataforma que trate a minoria e a
maioria como público-alvo. No Sun Tech Days deste ano não houve uma
única sessão que eu considere que foi para um programador de verdade.
tecnicamente este evento só vale pela interação com o staff da Sun e
os outros desenvolvedores. As sessões focavam a grande maioria,
exatamente como os produtos da Sun. A empresa tem que se livrar deste
estigma de ‘fazedora de ferramenta pra newbie’, existe gente de muita
competência nesta plataforma e eu realmente gostaria de ver este
talento em ação.

Algumas coisas mudam. A que parece a Borland/CodeGear fez da sua IDE uma delas. Durante o STD2007 tive um bate-papo com o representante da empresa sobre o novo JBuilder, o 2007. Como o JBuilder me deu dezenas de péssimas experiências, eu realmente queria saber a quantas andava o produto após a integração com o projeto Eclipse. O JBuilder me surpreendeu. Positivamente, pela primeira vez na vida do produto.

Na verdade não foi a IDE, não há nada que você realmente precise ou não possa substituir com alternativas livres ou pagas, mas a política da Borland é algo muito diferente do usual. Este primeiro release do JBuilder foca em ferramenta de UML, os assistentes para gerar artefatos Java EE que todas as IDEs têm e em integração com plataformas de ALM (Application Lifecycle Management).

O que mais me surpreendeu foi que a integração padrão não é com a suite de ALM da Borland mas sim com ferramentas Open-Source e largamente populares como Subversion, Buzilla, Mylar e Liferay. Métricas? Que tal PMD e Find Bugs? Realmente parece que a separação entre Borland e CodeGear fez muito bem…

O problema do produto que (ou melhor: o problema que puder perceber neste bate-papo) é o licenciamento. A menos que você crie um mercado de apaixonados como o IntelliJ e TextMate ou prenda seus desenvolvedores como faz a Microsoft não há vida no mercado de IDEs pagas há mais de cinco anos. Dado o corte enorme de custos que é utilizar a infra-estrutura (editor, debugger, etc.) do JDT o preço da plataforma caiu uns bons 70%, mas ainda é muito caro. Mais caro que o IntelliJ, que eu já acho caro!

Fatalmente as Borland-shops vão adotar a ferramenta e, pelo que vi até então, vão fazer uma escolha tecnicamente justificável (suporte no Brasil, funcionalidades e plugins do Eclipse, assistentes para RAD e integração com ALM é bem útil) mas economicamente furada. As empresas que usam outras IDEs vão continuar as utilizando e nenhuma nova comunidade será criada. O JBuilder seguirá sua tradição de só ser utilizada por empresas que enfiam a ferramenta pela guela abaixo dos seus desenvolvedores. S o desenvolvedor é do tipo que não quer baixar os plugins do Eclipse que precisa ou não sabe que pode baixar o pacote completo com todos os plugins de uma vez só (algo que os evangelistas do NetBeans fingem que não existe) ele vai buscar sua IDE em netbeans.org, de graça.

A Borland vence tecnicamente a Sun ao reaproveitar uma infra-estrutura excelente ao invés de oferecer mais do mesmo como o NetBeans, mas perde em modelo de negócios já que a Sun já aprendeu que desde o início do século o modelo de licenças está falido.

Cachorros velhos aprendem truques novos, mas nem todos os cachorros e nem todos os truques.

Enquanto o GUJ tem sua massagem noturna eu respondo ao post do Maurício por aqui. O tema é REST x POX, mais especificamente: precisamos usar REST o tempo todo?

Pra você que estava hibernando há uns 12 meses, REST é um estilo arquitetural que se coloca como uma alternativa ao uso de SOAP e padrõesWS -* para criar WebServices. REST é interessante porque este estilo arquitetural é conhecido e utilizado há anos: é o estilo arquitetural que define a Web. Um sistema REST vai usar os métodos HTTP (GET, POST, PUT e DELETE), os content-types, os código de resposta e tudo mais que você ignora solenemente na maioria das aplicações web atuais mas que estão desenvolvidas e especificadas há mais de uma década.

Um possível problema seria de que as pessoas estão dizendo que usam REST quando na verdade apenas usam XML passando por HTTP, o chamadoPOX ( Plain Old XML, um primo do POJO). Este processo é exatamente a mesma coisa que utilizar SOAP com HTTP, exceto pelo fato de que o XML é personalizado (ao invés de 500 envelopes, um dentro do outro) e que não temos umWSDL (o que provavelmente é ruim).

Bom, a pergunta do Maurício é: isso é ruim? A resposta você já sabe: depende, mas depende do quê?

Quando se usa WebServices SOAP ou REST o que se quer é ter uma interface padronizada para um serviço. Há décadas nós temos serviços distribuídos sendoamplamente utilizados, o motivo de existir SOAP e outros é padronizar este ecossistema. Quando você padroniza algo como o protocolo de interface remota de todas as aplicações obviamente você vai pagar um preço em eficiência. Uma aplicação que segue um protocolo genérico como HTTP provavelmente não será tão eficiente em comunicação remota quanto um que segue um protocolo específico e especializado.

A partir do momento que você resolve utilizar uma interface genérica você assina um contrato. Se você me disser que seu sistema éRESTful eu tenho certeza que se eu fizer a requisição de um objeto inexistente seu sistema irá retornar um código de erro 404, e não um código 200 com um XML bonitinho e uma mensagem de erro. 200 pra mimsignifica uma só coisa: “Ok, o objeto existe e seu conteúdo segue no corpo da mensagem”.

Ao fazer POX você quebra esta regra. Pode ser que seu sistema seja simples e que definir um mini-protocolo baseado em POX seja uma ótima solução, mas você acaba de inventar seu próprio padrão, que é exatamente o que o uso de WebServices tenta evitar. Mesmo para sistemas legados com seus próprios padrões (coisinhas em COBOL, por exemplo), nós temos oESB como tecnologia que converte mensagens para um formato intermediário, de modo que não sejam criados seus próprios padrões. A idéia por trás de REST não é abolir padrões mas sim ter uma especificação simples e eficiente, com um mínimo de primitivas e máxima extensibilidade.

(OBSERVACAO: usando teclado de Solaris, sem acentos)

Estou aqui nos computadores do Sun Tech Days 2007. O evento foi basicamente o que eu havia comentado antes que queria que nao fosse, uma grande dose de marketing netbeans. As unicas palestras interessantes foram na track do OpenSolaris. O evnetoe sta relativamente vazio e nao existem muitos conhecidos. Escrevi alguns posts durante uma palestra mas nao pude publicar porque nao tem rede wi-fi para os participantes. Isso foi realmente o cumulo, se der sorte vou postar do hotel.

Sempre vale a pena pelo networking mas o conteudo e estrutura do STD2007 cada ano pioram.

Acabao de receber da Editora Mundo os CDs da coleção Mundo Java. Fantástica a iniciativa do pessoal, nos CDs você encontra alguns dos melhores artigos já publicados na revista. Além das minhas cópias estou encomendando também para a empresa.

Existem alguns artigos ali que são os textos mais relevantes sobre Java que já vi de autores nacionais, uma literatura que você não acha. Enquanto no Brasil se costuma publicar tutorial de IDE e frameworks a MundoJava tem trazido matérias sobre Escalabilidade de Sistemas Web de alto desempenho, testes e mais testes unitários, entrevistas com grandes nomes como Scott Ambler, modelagem de sistemas e as matérias que saem do commodity.

Tudo isso disponível em 3 CDs. na verdade minha única crítica até então é que deveria haver uma versão em DVD com todo o acervo. Os artigos estão em PDF, a interface em HTML, funcionando maravilhosamente no Ubuntu.

Ótima sacada!

Mais uma vez vou estar no Sun Tech Days, mais uma vez em São Paulo e mais uma vez esperando que o evento seja melhor que o ano anterior. É uma grande infelicidade que o único evento real da Sun no Brasil tenha piorado tanto nos últimos anos mas vamos ver como vai ser desta vez.

A IBM é uma empresa que não inova. Deixou de ser o grande líder do mercado há décadas para se tornar um seguidor, e dos bem fraquinhos. O IBM AlphaWorks, entretanto, é uma das poucas coisas que sobrevive em termos de inovação da IBM. Eu recebo a newsletter há alguns anos e é sempre uma das primeiras mensagens a serem lidas quando chegam.

Talvez por essa esperança toda que me decepciona fortemente ver que as pessoas ainda, em 2007 (notou que “em 2007″ é uma expressão recorrente minha há algum tempo?) as pessoas ainda insistem em conexões com bancos de dados feitas pelo cliente. Saber disso realmente é frustrante como desenvolvedor.

Bancos de dados como coração da empresa já foram uma técnica válida. Era o único middleware que prestava ou era viável no cenário de algumas muitas décadas atrás. Hoje as pessoas querem SOA, querem componentes reutilizáveis e… continuam insistindo em repositórios de dados centralizados.

Certa vez a equipe que eu coordenava passou por um problema nessa área. Como parte do lançamento de um novo produto tivemos que eliminar algumas tabelas e mudar o schema de dados. Apesar daquele esquema só ser utilizado completamente pela minha equipe, sabíamos que algumas pessoas estavam fazendo consultas neles. Alguns greps no CVS (infelizmente não usávamos SVN) e vimos que três projetos usavam as tabelas que eliminamos e que quase todos usam as outras. A solução do mundo dos SGBDs corporativos é uma só: faça uma view e mantenha ela no ar enquanto as pessoas não alterarem, testarem, homologarem e instalarem seus sistemas modificados.

Esta foi uma epifania, as pessoas acordaram e vimos que precisávamos racionalizar isso. A solução veio na forma de um arquivo JAR que continha um cliente padronizado fazendo consultas em JDBC diretamente ao banco de dados. Eventualmente construímos alguns WebServices REST (como quase sempre, SOAP não fazia sentido) e os clientes que se conectavam ao banco foram migrados para versão que conectava-se ao REST. Quem teve o trabalho de se adaptar a primeira versão não precisou de mais anda para migrar para uma arquitetura SOA.

Quantas vezes vamos ter que resolver este mesmo problema até que todos percebam que bases de dados são apenas partes de sistemas?

Leu no InfoQ sobre o artigo do Jacobson no Dr. Dobb’s?

Além de dezenas de referências à métodos e práticas ágeis (tãããããão repudiados pelos que ainda vivem nos anos 70), Jacobson coloca os processos como um conjunto de práticas. Vendo sua apresentação é possível fazer uma analogia ao paradigma de Serviços. Está tudo lá, Serviços, Workflows, Front-ends, Barramentos…

Se estiver sem tempo para ler agora prometa que vai ler depois e só dê uma olhada no PPT. Ei, você tem que prometer!

Dia desses estava programando em par com um amigo quando encontramos um problema. Estávamos utilizando o excelente XStream para transformar um domain model em algo que pudesse ser consumido via webservices de arquitetura REST quando percebemos que nossos XMLs iam ficar enormes e com uns 40% de informações repetidas. Simplesmente haviam dados que eram comuns a várias entidades sendo serializadas em uma lista e se repetíssemos os dados para cada entidade serializada teríamos um grande problema.

Conversando com o Guilherme, ficamos sabendo que o XStream possibilita o uso de referências. Infelizmente também descobrimos que isso só funciona se você tem várias referências para o mesmo objeto (ou seja: tem que ser ==, não basta ser equals()). Seguindo indicações do Guilherme, vimos que para alterar este comportamento deveríamos mexer em uma classe específica que, a princípio, poderia ser estendida por uma subclasse nossa.

Aí a falta que faz seguir o Open-Closed Principle (OCP. E não, não é a ) se faz cruel. O OCP foi difundido por Bertrand Meyer, um dos papas da OOP, e diz:

Queria informar que sou o mais novo certificado pelo orgão abaixo:

http://www.agilecertificationnow.com/

Sim, eu sei. A certificação sempre foi algo que questionei mas essa é diferente. Esta é ágil. Esta tem valor. Eu concordo itnegralmente com ela, com o que diz o site e com a proposta.

A propósito, estou voltando para a faculdade após 3 tentativas frustradas. Após conversar com o melhor desenvolvedor que já vi na vida ele me convenceu que o diploma é o que faz a pessoa realmente saber alguma coisa. É surpreendente quanto tempo eu perdi procurando conhecimentos em livros e outros lugares escusos quando todos sabemos que não se adquire conhecimento fora da faculdade. Para dar mais nfase acabo de pedir demissão para fazer vestibular novamente.

Quando terminar meus 6 anos de graduação+mestrado, com meu certificado ágil na mão (além dos clássicos SCJP, SCEA, SPQP, etc.) eu volto a escrever neste blog, certamente vou estar trabalhando com sistemas importantíssimos para alguma mega-empresa. Ou para a NASA.
Até breve, quatro anos + 2 passam muito rápido!

(ps.: eventualmente o domínio e a hospedagem vão expirar e eu não vou ter grana para pagar até sair da faculdade e conseguir meu emprego, vou tentar negociar com o registro.br e infolink, quando eles souberem que eu sou um futuro acadêmico certamente vão me deixar pagar os retroativos quando me formar e for trabalhar como egenheiro-chefe do Google).

Update:Provando que rbasileiro é perseverante e não desiste nunca, temos mais dois Agile Software Specialist(’es’), o Kumpera e o DQO. Estamos nos unindo agora para termos o processo de certificação em Português.