RejectConf SP’07 agitando a comunidade Rails no Brasil

Por Fabio Kung em 27/10/07

RejectConf

Em todas as aulas do RR-11 (nosso curso de Ruby on Rails), comento com os alunos a necessidade de agitar um pouco mais a comunidade no Brasil. Recentemente, o meu xará Fabio Akita manifestou a vontade de organizar um evento diferente, nos moldes das RejectConfs que acontecem pelo mundo.

É com muito prazer que anunciamos um evento diferente, com participação aberta para todos: RejectConf SP’07, que vai acontecer no dia 17 de novembro de 2007 no auditório Jacy Monteiro do Instituto de Matemática e Estatística da USP.

O evento sai de graça para todos, mas são apenas 80 vagas. Corra e se inscreva no anúncio original do Akita, onde você também pode manifestar o interesse em palestrar sobre alguma coisa e descobrir como chegar no local.

A Caelum está patrocinando o evento e vai fornecer o coffe-break. Incrível a força da comunidade, não?

Nos vemos por lá!

Novo treinamento: PM-51, Programação Extrema (XP) com Java

Por Sérgio Lopes em 21/10/07

Você já desenvolveu software usando o modelo waterfall? Brigou com o cliente para discutir se aquele requisito fazia ou não parte do contrato? Se perdeu com tantas obrigações do processo unificado? Cansou de escrever todo UML antes de escrever uma única linha de código? E aí alterar todo o UML pois ele não representava aquilo que o cliente queria? Só faz uma release estável de ano em ano?

O mercado está mudando. O gerenciamento de software está mudando. Precisamos de releases  rápidos, código testado, responder rapidamente aos novos requisitos do cliente, não se perder em milhares de páginas de contratos e requisitos. Agilidade.

Curso de XPA Caelum acaba de anunciar a criação de um novo treinamento focado em desenvolvimento ágil: PM-51, Programação Extrema (XP) com Java. A elaboração do treinamento contou com a consultoria de Danilo Sato, mestre em Ciência da Computação pela USP em metodologias ágeis.

As metodologias “tradicionais” de desenvolvimento de software têm causado cada vez mais complicações para as empresas. A abordagem das metodologias ágeis (como Scrum e XP) procura resolver esses problemas focando no resultado final do produto, na rápida resposta às mudanças e na satisfação do cliente. Grandes nomes do desenvolvimento de software e grandes empresas pelo mundo todo (como Google, Yahoo e Microsoft) têm apostado nas metodologias ágeis e têm tido ótimos resultados. A Caelum também abraçou a causa, e utiliza metodologias ágeis em seus projetos e clientes.

Iniciamos o enfoque em metodologias ágeis com o treinamento de Scrum no início desse semestre, com Alexandre Magno. Agora completamos a grade com o treinamento de Extreme Programming (XP), metodologia que é inclusive muito utilizada em conjunto com Scrum.

Neste treinamento de XP abordaremos as práticas da metodologia e as práticas de programação que trazem agilidade ao desenvolvimento de software. Desde tópicos técnicos como testes automatizados, design patterns, refatoração e o processo de build até a integração contínua, programação pareada e o uso de controle de versão. Além disso, falaremos dos valores ágeis, das reuniões diárias, jogo do planejamento, métricas de qualidade de código e tracking para controle geral do processo de desenvolvimento. Diferentemente do treinamento de Scrum, a parte prática deste treinamento possui bastante código e desenvolvimento.

Entre em contato conosco para saber mais ou fazer sua reserva.

A prova de arquiteto SCEA 5.0 parte 1

Por Paulo Silveira em 15/10/07

Agora que já são cinco da Caelum que fizeram a prova beta da certificação Enterprise Architect, focada no Java EE 5.0, creio que possamos fazer um resumo sobre nossas opiniões e impressões sobre a prova, e sobre as diferenças para quem já fez a versão anterior da prova.

