Minhas impressões – Sun Tech Days 2009/2010 – Dia 1 (08-12-09)

Caros colegas,

Participei na última semana do Sun Tech Days 2009/2010, evento que aconteceu aqui em São Paulo, contando com a presença de grandes engenheiros da Sun e de ícones da comunidade Java do Brasil, e que tive o privilégio de me inscrever por um “golpe de sorte”, pois abriram-se entre o dia 02 e 03 de dezembro 200 inscrições gratuitas do evento, e tive sorte de me inscrever com sucesso 🙂

Vou disponibilizar para vocês agora um resumo de tudo o que aconteceu de acordo com a minha ótica.

Panorama 1: Para chegar até o local…

Para chegar até o local não foi as mil maravilhas no dia 08 de Dezembro…

Na madrugada/dia dessa data em SP choveu demais e tivemos um índice pluviométrico não esperado para o período, totalmente fora dos padrões. Portanto, vias principais congestionadas e o conseqüente problema do transporte público sobrecarregado. Levei quase 2h30 para chegar até o local (saída: 6h50 – chegada: 9h10!). Graças ao Google, GPS e Maps consegui encontrar o local, pois não conhecia a região e este foi meu primeiro Sun Tech Days 🙂

Panorama 2: Após a chegada

Presenciei uma organização/sinalização de locais/palestras/auditórios muito boa, fora a prestatividade dos envolvidos. Para pegar o crachá de conferencista não demorei muito tempo, além do espaço ser abrigador da chuva (acima de tudo…rs). De cara pude comtemplar as presenças do Marcelo Leal (SUN), Carlos Fernando Gonçalves (JavaNoroeste), Jorge Diz, Vinicius Senger e Yara Senger (Globalcode). Andando mais um pouco visualizei o mito James Gosling (!). Esperei mais 10 minutos até poder adentrar ao auditório principal. Nesse “meio tempo” fui visitar os estandes dos expositores, alguns como OpenSolaris, Oracle (é claro), Sun (é claro [2]) e Locaweb.

Após isso adentrei ao auditório principal para a primeira palestra do dia. Para saber sobre todos os palestrantes acesse esse link.

Boas Vindas ao Sun Tech Days – Luiz Fernando Maluf

Para dar as boas vindas ao pessoal do evento, o diretor para a América Latina da Sun Microsystems, Luiz Fernando Maluf, fez uma rápida apresentação mostrando o cenário no qual se encaixam os desenvolvedores Java (e usuários de tecnologias SUN) e como eles estão relacionados com o panorama do mercado, retorno profissional, técnico e financeiro, visando aproveitar as oportunidades que surgem no mercado de hoje: fim da crise, uso e expansão da plataforma Java pela linguagem Java (e outras) e abordagens acerca de novas tecnologias, como TV Digital, por exemplo. Agradeceu aos JUG leaders de comunidades, caravanas e o público do evento que estava presente.

Showcase de Tecnologia: Inspire-se! – Simon Ritter e Angela Caicedo

Antes do “pai do Java” falar sua “visão futurista” da plataforma, Simon Ritter e Angela Caicedo apresentaram alguns exemplos de aplicação das tecnologias Java e Sun do momento.  As implementações e demos foram mostradas para o público.

Simon mostrou como JavaFX pode ser produtivo, gerando animações com figuras ou vídeos, para Web ou Desktop, sem escrever uma linha de código e usando apenas uma “interface amigável de arrastar, soltar, colocar botões e etc.”. No fundo é o JavaFX Platform Suite, que pode ser usado como plugin para ferramentas pagas como Adobe Photoshop, Illustrator e etc. O objetivo era mostrar a produtividade da ferramenta com o objetivo de criar aplicações RIA com pouco “trabalho” (vulgo escrita de código).

