Últimas notícias do evento

Dicas para SCJP

Postado em Atualizado em

brainDurante os últimos meses tenho ajudado uma série de pessoas a obterem a SCJP e devido a esta experiência muito bacana, resolvi elaborar um post com algumas dicas e diretrizes que poderão fazer grande diferença nos momentos decisivos e críticos do estudo e da prova. Seguem a lista:

1. Estude periodicamente

Decida quantas horas vc terá de estudo, escolha um horário fixo e lugar adequado sem barulhos, ruídos, telefones etc….Cumpra este horário restritamente e não fique variando dia a dia. Sempre tome muita água durante os estudos !!

2. Leia e entenda o conteúdo

Não faça coisas ao mesmo tempo que estuda !! Não use msn ! Não escute música ! Não deixa a tv ligada ! Não cuide de crianças ! Não faça nada que venha interromper seu cérebro de entender e memorizar o conteúdo !!  Preste atenção no que vc esta lendo !! Não fique tentando acabar com as páginas do livro de forma rápida !! Caso contrario, vc terá a falsa impressão de que esta lendo tudo bonitinho, entretanto o conteúdo não vai entrar cachola !! Veja que isso é uma total perda de tempo !! Pois vc não ira memorizar nada e ainda terá que reler tudo novamente.

3. Releia os capítulos no qual tem dificuldades

Durante os estudos vc pode perceber que apresentará uma certa dificuldade em alguns tópicos, na maioria dos casos sera sobre conceitos e implementação do OO e a famosa Thread. Bem, cada um é cada um, independente disso, identifique estes tópicos e invista um tempo de qualidade maior posterior para reler os materiais sobre eles.

4. Implemente os exemplos

Se vc ficar com dúvida em alguma coisa, implemente exemplos e tire todas a limpo !! Não seja abelhudo de tentar fazer a prova na raça !! SCJP é um prova muito bem elaborada com pegadinhas extremamente estudadas e direcionadas para confundir o raciocínio do candidato relacionado a: sintaxe, lógica, matemática e conceitos OO com o único objetivo de fazer o mesmo perder a questão. Sem falar língua inglesa, se caso for optado por ela.

4. Faça cartões

Mesmo relendo os tópicos de maiores dificuldades, ainda sim existira alguma coisa que vc terá grandes dificuldades em memorizar ! Diante disso, use a técnica apelativa de cartões de memorização. Como funciona ? Simples..faça cartões com resumos descrevendo brevemente o conteúdo, conceito ou pedaço de código que vc deseja memorizar e leia-os no mínimo duas vezes ao dia. Tem pessoas que gosta de coloca-los em lugares que possam ser visualizados durante o seu dia: espelho, mesa de trabalho, papel de parede do desktop etc….

5. Fazendo exercícios/simulados

Faça os exercícios/simulados de forma séria como se vc estivesse verdadeiramente durante a prova !! Não faça intervalos durante os exercícios/simulados porque na prova real não existira isso ! Leia cada questão pausadamente, marque a resposta de acordo com seu raciocínio reflexo e não fique pensando muito durante a questão. Ou vc sabe ou vc não sabe !! O tempo limite da prova estará correndo, por isso responda a questão com objetividade !! E se porventura vc estiver com dúvida, marque a determinada questão para ser revisada após você responder todas as outras.

6. Não refaça o mesmo exercício/simulados seqüencialmente

A repetição seqüencial faz vc ter uma falsa sensação que vc esta acertando as questão, mas a real é que vc já decorou as perguntas. Quando for repetir os exercícios/simulados, faça-os  intercaladamente em espaço de dias consideráveis !!!! Isso fara sua mente perder a referência das respostas, fazendo com que vc não tenha uma enganosa média de acertos.

Bom turma..é isso ai !! Eu pratiquei todas as idéias acima citadas e obtive 96 % na minha (errei 2 questões). Desejo sorte a todos…e qualquer outra informações é só entrar em contato 😀

