Fragmental

Não, não é lançamento de livro em português, não ainda (agradeçam, esse livro não é legal e não vale a grana).

Está acontecendo mais uma vez. Assim como com o Struts, o Spring está ganhando a luz do dia nas empresas após ganhar força na comunidade (e, assim como o Struts, em algum tempo perceberemos que podemos fazer bem melhor…).

Para quem (ainda) não sabe, o Spring é um container leve (container leve é um conceito vasto, mas neste caso quer dizer um container de POJOs, segundo o time do Spring). Com ele você pode ter praticamente todos os benefícios de Java Enterprise Edition (JCA, JTA, Servlets, Pools, JMS, TMX, JavaMail, JDBC…) sem utilizar EJBs. Você não precisava de EJBs para usar estas coisas, mas geralmente as pessoas se apegavam a estes por serem a maneira “mais fácil” de lidar com os outros recursos.

O Spring provê uma API fácil e bem utilizável para utilizar estes recursos, mantendo seus objetos independente destes com um bom uso de AOP (que é facilmente configurável por qualquer um).

O problema atual do Spring é como é chato configurar seu XML. A semântica do negócio é simples, mas é muito ruim ter que digitar aquilo tudo (não me apontem uma ferramenta, não é isso que torna as cosias produtivas), mas ainda assim é *muito* mais simples que configurar EJBs e seus descritores, interfaces, pools, JNDI names e tudo mais, fora as gambiarras como Service Locators e Business Delegates.

Existe um velho refrão que diz algo como Não use um canhão para matar uma mosca. Esta frase mais que sábia diz muito sobre quando usar EJBs (praticamente nunca), mas também tem suas complicações.

Um caso típico é o de programas em ASP clássico/PHP/CGI. Estas plataformas são extremamente limitadas para aplicações de grande porte, praticamente qualquer integração com middleware é feita por banco de dados (bleargh) ou hoje em dia por XML sobre HTTP. Eu trabalhei muito tempo com ASP, e quando estava estudando minha diversão era fazer cosias improváveis, como editores de texto completos, editores de vídeo e outras coisinhas complexas em ASP puro (não adianta usar componentes, muitas vezes você não consegue instalá-los no servidor do cliente).

E ficava aquela gambiarrada toda. Trocas de mensagens através de tabelas no SGBD, arquivos temporários de download… etc. Esse é o caso contrário do ditado que acabei de falar, neste caso podemos aplicar o refrão: Não use um mata-moscas para matar um mamute.

Existem aplicações que não são mamutes, não são moscas, mas ainda assim precisam de algum suporte de plataformas coorporativas, como transacionamento XA, pools, conectores, ciclo de vida controlados, mensageria… a maioria das aplicações que são mais que um simples site de Internet tem pelo menos uma dessas necessidades. Neste cenário, coisas como o Spring são perfeitas, você usa apenas o que precisa, não precisa engolir o elefante de novo para usar o que quer.

Neste cenário, fica mais fácil produzir aplicações Orientadas a Objetos de verdade, sem as aberrações de BusinessDelegates/SessionFaçade/ServiceLocator/DTO/TO/VO que vieram trazer alguma usabilidade aos EJBs. Mas se você é amigo dos EJBs, ou realmente tem um caso onde els são úteis (chamadas RMI são um dos raros exemplos), pode continuar utilizando sua plataforma.

Se você está no mercado, estude Spring. Provavelmente quando a sua empresa for enfim usar haverá coisa melhor, mas por enquanto, essa é a opção mais sensata para aplicações médias. Não que paltaformas como Pico/Nano Container sejam ruins, pelo contrário, só que o Spring tem maior suporte e um apaltaforma mais vasta, cobrindo muita coisa que você precisa hoje.

A fila anda…

Dois assuntos que tem muito pouco a ver, mas me ocorreram hoje.

A coordenação do RioJUG foi convidada junto com clientes e parceiros para uma demonstração do novo Bea WebLogic 9 (aquele com o diabinho que parece desenhado pelo mesmo cara que desenhou o Tomcat, confira abaixo).

Eu considero a Bea uma empresa muito razoável no que faz, e pela apresentação a nova versão do WebLogic traz coisas muito, muito, muito legais, como possibilidade de rodar duas instâncias de uma mesma aplicação com versões diferentes, configuração atômica (nada de urânio, plutônio ou deuteronômio, apenas transacional) e scripting.

