Na última quinta-feira eu fui na palestra do Bruno Borges no RioJUG, sobre Apache Camel. A palestra em si foi bem legal, pois eu já conhecia um pouco do Apache Camel e pude ver algumas coisas a mais. Mas o ponto específico que eu quero abordar é um comentário que o Bruno fez, que diverge da minha postura em relação a open source.

Ele comentou que tenta sempre utilizar produtos Apache, evitando produtos open source que tenham vínculo com alguma empresa, como JBoss, SpringSource, entre outras. Não me recordo do motivo exato, mas a razão principal que ele explicou é o fato da Apache Software Foundation ser uma fundação composta de pessoas, em vez de ser uma empresa com fins comerciais.

Eu tenho uma postura diferente da dele em relação a open source. Eu gosto muito e tenho um respeito enorme pela fundação Apache. Já usei inúmeros produtos Apache e certamente continuarei usando por muito tempo. Entretanto, já usei vários produtos JBoss e vários componentes do Spring, e acho muito importante e saudável a existência dessas empresas.

A história do movimento open source tem vários elementos “românticos” e “filosóficos”, e essa característica ainda é muito presente em várias comunidades hoje em dia. Entretanto, com o crescimento do Linux, Java, Python, Ruby e outras tecnologias, existe hoje um mercado enorme de trabalho e negócios em torno do software livre.

O surgimento desse mercado naturalmente trouxe a participação de muitas empresas que vivem de software livre atualmente. Sei que há pessoas que enxergam open source e capitalismo como coisas opostas, mas na minha opinião essa visão é míope. Open source é um modelo de desenvolvimento de software e oferta de produtos e serviços. A busca do lucro é o que move nossas empresas, e isso não é diferente para quem atua com software livre.

O surgimento das empresas profissionais open source foi importantíssimo para o amadurecimento das tecnologias e dos profissionais. Se o movimento open source continuasse restrito ao meio acadêmico, o nível de competição no mercado de software seria muito menor, e o avanço tecnológico teria sido bem mais lento.

Além disso, minha postura profissional é de tentar sempre entregar os melhores resultados para os clientes e para a empresa em que trabalho. Em algumas situações pode ser mais adequado usar open source, em outras pode ser necessário usar software proprietário. Temos que nos adequar às necessidades dos clientes, em vez de esperar que eles se adeqüem às nossas preferências.

No meu ponto de vista, empresas como JBoss e SpringSource contribuíram e contribuem muito no processo de profissionalização do software livre. A existência delas criou um mercado fortíssimo em torno do software livre, e eu só tenho a agradecer por isso.

Framework web Java

Considerando o critério empregabilidade, é fundamental conhecer razoavelmente Struts 1.x. Eu creio que poucos projetos hoje em dia sejam iniciados usando o Struts 1.x, mas a quantidade de aplicações em produção com esse framework é enorme, e durante um bom tempo essa realidade ainda se manterá.

Depois do Struts 1.x, nenhum outro framework web Java conseguiu adoção semelhante, então é difícil recomendar uma opção mais moderna que garanta alguma coisa. É provável que a melhor opção “moderna” em termos de empregabilidade seja Java Server Faces, mas não me sinto bem em recomendar que ninguém estude JSF. Se alguém quer seguir na linha do JSF, eu recomendaria o JBoss Seam, do qual ouvi boas avaliações, mas nunca usei.

Dos frameworks web Java mais recentes, o meu preferido é o Spring MVC 2.5.x. O importante da versão 2.5 em diante é que os controllers suportam anotações para configuração, em vez dos XMLs monstros que eram a opção anterior. A maioria dos frameworks web está seguindo numa abordagem RESTful de arquitetura, o que me agrada também. O Spring MVC é um dos que está fazendo isso, e com uma abordagem legal.

Além disso, todos os componentes do Spring acabam te “seduzindo” a usar outros componentes dele, pela conveniência e pela qualidade dos mesmos. Então se você usar o Spring MVC, é muito provável que use a injeção de dependências, o controle transacional, talvez o web flow, entre outras coisas.

Frameworks web da “nova geração”