O post fica aberto para aquele que desejam completar com outras dicas.

“Confia no Senhor de todo o teu coração, e não te estribes no teu próprio entendimento…” Provérbios 3:5.

Anúncios

JEE 6 no Forno

Postado em Atualizado em

javaee6overviewiconJEE esta no forno esquentando como nunca !!! A especificação “rascunho” acabou de ser lançada para a galera dar aquele overview e algumas recomendações. Veja o artigo de Reza Rahman [que faz parte da equipe da especificação] descrevendo com o “meio de campo” vai ficar e como a nossa vida sera afetada a partir de realese que promete grandes mudanças 😀
“Nisto se manifestou o amor de Deus em nós: em haver Deus enviado o seu Filho…” 1 João 4:9.

JEE M1- Adetec 02/02/09

Postado em Atualizado em

Neste post podemos trocar informações, comentários, sugestões e criticas durante o curso. Vejam os links:

1. Curva de Aprendizado
2. Aplicativos Web com Java
3. Ajax
4. Rich Internet Applications
5. Ext JS – RIA
6. FeyaSoft – RIA

Tudo estático ?

Postado em Atualizado em

111-stupid_q1“Seria uma idéia estúpida colocar todos os métodos de uma classe DAO como estático ?”
Esta foi a discussão criada no java.net nesta semana que casualmente reforça o meu post sobre Programação em Equipe. Entre no post, veja as respostas e faça a sua própria conclusão !!!

“Nunca o deixarei, nunca o abandonarei..” Hebreus 13:5.

Kit JSF – PrimeFaces

Postado em Atualizado em

111-plug_ins

PrimeFaces é o mais novo kit de componentes visuais para especificação do JSF. Ele esta dividido em 3 módulos básicos:

1. Componentes UI – módulo com componentes RIA. Baseado no Yahoo UI Library, controlando todo a geração pesado de JavaScript e amarrações com o lado do servidor:

* Varios componentes RIA  – HtmlEditor, ImageCropper, Dialog, AutoComplete, Captcha, Menus Carrosel, ColorPicker e muitos outros interessantes.
* Componentes baseados em Flash.
* Serviços AJAX.
* 100% de compatibilidade com outros componentes.

Veja o demo.

2. Optimus – módulo que providencia uma serie de facilidades em soluções para JSF. Ele remove a grande sobrecarga de manipulação de arquivos XML, providenciando anotações baseados em container IOC Guice Framework:

* Anotações baseadas em IOC.
* Suporte a persistência com JPA.
* Controle de transações declarativas.
* Menos manipulações de XML.
* Exportação automática de componentes baseados em DataTable para Excel e PDF.
* Gerenciamento de Segurança.

Veja o demo.

3. FacesTrace

FacesTrace tem o objetivo de ser utilizado como apoio de desenvolvimento, com uma serie de informações sobre o JSF como:

* Visualizador do ciclo de vida do JSF.
* Performance Tracker.
* Controle de atributos e escopos.
* Gerenciamento de Log com Log4J.
* FacesMessage Lister.
* Visualizador da arvore de componentes JSF.

Veja o demo.

Eu não tenho duvidas de que o PrimeFaces veio para brigar de igual com o famoso e mais utilizado JBoss Rich Faces…e o melhor de tudo..como sempre…quem ganha somos nós !!!! Mais uma ótima opção de KIT para aplicações JavaServer Faces…..que nós, como desenvolvedores podemos utilizar ou mesclar com os outros já existentes….sempre dando graças ao modelo baseado em especificação. Um ótimo final de semana a todos 😀 .

“Como o ferro com ferro se afia, assim o homem, ao seu amigo.” Provérbios 27:17.

WidgetFX 1.0 Release

Postado em Atualizado em