Vá preparado: como toda prova beta, você sai esgotado. Leve água e algum chocolate. São 153 questões em 4:30. Uma maratona. A partir do início de 2008 a prova deve oficializar e ter uma duração próxima a 2 horas, e conter cerca de 50 questões. A prova está mais difícil que a anterior: há menos questões triviais e mais textos para ler.

A prova tem algumas surpresas: existem questões que abordam ajax, outras falam sobre unit test, webservices restful, POJOs e algumas até esbarram em AOP! Um grande avanço. Um pouco mais de sorte e quem sabe teríamos perguntas sobre DSLs, DDD, MDD e testes de aceitação. Mas Service Locators, Singletons e Transfer Objects continuam por ali, mesmo a plataforma já tendo injeção de dependências e entity beans serializáveis no Java EE 5.

Não existem mais questões sobre UML. Também não perguntam mais sobre código, interfaces, ciclo de vida e outros detalhes técnicos da API de EJB. Apesar da segurança Java EE ter ganho espaço, criptografia, digests e certificados têm menor peso em relação a prova anterior. SecurityManager e policies aparecem mais.

Design Patterns aparecem bastante, como já acontecia antes. A novidade é que os Core J2EE patterns estão mais presentes, não se restringindo apenas a DAOs. Esses dois livros são leitura obrigatória para a prova, até mesmo o capítulo inicial de Design Patterns tem grande valia: temos perguntas sobre frameworks, herança, encapsulamento e orientação a objetos.

Muitas questões envolviam conhecimento de webservices, em especial sobre o uso das APIs JAXB, JAXP, JAXR, JAX-WS, JAX-RPC. O uso das anotações nos stateless session beans e em pojos também é abordado. Conhecimento básicos sobre SOAP, WSDL, XML também é necessário. Escolher CORBA, Webservices SOAP/WSDL, RMI, Sockets puro ou webservices restful também é cobrado na prova, porém bem menos. Sendo uma prova de arquitetura, esperávamos que esse tipo de decisão tivesse um peso maior do que o conhecimento sobre siglas, procotolos e APIs.

EJB3, JPA e JSF são as tecnologias de destaque. Existe necessidade de usar EJB em um sistema que não necessita de remotabilidade nem transações? Qual a desvantagem do JSF passar os dados via POST? Quando usar JSF e quando optar por servlet + taglibs + EL? Quando usar JPA e quando escolher JDBC direto? Vale lembrar que EJB3, JPA e JSF são as tecnologias que a Sun mais aposta hoje em dia, então a não ser que a questão de fortes indícios do contrário, a provável resposta correta envolve essas tecnologias.

Temos então as questões sobre arquitetura: tiers, layers, performance, avaliability, reliability, etc. Essas questões são sem dúvida as mais confusas. Uma arquitetura X-tiers é mais reliable que uma Y-tier? Esse tipo de questão aparece muito e alguns casos necessitaria de mais algumas (muitas) informações para uma resposta. Um outro tipo de questão de arquitetura aparece e é bem mais interessante: tradeoffs entre tecnologias como Java Web Start, Applets, Ajax ou puro HTML.

A prova é interessante, porém muitas questões continuam quase que subjetivas: dependendo de uma visão mais ampla a resposta poderia ser totalmente diferente. Retirar UML e código já foi um grande avanço, juntamente com a atualização da versão e das tecnologias.

Se você está estudando, alguns links interessantes são o post do Urubatan sobre a prova e esse tópico do fórum no Java Ranch. E você, tem algum link interessante? Comentários sobre a prova?

JustJava 2007, Arquitetura e Caelum

Por Paulo Silveira em 08/10/07

Neste último JustJava palestrei juntamente com o Phillip Calçado a respeito das novidades em relação a arquitetura Java. Aproveitei para extrair conhecimento e idéias do Phillip, que sempre anda muito ligado com as novidades.

DSC00334 DSC00359