Angela Caicedo mostrou uma tecnologia que achei bem interessante: uma “lousa mágica” usando JavaFX. Se trata de uma lousa de vidro, transparente, que por trás dela havia um projetor multimídia (projetando um quadro negro, lousa) com um Wii Remote em cima captando sinais de movimento e toque feitos com uma luva (a qual ia tocando a lousa ou “escrevendo” na mesma). As respostas eram enviadas via bluetooth para um notebook que processava as coordenadas e passava para uma aplicação JavaFX. Com isso era possível relacionar na aplicação o ponto tocado e a significância disso: se era um botão ativado da aplicação que deveria abrir uma paleta de cores, se era para limpar o quadro e etc.

Esse exemplo mostrou a sinergia de algumas tecnologias, além de Java e soluções SUN, que podem gerar modelos inteligentes tão bons quanto o apresentado.

O que está acontecendo com o Java? – James Gosling

Após o showcase James Gosling subiu ao palco para o frissom dos presentes, que puderam comtemplar o “mito”. O overview de James Gosling estava relacionado com as novidades da plataforma Java: mais de um assunto foi abordado, como JavaFX, NetBeans, Glassfish, Java EE6 e etc.

Sobre o Glassfish foi mantido o discurso de ser o servidor de aplicação mais rápido, baixado e performático do mercado (lógico…rs). Foram mostrados “gráficos e informações comprovando”. O mesmo está a muito tempo na versão V2, mas a versão V3 (lançada no dia 10/12) terá suporte a Java EE 6. Gosling fez algumas demos mostrando um menor tempo de redeploy para as aplicações, quase instantâneo, evidenciando uma melhoria na capacidade de criação e manutenabilidade de projetos via Glassfish.

Uma das novidades mostradas pelo mesmo foi o lançamento da JavaStore, que no momento está disponível apenas para o público americano, mas que tem previsão de abrangência maior e sair da fase beta no ano de 2010.

Gosling e Tim Boudreau, especialista em Java Card, fizeram uma demo mostrando o novo suporte para contenção de aplicações Web, http e https, embarcados (um servidor web dentro de um chip!).

O NetBeans foi citado como IDE padrão e está na sua versão 6.8 com suporte a Java EE6 também (Gosling indica “jogar no lixo” o Emacs, Vi e Eclipse, inclusive…rs).

No final da apresentação, e de praxe para eventos da Sun, muitos brindes foram jogados para o público (Camisas da Sun e “Dukes“).

Glassfish V3: O servidor de aplicativos de última geração – Sang Shin

Sang é um velho conhecido do Brasil e de Sun Tech Days: essa foi a sua oitava viagem ao Brasil. Ao olhar para o mesmo sabia que conhecia ele de algum lugar. Voilá! Me veio a lembrança de já ter visto um vídeo no youtube dele “dançando” em uma das edições do Sun Tech Days. Confiram abaixo e tirem suas conclusões…rs.

Alguns pontos a ressaltar da apresentação

• O objetivo do Glassfish V3 é ser o melhor servidor de aplicações do mercado: é compatível com Java EE 6, modularizado (baseado em OSGi e usando Apache Felix), sem limites de containeres e pode rodar containeres Java ou não-Java;
• Glassfish tem suporte a mais de 200 bundles OSGi e podem ser desenvolvidos outros mais;
• Existem 3 tipos de bundles: relacionados a kernel, containeres ou serviços;
• Monitoramento e gerenciamento através de console web e asadmin;
• Facilidades de um ambiente composto por Netbeans 6.8 + Glassfish v3 + Java EE 6, tendo-se desenvolvimento e deploy de aplicações “sem dor” e com muito mais rapidez. O deploy/redeploy automático mantém sessões e informações existentes de sua aplicação, mesmo após restart do servidor.

Os demos executados durante a apresentação, e que embasavam a teoria passada, se encontram no site mantido pelo próprio Sang Shin, o javapassion.com (não acessar java.passion.com…é NSFW…rs.). Eis alguns abaixo:

• Build “Helloworld” OSGi bundle and deploy over Felix OSGi runtime;
• Build “Helloworld” OSGi bundle using Maven bundle plug-in;
• Embeddable GlassFish;
• Update Center (lista de módulos  OSGi instalados, que podem ser instalados e diponíveis para download).

No final de sua apresentação Sang convidou para subir ao palco Jerome Dochez, principal engenheiro da Sun no desenvolvimento do Glassfish, para responder algumas perguntas do público e apresentar o seu overview da nova versão.

Para os interessados, a apresentação de Sang se encontra disponível para download por este link.

JDK7: O futuro da plataforma Java – Simon Ritter

Simon Ritter trouxe um overview para o público com as novidades do JDK7. Os pontos mais relevantes escrevo abaixo:

• JDK7 está pronto, aberto e em constante desenvolvimento pela comunidade, o JSE7 ainda não está pronto e precisa de alguns pontos para ser resolvido (no JCP);
• Sobre a linguagem as mudanças são: annotations on java types (JSR308); Project coin e modularidade (JSR294). Vale lembrar que todas as mudanças estão aprovadas;
• Sobre o core: Projeto Jigsaw (a JSR294 impacta tanto no core quanto na linguagem. Modularidade = Jigsaw); atualização em concorrência e collections (JSR166); novas API’s a respeito de IO (NIO2);
• Suporte a linguagens dinamicas (da vinci machine project) e Garbage G1 são bem importantes e de grande relevância também;
• Uma das mudanças interessantes foi o uso de números binários de forma declarativa (int b = 0b01010101, binary b = 0X09AB), separação de grupos de números long por underscore (Long l = 9_938_827_122) e Switch usando string;
• Gerenciamento automático de recursos: cláusulas try/catch que sempre precisam de um finally para fechar algum recurso (alguma_coisa.close) agora não mais precisam. A JVM gerencia isso (!);
• Multi catch (2 cláusulas de exceção com o mesmo tratamento): talvez possa voltar no JDK7;
• Invoke Dynamic bytecode (JSR292).

Sobre o projeto Jigsaw, em particular:

• O JDK é grande, muito grande (só no JDK6 temos 47 pacotes toplevel e mais de 4000 classes), um problema em relação a tempo de download de pacotes e tempo de startup de algumas aplicações, por se usar bibliotecas demais;
• Há dificuldade de se criar uma “plataforma fina, concisa e leve”, principalmente para dispositivos mobile dos dias de hoje, por exemplo. Para isso foi criado o projeto Jigsaw.
• Já existe um projeto  de OpenJDK baseado no JigSaw;
• A intenção de “código modular” é criar código limpo e bem direcionando para uso, criando uma não dependência de código e uso de bibliotecas entre programadores (commiters) ou código implantado em cliente, não dando propósito a erro. Os módulos terão versionamento, portanto você poderá definir no seu código qual a versão do módulo que você vai querer usar na sua aplicação.

Nessa versão foi bastante pensado nas mudanças a serem feitas, para não cair no erro do assert (java 1.4) e enum  (java 1.5), fato que “quebrou muitos códigos” antigamente. Simon reiterou que “trabalhar mudando e adaptando java é realmente pesado”.

O Lançamento final do JDK está marcado para Setembro de 2010. A plataforma Java tende a fica mais poderosa e abrangente, sem dúvida.

Ginga, Lwuit, JavaDTV e você – Dimas Oliveira & Tamir Shabat

Dimas Oliveira é um grande conhecido da comunidade Java no Brasil quando o assunto é TV Digital. Referência, esteve presente no Profissão Java, Java@TV Digital e OpenTDC. Tamir Shabat, especialista em desenvolvimento com Lwuit e TV Digital foi palestrante no Java@TV Digital. Em todos esses eventos eu estive presente e vocês podem acompanhar os posts pelos links anteriores (o Java@TV Digital ainda hei de escrever). Nesse Sun Tech Days a apresentação de ambos foi um “compilado” do que já tinha sido apresentado nesses eventos. Abaixo algumas informações dessa apresentação:

• Perspectiva de no próximo ano termos 25 milhões de tv’s ligadas ao sinal digital, ou seja, é uma oportunidade palpável e direta para desenvolvedores gerarem aplicações, sendo que no ano que vem o Ginga estará mais maduro e a disponibilidade de set-up-boxes tende a ser maior;
• Histórico da TV Digital não é de hoje: desde 2005 há desenvolvimento;
• Para que já conhece Java é preciso aprender cerca de 8% a mais de Java para desenvolver para TV Digital;
• TV interativa = TV + aplicações (não é simplesmente um browser com acesso a internet na TV);
• Locais de estudo: Forum SBTVD e javatv-developers.

No final da apresentação Tamir mostrou uma demo, usando NetBeans + Lwuit (for TV Digital), de uma aplicação interativa para TV Digital baseada em uma aplicação real que a Rede Globo estaria disposta a usar. Um set-up-box foi usado para demostrar ao vivo os exemplos de interatividade desta aplicação.

Ajuste no desempenho do GC – Simon Ritter

Simon baseou-se para sua apresentação em 4 pontos:

• Opções para a JVM da Sun;
• Garbage collector;
• Garbage first;
• Dicas para tunning do GC.

No início foi exposta a evolução do gerenciamento de recursos, onde antigamente o desenvolvedor era responsável por alocar e desalocar memória (em C: malloc and free; em C++: new and delete). Hoje no Java só é preciso criar os objetos (“new”). A JVM se encarrega de gerenciar a memória (Garbage Collector).

Basicamente temos 3 tipos de opções, quando gerenciamos o GC:

• Standard options:  todas plataformas;
• -X options: não são aplicáveis a todas as plataformas;
• -XX options: -não são aplicáveis a todas as plataformas e podem precisar de privilégios adicionais para usá-las.

Para maiores detalhes, favor consultar a documentação da Sun.

As dicas mais importantes passadas pelo Simon foram:

• multi processos e cores criam objetos novos (todos tentam acessar o eden ao mesmo tempo): Solução: -XX:TLABSize=size-in-bytes ou -XX:ResizeTLAB;
• Serial: indicado para maioria das aplicações para desktop;
• Paralelo: indicado para maquinas com multiplos cores e bastante memória;
• “JVM ergonomics”: comece usando -XX:+UseParallelGC e -XX:+UseAdaptiveSizePolicy;
• Rode a opção -server;
• As opções -XX:MaxGCPauseMillis=n e -XX:GCTimeMillis=n podem performar, mas não são garantidas;

Sobre GC e escolhas de Design:

• Serial (-XX:+UseSerialGC);
• Paralelo (-XX:+UseParallelGC). Para Tuning: -XX:UseParNewGC  e -XX:ParallelGCThreads=n, onde n é o número de CPU’s;
• Concurrent (-XX:+UseConcMarkSweepGC). Para Tuning: -XX:ParallelCMSThreads=n, onde n é um quarto do número de CPU’s ; -XX:CMSInitiatingOccupancyFraction; -XX:+CMSIncrementalMode (off); -XX:+CMSIncrementalDutyCycle=n% (indicado n=50));
• Stop the world;
• Compacting (-XX:+UseParallelOldGC);
• Non compacting;
• Coping.

Sem dúvidas o G1 terá melhorias consideráveis para performance e foram mostrados exemplos de diagramas de alocação de memória com as respectivas legendas. Para saber mais, faça o dowload de um paper da Sun sobre o G1, por esse link.

Programação JavaFX para dispositivos móveis – Angela Caicedo

A apresentação foi bastante técnica e com muitos exemplos de código e demos. Foi uma sessão voltada para desenvolvedores que já conhecem a plataforma JavaFX e a plataforma de desenvolvimento de dispositivos móveis. Em resumo foi passado:

• Introdução a MIDlets, MSA e JavaFX Mobile;
• Conceitos de Mobile RIA , MVC, “stage e scene” e construção de UI’s;
• Migrando aplicações de JavaFX desktop para JavaFX mobile;
• Melhores práticas de performance;
• Mobile samples e adição de mídias;
• Demos.

A idéia central é: existem várias aplicações e modos de aplicar JavaFX para mobile devices, e essa é uma tendencia do mercado.

É preciso saber trabalhar com Java Micro Edition,  MIDP e aplicações e Wireless Toolkit (JavaME SDK). Algumas API’s de Java são essenciais: java.lang e java.io, além das específicas para desenvolvimento mobile: java.microedition. Com isso você consegue criar, editar, compilar, debugar, empacotar, testar e fazer deploy de aplicações (ou seja, tudo…rs).

O ambiente indicado para isso: Netbeans 6.8 + WTK (Wireless Toolkit) 2.5.2/JavaMe SDK 3.0.

Em termos de desenvolvimento:

• Java ME MSA platform (JSR248 – Mobile Service Architechture). Essa é a base e dá suporte a tudo: audio, vídeo, camera, SIP, bluetooth, etc;
• Para construir aplicações  de UI no MSA use API de alto nível (MIDP 2.0 widgets): é fácil, rápido e tem a beleza nativa de UI;
• Há outras API’s disponíveis: JSR226 (SVG Tiny 1.1), JSR184 (3d graphics API) e OpenGL, por exemplo;
• JavaFX mobile cria RIA para mobile;
• Ao invés de trabalhar com aplicações de media (gimp, photoshop), passar as imagens para o MIDP  e só depois portar para o celular, agora você pode usar qualquer ferramenta de media (gimp, photoshop, adobe), passar pelo editor de media do JavaFX e portar isso para JavaFX mobile direto ou trabalhar via Netbeans para depois portar;
• Modelo MVC pode ser implementado: Model (dados e sua lógica), View (Rich UI) e Controller (regras de processamento).

Para maiores detalhes e exemplos: http://javafx.com/samples

Linguagens de criação de scripts: opções para a JVM – Simon Ritter

Finalizando o primeiro dia (ufa!) o lema foi: Languages everywhere. Para o JDK7 é imprescindível saber o poder das linguagens dinâmicas e as mudanças que elas trarão. No caso são 4 que se destacam, ou melhor, são as que realmente são levadas em conta: Groovy, Ruby, Scala e Clojure.

Mas porque o número excessivo de linguagens? Liberdade de escolha e diferentes linguagens resolvem problemas de tipos diferentes. Java + todas elas + JVM : muitos poderes! (domain specific languages).

Abaixo um resumo de cada uma delas:

GROOVY

• Linguagem OO;
• Sintaxe é muito similar a Java, além de ser compacta e concisa;
• Groovy herda classes Java e implementa interfaces Groovy ;
• Permite closure e sobrecarga de operadores (-, +, * ou /), uma “máxima” das linguagens de script;
• Integração com Java via JSR223;
• Use groovy quando precisar de novas features que Java não tem pois os códigos se aproximam muito;
• Meta object protocol – MOP (provê comportamento dinâmico para groovy);
• Livro indicado: Groovy in Action (Dierk Konig).

RUBY

• Imperativo, funcional e reflexivo (suporta muitos paradigmas programacionais);
• Excelente suporte a metaprogramação e reflexão;
• Suporte a continuação (“congela” um ponto e pode voltar a um anterior);
• Tudo em ruby é objeto;
• Tudo é chamada de método (obj.fred é o mesmo que obj.send(:fred));
• Métodos podem ser invocados com ou sem parênteses.

SCALA

• Puramente orientada a OO e tudo é objeto;
• Scala não permite overload do operador true;
• Array index é acessado por () e não [];
• Não tem pré ou pós incremento (i++ ou ++i);
• Arrays são mutáveis (ao contrário de Java);
• Scala não suporta membros staticos (usar singletons no caso!);
• Scala não requer construtor (pode ser definido implicitamente num código anonimo e se quiser fazer overload pode usar this).