Foi liberado este mês o projeto WidgetFX !  Veja o link oficial: http://widgetfx.org/.
WidgetFX é uma plataforma open-source para componentes visuais desktop escrita sobre a plataforma JavaFX, disponibilizando um kit de componentes visuais (widget) escrito em JavaFX Script e Java,….tendo é claro todas vantagens da plataforma. Estaremos “firme e forte” acompanhando e aguardando o crescimento do JavaFX.

widgetfx-1011
“Ele é como árvore plantada junto a corrente de águas, que, no devido tempo, da seu fruto….e tudo quanto ele faz será bem sucedido.” Salmo 1:3.

Programando em Equipe

Postado em Atualizado em

111-scripting_languagesO desenvolvimento de um software consiste em um grupo de pessoas manuseando os mesmos arquivos fontes e componentes. Se um individuo deste grupo não conseguir escrever a sua parte de forma clara, de fácil compreensão e manutenção, o projeto estará comprometido a uma série de conseqüências problemáticas. Entendo que isso é uma situação de peso, uma vez que a manutenção representa em média 80% do tempo de vida de um sistema.

Ao longo das consultorias em projetos que venha participando, diagnostiquei que os programadores em geral não sabem o significado de se “Programar em Equipe“. Percebo que é um problema de nível cultural e acredito que isso possa ser revertido se cada um pensasse da seguinte forma:

Eu estou trabalhando em uma equipe, por isso eu tenho que me esforçar ao máximo para implementar este requisito de forma mais simples, clara e de fácil manutenção possível…porque haverá algum momento no ciclo de vida do desenvolvimento que um companheiro de equipe precisara alterar ou complementar o que eu fiz e inevitavelmente eu também precisarei manuziar algum código que foi construído por outra pessoa.

Acredito que o fato acontece por 3 motivos:

  1. Pessoas remanescentes de outras tecnologias/ferramentas nas quais não existiam esta filosofia.
  2. O desconhecimento de que na tecnologia java existe um padrão de codificação.
  3. A falta de um sólida base de princípios de projetos orientado à objetos.

1. Pessoas remanescentes de outras tecnologias/ferramentas nas quais não existiam esta filosofia:
Eu percebo que atualmente existe um galera muito inteligente e esforçada que vem migrando de outras tecnologias para o java e que realmente tem conseguido produzir software funcionais, entretanto 100% deles deixa muito a desejar neste ponto. Percebo que o pessoal traz seus costumes e hábitos de programação para dentro do java.

2. O desconhecimento de que na tecnologia java existe um padrão de codificação:
Em java existe um forma padrão de como se deve ser escrito um código fonte. Ou seja, o autor não tem a liberdade de ficar usando/inventando uma série firulas, gafs, comentários, regras de espaçamentos sem coerências, delegação de nomes para identificadores completamente malucos etc….. Existe um documento chamado “Java Code Conventions” que possui todas as regras e diretrizes previamente estudada e estabelecida para que qualquer pessoa em qualquer lugar no mundo possa escrever mesmo código fonte. Isto quer dizer oque ? Quer dizer que uma pessoa de um lado do mundo pode abrir o código fonte de uma outra pessoa, do outro lado e ter a sensação que ela mesma que escreveu !!! Sendo que ambos devem seguir a convenção de codificação. Faça o download do “Java Code Conventions” aqui.

3. A falta de uma sólida base de princípios de projeto orientado à objetos:
Fácil manutenção esta intimamente ligado com a utilização de princípios e diretrizes da filosofia orientada a objetos e é aqui aonde o galera mais deixa a peteca cair ! Como é incrível ver o pessoal mesmo usando uma tecnologia OO conseguir programar usando conceitos procedurais/globais e fazer uma coisa simples OO virar um monte de macarrão trançado. Sempre lembrando que a POO é uma filosofia e pode ser furada fácil fácil em qualquer parte do projeto.

