Logo PUJ 2008

O PUJ (Prêmio Universitário Java) 2008 foi realmente sensacional. Foi a segunda versão do prêmio universitário, que teve em 2007.2 a primeira versão com 2 (dois) participantes. Nesta versão foram nada menos que 12 (doze) participantes no prêmio e cada um fez o melhor que pode para que seus projetos de faculdade tivessem um nível alto para o concurso.

As aplicações foram de vários estilos diferentes, desde aplicações desktop com swing a aplicações robustas WEB com Spring, Hibernate e JSF. Vale a pena BAIXAR (Link para todos os trabalhos em um .rar) as aplicações para conferir. O código está o mais fácil e legível possível para poder ser avaliado pelos professores e profissionais do mercado.

Abaixo, seguem 2 (dois) screenshots, um da aplicação vencedora que foi a do Daniel Velente (UNIFOR), onde ele se garantiu mesmo ultilizando a tecnica de busca de melhor caminho através de grafos. Sendo que a aplicação ainda lhe permite ultilizar diversos algoritmos para o cálculo do melhor caminho. Ficou realmente espetacular, mereceu o prêmio. E a outra da minha aplicação, que é um aperfeiçoamento do famoso jogo Pong, um dos jogos mais antigos (talvez o mais) que existe para computador. A idéia era usar OpenGL com Java. E foi mostrado que era possível de se fazer através desse projeto.

ScreenShot 01- Trabalho de Grafos

Aplicação do Daniel Valente

ScreenShot 02 - Jogo do OpenGL (PonGL)

Tela de abertura do Jogo

A parte do Jogo em 3D

Estou anexando os arquivos fonte e também o jogo para os interessados. E indico desde já um site que é excelente  para aprender OpenGL, tanto em Java quanto outras linguagens. NeHe GameDev.

A classificação geral do PUJ está aqui e o Código Fonte com o Jogo Aqui.

Os demais alunos também estão de parabéns e merecem destaque. Citando pelo menos os cinco primeiros (que infelizmente não estou nessa lista):
1- Daniel Valente (UNIFOR)
2- Robson Araújo (CEFET)
3- Pedro Belmiro (UNIFOR)
4- Francisco Barroso (LOURENÇO FILHO)
5- Francisco de Assis (FIC)

O prêmio de primeiro lugar foi incrível. Uma viagem para bélgica com passagem e hospedagem paga. Ainda de quebra, um voucher para certificação java. O segundo foram livros e assinatura da revista Java Magazine, e o terceiro, apenas a assinatura da Java Magazine.

Para o próximo PUJ (2009?) eu aconselho demais a participação de todos os interessados. Fazer um projetinho simples, porém bem estruturado no código, é o que vale.

Aqui no nosso trabalho, o nível dos profissionais é altíssimo. Veja para que usamos os livros de Java que temos na empresa…

Livros de Java servem como suporte pra monitor

A História Real

Isso foi um brincadeira que originou-se a partir da falta de um suporte para o monitor de nosso colega. Então ele colocou temporariamente dois livros para servir como “SUPORTE” ao monitor. O legal é que o livro que ele colocou não era da empresa, e sim de um outro colega de trabalho, que quando viu a situação não acreditou no uso do seu tão estimado livro para tal fim

Enfim, foi um fato engraçado que ocorreu na empresa e todos ficaram dizendo que ele não precisava mais de livros porque se garante demais.

Algo engraçado para mudar o estilo do blog um pouco.

Uma forma simples de se pensar no Desing de sua aplicação, é aplicar o velho termo É UM  e TEM UM. A coisa é simples, porém trás grandes lucros. Vejamos:

É UM

Parte da herança de classes ou implementação de interfaces.
Esse termo, é o mesmo que dizer “A Ferrari é um tipo de Carro” ou “O Carro é um tipo de Veículo”, assim como “Uma moto É UM tipo de Veículo”.

Mas o que isso tem haver?

Digamos que você precisa desenhar um sistema OO para controlar o campeonato brasileiro. A primeira coisa que vem a mente ao falar de fultebol, são os times. Assim:

class Time {

static final NUMBER_OF_PLAYERS_PLAYING = 11;

void comemorarVitoria() {
System.out.println("IIIIIIIUUHHHHHHUUUUUUUUUUUU!!!!!!")
};

}

Agora temos um time que tem um número máximo de 11 jogares em campo e sabe comemorar uma vitória. Especializando um pouco mais nossas classes, podemos agora saber quem são os times que vão jogar.

class Palmeiras extends Time {

}

Assim sendo, temos então a relação que gostaríamos, “O Palmeiras É UM Time”.