Qualquer desenvolvedor web hoje em dia TEM OBRIGAÇÃO de olhar pelo menos um entre Django, Grails e Ruby on Rails. O ideal mesmo é avaliar os três e ter um deles como opção principal. Eu já conheço legal o Grails e estou evoluindo rápido com o Django. Em algum momento esse ano eu dedicarei um bom tempo avaliando e fazendo algo relevante com Ruby on Rails também.

Pode parecer que leva um tempo enorme para conhecer os 3, mas isso não é verdade. Os 3 são extremamente produtivos e têm muitas características semelhantes. Quando você começa a utilizar um deles já tendo experiência com outro, a curva de aprendizado fica muito rápida.

Um aspecto muito legal do aprendizado desses frameworks da “nova geração” é que você tem contato com outras formas de fazer software (para quem tem um background Java), outras comunidades, e várias idéias interessantes que te farão um programador melhor em qualquer linguagem ou plataforma. Se você ainda não conhece nenhum dos 3, não perca mais tempo e escolha um para começar. E de preferência conheça os outros em seguida também

HTML, CSS, Web Standards

Estamos em 2009. Embora ainda vejamos muitos sites bisonhos que só funcionam com o IE, se você é um desenvolvedor que se preza você precisa conhecer bem HTML, CSS e os web standards. Na verdade, fazer o site funcionar no IE 6 por exemplo é secundário. Você precisa aprender primeiro a gerar HTML e CSS válido de acordo com as normas da W3C, que garantem padrões de qualidade e interoperabilidade entre browsers. Leia de cabo a rabo todos os tutoriais referentes a essas coisas no W3Schools. É muito rápido estudar por lá, e é uma ótima referência depois.

Depois que você conhecer isso, um pouco de prática na escola norueguesa de software fará suas aplicações rodarem no IE 6 também

Javascript

Ainda há pessoas que escrevem javascript na unha, mas acho que elas são cada vez mais raras. Temos hoje uma oferta enorme de bibliotecas javascript para resolver todos os problemas comuns dos desenvolvedores web. Eu era um fiasco em javascript antes de conhecer o jQuery, mas há um bom tempo eu gosto MUITO de javascript, e minha produtividade no client-side melhorou absurdamente.

O jQuery tem uma abordagem que eu acho excepcional. Temos 3 aspectos claramente distintos para tratar em uma página web: Estrutura (HTML), Estilo/Visual (CSS) e Comportamento (Javascript). Se você fizer tudo direitinho e usar o jQuery, essas 3 coisas ficam totalmente desamarradas.

Você não precisará colocar nenhuma declaração de estilo na estrutura (leia-se: sem CSS inline). A definição do comportamento fica totalmente por fora da estrutura. A beleza do jQuery está em aplicar todo o comportamento da página de uma maneira não-intrusiva, e com uma abordagem muito limpa. Ah, e o javascript funcionará em todos os browsers sem você ter que tratar disso explicitamente. Um sonho, não é mesmo?

Há várias outras opções, e não estou defendendo a idéia de que se use apenas uma. Eu uso o jQuery para tudo que posso, e até hoje não precisei de outra biblioteca, mas vá em frente e experimente algumas opções até encontrar o que lhe atender melhor.

Plugins legais do Firefox

Firebug

Além do jQuery, outra descoberta que mudou minha opinião e gosto por client-side foi o Firebug. Ele ajuda MUUUUUITO na criação do HTML/CSS das páginas, pois você consegue inspecionar de forma fácil o conteúdo e o estilo, e aplicar mudanças imediatas sobre o que está vendo. Depois de acertar as coisas pelo Firebug, você simplesmente aplica as mudanças no HTML/CSS originais e continua implementando sua página. Além disso, ele te permite debugar javascript e analisar as requisições HTTP detalhadamente. Eu já o utilizo há pouco mais de 1 ano, e ele contribuiu muito para meu amadurecimento no client-side, e me dá muito mais produtividade.

Web Developer

Um companheiro freqüente do Firebug é o Web Developer. Ele te permite inspecionar detalhadamente uma porção de coisas na sua página, como informações de todas as imagens, todos os formulários, estilos, entre outras coisas. Além disso, permite a manipulação de cookies, valida HTML/CSS/Javascript, e tem muitas outras funcionalidades úteis. É indispensável para trabalhar com web, assim como o Firebug.