Eu tenho um pet project que não avançou muito de colocar um Shell no JBoss. Onde eu trabalhava (já falei que mudei de emprego?) isso era muito útil, principalmente acessando máquinas dos clientes via uma VPN fedorenta, tendo que atravessar mil servidores para chegar na máquina de produção… enfim. A minha alternativa (como o que pretendo no Funky) é algo independente da linguagem, mas bem focada em Groovy (BeanShell é legal também).

Eu estava ansioso por saber como é o scripting do WL, e não é que eles usam…Python! Pelo que o cara de marketing falou (aliás, pausa aqui: O cara de marketing era muito, mas muito mesmo mais técnico que todos os outros que já conheci, seja da IBM, Sun, Microsoft, Novell…o cara deu um parecer técnico-porém-marketeiro muito legal) que ele roda sobre Jython. Não tive a chance de perguntar o porque, vou pesquisar por aí, alguém sabe de algo?

Não me entendam mal, Python é legal, a Bea investir em algo aberto como Jython é legal… mas o JCP está padronizando três linguagens de script (Groovy, BeanShell e JavaScript), pra que uma tão alienígena?

Eles estão trabalhando junto com o Rod Johnson para prover um suporte melhor ao Spring que outros AS. Vamos ver…

Eu curto o estilo deles. Tá certo que tudo que a Bea faz é comprar empresas que fazem algo legal (Tuxedo, WebLogic…), mas eu curto. Apesar disso, ainda sou adepto ao JBoss, mas num ambiente onde software-livre não entra, seria minha primeira escolha.

O problema da Bea é tentar vender toda aquela parafernalha quase-RAD com Workshop, Beehive, portal, blablabla. O velho truque de vender ferramentas que vão esconder o fato dos seus “profissionais” serem apertadores de parafuso. Vão mesmo?

Ah, o logo:

Gostei da audácia do slogan, parece coisa do WinAmp :)

Só eu que acho eles parecidos?

Nota: Não ganhei comissão (aidna, ao menos) por este post. Na verdade não ganhei nem um CDzinho demo do Diablo :(

Por último, conversando com as pessoas no evento, vi o que já é fato conhecido: está todo mundo procurando desenvolvedor no Rio. Você não acha ninguém bom sem emprego e/ou ganhando pouco.

Achar um profissional JSP+JavaBean é mole. Profissional razoável? Prepare-se para gastar uma grana. Profissional bom? Conheço gente que está procurando ha um ano, literalmente. O emrcado aqueceu e os desenvolvedores sumiram… cadê vocês?

Você que foi no CJ2005 não deixe de preencher a ficha de avaliação. Desta forma teremos um evento aida melhor ano que vem ;)

Como falei aqui, vou falar um pouco sobre Camadas na reunião mensal do RioJUG.

Para quem se itneressar, a entrada é gratuita e não é necessário fazer pré-inscrição, basta aparecer por lá ;)

Arquitetura de Camadas em Java Enterprise Edition

por Phillip Calçado

Dia: 12/Setembro/2005 (segunda)
Horário: 19:00 horas
Local: Auditório do SENAC - Rua Santa Luzia, 735/7º andar
Dica de Acesso: Estação Cinelândia do Metrô pela saída Santa Luzia, atrás do Consulado Americano
Entrada: Gratuita

A Palestra

Algumas pessoas acreditam que uma aplicação Java Enterprise Edition utiliza Camadas por si só.
Outros acreditam que o Modelo MVC garante o uso de Camadas, muitos ainda nunca ouviram uma definição do que seriam as tais Camadas.
Nesta breve apresentação, os conceitos de Camadas serão apresentados e discutidos no contexto de aplicações Java EE, incluindo novas tendências como IoC e AOP.

O Palestrante

Phillip Calçado é JUG Leader do Grupo de Usuários Java do Rio de Janeiro (RioJUG) e do GUJ, o maior fórum brasileiro sobre a tecnologia.

Programa em Java desde 2003 e já atuou nas áreas de previdência privada, gestão de conteúdo, redes de telefonia e energia.
Instrutor, coach, conferencista e escritor ocasional.
Participa de projetos open-source e mantêm um site e blog em www.fragmental.com.br

Olá,

Muito feliz, continuo o relato do CJ2005 :)

Eu dirigi o workshop Aumente o QI dos seus objetos: camada de negócios de verdade com Spring, no domingo. O objetivo era mostrar como cosntruir uma aplicação focada na camada de negócios, sem usar DTOs e derivados, e de quebra aprender um pouco de Spring e IoC…enfim, o que descrevi aqui.

