NetBeans Platform na Mundo Java nº 29

Este mês saiu nas bancas a revista Mundo Java nº29, um artigo meu sobre a plataforma NetBeans, expliquei as principais classes e funcionalidades, e no final apresentei um tutorial prático de como extender o NetBeans e criar poderosos plugins..
Ainda nesta edição na seção "Eu uso" teve a participação mais que especial do Tim Boudreau, um dos engenheiros e pioneiro na criação das primeiras versões do IDE e do nosso querido Bruno Souza o JavaMan..
Eu mesmo traduzi o artigo do Tim, espero que quem leu tenha gostado.
Com a autorização do Tim, vou publicar o artigo dele na seção "Eu uso", claro, em inglês !!!

I work on the NetBeans Platform. Probably the most gratifying thing about that work is to see how it is used - anybody who creates software wants to see it used - it is what gives our work meaning. In the simplest view, what the NetBeans Platform does is solve problems. I believe in writing software that can be finished. That is, you write something that is solid and right and works and then you can leave it alone and move on to the next problem. The modular nature of NetBeans - indeed, the module system itself - makes it easier to build software out of a lot of libraries each of which does one thing well - and guarantee system integrity at runtime. It solves the DLL hell problem for once and for all, and in the process creates design patterns that are ideal for distributed development - how do you build software created by a large community and minimize the risks that changes to one part of the system will break another? The core beauty of NetBeans is the module system.

But what amazes me more is what people do on top of it. Let's take one case-in-point: Nokia. If you are a mobile service provider, such as Tim in Brazil (no relation :-)), and you buy your hardware from Nokia (your transmitters, the things that make a mobile phone network work), you will need some software to manage that network. If you are buying that hardware from Nokia, you get an application for managing your network. But it's not just one applications - it is many applications and one at the same time. They have used the NetBeans Platform plus Java WebStart technology together in an incredibly innovative way - and because Nokia contributed WebStart support to NetBeans, you can do the same thing for your applications.

Java WebStart is a technology that lets you launch a Java desktop application by clicking a URL. Anybody who has installed Sun's Java has Java WebStart. It's not wildly popular yet, but it is an incredible technology for improving the experience people have with internet-based applications. Why? Because there is only one copy of the software. I once visited a company - actually a software development organization for a state in the U.S. They asked us: "Can you please release new versions less often? Every time you have a new version, some guy has to walk around with a CD-ROM and visit 350 workstations and install it!"

That's crazy, and Java WebStart offers the solution. You click a URL and a desktop application starts - all the benefits of centralized management that you get from web applications, but it's a real desktop application. And when you download a new version, you don't download all the bits - only a diff between what was and what is. It's a darned cool technology.

Now put that together with a modular system like NetBeans, where an application discovers its parts during startup.

With Nokia's NetBeans-based software, it works like this: Imagine you work for a telecom in the mobile phone space. There are a lot of different jobs you might be doing: Some people monitor the network for problems. Some people dispatch physical repair trucks to go fix things. So, if you are using this software, well, you start it by clicking a link on the web. And to even see the link, you had to log in, so the system knows who you are and what you need.

So what happens? You click the link. The server knows who you are and what your job is. The result is that you start up one application - but it is an application with many faces. The server gives you an application which contains those modules you need to do your job - it will be a different set of modules depending on what you do and what you need access to.

Now think about what this does for the people who write this software! In a modular system, you usually do UI in one module and back-end logic in another. The result of all this is that the users have a better experience - they get a UI tailored for their job; and the developers get a better experience: 1. They can write back end logic once and share it for all possible cases, and 2. They don't have to write multiple applications that do variations on the same thing, and that saves a lot of time.

Anybody who is doing a large-scale desktop application should consider the NetBeans Platform; anybody who is considering a suite of related programs that share some logic and diverge in UI would be insane not to consider using it.

I am, of course, biased - I have worked on the NetBeans Platform. The criteria for people who could benefit from it are clear and hard to argue with:
- Anybody doing a multi-window desktop application
- Anybody writing a desktop application that needs to save state on shutdown
- Anybody writing an application with a concept of selection that determines action enablement or similar
- Particularly anybody writing several related applications that share some logic

We've worked very hard to make it easy to try the NetBeans Platform for your application. If you fit, even remotely, into any of the categories above, you could save time, money and effort with it - give it a look.

-Tim Boudreau, 16/12/07

Um agradecimento especial para o Bruno Souza por ter aceitado o convite, para o Tim Boudreau, para o Guapo e o Eduardo Guerra da Mundo Java que vem lutando para manter esta revista com um alto padrão, e claro para você leitor !!!

Se você se interessa por aplicações desktop e tem interesse em saber como funciona a arquitetura por trás do IDE NetBeans, compre essa revista, além deste artigo você vai encontrar nesta edição os seguintes temas..