Ao se estruturar a aplicação, deve-se pensar nas partes que É UM de alguém e modelalos como tal. Fica fácil imaginar essa dependência pensando se ele É UM do objeto que você quer. Vejamos alguns exemplos:

“Gol É UM Carro” (Mesmo que a Wolks diga que não)
“Cliente É UMA Pessoa”
“Coca_Cola É UM Refrigerante”
“Tomate É UMA Fruta” (Para não se confundir)
e assim segue…

Todas essas associações, são feitas através da herança que existe entre os objetos.

Certo, entendi porque É UM, mas e quando é que ele tem um?

TEM UM

Um objeto TEM UM, quando ele utiliza o outro objeto. Ou seja, ocorre quando o objeto que TEM UM, possui uma referência a uma instância de outro objeto.

Continuando o Desing de nosso sitema do Campeonato Brasileiro, vejamos então, o Palmeira É UM Time, mas ele também TEM UM Técnico.

class Tecnico {
String nome;
Date inicioDaCarreira;
int numeroDeCampeonatosGanhos;
// get's e set's
}

class Palmeiras extends Time {
Tecnico tecnico;
}

O código acima demostra bem, o relacionamento TEM UM. O Palmeiras TEM UM Tecnico. O código acima ainda poderia ser melhorado, colocando-se o Tecnico na superclasse Time, pois todo Time TEM UM Tecnico. Porém, apenas para fins didáticos, foi que fiz como está.

Um mal design seria fazer algo parecido com isso:

class Tecnico extends Time {
String nome;
Date inicioDaCarreira;
int numeroDeCampeonatosGanhos;
// get's e set's
}

class Palmeiras extends Tecnico {

}

No final das contas o Palmeiras ainda É UM Time, porém o Tecnico NÃO É UM Time, por isso ele não deve extender de Time, e muito menos o Palmeiras NÃO É UM Tecnico, ele também não deve extender de Tecnico.

Você pode estar imaginando, “Quem seria louco o bastante para fazer algo parecido com isso?”. Infelizmente, como dito acima, muitos programadores hoje, que aprendem programação “por demanda”, acabam cometendo erros primordiais simplesmente por não conhecerem as formas de design simples de aplicações OO. Ou ainda programadores que veem de outras linguagens estruturais, e tem dificuldade de pensar em sistemas verdadeiramente OO.

É UM e TEM UM são velhos conhecidos dos Desings de Sistemas OO, e fazem uma diferença imensa no momento de pensar a estrutura da aplicação.

Dependências

Netbeans IDE 6.0 (ou qualquer IDE que você ache melhor, sabendo fazer as devidas alterações)

Tomcat 6.0.14 (ou outro container web JEE 5)

“Basicamente só esses dois resolvem, pois o Netbeans já tras as bibliotecas necessárias ao JSF”

Iniciando

Na aba de projetos do netbeans (Projects), clique com o botão direito do mouse e escolha, New Project. Depois em Web -> Web Application. Dê o nome para seu projeto e abaixo selecione o container Tomcat 6.0.14. Clique Next. Na tela de seleção do framework, escolha JavaServer Faces somente. Finish.

Implementando

O Netbeans criou para você uma nova tela jsp com um HelloWord em JSF. Vamos modificar as coisas um pouco.

O Netbeans criou seu web.xml e o faces-config.xml já configurados para rodar o JSF. Estou disponibilizando os fontes, para uma idéia real do que está sendo feito por trás. Vamos lá..

Estrutura de diretório:
[Projeto]
-web
-WEB-INF
-web.xml