Segue abaixo a lista resumida dos erros mais comuns:

  • Estado do objeto – Não use variáveis de instâncias para controle de fluxos locais ! Variável de instancia é usado para definir estado do objeto durante seu ciclo de vida. Caso precise controlar algo localmente, use variáveis locais.
  • Declaração de variáveis – Somente declare e inicialize as variáveis locais antes (o mais próximo o possível) de ser usada ! Único momento onde é aceitável declarar uma variável muito longe de sua utilização é em caso de utilização fora de escopos de controle de fluxo ou loop. Mesmo assim, mantenha em mente que vc deve declarar sempre o mais perto possível.
  • Escopo de variáveis – Sempre reduza os escopos das variáveis o máximo possível ! Nunca declare uma variável fora de um escopo lógico (while, if, do/while, for) se vc só vai precisar da variável dentro dele.
  • Nomeação de variáveis – Independente do seu escopo (instância ou local) os nomes das variáveis devem ser auto-explicativo ! Não coloque nomes sem sentido ou com apenas um caracter ! Único lugar aceitável para se colocar uma variável com um único caracter é no contador de um for, o resto tem que possuir um nome significativo dentro do contexto de implementação. Outra coisa, não faça nomes grandes de mais, resuma ou procure um sinônimo menor.
  • Nomeação de classes e métodos – Nome de classe geralmente é um substantivo que reflete a abstração da automação de alguma coisa do mundo real e os nomes dos métodos devem ser verbos que refletem ações que um objeto da classe faz.  Qualquer coisa que passar disso fara com que o projeto fique completamente ilegível e confuso ! Única possibilidade de exceção ao este caso seria a possível utilização de design patterns dentro das arquitetura.

Programador procedural no mundo orientado à objetos:

  • Reduza a visibilidade da classe – Nunca deixa publico e exposto pela classe algo que somente esta sendo usando por ela internamente (atributos e métodos). Quanto mais coisas publicas a classes possuir, menos flexibilidade de manutenção ela terá.
  • Use sobrecarga de métodos – De preferência a sobrecarga de métodos ao vez de ficar implementando controle de lógica baseado na passagem de parâmetros.
  • Longas listas de argumentos – Métodos com muitos parâmetros refletem em geral a falta de percepção de que esta faltando a criação de um objeto que contivesse estes dados devidamente encapsulado, utilizado posteriormente como agregação.
  • Classes sem métodos ou sem atributos – A classe  é a expressão de um componente portador de características e comportamentos. Salvo em raros casos na utilização consciente de design patterns.
  • Reutilização de código – Na POO podemos reutilizar código de duas formas: por herança ou agregação. Sempre faça uma análise critica no caso de qual utilizar, mantendo em mente de que a agregação é a forma mais flexível. Entretanto, existirão casos de herança (considere casos de classes abstratas). De forma alguma faça CTRL+C e CTRL+V nas classes por mais pequeno que seja a circunstância !!
  • Polimorfismo sempre – Use indiscutivelmente quando puder argumentos, variáveis, tipos de retornos polimórficos. Não existe nenhuma outra coisa na POO que ofereça mais flexibilidade e manutebilidade como a codificação polimórfica.
  • Classes Enormes – Isso é uma das picaretagens mais feias que pode ser feita contra o patrimônio OO !!! Nunca faça classes longas, cheias de métodos, resolvendo tudo……é o famoso canivete suíço. Passe um pente fino nas classes usando a  SRP – Single Responsability Principle na qual afirma que cada classe deve ser implementada para resolver apenas uma situação, uma responsabilidade ! Busque a granularidade certa entres as classes do seu projeto, considerando é claro o escopo em questão.
  • Métodos Enormes – métodos grandes, cheios de controle de fluxo normalmente devem ser analisados e fracionados em métodos menores com visibilidades mais restritas.
  • Abuso em Recursos Estáticos – outra ofensa contra o patrimônio OO !! Na POO não existe funções e variáveis globais perdidas no espaço mágico do mundo encantando !!! Tudo é objeto se relacionando com outro objeto através de seus estados e ações.  Classes que apresentam abusos deste recurso expressam que o programador (autor) não conseguiu visualizar as abstrações e seus relacionamentos dentro do contexto da implementação. Recursos estáticos representam um escopo especial que é compartilhado por todos objetos de uma classe e devem ser usados para satisfazer somente este caso.
  • Nunca Reinvente a Roda – Java tem atualmente 14 anos (desde 1995) de existência e apresenta uma serie de recursos agrupados pelas plataformas. Fora isso, existem uma muitos produtos proprietários, open-source ou pagos e por esse motivo nunca tente elaborar ou inventar algo do zero antes de pesquisar a fundo !! Porque na maioria dos casos vc vai achar alguma coisa pronta (classe, componentes, framework, especificação, produto open-source ou proprietário pago com preço acessível) para resolver aquilo que vc esta necessitando !
  • Encapsulamento – Sempre esconda as estruturas internas de uma classe e controle o acesso ao estado dos objetos através do encapsulamento usando a padronização JavaBean.
  • Implemente as Regras Arquiteturais – Se uma classe é a ultima da hierarquia, declare como final !! Se um método não pode ser anulado, declare com final !! Se um argumento ou variável não deve ser mudado, declare como final etc…Ou seja, impeça ou force polimorfismo, libere ou restrinja visibilidades em herança ou agregações. Entenda seu domain model e expresse-as no modelo de classes !!
  • Ciclo de vida dos objetos – Sempre programe pensando em cooperar com o coletor de lixo !! Ou seja, analise bem os escopos de criação dos objetos (estático, instância ou local) e libere eles (atribuindo null para as referências) logo após verificar que não ira mais utiliza-lo. Perceba que esta prática deixa o código claro e legível.
  • Modere a Criação de Objetos –  Sempre seje moderado na criação de objetos, nunca criando mais do que vc precisa…sendo que o coletor de lixo é muito eficiente, mas não faz milagres. Quando possível, tente reusar os mesmos objetos reiniciando-os ao seu estado inicial. Analise cada new que vc declarar !! Em aplicações de médio/grande porte isso pode resultar em uma grande economia e conseqüentemente performance.