O objetivo era levantar uma discussão e desenvolver o sistema em cima desta, mas como a turma era heterogênea, haviam pessoas com muita experiência e pessoas que nunca haviam visto Java. O CJ precisa definir tracks :(

Então a parte mais teórica da apresentação foi legal, mas a parte prática foi prejudicada. Não conseguimos criar mais que o esqueleto de uma estória (um casode uso) e não chegamos no Spring (problemas nos meus CDs e máquinas sem rede ajudaram também). A galera ficou frustrada :(

Eu acredito que quem foi gostou, mas teria sido melhor um tutorial ou palestra. Ficou um mini-curso teórico demais para o gosto de qualquer um :P

Em breve vou estar liberando aqui os slides e o código de exemplo, por enquanto os slides estão disponíveis no GUJ (em breve estarão também no site do evento).

Se voce nao levou a serio meu post sobre Rails do outro dia, saiba que tem gente grande de olho.

Será?

Eu não ia conseguir falar sobre o CJ2005 hoje, estou extremamente atarefado, mas vou ter que comentar algo.

Para quem não sabe, o tal “TBC” (To be Confirmed) da grade no debate era eu. Fui chamado pelo Rafael Steil e depois pelo louds (Rodrigo Kumpera) para participar do debate com o hammett, o Hamilton Veríssimo. Eu conhecia o hammet de nome, me parece que quando eu entrei definitivamente para a comunidade Java ele estava indo apra o .Net.

A culpa por não ter meu nome no evento foi minha, que não consegui participar efetivamente da organização da atividade, mas enfim, rolou. Minha impressão é que foi muito bem.

Antes de continuar, o Hamilton provou que é um profissional extremamente competente e confiante. Ele aceitou a proposta de participar de um evento sobre Java falando mal de .Net. Você faria isso com a sua tecnologia? Convidamos outras pessoas para compôr a mesa, mas ninguém teve coragem, por isso o debate foi 1 a 1.

Para quem ainda não percebeu (tem gente muito lenta por aí..), o debate foi o contrário do normal (apelidamos carinhosamente de !debate). Eu meti o pau no Java e o hammett no .Net, a visão era de quem usa a tecnologia, não um cara xingando a mãe do outro que nem conhece.

Parece que mesmo assim tem gente que prefere xingar tudo e todos sem entender. Questionam a qualificação técnica do participante (engraçado ler os comentários nos blogs depois que eles “descobrem” que o hammet é commiter de projetos super respeitados e autor de livro sobre ASP.Net…além de entender muito de Java) e até conceitos básicos de Ciência da Computação como listas ordenáveis.

Pessoas que nem sequer foram no evento tentar desmerecer os participantes. Pessoas que foram e não repararam nem que o Rodrigo era o moderador, não participante, questionam.

“Ah, é porque eles são de .Net, esse povinho é assim mesmo” …ah é? Na verdade eu ainda estou esperando reações parecidas do lado Java, bem parecidas. Muito parecidas.

O Hamilton postou uma resposta de altíssimo nível no seu blog. Não sou indicado para falar de .Net (e por isso nem poderia participar dum debate normal deste tipo), mas acho que foi na mosca.

Você tem que alterar os pacotes no import de 1000 arquivos. Opção? sed, claro.

No meu caso, acho que foi mais rápido escrever este scriptizinho em groovy do que ler as páginas de manual dos pipelines que teria que fazer.

#!/usr/bin/env groovy

new File(this.args[0]).eachFileRecurse(){
input ->
filename = input.getAbsolutePath();
output = new File(filename+”.REPLACING”);
if(!input.isDirectory() && (input.getName().matches(”^.*java\$”))){

println(”################# UPDATING FILE [”+ input.getAbsolutePath()+”] ##############################”);
input.eachLine{
line -> modified = line.replaceAll(this.args[1], (this.args[2]+”\n”));
output.append(modified)
}
}
input.delete();
output.renameTo(new File(filename));
}

Ele recebe três parâmetros: [0] diretorio onde começar [1] regexp com linha a substituir [2] texto para colocar no lugar. Como sou newbie em Groovy, acho que dá pra melhorar muito…sugestões?

(não o algoritmo em si, eu sei que tá uma merda, mas otimizar script que você vai usar uma vez na vida é um tanto quanto perda de tempo demais para mim, quero saber sintaxe e truques)