CLOJURE

• Modelada em Lisp;
• Linguagem functional;
• Funções são stateless;
• Todos os dados são imutáveis;
• Tem algumas complicações pois é uma linguagem onde se deve conhecer “onde se colocar as chaves, parênteses, ou chaves”.

A “sacada” é estar por dentro do JDK7 que vai dar suporte a linguagens dinâmicas de forma mais aberta (InvokeDynamic bytecode – JSR292).

Conclusão do dia 1

Como não podia deixar de ser, uma “avalanche” de informação…rs. Apesar de já ter visto muitos dos termos apresentados em outros eventos, sempre é bom revê-los por outras pessoas e com outras explicações. O primeiro dia foi de bom grado para mim, até uma camisa da Sun eu ganhei 🙂 . E a volta para casa mais tranqüila…rs.

Amigos leitores, essa foi a primeira parte do meu relato desse evento. Agradeço desde já os que deram uma passada por aqui e publicarei o mais breve possível a parte 2 da história.

Até logo!

Java vs .NET

Uma “eterna” discussão. Mais uma vez prevalece a máxima: qual a melhor? A que melhor se adequa a sua realidade. Um post bem escrito e esclarecedor. Merece leitura. Retirado do site JavaFree.org.

Escrito por Paulo Krieser:

Prosseguindo com a sequência de colunas sobre as comparações entre linguagens de programação, neste artigo vamos comparar o Java ao .NET.

Antes que sigam as críticas, cabe esclarecer que o .NET não é uma linguagem, e sim uma plataforma da Microsoft que permite a utilização de diversas linguagens, como C#, Visual Basic, J# e ASP. Vamos focar então a comparação na construção de aplicações web, utilizando J2EE e o framework ASP NET da Microsoft, que é onde as duas linguagens mais competem.

Comecemos pela questão das licenças de uso, que influenciam diretamente no TCO (para referência aos fatores sendo comparados, consultar na minha coluna Fatores para Escolha da Linguagem de Programação). Apesar da Sun deter a marca Java, a mesma tornou a linguagem open source, permitindo aos usuários efetuar alterações convenientes. Para a plataforma .NET, existem algumas iniciativas free, como os projetos Mono e DotGNU. Porém, para se aproveitar todo o potencial da plataforma, é praticamente necessário se adquirir o servidor Microsoft juntamente com o ambiente de desenvolvimento Visual Studio. Sem estas ferramentas, além de não se aproveitar tudo o que se tem, a velocidade de desenvolvimento fica fortemente prejudicada. Além disto, nada na Microsoft é open source.

No item escalabilidade, as implementações das duas plataformas provêem mecanismos de balanceamento de carga, permitindo habilitar um cluster de máquinas para servir às cargas dos usuários que forem aumentando ao longo do tempo. A grande diferença entre o J2EE e o .NET é que desde que o .NET suporta apenas Win32, um número maior de máquinas se faz necessário, comparando ao J2EE, devido às limitações dos processadores.

Em um fator de extrema importância, como velocidade de desenvolvimento, o .NET leva grande vantagem. A sua IDE proprietária, o Visual Studio, é baseado em RAD (Rapid Application Development), aumentando a agilidade na construção de aplicações. O Visual Studio .NET inclui várias ferramentas interessantes em termos de produtividade, como por exemplo o Web Forms. Estima-se que um projeto criado do zero, leve-se de 10% a 20% menos tempo para entrar em produção quando desenvolvido em .NET.

O Microsoft .NET oferece independência de linguagem, permitindo os componentes serem escritos em VB.NET, C# e J#, por exemplo. Para fazer isto funcionar, o código-fonte nestas diferentes linguagens é traduzido para um código intermediário (análogo aos bytecodes do Java) chamado Microsoft Intermediate Language, abreviado IL. O Common Language Runtime (CLR), análogo ao JRE (Java Runtime Enviroment) do Java, interpreta o IL e traduz em código de máquina.