Como a apresentação é bem sucinta, vale falar um pouco sobre ela. O intuito foi mostrar as arquiteturas e designs enlatados e que durante muito tempo reinaram por aí, seja na forma de Core J2EE patterns mal aplicados ou no mal uso de clusters. O início da palestra mostra diversos pontos do nosso cotidiano de décadas passadas: destaque para os design patterns ValueObject (na realidade TransferObject), BusinessDelegate e ServiceLocator. Esses design patterns faziam muito sentido quando no J2EE os entity beans não eram serializáveis, e sim acessados remotamente, além de que não existia injeção de dependência.

Apesar do Java EE 5.0 trazer essas novidades, muita gente acaba aplicando esses design patterns sem nenhuma necessidade, o que acaba criando o padrão carinhosamente chamado de BOLOVO pelo Phillip: classes como UsuarioBusinessObject (BO), UsuarioLayerObject (LO), UsuarioValueObject (VO), UsuarioXYZ, etc.

Toda vez que uma classe de domínio é criada em um sistema como esses, suas irmãs também aparecem: BOs, VOs, LOs, XYZs. Utilizar TOs apenas para transportar objetos entre camadas (e não tiers) não faz sentido algum, polui o código e diminui flexibilidade e manutenção. Separar funcionalidade e dados entre BOs e VOs é outro grande problema: onde está a orientação a objetos? Entity beans apenas com getters e setters é um mau sinal.

Passamos por Model Driven Design, dando alguns exemplos com código de Domain Driven Design e de Domain Specific Languages. Por último atacamos SOA, comparando o modelo WSDL/SOAP com o Plain Old XML (POX), além de outras alternativas. Cada forma de webservices, seja SOAP, POX ou JSON, tem seu caso de uso. O que mostramos na palestra foi que não deve-se optar diretamente por SOAP sem antes pensar bem nas necessidades para aquele serviço. O mesmo para os design patterns, práticas e idéias aqui discutidos ou até mesmo criticados: cada um tem seu lugar, não utilize-os apenas porque estão em um livro ou já foram muito usados em prévias arquiteturas.

No final falamos que não há uma arquitetura enlatada que possa resolver todos nossos problemas, e que devemos tomar muito cuidado para não construir um monstro para resolver um pequeno sistema. Cada projeto deve ter sua arquitetura muito bem estudada, com todas as suas particularidades.

Na sexta feira ainda tivemos uma palestra de Lucene apresentada pelo Guilherme Moreira. Aproveitando a ocasião, este domingo ocorreu uma confraternização e reunião da Caelum para discutir idéias, projetos e metas.

DSC00377 DSC00389
Time Caelum Out/2007 faltando 3 pessoas DSC00392

Tivemos novos participantes, os mais novos integrantes e colaboradores da Caelum: Jonas Abreu, Cecília Fernandes, Alexandre Magno, Danilo Sato e Ricardo Nakamura! O time está crescendo. Nas fotos faltam apenas o Carlos Felício, Suellen Campana e o Rafael Consentino.

Internacionalização no código Java

Por Nico Steppat em 02/10/07

Já falamos neste blog sobre i18n, o Fabio postou um artigo como internacionalizar as suas aplicações web usando JSTL.
fmt dá todo suporte, mas fora do ambiente web precisamos procurar outra solução. Por exemplo, numa aplicação swing, ou mesmo web tem casos que precisamos mostrar uma mensagem já internacionalizada. Temos que saber com i18n / L10n também programaticamente fora do contêiner web. Isto é útil no dia-a-dia e também faz parte da certificação SCJP ;)

java.util.Locale

Esta classe influencia fortemente o trabalho de outras classes referente à formatação e internacionalização. Com ela será definida uma região, por exemplo:

Locale ptBr = new Locale("pt""BR")//Locale para o Brasil

Definimos um Locale com o idioma português (iso-code pt) e o país Brasil (iso-code BR). Vocês poderiam reclamar que está óbvio que o Brasil fala português, mas isso não aplica para todos os países, Veja o exemplo:

Locale enCA = new Locale("en","CA");
Locale frCA = new Locale("fr","CA");

Definimos o mesmo pais Canada mas com dois idiomas diferentes (uma região para francês outra para inglês).

Também podemos pegar o Locale da maquina virtual:

Locale vmLocale = Locale.getDefault()//pergunta de certificação