Screengrab

É muito comum termos que mostrar uma página para outras pessoas, e nem sempre elas têm acesso à nossa máquina. Para facilitar isso, podemos usar o Screengrab, que é semelhante a um Print Screen, mas salva o conteúdo completo da página como uma imagem. Isso é bem melhor do que o Print Screen, pois pega apenas a área útil da página (sem pegar barras do Firefox e barra de tarefas) e pega toda a área útil. As regiões da página que precisam ser “roladas” para visualização também são incluídas na imagem, o que é certamente o desejado.

NoScript

O NoScript é um plugin bem incômodo para uso em geral. Ele bloqueia a maioria dos javascripts e você precisa ficar liberando a execução de scripts toda hora. Quando não estou desenvolvendo eu sempre deixo ele desligado.

Entretanto, para desenvolver ele ajuda em algumas situações. Por exemplo, você pode precisar desabilitar alguns scripts específicos da sua página para testar alguma coisa, ou testar se a página funciona sem scripts. Ou então você pode ter uma situação como uma recente minha.

Eu tive que customizar um plugin do jQuery que faz algumas animações, e aí o HTML da página ficava mudando o tempo todo. Eu precisava customizar o HTML/CSS de vários “instantes” da animação, mas era impossível fazer isso com a animação rodando. Para resolver isso, eu usei o NoScript para interromper os scripts exatamente no trecho da animação que eu precisava mudar o HTML/CSS. Com isso, eu conseguia um HTML estático que eu podia mexer pelo Firebug, e consegui trabalhar tranqüilamente nas customizações que eu precisava fazer.

Conclusão

Deixei algumas opiniões e dicas sobre algumas coisas de desenvolvimento web, mas é óbvio que eu também tenho muita coisa a aprender. Se alguém discordar de alguma opinião minha ou quiser acrescentar sugestões, estejam convidados a participar   Além disso, se alguém tiver mais dicas de extensões do Firefox para desenvolvimento web, eu sempre estou interessado.

O que me intriga é que a Oracle não é tradicionalmente uma empresa de serviços. Ela costuma desenvolver e vender produtos, e a prestação de serviços é feita através de parceiros, como a Concrete por exemplo. Não consegui ter ainda a visão de como essa aquisição vai se encaixar dentro da estratégia da Oracle.

Não sei bem também como será a relação da Oracle com Open Source. A Sun não vinha tendo resultados financeiros muito bons, mas mantinha muitos projetos open source importantes, como o Glassfish, Solaris, MySql, stack SOA e vários projetos Java em geral. Além disso, desempenha um papel muito importante no desenvolvimento de linguagens dinâmicas para a JVM, além do desenvolvimento da própria JVM.

Se em termos de software tenho várias dúvidas, em relação às ofertas de hardware da Sun eu já consigo ter algumas idéias. Um dos principais concorrentes da Oracle é a IBM, que tem um braço bem forte de hardware. Não é raro a IBM ganhar concorrências com a Oracle “dando” o hardware, e vendendo o software. A Oracle não tinha condições de oferecer uma proposta equivalente, mas agora isso será possível.

Além disso, a Sun anunciou recentemente sua oferta de Cloud Computing, que pode ser um mercado que a Oracle quer entrar. Como ela já possui muitas aplicações críticas para empresas, ela pode querer oferecer estas aplicações como serviços, em uma estrutura de Cloud. Posso estar totalmente fora do alvo, mas não duvido que isto seja um objetivo da Oracle para diversificar seu modelo comercial.

Assim como em outras aquisições, muita coisa ainda não está clara, mas já temos vários aspectos para prestar atenção.

No momento atual, temos de 8 a 10 vagas, todas para início imediato e horizonte de longo prazo. Queremos profissionais que tenham paixão por software e auto-motivados, buscando evolução contínua. Profissionais deste perfil encontrarão um ambiente ótimo para seu crescimento dentro da Concrete. A descrição técnica dos perfis pode ser vista a seguir.