Com um conjunto de linguagens rodando sobre a plataforma .NET, os desenvolvedores diminuem a habilidade de compartilhar as melhores práticas, diminuindo a assertividade do compartilhamento de informações. Assim, especula-se que um conjunto de linguagens rodando em CLR pode levar a uma combinação de código espaguete que fica difícil de manter. Com a liberdade para se utilizar diversas linguagens, a aplicação torna-se mais complexa, necessitando de experts em diferentes linguagens, o que também faz aumentar o TCO e a entropia do sistema.

As duas tecnologias apresentam uma curva de aprendizado parecida, com a diferença de que o Java possui mais material para aprendizado na internet do que o .NET, que é proprietário e a principal fonte de conteúdo é o MSDN.

Analisando o último quesito, portabilidade, praticamente não há o que comparar. Como já dito na coluna anterior, o Java segue o princípio write once, run anywhere, permitindo executar as aplicações na virtual machine em praticamente qualquer ambiente. O .NET roda apenas no Windows, no seu hardware suportado, e no ambiente .NET. Há algumas implementações adicionais do .NET que rodam em outras plataformas, porém que não permitem o uso de todo o potencial do framework.

Concluindo a análise, a plataforma J2EE, possuindo uma interoperabilidade melhor, permite mais facilmente integrações com o legado através de web services e JCA (Java Connector Architecture) e uma maior facilidade de portabilidade, podendo rodar em qualquer sistema operacional. A grande vantagem do .NET é a sua incrível ferramenta de desenvolvimento, que incrementa bastante a velocidade na construção de aplicações. Porém, esta vantagem apresenta o custo das licenças de uso e de se ter uma plataforma proprietária e fechada, seguindo a iniciativa monopolística da Microsoft.

Para a escolha de qual tecnologia utilizar, deve-se analisar o que já se tem de legado e os skills da equipe que irá trabalhar no projeto, aproveitando os conhecimentos já existentes nas linguagens.

Encontre os bugs perdidos no seu código com Sonar

Artigo proveniente do site Boaglio.com. Uma ferramenta para ser usada em conjunto (DEV & QA), e se prometer o que faz é muito poderosa. Gostaria de poder achar reports de uso para ver as impressões. No momento apresento-lhes o conteúdo da ferramente abaixo:

Sonar é uma sigla para SOund NAvigation and Ranging, ou seja, variação e navegação do som, que é justamente o uso das ondas do som para detectar a presença de objetos estranhos no seu caminho.

Pois bem, é exatamente essa a proposta do projeto opensource Sonar faz, ele vasculha o código dos seus projetos, faz uma boa análise e gera relatórios que podem ser acessados com o seu web browser favorito.

Existem alguns vídeos disponíveis para mostrar o poder da ferramenta, que é interessante assistir enquanto você faz o download.

O seu projeto precisa usar Maven2 para se integrar ao Sonar, e isso é feito magicamente apenas com um único comando:

view source

print?

1.mvn org.codehaus.sonar:sonar-maven-plugin:1.8:sonar

O Sonar vai agrupar o resultado dessa análise e armazenar em um banco de dados.

// //

O interessante também é o recurso chamado Time Machine que permite o acompanhamento da evolução da qualidade do código de seus projetos através de gráficos.

As regras impostas pelas análises são totalmente configuráveis. Se você acha que seu projeto não precisa ter a regra If Stmts Must Use Braces, afinal na sua opinião não há problema em existir comando IF sem as chaves, não tem problema, basta você criar o seu próprio perfil do Sonar e nele desativar e ativar o que quiser. Depois que alterar
o perfil, basta atribuir a esse novo perfil os projetos que desejar e pronto, na próxima análise ou no próximo build, o Sonar usará esse novo perfil.

