Java memory leak, isso tem jeito ? 1/4

Olá pessoal,

Gostaria de compartilhar com vocês um dos grandes problemas que a arquitetura java tem dado a quem trabalha com ele, especialmente com aplicativos de alto desempenho e disponibilidade. Ando estudando um pouco sobre isso e achei diversos materiais interessantes e vou tentar compilá-los aqui numa série de 3 ou 4 posts.

Vamos falar um pouco sobre as causas mais comuns para esse famigerado problema, que não tem nada de simples. Porque é tão difícil de ser ser identificado? Qual a parcela de culpa de quem desenvolve, se é que existe culpa? Servidores de aplicação são a solução? Por que eles acontecem ?

Espero descobrir as respostas para esses problemas, postar aqui minhas impressões e dividí-las com quem tiver interesse. Espero receber contribuições também !

Abraços e até a próxima.

 

Rich Internet Applications com JBoss Seam (1/3)

Olá pessoal,

Continuando minha tentativa de manter o blog atualizado, como prerrogativa para estudar e aprender sobre novas tecnologias , escolhi um tema interessante pra mim e espero que para vocês também.

Quem trabalha com aplicações para Internet, sabe que o grande desafio é criar uma interface bastante amigável para os usuários, apesar das limitações características ao ambiente. Existem diversas tecnologias distintas no mercado open source ou não, que atendem esses requisitos de forma desintegrada e de diversos fornecedores.

Dentro do projeto JBoss, existem diversos frameworks que compõem o JBoss AS ( Application Server ), entre os mais conhecidos estão o Hibernate, Web Services, Web,  Transactions, jBPM e o Seam.

JBoss AS

O Seam integra as tecnologias mais badaladas do mercado open source como AJAX, JSF, EJB3.0 e BPM  em um único framework, para facilitar o desenvolvimento de aplicações RIA, de maneira integrada e “eliminando” a complexidade dessas APIS. Ele promete a criação de aplicações complexas com poucas classes java, interfaces com usuário poderosas e com arquivos xml de configuração.

No próximo post, vamos mostrar de forma resumida, suas principais características e como utilizá-las.

 

O papel do arquiteto de software 3/3

Para concluir o tema que abordamos nos ultimos dois posts, vamos falar um pouco sobre os padrões e as técnicas para adotá-los, que são tão importantes no papel do arquiteto de software.

O uso de padrões ou como é mais conhecido Design Patterns, é uma das partes mais difícieis no dia-a-dia de qualquer profissional de TI, pois a todo tempo novas abordagens surgem para otimizar ou modificar a maneira de solucionar um mesmo problema. Quando eu leio sobre uma nova tecnologia, tento listar e identificar os diferentes padrões que são utilizados e extrair qual a abordagem que a diferencia das outras ( essa parte não é fácil de implementar).

Para se definir qual o padrão ou framework a se utilizar, deve-se observar primordialmente que os melhores, são geralmente desenvolvidos de forma genérica a atender todas as possíveis abordagens, podendo assim dessa forma, incrementar a produtividade no desenvolvimento de uma solução de software, sem invenções incríveis.

Durante reuniões técnicas para discussão de um problema, deve-se evitar erros comuns, como as famosas siglas, criando uma “sopa de letras” que não permitem que todos entendam de forma clara e objetiva o que se pretende fazer, deixando na verdade, mais dúvidas que soluções nas cabeças das pessoas. Ser objetivo é o principal !

“Entender como uma tecnologia trabalha, não é o bastante para desenvolver uma solução de software robusta, entender aonde a tecnologia é aplicável numa solução, é essencial para o desenvolvimento de um produto de qualidade.”

Essa frase resume bem qual o real sentido da coisa, utilizar tecnologia por si só, não é garantia de solução para os problemas.

Com isso concluímos essa série e espero que todos tenha gostado.

 

O papel do arquiteto de software 2/3

Dando continuidade a segunda parte desse post, vamos hoje sumarizar e conceitualizar duas das áreas chaves de conhecimento para um arquiteto de software.

O Domínio, que pode ser aplicado de maneira horizontal ou vertical para um solução de software. O domínio horizontal surgiu e é aplicado nas industrias em geral, como por exemplo um fluxo de trabalho de automação (workflow). O vertical, é utilizado para situações particulares como por exemplo na industria de telecomunicações ou tecnologia da informação. Existem muitos padrões e protocolos que abrangem cada uma dessas vertentes e devem ser consideradas na construção de uma solução de software.

Os Conceitos são uma das maiores responsabilidades de um arquiteto de software, ou seja, repassar uma solução de forma clara e objetiva, tanto para o pessoal técnico de sua equipe, como também, para os patrocinadores de um projeto. Essa habilidade é essencial, para que todos as possíveis situações possam ser vislumbradas e que os participantes possam dar um feedback de entendimento ou não, a respeito do proposto. Exitem duas visões que o arquiteto deve considerar nessa fase, como na a figura abaixo.