Controlando condições excepcionais:

  • Controle de Erros – Nunca use como controle de erros com retorno de booleano ou códigos de erros ! Em java existe uma mecânica padronizada chamada de tratamento de exceções. Lance exceções indicando as condições excepcionais, usando classes existente no core do JSE ou não tenho receio de criar as suas próprias quando necessário.
  • Propagação de Exceções– Nunca propague uma exceção ocorrida de dentro de uma camada lógica para fora da mesma, sendo que a outra camada cliente não deve conhecer detalhes internos de execução. Neste caso propague outras exceções mais significativas refente ao contexto da camada/componente/classe ou serviço.
  • Exceções Polimórficos – Nunca use o tratamento de exceções  de forma polimórfica !!! Sempre encadeie os catch de todas as exceções, deixando o código claro e legível para o próximo programador amigão do peito !
  • Comendo Exceções – Nunca faça um try sem colocar nada no catch !! No minimo tem que existir uma impressão da lista do trace ou substitua se possível o try por um if identificando a condição.
  • Fluxo de Controle em Exceções – Nunca use um try/catch como fluxo de controle !! Ou seja, não baseie nenhuma logica condicional no controle de exceções. O próximo programador agradece a legibilidade do seu código.

Bom galera, este foram as “pérolas” que eu já peguei espalhada por ai !! O post fica livre para quem quiser complementar ou dar sua opinião. Para quem deseja realmente ter uma boa base sobre o assunto sugiro a leitura e a pratica do Java Code Convention e o livro Head First OOA&D – (em português Analise e Projeto Orientado a Objetos)

“Bem-aventurado o homem que não anda segundo o conselho dos ímpios…Antes tem o seu prazer na lei do SENHOR” Salmo 1:1-2.