Veja um exemplo de análise de um projeto:

Depois de tudo feito, o Sonar permite que você exporte todas suas configurações para um arquivo XML e restaure em outra instância qualquer do Sonar.

Uma ótima saída para automatizar isso é usar o Apache Continuum, vejam no blog do Fernando Franceschi como instalar em seu ambiente.

Existem opções pagas, como o Sonar PL/SQL plugin, que custa duas mil libras e com ele você analisa o código Oracle PL/SQL de sua empresa, o que é muito útil para medir a qualidade interna de seus desenvolvedores, ou de um projeto terceirizado.

Os seus projetos só tem a ganhar se adotarem o Maven, o Sonar é um excelente exemplo disso.

8 Boas Práticas Para Melhorar a Escalabilidade

Artigo traduzido, e retirado do InfoQ, voltado a análise de arquitetura, performance e escalabilidade de soluções, com ênfase em banco de dados. .

Wille Faler propõe 8 boas práticas para melhorar desempenho e escalabilidade como diminuir a carga no banco de dados, usar cache, minimizar tráfego na rede, entre outros.

1. Diminua a carga do banco de dados – fique longe do banco de dados o máximo que puder. Isso significa não abrir conexões ou iniciar transações a menos que seja realmente necessário.

2. A diferença que o uso de cache faz – cache diminui significativamente a carga em banco de dados, especialmente em aplicações que somente lêem desse banco. Cache em memória é melhor que cache em disco, que é melhor que um banco de dados relacional ou remoto.

3. Use cache em objetos de baixa granularidade – usar cache em objetos pouco granulares “economiza ciclos de CPU e tempo necessário para consultar n zonas de cache, ao invés de uma somente. Além disso, retornando o grafo do objeto completo economiza tempo ao montar o grafo do objeto.

4. Não armazene estado temporário em memória permanente – evite armazenar dados temporários como dados de sessão para um login em um banco de dados.

O “monstro do estado temporário” é uma besta perigosa. Como regra geral, somente dados de negócio reais, necessários, críticos e prontos para processamento devem ser armazenados de forma permanente (banco de dados, disco); nada mais.

5. Localização, Localização – deixe as coisas perto de onde elas devem ser fornecidas. Em vez de utilizar um balanceador de carga, um servidor web, um servidor de aplicação e um banco de dados, lembre-se que é melhor utilizar um balanceador de carga e um servidor web; e obter parte do conteúdo de uma Rede de Fornecimento de Conteúdo (CDN).

6. Restrinja acesso simultâneo a recursos – se mais de uma requisição acessa o mesmo recurso e executa o mesmo cálculo, é melhor que somente a primeira requisição faça o cálculo até o fim, e as demais requisições somente utilizem o resultado final. Permitir que todas as threads acessem o recurso somente tornará o processo mais lento.

7. Processamento assíncrono e em etapas

Algo que costuma fazer maravilhas para escalabilidade e desempenho é separar um processo de forma que seja assíncrono, dividido em etapas separadas por filas e executadas por um número limitado de threads em cada etapa.

8. Diminua a comunicação na rede – tente fazer com que sua aplicação se comunique o mínimo possível através da rede, pois é um processo muito mais lento do que comunicação em memória.

Steve M. Ciske, comentando sobre o post do Faler, é cauteloso em relação a reduzir a carga do banco de dados:

Eu tomaria cuidado ao diminuir a carga do banco de dados. Já vi pessoas no outro extremo que colocam tudo na camada de aplicação.

Pawel Stradomski considera cache remoto em memória mais rápido do que cache local em disco e Faler concorda com ele:

O uso de cache em um host remoto (via rede) pode ser mais rápido que o uso de cache em um disco local. A leitura dados sequenciais em um disco é por volta de três vezes mais lenta que a leitura na memória de hosts remotos; isso desconsiderando o tempo de busca.

Fonte relacionada: Simon Brown escreveu um artigo sobre princípios de escalabilidade.