O arquiteto pensa em bolhas

Deve-se pensar de forma abstrata a ponto de não se preocupar com os detalhes da implementação de uma solução, para isso utiliza-se dentre muitos artefatos modelos que permitam conceitualizá-la, podendo utilizar ferramentas auxiliares para isso como, MDA ( Model Driven Architectute ).

O desenvolvedor ver apenas parte da solução

O arquiteto de software também deve considerar e entender que uma solução de software consiste em mais do que apenas atender os requisitos funcionais a serem implementados, por exemplo, plataforma de desenvolvimento, frameworks e infra-estrutura de tecnologia. Também devem ser considerados requisitos não funcionais como: distribuição, segurança, escalabilidade e performance. Esquecer pontos importantes como esses, aumentam os riscos de que a solução possa falhar.

No próximo post concluiremos esse assunto falando sobre Padrões e Técnicas.

 

O papel do arquiteto de software 1/3

No meu primeiro post sobre o papel do arquiteto de software vamos falar um pouco sobre as habilidades que um profissional precisa ter para alcançar essa condição. Dentre muitos fatores que iremos tratar aqui, um dos primeiros é que um arquiteto de software precisa estar apto para resolver problemas, através da definição de uma solução utilizando tecnologia.

Porém é preciso definir qual a melhor maneira de aplicar seus conhecimentos abstratatos  de forma objetiva, para que a tecnologia seja utilizada da melhor forma, não apenas por modismos e sim, atingindo os objetivos ao que se propõe na construção de uma solução de software.

O conjunto de conhecimentos necessários, passam pelo domínio do problema, conceitos envolvidos para a solução, o uso de técnicas e padrões de mercado para agilizar e melhorar o desenvolvimento do software durante todo o ciclo de vida de um projeto, como exemplificado na figura abaixo:

Áreas chaves de conhecimento para um Arquiteto de Software

Parece fácil falar sobre isso de forma tão simples, mas o desafio está em como um arquiteto de software aplicará todos esses conhecimentos na definição e desenvolvimento de uma solução robusta e aderente aos requisitos do software ao qual ela atenderá. Na próxima figura está ilustrado quando esses conhecimentos deverão ser utilizados durante o desenvolvimento do projeto.

O uso das habilidades de um Arquiteto nas fases de desenvolvimento

A figura acima, ilustra que os diferentes tipos de habilidades são utilizadas durante todo o processo de desenvolvimento, iniciando pela definição do problema (conhecimento do domínio/habilidade para conceitualizar) até o desenvolvimento da solução (utilização de técnicas/habilidade para utilizar padrões).

No próximo post tentaremos sumarizar e contextualizar cada um das áreas definidas nesses gráficos.

Fontes: The Architecture Journal e www.iasahome.org

 

Voltando a ativa !

Olá pessoal, estive ausente um longo tempo, pois andei extremamente ocupado com um projeto no trabalho e por isso não postei mais novos assuntos por aqui. Mas nesse longo tempo, tive oportunidade de aprender um pouco mais sobre tecnologia e especialmente sobre arquitetura de software.

Nessa última, descobri uma vertente interessante de assuntos que andei me questionando há algum tempo e que estão no topo dos foruns e revistas especializadas. Entre eles estão:

• Qual o papel do arquiteto de software ?
• Nós precisamos de um arquiteto de software ?
• Tornando-se um arquiteto de software, Quais os pré-requisitos ?
• Entre outros…

Nos próximos post’s falaremos sobre esses assuntos e também sobre tecnologia é claro !

 

Feliz Natal e um Produtivo 2008

Olá pessoal, estou de volta após um longo tempo sem postar !

Estou muito atarefado no trabalho me envolvendo em vários projetos e infelizmente tive que deixar o blog um pouco de lado, mas felizmente, em 2008 estarei de volta abordando novos temas e aguardando suas contribuíções, para progredirmos juntos… !

Abraços a todos que me prestigiaram e que em 2008 possamos aprender cada vez mais…

Feliz Natal e um 2008 produtivo para todos.

Berg.

 

JavaFX: Parece bom, mas ainda tem algumas limitações (3/4)

Como falamos nos posts anteriores , o JavaFX traz algumas diferenças significativas em relação ao Java, por aproveitar as APIS do Java, permitindo uma gama de possibilidades tão vastas como o próprio java. Por exemplo é possível fazer chamadas para métodos ou criação de objetos de forma procedural, como em java.

No trecho de código abaixo temos um exemplo de que como criar de forma procedural um frame e adicionar um evento a um botão, feito em java.