• Desenvolvendo aplicações desktop ricas na Plataforma NetBeans.
• Animações 2D em JavaFX na prática.
• Binding, Componentes, Customizados e Template de Telas no SwingBeans 1.2.
• Click Framework.
• Acesso a Serviços Multimídia em Java ME com SIP-API e IMS.
• Tendências em foco: Java e o Mundo Web.
• RSS dinâmico, rápido e fácil com ROME e STRUTS 2
• Escolhendo uma ferramenta Case Gratuita para modelagem UML.
• Modelando Transações de Facade a AspectJ.
• De olho no mercado: Educação continuada de um Desenvolvedor
• Mundo OO: O Ciclo Ágil de um Dia

E mais , você leva de graça um Poster Mundo Java: Resumão SCJP- Parte III

Diversão Garantida !!!

Sai resultado da competição de Blog do NetBeans

A lista do vencedores saiu no dia 12 deste mês, foram aproximadamente 300 blogs de vários países competindo entre si, e para a minha felicidade acabei sendo um dos ganhadores, na verdade o único do Brazil, ou pelo menos o único que blogou em português, agora é só ver o que posso fazer com os U$500,00 dólares em vale presente e ir para o abraço.

Países que participaram

Australia, Canada, China, Denmark, France, Germany, India, Indonesia, Israel, Italy, Japan, Korea, Mexico, Poland, Russia, Spain, Sweden, Switzerland, Thailand, the United Kingdom, Taiwan, Argentina, Finland, Norway, Malaysia, South Africa, Bulgaria, Hungary, Chile, Turkey, Sri Lanka, Peru, Romania, Austria, New Zealand, Egypt, Panama, Brazil and the United States.

Segue a lista dos vencedores:

Winners of $500 American Express Gift Certificates

Name	Language	Blog Entry
Matthew Nuzum	English	Netbeans 6.1 spanks Eclipse and challenges Visual Studio
Patrick Julien	English	NetBeans 6.1: The Best just got Better
Ding Liang	Chinese	About NetBeans
Diego Silva	Spanish	JavaScript en NetBeans 6.1
Wagner Roberto dos Santos	Portuguese	O que podemos esperar do NetBeans 6.1 ?
Pat Coleman	English	Can NetBeans create a code-less P2P app?
James Eliyezar	English	Subversion and NetBeans - A quick start guide
Junji Takakura	Japanese	NetBeans 6.1 RC to use PHP
Jacek Laskowski	Polish	NetBeans IDE 6.1 - Spring Framework Support
Joshua van Aalst	English	NetBeans 6.1 A Delight To Use

Um agradecimento especial para a equipe de tradução, ao SOUJava, a Janice Campbell e a você leitor do blog.

A lista completa dos competidores você acha aqui http://www.netbeans.org/competition/blog-contest-posts.html

[EJB 3.1] Novidades na especificação - Parte 2

Continuando o artigo sobre as novidades na Especificação EJB 3.1, nesta segunda parte vamos abordar o invoções assíncronas e EJB sem interface.

Na nova especificação um cliente pode invocar um session bean de maneira síncrona ou assíncrona. Invocações assíncronas que é a novidade nos permite efetuar uma chamada a um método remoto (assíncrono) e não precisamos esperar o seu retorno, neste caso a assinatura do método deve ser void, ou o método pode retornar um objeto Future que retorna o resultado para o cliente após o processamento, o que permite verificar as exceções ou até mesmo cancelar a invocação ao método no meio da execução.

Exemplo:

@Asynchronous
public Future executarMetodo() {
String resultado = "Executando Método";
return new AsyncResult(resultado);
}