java.text.DateFormat e java.text.NumberFormat

A formatação das duas classes é baseada em um Locale. Elas servem para formatar Data ou Números/Moeda respectivamente. Para receber um instância das classes é preciso usar um dos métodos getInstance() delas:

DateFormat dateFormat = DateFormat.getInstance();
NumberFormat numberFormat = NumberFormat.getInstance();

Mas aonde está o Locale? Nesse caso DateFormat/NumberFormat são baseado no Locale padrão, ou seja o da máquina virtual. Você pode passar o Locale no método, por exemplo:

DateFormat dateFormat = 
  DateFormat.getDateInstance
(DateFormat.FULL, ptBR);
NumberFormat numberFormat = 
  NumberFormat.getNumberInstance
(ptBR);

Agora você recebe uma instância para formatar datas ou numeros referente do Brasil. Existem outros métodos para receber uma instância, aqui algumas variações:

Locale ptBR = new Locale("pt""BR");
DateFormat dateFormat = 
  DateFormat.getDateInstance
(DateFormat.FULL, ptBR);
System.out.println(dateFormat.format(new Date()));

DateFormat timeFormat = 
  DateFormat.getTimeInstance
(DateFormat.MEDIUM, ptBR);
System.out.println(timeFormat.format(new Date()));
        
NumberFormat numberFormat = 
  NumberFormat.getNumberInstance
(ptBR)//para números
System.out.println(numberFormat.format(13.23));
       
NumberFormat moedaFormat = 
  NumberFormat.getCurrencyInstance
(ptBR);  //para moedas
System.out.println(moedaFormat.format(13.23));

Dependo do dia, o resultado seria:

Sexta-feira, 21 de Setembro de 2007
00:51:05
13,23
R$ 13,23

As duas classes, junto com o Locale dão muito poder e não servem somente para formatação, mas também para fazer parsing de uma String para um Date/Number, veja só:

System.out.println(dateFormat.parse(
  
"Sexta-feira, 21 de Setembro de 2007"));
System.out.println(timeFormat.parse("00:58:16"));
System.out.println(numberFormat.parse("13,23"));
System.out.println(moedaFormat.parse("R$ 13,23"));

Imprime (Dependo da data):

Fri Sep 21 00:00:00 BRT 2007
Thu Jan 01 00:58:16 BRT 1970
13.23
13.23

ResourceBundle

A classe ResourceBundle é aquela que acessa seu arquivo de internacionalização. Supondo que temos dois arquivos de propriedades no classpath, um para as mensagens em português, outro para as em alemão e um padrão, com o conteúdo seguinte:

messages_pt_BR.properties
welcome=Bem vindo no Brasil

messages_de_DE.properties
welcome=Hallo in Deutschland

messages.properties
welcome=Welcome in default
logout=Leaving default

A nomenclatura segue o padrão, messages_’iso-code-language’_'iso-code-country’. Parece familiar? Para carregar o arquivo “messages” baseada na Locale pt-BR basta usar:

Locale ptBR = new Locale("pt","BR");
ResourceBundle bundle = ResourceBundle.getBundle("messages", ptBR);
System.out.println(bundle.getString("welcome"));

O resultado será:

Bem vindo no Brasil

Para carregar a mensagem em alemão, só precisamos mudar o Locale. Mas se eu chamo uma mensagem com a chave “logout”? Por exemplo:

System.out.println(bundle.getString("logout"));

O bundle vai procurar de maneira seguinte:

messages_pt_BR.properties //não acha
messages_pt.properties //não acha
messages.properties

e finalmente acha o valor da chave ‘logout’ no arquivo messages.properties e imprime na tela:

Leaving default

MessageFormat

Falta mencionar a classe que ajuda substituir parâmetros na mensagem.

String mensagemParametrizada = "Isto foi um blog sobre {0} e {1}.";
String mensagem =
  MessageFormat.format
(mensagemParametrizada, "i18n""formatação");
System.out.println(mensagem);

Imprime:

Isto foi um blog sobre i18n e formatação.