Mas segundo a documentação do JavaFX, a melhor forma de fazer o seu uso é trabalhar de forma declarativa, como no trecho de código abaixo, relativo ao código anterior.

Observamos que o “operation” é o equivalente a um método em java, podendo conter métodos java, controles de fluxo, tratamento de exceções, loops e outros. Outra coisa que difere é que as variáveis não são tipificadas. Existem também uma grande variedade de novas funcionalidades como: Lista de Compreensão e Arrays, Concorrência, Classes e Objetos, Triggers e Reflections.

• Lista de Compreensão e Arrays – novo conceito que o java puro não possui. A lista é composta por uma ou mais listas de entrada, um filtro opcional e uma expressão geradora.
• Concorrência – a palavra reservada “do” é utilizada com uma finalidade diferente do Java, permitindo que a thread de Eventos AWT continue executanto, enquanto o código entre o “do” será executado em uma outra thread em background. ( Excelente recurso para preenchimento de combos e listas para exibição na Interface com o usuário )
• Classes e Objetos – as classes também são criadas declarativamente, ficando a implementação das funções e operações fora do corpo da classe.
• Triggers - essa funcionalidade foi inserida para resolver o problema da falta de construtores das classes e a não existência de métodos set/get.  Existem quatro tipos de triggers : criação de objetos, inserção, atualização e deleção de um atributo.
• Reflexão – utiliza-se da mesma forma que em Java puro para acessar classes, atributos, funções e operações através da palavra reservada class.

Com esse post, o objetivo principal foi deixar claro algumas das novas funcionalidades e características do JavaFX, mas sugiro que um bom e velho hello world (existem tutoriais) seja implementado, para que se possa aprender mais.

No próximo post concluiremos o tema, tratando das limitações.

 

JavaFX: Parece bom, mas ainda tem algumas limitações (2/4)

Dando continuidade ao tema JavaFX , vamos falar hoje do JavaFX Mobile que é o novo OS da SUN para dispositivos móveis e que serão distribuídos aos fabricantes sob licença GPL e comercializado para as operadoras de celular e fabricantes de PDA, Smartphones, no modelo OEM.

A figura abaixo demonstra os serviços e aplicações oferecidos no SO JavaFX Mobile.

Dentre as principais características estão os serviços básicos de mensagens (SMS, MMS,etc) , browser, suporte a música e vídeos, e total integração com a API do Java, software updates , frameworks de segurança, multimídia, telefonia e um engenho de avançado de funções gráficas , entre outros.

Também tem uma completa e pré-integrada solução que habilita os fabricantes de dispositivos móveis a concentrarem esforços nos desenvolvimento de novos serviços, com baixo custo de investimento, pois como dito anteriormente, utiliza toda a API do Java como plataforma base.

Poderão ser implementadas bibliotecas, middlwares e aplicações em Java de forma mais fácil, simplificando e acelerando o desenvolvimento de aplicações mais seguras e mais eficientes, com interfaces gráficas mais ricas para os usuários.

No próximo post falaremos sobre mais algumas características e trançando um paralelo entre as principais diferenças entre o Java e JavaFX.

 

JavaFX: Parece bom, mas ainda tem algumas limitações (1/4)

Ando estudando e lendo sobre essa nova tecnologia que a SUN criou para as chamadas aplicações RIA (Rich Internet Application) e resolvi compartilhar com vocês alguns do conhecimentos e também fazer um exemplo prático de seu uso, como também, discutir algumas de suas limitações, nessa primeira versão.

O JavaFX veio para atender a necessidade de sofisticação da interface com o cliente, com o JavaFX Script e também incrementar a tão conhecida “portabilidade” para todos os dispositivos, com o JavaFx Mobile.

A imagem abaixo mostra a arquitetura do framework JavaFX Script e suas principais características.

A grande chave para o uso dessa tecnologia é o uso do java, instalado nos dispositivos, como base para a integração e evolução da linguagem de script.

“The write once, run anywhere portability ” …essa frase famosa promete que uma vez escrito o código de uma aplicação, ela poderá ser executada em qualquer lugar, sem a necessidade de re-escrita.

Entre as principais novidades do JavaFx Script estão:

1- JavaFX Script usa uma sintaxe declarativa para especificação de GUI´s;

2 – Através do link declarativo e incremental de valores, é possível criar e configurar componentes individuais, sincronizando “automaticamente” os dados às interfaces(GUI) desenvolvidas;

3 – Será prossível utilizar o JavaFX com as principais IDE´s de mercado;

4 – Diferentemente de outros scripts java, o JavaFX é fortemente tipado, possibilidanto o reuso de código, de programas bem estruturados e as características de encapsulamento que permitem criar e manter grandes programas em java.

No próximo post, vamos falar um pouco mais sobre os conceitos do JavaFX e também do JavaFX Mobile.

Até lá