Os níveis de experiência são variados, então entre em contato se você se julgar dentro do perfil de profissional que buscamos. Quem quiser mais informações, não deixe de entrar em contato.

Desenvolvedor Java (preferencialmente com experiência em Web e/ou Mobile)

Java SE 5 e/ou 6. Java EE 1.4 e/ou 5.

JPA e/ou Hibernate são bastante desejáveis. Importante conhecer banco de dados relacionais e mapeamento objeto-relacional.

Experiência de uso com alguns dos seguintes application servers: BEA Weblogic 9 ou 10, Jboss AS, Jetty, Apache Tomcat  e Geronimo.

Struts, Spring MVC ou outro framework para web em Java. Boa experiência com Grails, Ruby on Rails ou Django também são válidos, e podem nos interessar mesmo se você não conhecer um framework web Java.

Inglês para leitura e estudo de material técnico.

Desejável

Graduação em Ciência da Computação, Engenharia da Computacão ou Informática

Conhecimento e interesse em outras linguagens de programação é bastante apreciado: Python, Scala, Ruby, Rhino, Javascript, Perl, OCAML, Common Lisp.

Bons conhecimentos de client-side (HTML, CSS, Javascript) são muito positivos.

Conhecimento de plataforma Linux é desejável, mas não obrigatório.

Conhecimento em shellscripting para Unix/ Linux é muito bem-vindo.

Os interessados devem enviar um e-mail com currículo para marcia.cataldi@concretesolutions.com.br com cópia para bruno.pereira@concretesolutions.com.br

Desenvolvedor Java (2 vagas)

Fundamental:

Experiência comprovada de pelo menos 4 anos de trabalho como programador/desenvolvedor de software.

Java EE 5 e 6.

JPA, Hibernate, Struts ou outro framework para web  em Java.

Experiência de uso com alguns dos seguintes application servers: BEA Weblogic 9 ou 10, Jboss AS, Jetty, Apache Tomcat  e Geronimo.

Conhecimento de banco de dados e mapeamento objeto-relacional (desejável).

Inglês para leitura e estudo de material técnico.

Comprometimento, concentração e auto-didatismo são valores extremamente importantes. Argumentação fundamentada .

Desejável

Graduação em Ciência da Computação, Engenharia da Computacão ou Informática

Conhecimento e interesse em outras linguagens de programação é bastante apreciado: Python, Scala, Ruby, Rhino, Javascript, Perl, OCAML, Common Lisp

Conhecimento de plataforma Linux

Conhecimento em shellscripting para Unix/ Linux é bastante desejável.

Os interessados devem enviar um e-mail com currículo para marcia.cataldi@concretesolutions.com.br com cópia para bruno.pereira@concretesolutions.com.br

Na minha opinião, a Sun fez e vem fazendo um excepcional trabalho mantendo a plataforma Java como um todo. O problema todo está no contexto que girou em torno disso.

Em um determinado momento a Sun lutava bastante contra a Microsoft e suas soluções Windows/.NET, e de fato parecia que as empresas seriam adversárias. O que ocorre é que a Sun gastou tantas energias combatendo a Microsoft que não dedicou o esforço necessário para conquistar espaço dentro do próprio mercado Java.

O Glassfish V2 foi o primeiro bom servidor de aplicações da Sun, mas ele chegou bem tarde. Muito antes a BEA e a IBM já tinham um vasto portfólio de produtos Java Enterprise, e servidores de aplicação bem melhores do que o antigo Sun Application Server. Com isso, mesmo com o enorme sucesso da plataforma Java, a Sun não estava muito bem posicionada no mercado de software.

Creio que em decorrência deste primeiro problema (a falta de um bom app server), veio o problema que eu acho o mais grave. Na minha opinião o que fez mais falta à Sun é um bom modelo de serviços em torno da plataforma que ela desenvolveu tão bem. A Sun tem muitos grandes engenheiros, mas não conseguiu traduzir isso em muito lucro com Java. Penso que um modelo de serviços semelhante ao da IBM teria sido adequado à Sun, mas para isso eles precisariam de um portfólio de produtos melhor.