Outra novidade é o que todos já esperavam "O Fim das Interfaces", ou pelo menos agora elas são opcionais. Antes que alguém se empolgue é bom deixar claro que isso só funciona para objetos LOCAIS, ou seja, o cliente que irá chamar o método deve estar na mesma JVM. :-(Na verdade um session bean sem interface é uma variação do EJB local, mas expõe os métodos públicos da classe bean sem utilizar uma interface de negócio separada.
A referência para o Bean sem interface pode ser passada como um parâmetro, como valor de retorno de qualquer interface de negócio local ou como método de uma classe ejb sem interface.
A implementação do contêiner para Beans sem interface é o mesmo que nós fazemos quando acessamos um método qualquer de uma classe qualquer pela referência, o método de negócio da instancia do session bean e seus interceptors são invocados conforme a necessidade.
Somente os métodos públicos da classe bean (e qualquer super-classe) pode ser invocado através do Bean sem interface. Qualquer tentativa de invocação a métodos com modificadores de acessos diferente de público, irá lançar um javax.ejb.EJBException.
Vejamos a evolução da especificação EJB, dando o mesmo exemplo nas versões 2.1, 3.0 e finalmente 3.1.

Versão 2.*

Até a versão 2.* a comunidade reclamava muito da complexidade dos EJBs, para a criação de um método simples era preciso criar as interfaces (remota e local), a interface home e finalmente a classe de negócio...

Interface Local

import javax.ejb.EJBLocalObject;

public interface SayHelloRemote extends EJBLocalObject{
public void hello();
}

Interface Home

import javax.ejb.CreateException;
import javax.ejb.EJBLocalHome;

public interface SayHelloHome extends EJBLocalHome {
SayHello create() throws CreateException;
}

Session Bean

import javax.ejb.SessionBean;
import javax.ejb.SessionContext;

public class SayHelloBean implements SessionBean {
public void sayHello() {
System.out.println("Hello");
}

public SayHelloBean() {}
public void ejbCreate() {}
public void ejbRemove() {}
public void ejbActivate() {}
public void ejbPassivate() {}
public void setSessionContext(SessionContext sc) {}
}

Cliente Session Bean 2.1

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;

public class SayHelloClient {
public static void main(String[] args) {
try {
Context initial = new InitialContext();
Context myEnv = (Context)initial.lookup("java:comp/env");
Object objref = myEnv.lookup("ejb/SayHello");
SayHelloHome home = (SayHelloHome) PortableRemoteObject.narrow(objref,
SayHelloHome.class);
SayHello papagaio = home.create();
papagaio.sayHello();
papagaio.remove();
System.exit(0);
} catch (Exception ex) {
ex.printStackTrace();
}
}
}

Versão 3.0

Vemos que até a versão 2.1 era muito trabalho criar um simples Hello World com EJB, a Sun vendo que o EJB estava perdendo espaço para frameworks comunitários, como Hibernate para persistência e outras alternativas para Session Beans, decidiu fazer uma mudança radical na especificação, descontinuando os Entity Beans e apresentando o JPA, e tirando a obrigatoriedade de criar a classe Home, eliminando a criação de deployment descriptors, usando e abusando da IoC com o uso extensivo de annotations. A especificação facilitou muito o desenvolvimento e a especificação EJB voltou a ser o supra sumo do Java, vejamos um exemplo

Interface de Negócio Local

import javax.ejb.Local;

@Local
public interface SayHelloLocal {
void hello();
}

Session Bean

import javax.ejb.Stateless;

@Stateless
public class SayHelloBean implements SayHelloRemote, SayHelloLocal{
public void hello() {
System.out.println("Hello");
}
}

Cliente que executa o EJB

public class SayHelloClient {
private static Properties prop = new Properties();
private static Context c;
public SayHelloClient(){
prop.put("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
prop.put("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");
prop.put("java.naming.provider.url","localhost");
}
public static void main(String[] args) {
SayHelloClient main = new SayHelloClient();
SayHelloRemote remote = main.lookupSayHelloBean();
remote.sayHello();
}
private SayHelloRemote lookupSayHelloBean() {
try {
c = new InitialContext(prop);
return (SayHelloRemote) c.lookup("SayHelloBean/remote");
} catch (NamingException ne) {
throw new RuntimeException(ne);
}
}
}

Versão 3.1 Draft

Com a eliminação da classe home não precisamos mais fazer o narrow no código cliente. Agora basta efetuar um lookup na classe Bean.

Classe de implementação de negócio
// Sem Interfaces Remota ou Local

import javax.ejb.Stateless;

@Stateless
public class SayHelloBean implements SayHelloRemote, SayHelloLocal{
public void hello() {
System.out.println("Hello");
}
}

Cliente que executa o EJB

public class SayHelloClient {
// Se o cliente estiver no conteiner, Injeção nele !!!
// Veja que estamos referenciando ao session bean
// SayHelloBean e não SayHelloRemote.
@EJB SayHelloBean falaAi;
@Resource SessionContext c;
public SayHelloClient(){}
public static void main(String[] args) {
falaAi.hello();
SayHelloClient main = new SayHelloClient();
SayHelloBean sayAgain = main.lookupSayHelloBean();
sayAgain.hello();
}

// Ou podemos fazer via JNDI
private SayHelloRemote lookupSayHelloBean() {
try {
return (SayHelloBean) c.lookup("sayHello");
} catch (NamingException ne) {
throw new RuntimeException(ne);
}
}
}

Podemos observar que esta muito mais simples criar EJBs, sem as interfaces o código fica muito mais limpo e temos uma programação muito próximo de objetos POJO, entretanto, por motivos já conhecidos não é possível instanciar um objeto com o operador new, somente via injeção ou jndi. Para a especificação 2.1 por exemplo, tínhamos que criar 4 objetos para um simples hello world (local), na especificação 3.0 não é obrigatório implementar a interface SessionBean na classe session bean ou a interface Serializable, assim como as classes Interceptors. Viva a injeção de dependência !!!
Veja que ainda precisamos de 3 objetos (sai a interface home) mas o processo já simplifica com a entrada das annotations. Agora na versão 3.1 foi eliminada a necessidade de interfaces (lembre-se, apenas para objetos locais)..
Para criar um EJB sem utilizar a interface, ela deve seguir algumas seguintes regras, ela deve expor os métodos sem interface via definição de classe ou pelo deployment descriptor. E ... :

• Se o bean não expor nenhuma outra interface(s) e não implementar nenhuma interface, então o bean define uma EJB sem interface.

• As seguintes interfaces são excluídas quando implementamos um EJB sem interface : java.io.Serializable, java.io.Externalizable; E qualquer outra interface definida no pacote javax.ejb.
• Todos os métodos da classe bean e qualquer superclasse são expostos como métodos de negócios através de um bean sem interface. E isto inclui os métodos de callback (muito cuidado !!!).
• Os métodos expostos da classe bean sem interface não devem lançar a exceção java.rmi.RemoteException.
  

Ainda tem várias coisas legais para discutir, provavelmente será possível rodar EJB no TomCat :D, com o pacote light do EJB, no próximo post vou cobrir o calendário para o Timer e concorrência !!!

Certified Scrum Master (Scrum Alliance)

Recentemente tirei o certificado de Scrum Master fazendo um treinamento pela TeamWare, quem deu o treinamento foram os americanos Chris Doss e David B. Douglas, e o foco do treinamento é o de efetivamente treinar Scrum Masters.
O papel do Scrum Master é o mesmo de Gerente de Projeto, mais o Scrum Master não tem autoridade sobre o Product Owner ou a Equipe, ele é responsável apenas de seguir o processo Scrum conforme descrito, atuam como um coach , auxiliando o Product Owner e a Equipe a entender melhor como realizar o seu papel dentro do processo.
O treinamento foi totalmente ministrado em inglês e teve uma abordagem altamente prática sendo apresentado vários cases.
O treinamento focou os seguintes pontos:

• Estimativa de esforço / tempo, utilizamos o planning poker.
• Sprint Planning baseado em um case (com um PB já definido), onde fizemos a priorização dos Sprints.
• Execução do Sprint.
• Desenvolvemos nosso próprio modelo de Sprint Backlog.
• Formas de comunicação com o Product Owner.
• Sprint Demos (com direito a criação de protótipos e tudo mais).
• Retrospectivas
• Como buscar feedback.
• Melhores Práticas

Minhas observações:
O curso foi bom, entretanto, acho que deveria estar explícito que para participar deste treinamento, o camarada precisa ter pelo um conhecimento prévio do assunto ou estar trabalhando com a metodologia.
Na minha opinião deveria ter uma prova de conceito para avaliar os conhecimentos do aluno.
Outra coisa, o treinamento como eu disse, é para formar SCRUM MASTERS, o curso não ensina como você pode definir a quantidade de pontos de estória que você pode incluir no seu Sprint. Como posso estimar a velocidade da minha equipe ? Como faço a estimativa de disponibilidade da equipe por Sprint ? Como posso analisar os Sprints anteriores no momento de planejar um novo Sprint ? Não foi explicado qual é a melhor maneira de você montar um taskboard, ou como calcular um gráfico burndown ? Como posso estimar dias VS horas ?
Digo isso para que você saiba que não vai encontrar estes tópicos, se você estiver procurando um curso de como fazer Scrum, eu não recomento este curso, recomendo que você faça um treinamento no mercado.
Enfim, o treinamento foi focado em gestão, e em como o Scrum Master deve se comportar e qual é o seu papel. E acho que o curso cumpriu o seu objetivo.

[EJB 3.1] Novidades na especificação - Parte 1

O mercado brasileiro ainda nem assimilou direito a especificação de EJB 3.0 e a JSR-318 - Enterprise JavaBeans 3.1 já foi aprovado pela maioria dos membros do comit executivo para as especificações SE / EE do Java. O único membro que reprovou a JSR foi a Apache.


Isso porque a Apache Software Foundation diz que a spec lead (SUN) esta em desacordo com a JSPA. O que foi explicado pela própria Sun.

The spec lead of the EJB 3.1 specification has confirmed that the TCK would contain no "field of use restrictions", as originally raised by Apache with regard to another JSR (i.e. the SE TCK licensing). That is a good thing.

However, in the absence of an explicit JSPA rule that would forbid such field-of-use restrictions, we will remain worried that a similar issue might resurface anytime, for any JSR.

Consequently, in the future, for any submitted JSR (by SUNW or not), we will specifically expect the spec lead to provide clear information on that aspect and take the answer in account when casting our vote.

As novidades na especificação 3.1 visou simplificar a já fácil especificação 3.0 dos EJBs, aumento o uso de annotations e consequentemente o uso ioc, conforme segue:

• Uma visão Local simplificada que forneça acesso ao Session Bean sem a necessidade de uma interface de negócio local.

• Empacotamento e o deployment de componentes EJB diretamente de uma arquivo .war sem a necessidade de um ejb-jar.

• Um componente Session Bean Singleton que forneça um acesso fácil para estado compartilhado, assim como callbacks de startup/shutdown da aplicação.

Isso quer dizer que agora temos um novo tipo de Session Bean, diferente de um Session Beans Stateful ou Stateless, o Session Bean Singleton é um componente que é instanciado apenas uma vez por aplicação. Em casos onde o conteiner é distribuído para várias JVMs, cada aplicação irá possuir uma instância de um bean Singleton para cada JVM. O Session Bean Singleton é compartilhado e suporta acessos concorrentes.
Uma vez instanciado, o tempo de duração da instância do Session Bean Singleton é o mesmo do Contêiner onde ele foi criado. O que mantêm o estado entre as invocações do cliente mas o conteiner não é obrigado a preservar o estado do bean em um suposto crash ou shutdown no conteiner. Resumindo, Singleton Session Beans NÃO são passivados (é assim que se traduz ?).
Outra coisa, um Session Bean Singleton pode ser utilizado como um cliente web service. Somente um Session Bean Stateless ou Single podem fornece uma visão cliente de web service.

Eis o ciclo de vida de Singleton Session View.

• O ciclo de vida de um session bean singleton inicia quando o conteiner invoca o método newInstance da classe Session Bean para uma instância do Singleton. A seguir, o conteiner realiza as injeções de dependência especificado pelas anotações na classe bean ou pela DD. O conteiner chama o método callback PostConstruct para o bean, se houver.

• A instancia do SB Singleton esta agora pronta para delegar a chamada do método de negócio para qualquer cliente ou a chamada do conteiner para método callback disparado por timeout.

• Quando a aplicação esta em shutdown, o conteiner invoca o método callback PreDestroy do Singleton, se houver. Isto finaliza o ciclo da instancia do session bean singleton.

Inicialização do Singleton

O conteiner decide o momento de instanciar o bean Singleton. Se o conteiner encontrar a anotação Startup na classe Singleton ou se o deployment descriptor estiver especificado startup na classe bean o conteiner DEVE instanciar durante o startup da aplicação. O exemplo abaixo inicializa a classe Singleton com estado compartilhado:

@Startup
@Singleton
public class SharedBean implements Shared {
private SharedData state;
@PostConstruct
void init() {
// initialize shared data
...
}
...
}

Outra novidade, é a possibilidade de criar uma cadeia de dependência entre múltiplos componentes Singleton em uma aplicação, através da anotação DependsOn.

@Target(value=TYPE)
@Retention(value=RUNTIME)
public @interface DependsOn

Esta anotação é utilizada quando precisamos iniciar uma instancia de um bean Singleton antes de instanciar outro objeto. Se um Singleton precisa invocar outro Singleton a partir do método PostConstruct, não é necessário uma ordenação via metadados (DD). Exemplo:

@Singleton
public class B { ... }
@DependsOn("B")
@Singleton
public class A { ... }

Essa anotação diz para o conteiner para garantir que o Singleton B é inicializado antes do Singleton A.
É possível incluir um ou mais valores no atributo value de DependensOn, onde cada valor especifica o ejb-name do Singleton destino utilizando a mesma sintaxe do atributo beanName() de @EBJ. Exemplo:

@Singleton
public class B { ... }
@Singleton
public class C { ... }
@DependsOn({"B", "C"}) // A só será iniciado após B e C serem iniciados
@Singleton
public class A { ... }

Isso garante que A só será iniciado após B e C serem iniciados. No caso de múltiplos valores, a ordem que os valores foram informados em value não garante a ordem de execução em runtime.

Ex,: Se o Singleton B possui uma dependência na ordenação no Singleton C, é a responsabilidade do Singleton B de capturar o que está explicito em seu metadado. Exemplo:

// 2 componentes Singleton empacotados em ejb-jars diferentes
// mas no mesmo arquivo .ear
// empacotado no arquivo b.jar
@Singleton
public class B { ... }
// packaged in a.jar
@DependsOn("b.jar#B")
@Singleton
public class A { ... }

Isto demonstra o uso do nome totalmente qualificado da sintaxe do ejb-name para referencia ao componente Singleton empacotado em um módulo diferente na mesma aplicação.

Lembra no EJB 3.0 para evitarmos nomes ambíguos

@EJB(beanName="netfeijao-ejb.jar#NetFeijaoEJB")

Em breve vou publicar mais sobre a nova especificação, para saber mais leia o artigo publicado no server-side, e a página da JSR..

1. JSR 318: Enterprise JavaBeans 3.1
2. Artigo na Server Side
   

O que podemos esperar do NetBeans 6.1 ?

Foi lançado recentemente o Release Candidate 1 do novo NetBeans 6.1, ao terminar e instalação, a primeira coisa que pude observar foi o aumento extraordinário de performance em comparação com a versão 6.0, esta aproximadamente 40% mais rápido em performance..

Desempenho

Abaixo segue dois prints mostrando o gerenciador de tarefas com o consumo do NetBeans 6.0 (203.736 K) e o NetBeans RC 1 (170.248 K), ainda o consumo é grande, mas com certeza já é uma grande melhoria.

Consumo de memória no NetBeans 6.0

Consumo de memória no NetBeans 6.1 RC.1

Entre as melhorias foram feitas diversas otimizações para redução do I/O e acesso ao disco, essa é a grande mágica que tornou a resposta muito mais rápida, principalmente em ambientes de rede. Foi alterado também o algoritmo para o parsing incremental no editor Java e JSP, aumentando a velocidade na resposta do auto completion, para este último foram feitas alteração no caching, gerenciamento de memória e nos algoritmos de alteração.
Outro recurso que consumia muito recurso da máquina era o pacote Visual Web, quem baixar a nova versão
irá notar uma grande diferença na abertura das páginas, menor consumo de memórias entre outras melhorias...


Biblioteca Compartilhada

Outra novidade bacana são as novas bibliotecas compartilhadas, antes se eu tinha que compartilhar bibliotecas em um ambiente multi usuário, isso só seria possível se eu criasse um projeto NetBeans Platform e "amarrasse" a biblioteca que criei a um Java SE Library Descriptor, e distruibui-se como um nbm, mas como poucos conhecem as funcionalidades do NetBeans Platform, isso se tornou uma prática pouco comum, na nova versão para utilizar uma biblioteca compartilhada basta no momento da criação do projeto (web, enterprise, java desktop) utilizar a opção "Use Dedicated Folder for Storing Libraries" ao clicar nessa opção, o projeto irá incluir as libraries no classpath.
















Para projetos antigos, é possível incluir as bibliotecas compartilhadas, para isso entre nas propriedades de um projeto, na categoria "Libraries" e clique no botão Browse... em Libraries Folder, basta escolher a pasta onde estão armazenadas as libs e clicar em Next, neste passo (Actions) é possível definir o comportamento das libs armazendas, podemos copiar as os arquivos jar para uma nova pasta de libraries (opção default), podemos utilizar o caminho relativo para os arquivos Jar, podemos utilizar o caminho absoluto para os arquivos Jar, ou utilizar a pasta selecionada mesmo.










































JavaDoc


Outra boa novidade é o suporte as tags do JavaDoc, quem é que nunca tentou o auto complete em um comentário, pois bem , agora isso é possivel.

AutoComplete em JavaDoc para classe

AutoComplete em JavaDoc para método.

Suporte ao MySQL

Desde que a Sun comprou a MySQL o suporte a este banco de dados no NetBeans só vem aumentando, na versão 6.1 já existe uma infra pronta para o MySQL, se você já possui um servidor do MySQL instalado basta registrar o servidor acessando a tab services e clicar com o mouse em cima de Database, e selecionar a opção "Register MySQL Server"(foto abaixo),e preencher o formulário, perceba que é só indicar o caminho da ferramenta de administração do MySql, que é possível dentro do NetBeans abrir e acessar a ferramenta de adminstração, mais facilidades na criação de novos bancos, ...

Registrar um servidor existente e configuração de Admistrator Tool

Editor de JavaScript

Outra ótima novidade são as diversas melhorias no editor de JavaScript, na verdade, todos os beneficios do novo editor do NetBeans 6.0 / 6.1 foram implementados no editor JavaScript, ainda de quebra é disponibilizado a documentação baseada no arquivo javascript.. Perfeito !!


Na nova versão ainda foram disponibilizadas diversas novidades como novos os componentes na biblioteca Ajax (WoodStock), melhorias em Ruby, e finalmente um Suporte ao framework Spring, entre outras novidades..

Baixe a nova versão no site netbeans.org ..

Esse post é para integrar o concurso de blog do NetBeans, no link http://www.netbeans.org/competition/blog-contest.html


Diversão Garantida !!!

L10N no SouJava

No dia 10 de Abril tive o prazer de dar uma palestra no auditório da Globalcode sobre o projeto de L10N que significa Localization, o 10 se refere as dez letras que existe entre a letra L e N.. Jefferson Prestes um dos colaboradores do Projeto e tradução da lista de notícias (newsletter) acabou ajudando bastante nesta apresentação.
No mesmo dia Greg Sporar, deu uma palestra sobre as novidades do NetBeans 6.1 (ainda Beta), sobre performance, sobre um plugin do NetBeans para o IReports, entre outras coisas..
Janice Campbell a Gerente Mundial de programas de tradução escreveu sobre a palestra neste link.
O material da apresentação se encontra no java.net, no projeto do soujava, e pode ser baixado neste link.
Sobre a palestra:
Falamos sobre o projeto de tradução IDE, que desde a versão 5.5 do NetBeans tupiniquim liderada por Michel Graciano, foi totalmente internacionalizada e organizada pela comunidade, ganhando um destaque no cenário internacional sendo considerado um padrão para os outros países em termos de organização e postura.

Benefícios

• Ambiente Acadêmico.

Facilidade no aprendizado para os iniciantes cuja língua nativa seja diferente do inglês.

• Software Governamental

Preferência por ferramentas no idioma oficial.
Muitas vezes sistemas com idioma estrangeiro é vetado.

• NetBeans Platform

Impacto direto, pois a ferramenta traduzida é disponibilizada de graça para as empresas e desenvolvedores da plataforma.

Falamos sobre a tradução da Newsletter e da lista de discussão (nbdiscuss_pt@netbeans.org)

Como Participar

1. Cadastre-se na lista de discussão pt_br@netbeans.org
2. Apresente-se
3. Colabore
4. A Versão 6.1 em breve estará disponível
5. Estamos ansiosos por sua contribuição!

Segue algumas fotos do evento.




No inicio da palestra.


















Sobre o projeto de tradução.



















Jefferson Prestes.




















E Greg Sporar.














As fotos foram cortesia da minha grande amiga Valéria Guimarães Mendonca vulgo "JavaGirl"...

SCRUM - Uma abordagem prática

Metodologias Ágeis vem ganhando um espaço mais do que merecido no meio da comunidade, e vem sendo adotado de forma acelerada por grandes empresas, como Microsoft, Xerox, IBM, etc..
As vezes seguir a risca metodologias como RUP nem sempre é a melhor opção para as empresas que possuem um tempo escasso para entregar o software com qualidade em prazos cada vez mais curtos, foi quando nos dias 11 a 13 de Fevereiro de 2001, caras como Martin Fowler, Kent Beck, Alistair Cockburn, Ward Cunningham e Ken Schwaber se reuniram em resort de ski em Snowbird (Utah) para mudar o rumo do desenvolvimento de software, foi nesta reunião que nasceu o XP, Scrum, DSDM, Crystal, FDD, e outras metodologias que visam "desburocratizar" o desenvolvimento de software, entre as metologias propostas esta o Scrum idealizado por Ken Schwaben, que vem ganhando cada vez mais adeptos.
Esse post é um tutorial prático de SCRUM, para que se interessarem no assunto recomendo o livro Agile Project Management with Scrum de Ken Schwaben
OBS> Esse tutorial é fortemente baseado no documento pdf Scrum And Xp From The Trenches e no livro Agile Project Management with Scrum de Ken Schwaben.

O que é Scrum ? SCRUM é uma metodologia (ou Framework de acordo com o criador Ken Schwaber) onde a espinha dorsal é que chamamos de Sprint. Que nada mais é do uma lista de objetivos ou requisitos bem definidos cujo time de desenvolvimento irá trabalhar focado em um período de 30 dias.

Papéis no Scrum ?

No Scrum existem 3 papéis que devem estar bem definidos, que são:

Product Owner	Scrum Master	Scrum Team
É o "cliente" focal, responsável por reunir todas as mudanças planejadas para o produto e priorizar as funcionalidades possíveis. Administra o Backlog do Produto e assegura que o Scrum Team esta trabalhando com as tarefas certas na perspectiva do negócio.	O Scrum Master lidera o time de desenvolvimento, resolve possíveis impedimentos e trabalha para assegurar que o time possui a ferramentas e condições necessárias para alcançar os objetivos estabelecidos pelo Sprint. Realiza reuniões diárias “Daily Scrum” com o Scrum Team para o acompanhamento das atividades.	São os membros que formam o time de desenvolvedores, designers, consiste de 5 a 9 pessoas. Interagem com o Product Owner para determinar o objetivo do Sprint e priorizar as funcionalidades, e quebrar o Sprint em tarefas detalhadas. O time é auto organizável e tem a responsabilidade conjunta pelos resultados.

	O Product Owner é responsável por compilar todas as requisições e especificações no documento chamado Product Backlog, essas mudanças são referentes ao produto, como novas funções e correções de bugs. As prioridades devem ser feitas durante a criação de cada tarefa.
	Em um período de 30 dias, é feito uma reunião que será definido o Sprint Backlog de acordo com os itens do product backlog levantado pelo Product Owner, ou seja, de acordo com os itens de maior prioridade é criado o Sprint Backlog que a equipe terá a responsabilidade de terminar até o próximo Sprint.
	Uma vez com o Sprint definido, o Scrum Master diariamente faz o “Daily Scrum”, que é uma reunião com o Scrum Team cujo propósito é eliminar qualquer impedimento. Cada integrante deve responder a 3 perguntas: 1º O que você fez desde a ultima reunião ? 2º O que você vai fazer entre esse e a próxima reunião ? 3º Tem algo impedindo você de efetuar a sua tarefa ?

Qual é o critério para decidir a história que será incluída no Sprint ?

* Base da conversa

* Cálculo de Velocidade
Base da conversa, é ideal quando a equipe não possui histórico de sprints, ou seja, para equipes que nunca trabalharam com Scrum e não possuem dados estátiscos para realizar o calculo de velocidade.
A conversa gira em torno dos desenvolvedores, onde o Scrum Master pergunta para cada membro do time quanto tempo uma atividade do Backlog demora para ser desenvolvida (em horas), e com base nisso as horas necessárias para o projeto.
Quando já passou por alguns ciclos com Sprints, é utilizado o Cálculo de Velocidade é uma medida em cima do “total do trabalho feito”, onde cada item recebe um peso de acordo com a sua estimativa inicial.

.

Como estimar a velocidade ?
Resp: A maneira mais simples de estimar a velocidade é verificar o histórico do time. Qual foi a velocidade do time nos últimos Sprints ? Então assumir que a velocidade será a mesma para o último Sprint, mas isso só funciona se o time já tive feito alguns Sprints antes.
Outra maneira de calcular é através de cálculo de recurso. Por exemplo, vamos assumir que estamos planejando um Sprint de 3 semanas (15 dias) com um time de 4 pessoas. O recurso João ficará dois dias de folga, Zezinho apenas 50%, colocando tudo isso no papel ficará:

Recursos	Disponibilidade em dias
Zezinho	7	Esta não é ainda nossa estimativa de velocidade, a nossa unidade de estimativa são os pontos de estória, que no nosso caso corresponde ao “dias de recurso ideal”.
Wagner	15
João	13
Trainee	15
Total	50 Dias de Recurso disponível para este Sprint

Estimamos que a velocidade estimada será menor que 50. Mas quanto menos ? Utilizamos o termo “Fator Foco” para isso:
Fórmula para velocidade estimada do Sprint:
(Dias de Recurso Disponível) * (Fator Foco) = (Velocidade Estimada)
Fator Foco é uma estimativa de como o time esta focado no Projeto. Um fator foco baixo significa que o time espera encontrar vários inconvenientes. A melhor maneira de determinar um Fator Foco concreto é analisando o ultimo Sprint, ou melhor, a média dos últimos Sprints.
Fator Foco do último Sprint:
(Fator Foco) = (Velocidade Atual) .
(Dias de Recurso Disponível)
Velocidade atual é a soma da estimativa inicial de todas as estórias que foram finalizadas no Sprint anterior. Por exemplo, no ultimo Sprint complemos 18 pontos em um time de 3 pessoas, trabalhando por 3 semanas para um total de 45 Dias de Recurso. Vamos calcular o novo Sprint baseado nestes dados, para complicar imagine que chegou mais um recurso (Trainee), que totalizando dá 50 Dias de Recurso com treinamentos, feriados, etc...

Fator Foco do último Sprint:	(40%) =(18 Pontos de estória) (45 Dias de Recurso)
Velocidade Estimada Sprint:	(50 Dias de Recurso) * (40%) = (20 Pontos estória)

Desta maneira a velocidade estimada para o próximo Sprint é de 20 pontos de estória. Isso significa que o time deve adicionar estórias para o Sprint até o mesmo chegar perto de 20 pontos.

Index Cards: O que são ?
As reuniões de planejamento são gastas lidando com estórias do Product Backlog. Fazendo estimativas, priorizando-os, discutindo-os.
Scrum propõe uma maneira muito mais ágil de expor os problemas que serão discutidos que são os Index Cards. Na verdade para cada item do backlog é criado um cartão e estes cartões são expostos em um mural.
EX:

** Estas informações serão as mesmas do Product Backlog que podem ser armazenadas em arquivo Excel

Os cartões deverão conter as seguintes informações **: ID: Identificador único Nome: Descrição curta da estória. Importância: Grau de importância da estória. Ex: 10–50. Alto: Mais importante. Estimativa inicial: Estimativa do time de quanto trabalho é preciso, a medida é feita por pontos de estória que corresponde a “Dias de Recurso” Demonstração:Uma descrição de alto nível de como será feito a demo do Sprint. Observação: Outras informações...

Quebrando estórias em tarefas:
A diferença entre estórias e tarefas, é que estórias são as funções que o Product Owner solicitou e que espera que elas sejam entregues.
Desmembramos as estórias em tarefas unitárias de modo a distribuir as atividades do desenvolvimento da estória para toda a equipe.
Ex:

No nosso exemplo o quadro branco (consulta de clientes) seria a estória (item de Sprint) e os post its amarelos as tarefas deste item de backlog.

Gráfico Burndown de acompanhamento diário.

Na linha vertical, colocamos a quantidade de pontos de estória, que é a quantidade de trabalho que deve ser feito para este Sprint através do cálculo de velocidade por atividade, é a velocidade estimada de todo o Sprint. Na linha horizontal, marcamos o primeiro dia do Sprint, nor exemplo 1º de Augusto, e esperamos terminar este Sprint no dia 19 de Junho, a linha tracejada indica a estimativa de trabalho. A linha azul indica o trabalho realizado, no exemplo o gráfico nos mostra que no dia 16 ainda temos aproximadamente 15 pontos de estória de trabalho para fazer. O gráfico é atualizado diariamente durante o Daily Scrum.

Indicadores:De acordo com o gráfico podemos tomar algumas decisões, e saber diariamente o que esta acontecendo no projeto, se está dentro do prazo, etc...

Dissecando o quadro indicador:

Retrospectiva
Ao final de cada Sprint é ideal a equipe e o Scrum Master e discutir o que cada um achou da Sprint e dar suas opiniões. A idéia central se resume na seguinte pergunta: O que podemos melhorar no próximo Sprint ?
No quadro no exemplo, temos 3 colunas:
1ºBom (Good): Se tivéssemos que fazer outra Sprint, faríamos da mesma maneira.
2ºPoderíamos fazer melhor (Could have been better): Se tivéssemos que fazer outra Sprint, faríamos de maneira diferente..
3º Melhorias (Improvements): Idéias concretas que poderíamos implementar no futuro

Exemplo de um quadro de sugestões / análise:


É possível ainda mesclar Scrum com XP, o que torna o trabalho ainda mais produtivo, em tempo oportuno mostrarei algumas das técnicas utilizadas..