<context-param>
<param-name>com.sun.faces.verifyObjects</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>com.sun.faces.validateXml</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>0</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/faces/*</url-pattern> <!–- Altere essa linha para [ <url-pattern>*.jsf</url-pattern> ] -–>
</servlet-mapping>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>

Estamos declarando um servlet chamado de Faces Servlet que está sendo mapeado por *.jsf. Isso quer dizer, que todo arquivo chamado com nome_qualquer.jsf, será carregado pelo servlet do jsf. Esse é o servlet que faz todo controle do JSF em nossas aplicações.

O outro arquivo que o Netbeans já criou e configurou para nós foi o faces-config.xml, que contém a estrutura e mappeamento dos nossos BackingBeans. Ele é o arquivo mais importante para uma aplicação JSF, pois também contém as regras de navegação da aplicação e várias outras coisas.

O faces-config.xml fica no mesmo diretório do web.xml, e sua estrutura está como abaixo:

<?xml version='1.0' encoding='UTF-8'?>

<faces-config xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd"
version="1.2">

</faces-config>

Perceba que não existe ainda nenhuma configuração especial dentro do arquivo, pois nenhuma regra foi criada ainda.

Um outro arquivo criado foi o welcomeJSF.jsp que contém duas tags JSF. A primeira é a <f:view /> que informa ao JSF onde começa o arquivo para o jsf e onde termina. Ou seja, ele só reconhecerá as tags e atributos JSF que estiverem dentro da view. E a outra tag é a <h:outputText />, que é apenas uma saída de texto, onde o valor da saída é expresso pelo value=”".

Vamos começar a fazer as coisas a nosso modo realmente. Altere o arquivo welcomeJSF.jsp para o seguinte (lembrando que a parte que não é apresentada, não sofrerá modificações):

welcomeJSF.jsp

<f:view>
<h:form id="formLogin">
<h:messages />
<br />
<h:outputText value="Login" />
<h:inputText value="#{loginBean.login}" />
<br />
<h:outputText value="Senha" />
<h:inputText value="#{loginBean.senha}" />
<br />
<h:commandButton action="#{loginBean.logar}" value="Entrar no Sistema" />
</h:form>
</f:view>

No código acima estamos fazendo uma pequeno formulário de login, bem simples. Onde o primeiro dado que é soliciado do usuário é o login, e logo após sua senha. Seria uma tela básica de login em um sistema qualquer.

Usamos dois outputText que nós já conhecemos e dois inputText que são entradas de texto. No final, geram inputs html assim: <input type=”text” value=”Valor que vier do backingBean” name=”aleatorio” />. E também usamos o h:commandButton que gera um botão html com uma ação definida pelo método chamado no action. Perceba que definimos um, <h:messages />. Ele é responsável por exibir mensagens jsf, como erros de validação, erros de conversão, mensagens que definimos de alertas, como abaixo será mostrado.
Perceba que também estamos fazendo referência a um backingBean através do value e do action do botão. Porém ainda não criamos esse backingBean. Mas o que são backingBeans?

BackingBeans: Como o próprio nome já expressa, são beans, ou classes java (bean), que ficam por trás da view, ou da página jsf. Eles são diretamente ligados com a visão da aplicação jsf, onde são definidos atributos (exemplo o e-mail e a senha) e também são definidos métodos (como o logar do botão de entrar no sistema). Eles são a base para uma página jsf.

Vamos então desenvolver nosso backingBean para entendermos como funciona essa comunicação entre a visão jsf e a classe java “por trás”.

LoginBean.java

public class LoginBean {

private String login;
private String senha;

// get's e set's

public String logar() {
if (login.equals("paulojr")) {
if (senha.equals("123")) {
return "autorizado";
}
}
FacesContext.getCurrentInstance()
.addMessage("erro", new FacesMessage("Login não autorizado!"));
return null;
}

}

Algumas explicações sobre nosso backingBean.
Nossa visão só consegue ler propriedades que possuam métodos acessores (get’s e set’s). É por esses métodos que o JSF procura na propriedade <h:inputText value=”#{loginBean.login} />.
O método logar() é invocado pelo commandButton, que tem um retorno do tipo String. Esse retorno informa ao JSF para que página ele deve direcionar o usuário. Agora é onde entra nosso mapeamento.

Após criado nosso BackingBean (LoginBean.java), vamos configurar para fazer o JSF conhecer nosso BackingBean.
Abra o arquivo faces-config.xml e adicione as seguintes linhas:

faces-config.xml

<managed-bean>
<managed-bean-name>loginBean</managed-bean-name>
<managed-bean-class>exemplo.LoginBean</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
<navigation-rule>
<from-view-id>/welcomeJSF.jsp</from-view-id>
<navigation-case>
<from-outcome>autorizado</from-outcome>
<to-view-id>/autenticado.jsp</to-view-id>
<redirect/>
</navigation-case>
</navigation-rule>

A tag <managed-bean> é o mapeamento da nossa classe para a visão, onde usamos algo do tipo <inputText value=”#{loginBean.login}” />. O <managed-bean-name> faz referência ao nome que será usado na visão. O <managed-bean-class> faz referência a classe mapeada com seu respectivo pacote, e o <managed-bean-scope> é o escopo da aplicação, que pode ser “request”, “session” e “application”. (Em outro artigo poderei detalhar mais sobre o escopo).

As regras de navegação, são marcadas pelo <navigation-rule>, que diz: Se eu estiver em /welcomeJSF.jsp e receber a String autorizado, quero ir para /autenticado.jsp.
A ultima tag <redirect />, informa ao jsf que o usuário deve ser redirecionado para a página autenticado.jsp sem manter o estado.

Vamos criar então a tela de mensagem de sucesso para o caso do login esta correto.

autenticado.jsp

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Autenticado</title>
</head>
<body>
<h2>Sucesso!</h2>
<p>
Você foi autenticado com sucesso!
</p>
</body>
</html>

Perceba que é apenas uma página jsp normal, que serve só para sabermos se os dados foram validados com sucesso, e se nossa app jsf está obedecendo as regras criadas no faces-config.xml.

Agora coloque para rodar o projeto feito, e veja o resultado. Tente logar com o usuário diferente do definido no LoginBean e senha diferente também. Depois tente fazer um login com os usuários definidos e veja se você é direcionado para a página correta.

Conclusão

Tentei exibir um uso simples de jsf, tentando demostrar desde a criação de uma página simples, passando os dados pelo managed bean e validando as configurações do faces-config. Daí em diante dá pra ir abstraindo-se de algumas coisas e melhorar a aplicação de uma forma gigantesca.
Qualquer dúvida podem comentar ou enviar e-mail que ajudarei no que for possível.

Os temas foram:
Conhecendo o Spring por Igor Coelho
OpenSocial: construa sua rede social por Cristiano Milfont
Os melhores do mundo: comparativo entre Spring e EJB 3.0 por Rafael Carneiro e Tarso Bessa

Todas as palestras foram incríveis, porém quero dar destaque a dupla Rafale e Tarso que se superaram e mostraram o poder do EJB e do Spring. E uma comparação entre os dois. O poder e as facilidades que os dois trazem ao desenvolvimento JEE.

Assim que sair fotos, vou publica-las, porém você pode acompanhar por AQUI as fotos do evento e o material que será diponibilizado. Mas óbvio que não vou esperar e vou publicar em breve também
De antemão deixo a ressalva que a mês MAIO terá mais um CCT de peso. Aguardem…

Ao fazer um breve pesquisa na WEB, caí no blog da Caelum, que por sinal é excelente, respondendo a minha questão. Deixo então para vocês a mesma resposta, se isso lhe interessar.

Veja o link abaixo:

http://blog.caelum.com.br/2008/04/01/entendendo-o-serialversionuid/

Abraços e bom proveito.

O Reggie falando sobre o programa para desenvolvedores recursos, dentre outros. Já o Simon, falou sobre o JavaFX, que foi uma excelente visão e palestra sobre esta nova tecnologia da SUN e falou também sobre o SUN Spot. Foi realmente incrível.

Já o brasileiro Paulo Silveira da Caelum, deu um show a parte. Falou muito bem e com muita autoridade sobre a arquitetura Java. Um pouco sobre SOA “Same Old Architecture”.

Resumindo um pouco, quem não foi só perdeu. E quem foi vamos continuar nos preparando porque os próximos eventos vão ser de imensa qualidade.

Alguns dos grandes nomes da programação Java Cearense compartilharam de um baião com uma picanhazinha assada de primeira.

Os presentes foram:

• Rafael Carneiro
• Igor Coelho
• Israel Freitas
• Handerson Frota
• Rafael Tabosa
• Rafael Ponte
• Alyson Bandeira
• Arisson Leal

O Embaixador SUN (Silveira Neto) chegou no final com os cartazes do evento.

Ainda tivemos tempo para trocar umas idéias sobre tecnologias Java dentre outras..
Algumas fotos ai:

É, as fotos não estão lá essas coisas, mas ainda dá pra ver algo Abraços e um ótimo evento a todos

Esse evento está prometendo, a comecar pelos palestrantes. São eles:

• Simon Ritter (Sun Microsystems);
• Reggie Hutcherson (Sun Microsystems);
• Paulo Silveira (Caelum);

As palestras são no mínimo interessantíssimas:

• JavaFX para desenvolvimento de aplicações Rich Client
• Arquitetura Java Enterprise Edition
• A Estratégia de Software da SUN para desenvolvedores
• Projeto SUN SPOT para Redes de Sensores sem Fio em Java

Para os palestrantes internacionais (SUN Microsystems), haverá tradução simultânea.

O mais importante para os caros internautas é quando e onde. Será:
Dia 12 de Fevereiro de 2008 às 18:00h
No auditório da FA7 (Faculdade 7 de Setembro)

De certo modo, parece aqueles shows iluministas com um monte de imagem que mexe com você e um som bem interessante que te leva pra lua.

A diferença é que é um pdf, num tem show nem som , mas os slides estão muito bons. Feito pelo pessoal do JAVA RN.

Vale a pena clicar