O grande (e bem-sucedido) esforço no desenvolvimento da plataforma Java consumiu energias que poderiam ter sido aplicadas na construção de uma linha de produtos mais rica, e com isso o sucesso do Java acabou drenando muito da saúde da Sun.

Mais recentemente a Sun tentou mudar a sua estratégia, e passou a abraçar ainda mais o modelo open-source. Embora isso tenha sido muito bem recebido pela comunidade de desenvolvedores, não podemos dizer que essa mudança tenha trazido mais sucesso para a empresa.

Eu tenho a clara impressão de que a Sun abraçou este modelo sem ter muita noção do que a esperava, mas talvez a sensação fosse de que não havia uma outra alternativa óbvia. A verdade é que a Sun está há anos lutando, mas sem encontrar a estratégia correta. O modelo de negócios em torno de open source foi mais uma tentativa da empresa, mas não estou vendo muitas perspectivas da Sun conseguir deste modelo as receitas necessárias para cobrir seus custos.

Eu fico triste por essas dificuldades da Sun, pois eles fizeram um excelente trabalho desenvolvendo a plataforma Java, mas isso custou a própria saúde da empresa.

E o que poderá vir em conseqüência? Difícil dizer, mas me parece inevitável que a Sun seja comprada por um player de maior porte, como a HP ou a SAP.

Como a Oracle agora é um concorrente direto da SAP em várias linhas, e a SAP começou a investir em Java, talvez faça sentido que a gigante alemã compre a Sun.

Quanto à HP, seria um movimento muito mais coerente do que a compra da EDS, que ocorreu esse ano. Comprando a Sun, a HP teria a stack completa, com hardware HP, sistema operacional e middleware da Sun, e serviços provenientes da EDS. Isto a deixaria em situação semelhante à da IBM, e acho que faria sentido nesse contexto atual.

Não sei qual será o futuro da Sun, mas sinceramente torço muito para que seja próspero, pois seu legado de contribuições ao cenário mundial de software é valioso demais para que a empresa tenha um final agonizante.

Na Globo.com eu trabalhei muito com open source, e estava acostumado a montar as aplicações a partir de componentes “crus”, em vez de usar ferramentas sofisticadas. Open source faz parte da cultura da empresa, e tínhamos uma boa liberdade de escolha de tecnologias e arquiteturas.

Como falei algumas vezes no passado, nós migramos boa parte da arquitetura legada com EJBs para serviços REST usando por baixo o Jersey, Spring e Ibatis. A produtividade no desenvolvimento de serviços REST me agrada muito, e mesmo alguém que não conheça muito de serviços REST consegue desenvolver um serviço sem tanto esforço.

Agora vou trabalhar mais com serviços SOAP, mas usando ferramentas muito produtivas, como o Aqualogic ESB e o Workshop, entre outros. Essas ferramentas facilitam muito o trabalho oferecendo Abstrações Opacas. Como ainda estou muito ligado ao trabalho com Open Source, eu venho tentando no meu tempo vago encontrar ferramentas open source com a mesma proposta.

Neste momento estou tentando encontrar a maneira mais produtiva de se trabalhar com web services SOAP usando open source. No passado eu desenvolvi serviços com o XFire, com o Axis 2 e com o JAX-WS, mas achei interessante reavaliar as opções existentes atualmente.

Nos últimos dias eu fiz testes com o Axis 2, com o Apache CXF e com o JAX-WS.

Eu não gosto muito do Axis 2. Você até consegue desenvolver serviços rapidamente com ele, mas ele gera um código tão sujo que é muito triste colocar qualquer coisa em produção com ele, sabendo que você vai ter que manter depois aquele código. Além disso, para utilizá-lo você precisa levar nada menos que 51 jars para sua aplicação, o que transforma qualquer aplicação em um mastodonte. Um outro problema dessa lista massiva de dependências é que a chance de uma aplicação pré-existente ter conflitos de dependências com o Axis é grande.

Na prática, eu só utilizaria o Axis 2 (e mesmo assim com má vontade) para desenvolver serviços se fosse numa estrutura como o WSO2 Web Services Application Server, que é um servidor de aplicações “dedicado” a serviços Axis.

O Apache CXF oferece um “front-end” com JAX-WS (que é o mais recomendado) e um “front-end” alternativo, que usa o Aegis Databinding. Por enquanto olhei apenas o front-end com JAX-WS, mas não vi nenhuma vantagem em utilizar o CXF em vez da implementação de referência presente no Glassfish. Se pintar disposição eu darei uma olhada no front-end com Aegis Databinding, mas por enquanto não tenho grandes expectativas em relação a ele não.

Para finalizar, fiz muitos experimentos com a implementação de referência do JAX-WS, embutido no Glassfish V2. A forma de trabalho que achei mais produtiva nestes meus testes foi desenvolvendo com JAX-WS no Netbeans (utilizei a versão 6.5).

Tentei desenvolver a partir de classes Java, e a partir do WSDL, e esta última me trouxe melhores resultados.A melhor forma que achei foi começar desenhando os schemas XML com o editor do Netbeans:

Criei um Complex Type para cada classe de domínio, e 1 Complex Type para o Request de cada operação e 1 Complex Type para o Response de cada operação. Tendo feito isso, criei depois 1 Element para o Request de cada operação e 1 Element para o Response de cada operação. Com o schema XML criado dessa forma, criei em seguida o WSDL, com o editor do Netbeans também:

Na criação do WSDL, coloquei nas mensagens de Request/Response das operações os Elementos declarados no schema XML anterior. É importante prestar atenção nisso. Usando Elementos nas mensagens, você está criando serviços no modelo Document/Literal. Se você colocar nas mensagens um Complex Type diretamente, em vez de colocar um Elemento, você estará criando um serviço no modelo RPC/Literal. Eu particularmente prefiro Document/Literal, e o código gerado pelo JAX-WS neste modelo me agrada mais.

A implementação do serviço com JAX-WS ficou parecida com isso aqui:

package org.brunopereira.cadastro;
import javax.jws.WebService;
import org.brunopereira.schema.cadastroclientes.CadastroClienteRequestType;
import org.brunopereira.schema.cadastroclientes.CadastroClienteResponseType;
import org.brunopereira.schema.cadastroclientes.Cliente;
import org.brunopereira.wsdl.cadastrocliente.CadastroClientePortType;
 
@WebService(serviceName = "CadastroClienteService", portName = "CadastroClientePort",
endpointInterface = "org.brunopereira.wsdl.cadastrocliente.CadastroClientePortType",
targetNamespace = "http://brunopereira.org/wsdl/CadastroCliente",
wsdlLocation = "WEB-INF/wsdl/CadastroCliente/CadastroCliente.wsdl")
public class CadastroCliente implements CadastroClientePortType {
public CadastroClienteResponseType cadastrarCliente(CadastroClienteRequestType request) {
System.out.println("Cadastro de cliente foi invocado!! Será feito o roteamento para o serviço adequado!!");
Cliente cliente = request.getCliente();
CadastroClienteResponseType response = new CadastroClienteResponseType();
response.setCliente(cliente);
return response;
}
}

O código do cliente foi gerado bem facilmente a partir do WSDL também, e ficou bem limpo. O que achei bem fraco foi a parte de teste dos serviços tanto no Netbeans como no Eclipse. No Eclipse você só consegue usar os plugins de teste se você tiver desenvolvido os serviços dentro do Eclipse, o que inviabilizou o meu uso. E o Netbeans tem um suporte que só serve pra HelloWorld, pra aqueles serviços de Calculadora, que você passa uns parâmetros primitivos e recebe um resultado simples. A interface do testador do meu serviço ficou dessa forma:

Dá pra ver que não serve para nada além de um HelloWorld basicão.

Bom, de uma maneira geral, o suporte a Web Services no Netbeans é muito melhor do que no Eclipse, que pra piorar só suporta a criação de serviços com o Axis. Até agora a maneira mais produtiva que encontrei de trabalhar com serviços SOAP foi essa que descrevi. Nos próximos dias olharei o que tem de interessante no projeto Metro e no JBoss ESB. Se encontrar coisas interessantes falarei mais por aqui. Ah, e se alguém tiver dicas para melhorar esta forma de trabalho que descrevi, por favor me avisem, pois estou avaliando muita coisa e não dá tempo de dedicar tanto tempo a cada opção dessas.

The plugin would be great and extremely useful if it worked. Really, I’d love to have this plugin as an everyday tool, helping me deliver software. It offers a very productive way to work with Maven in Eclipse, except that it brakes Eclipse in such an unbearable way that I cannot afford to think about using it anymore.

Initially I was using m2eclipse with an external Maven installation, instead of the embedded one. With this setup, I was facing many (and I mean MANY) NullPointerExceptions doing some Maven stuff in the IDE. It was impossible to work with that much errors, so I tried using the embedded Maven installation.

Initially it seemed like I was gonna be able to work without problems, but I was wrong. Instead of all the NullPointerExceptions, now Eclipse itself would crash hard when I used the POM editor. Adding a dependency, adding a new build plugin. I was frequently having Eclipse crashes doing this stuff.

I first thought that it could be just an issue in the “graphical” POM editor, so I tried using the simple XML editor. The errors kept occuring, and I got mad.

I could live with this problem if my Eclipse crashed 2 or 3 times a day. I’d gladly restart it, and keep working. However, facing Eclipse crashes every 5-10 minutes can make you crazy before you deliver any piece of software.

I am a man of faith, so I’ll try using it with Eclipse Europa and with minimal features, to see if it hangs on. I use this setup at work, and although it doesn’t work perfectly, at least it stands a whole day without crashing.

Maven is such a widespread Java tool. It’s far from unanymous among developers, but it’s a very valuable tool for me. I think it deserves much better tooling support, so I hope this Ganymede mess is fixed someday. But maybe the Eclipse ecosystem got so complex that it’s becoming impossible to keep everything stable.

I’ve tried using Netbeans before, but I couldn’t be nearly as productive as I am with Eclipse. So please Eclipse, please don’t let me down!

What I liked the most about the test was that many questions presented different problems and requirements, and asked me to give the most suitable solution. Besides that, most of the design patterns questions were contextual. Based on a given problem, I had to decide which patterns could help in the design of a good solution for the problem. I liked the fact that these questions made me THINK much more than REMEMBER stuff. There were a few questions focused on specific pattern details, but fortunately they were only a small portion of the exam.

There are many EJB/JPA questions in the exam, but if you’re familiar with the technologies, you should have no problem with them. The questions were not tricky. If you know the main aspects of these technologies, you’ll be just fine.

There were several Web Services questions, actually more than I expected. I liked this, because such knowledge is very important for any enterprise architect, and I’m particularly interested in the subject. I have a reasonable experience with web services, and I thought the questions were not very demanding.

The exam objective that I thought was my weakest was security. I didn’t know much about the JVM Security prior to this exam, and now I’m still no expert, but I did learn a few things.

Overall, I thought this was a nice exam and definitely it was more pleasant than I expected. I had 120 minutes to do the exam, but it took me around 80 minutes to finish it. The SCJP and SCWCD exams were more tiresome than this one. When I finished the exam, I wasn’t sure if I had passed, but the same thing happened to me in the SCJP and SCWCD exams, and I did ok.

There are 64 questions in the exam, and the minimum score to pass is 57% (37 questions). I answered 49 questions correctly, which translated into a 76% score.

Now I must checkout the Part 2 Assignment, and design an application during a 1 year span. I definitely won’t touch anything this year, because I must chill out. I hope Part 2 gives me more pleasure than Part 1, and hopefully I’ll learn a few more things.

If anyone’s planning to take this exam and want to talk about it, feel free to contact me, and I’ll try to help.

Tudo bem, a culpa é minha mesmo. No final do ano passado eu resolvi aproveitar uma das promoções de vouchers com retake da Sun, e comprei não 1, mas 2 vouchers de uma vez. Naquela época eu achava que iria gostar de estudar para as provas de EJB 3 e Web Services.

Bom, ao longo desse ano eu estudei bastante mesmo. E coisas muito legais. Mas em nenhum momento me senti tentado a fazer nenhuma dessas provas, e fui enrolando, enrolando, e meus vouchers vencem dia 30/11. Em setembro eu já sabia que não tinha nenhuma hipótese de eu fazer 2 certificações, então resolvi estudar para a de arquiteto, e usar 1 dos vouchers para a prova teórica, e o outro para a parte prática. E é pra isso que estou estudando, mas como é chato!!!

Para esta prova eu não sabia muito bem que material seguir, então estou lendo o único livro que me pareceu razoável:

Na verdade eu não estou gostando do livro, mas estou lendo alguns tópicos por ele. Os 4 primeiros capítulos falam de aspectos gerais de arquitetura, análise e projeto OO e aplicabilidade da arquitetura Java EE. Eu passei rapidamente por eles, e acho que deve ter sido tão divertido como escutar a “Voz do Brasil”. Teoricamente os assuntos poderiam ser interessantes, mas a exposição é feita de forma tão enfadonha e repetitiva que acho que não consegui obter nada de útil desse conteúdo.

Basicamente eu lia uma porção de coisas que eu já sei, algumas coisas que eu discordo, e alguns devaneios da Sun. É, por exemplo aquele papo insano de que designers podem escrever JSPs… hahahaha! Se eu tentasse ensinar JSP pro designer do meu time ele ia fazer dezenas de caricaturas e montagens minhas no Photoshop, pra eu aprender o que é trabalho de designer

Bom, nesse momento eu estou acabando a parte dedicada a estudar padrões de projeto. Certamente posso dizer que está sendo a melhor parte do estudo, mas me fez refletir um pouco também. Nessa prova são abordados todos os padrões do GoF e todos os Core J2EE Patterns. São 24 padrões do GoF e 22 do Core J2EE Patterns. Uma boa parte eu já conhecia e estou revendo, e outros eu nem conhecia.

Sempre é bom dedicar um tempo para estudar padrões de projeto, mas deveria ser possível filtrar apenas o que interessa. Eu não gosto de Singletons, não gosto de DTOs e não gosto de usar EJBs, então eu já poderia limar facilmente uns 10 padrões dessa lista. Eu gosto bem mais dos patterns do “Patterns of Enterprise Application Architecture (PEAA)”, mas esses infelizmente não estão na prova…

E outra coisa, é fundamental não ficar bitolado nesses patterns. Se você tiver uma overdose de patterns, sua criatividade ficará prejudicada e talvez você siga por um caminho não muito legal só porque existe um pattern para aquilo. Padrões de projeto são interessantes pela possibilidade de te trazer idéias novas para problemas comuns. Mas o importante é que você adquira o know-how e as ferramentas de raciocínio, e pense por si mesmo. Eu já peguei projetos em que parecia que os desenvolvedores estavam procurando problemas para aplicar os patterns, em vez de usar os patterns como idéias para resolver bem um problema que havia surgido. Mais importante do que qualquer padrão de projeto é raciocinar, pensar bem no problema. Rabisque qualquer abobrinha num papel e resolva bem o seu problema com bom software. Ser uma enciclopédia de patterns não faz de ninguém um programador ou arquiteto melhor.

Bom, para finalizar meus rabujos sobre esta prova, devo dizer que estou decepcionado com o que estou absorvendo em minha preparação para ela. Quando eu me preparei para as provas de SCJP e SCWCD, eu nitidamente evoluí como desenvolvedor neste processo. Foi muito válido fazer essas 2 provas e o tempo que dediquei estudando para elas me tornou um desenvolvedor mais eficiente.

Agora, esta prova de SCEA não está me agregando nada até o momento. Eu poderia estar estudando outras coisas mais interessantes e eu não vou ser um arquiteto melhor por ter este título. Talvez a parte prática dessa certificação seja mais legal, mas até agora ela está servindo apenas para eu não desperdiçar meus 2 vouchers que estão expirando.

Será que na prova prática eu posso usar os patterns do PEAA e montar uma arquitetura sem EJBs, sem SOAP, sem JSF e sem DTOs?? Ou será que isso vai ser censurado? Bom, acho que vou pagar pra ver, pelo menos vai ser bem mais divertido!