Já está disponível no JavaFX.com mais um preview release do JavaFX SDK.

Há tanto o JavaFX SDK sozinho como ele integrado com o NetBeans 6.1, que é o que eu tenho usado e recomendo.

Há também o projeto Nile, um conjunto de ferramentas e plugins para o Adobe Photoshop CS3, Adobe Illustrator CS3 e outras ferramentas como o exportador de SVG para JavaFX. Já da pra ver que é bem focado em designers. Eu tenho conversado com o pessoal do projeto Inkscape (editor vetorial livre e multiplataforma) e estamos desenvolvendo um plugin de exportação já embutido no Inkscape.

Respondendo aos que haviam perguntado na lista antes, eu li que a versão Mobile e a de Tv digital saem só em 2009. No site há também uma lista mais completa sobre o que haverá na versão 1.0.

Quem quiser conhecer mais um pouco dá uma olhada aqui.

por Silveira Neto

O seu provedor de Internet está interferindo em seu BitTorrent? Derrubando suas chamadas de voz sobre IP? Desrespeitando o princípio de neutralidade? Para sanar estas dúvidas, os usuários de Internet precisam primeiro de ferramentas de testes que lhes forneçam evidências de abuso dos provedores de Internet. Por exemplo, se não fosse o esforço de Rob Topolski, a Associated Press e a Comcast poderiam continuar negando seus infames esforços em bloquear o BitTorrent. Descubra mais sobre este assunto: http://www.eff.org/testyourisp/switzerland

Vemos grande poder de armazenamento de dados que os bancos de dados relacionais oferecem para as empresas. Devido esse fato, a grande maioria não pensa (pelo menos ainda) em migrar para um banco de dados orientado a objetos. Isso se deve ao fato de ser um projeto ainda muito academico, pois só quem usa esses bancos de dados orientados a objetos são universitários.

Mas afinal de contas, porque existe esse tal de Hibernate e o que vem a ser esse kra?

Primeiramente vamos fazer a seguinte análise:

1. As melhores linguagens de programação são orientadas a objeto (isso torna difícil a integração entre o banco de dados e a linguagem);
2. Vamos supor que você programe, mesmo assim, com uma linguagem estrutural. Mas pense no quanto fica difícil trabalhar com o banco de dados a medida que a aplicação vai crescendo

Você pode se perguntar: "E agora, quem poderá me ajudar?"

Mas para te deixar mais preocupado ainda, vamos imaginar a seguinte situação: e se você já tem o privilégio de trabalhar com uma linguagem de programação OO. É comum misturarmos lógica de negócio com código SQL (isso não é nada agradável :S). Você pode achar isso totalmente normal e não pensa no quanto isso é prejudicial, mas pense: Se o banco de dados mudasse? Seria necessário mudar toda a aplicação.

Então, qual seria a solução?

Calma, os seus problemas (não todos, mas parcialmente ). O hibernate é uma framework ORM (Object-Relational Mapping) ou Mapeamento Objeto-Relacional para Java. Segundo a documentação oficial: "o Hibernate pretende retirar o desenvolvedor cerca de 95% das tarefas mais comuns de persistência de dados".

O Hibernate é apropriada para modelos OO e lógica de negócios implementados em uma camada uma camada de uma aplicação baseado em Java.

DESVANTAGEM: não é a solução mais adequada para aplicações que utilizam stored-procedures para implementar suas lógicas no banco de dados.

O Hibernate é a framework de persistência Java mais documentada e utilizada (acessem o site: Hibernate.org). É mantido pela JBoss sob a licença LGPL.

Algumas de suas características:

• Suporta classes desenvolvidas com agregações, herança, polimorfismo, composições e coleções;
• Permite a escrita de consultas tanto através de uma linguagem própria (HQL) como também através de SQL;
• É uma framework que não restringe a arquitetura da aplicação;
• Implementa a especificação Java Persistente API (JPA);
• Grande a ativa da comunidade

Quem deseja conhecer mais sobre o Hibernate, estarei postando mais conteúdo pela frente ou então visite o site Hibernate.org.

Copiado de - Programação, Análise de Sistemas e Gerência de Projetos

Este mês teremos o prazer de ver quatro membros do CEJUG na 60ª edição da Java Magazine.
Confira logo abaixo os artigos dessa edição, bem como os membros do CEJUG, que estão destacados em negrito:

• Quick Update - Conhecendo o Quartz- Por: Igo Coelho
• A memória do Java- Por: Osvaldo Pinali Doederlein
• Enviando e-mails com Spring 2.5- Por: Edson Gonçalves
• M-Stocks App- Por: Ernandes Mourão Júnior e José Alécio Carvalho
• Introdução ao Framework ExtJS- Por: Christiano Milfont
• BeansBinding- Por: Serge Rehem e Alexandre Lima
• LWUIT: "Swing" para Java ME- Por: Antonio Marin Neto
• Hibernate e AspectJ- Por: Paulo César Coutinho
• JSR-311 e Jersey- Por: Bruno Pereira e Silvano Buback

Há um tempo atrás eu e uma amiga recebemos a seguinte missão onde trabalhamos: pesquisar algo sobre INTEGRAÇÃO CONTÍNUA. Fazemos parte de uma equipe de desenvolvimento de sistemas web em Java, composta por 7 membros. Visitamos vários sites, estudamos bastante e depois de um tempo a gente fez uma apresentação para todos.

Houve uma palestra no CCT onde o assunto era sobre INTEGRAÇÃO CONTÍNUA. Mas quero expor aqui sobre esse assunto para ajudar aqueles que estão querendo aprender e / ou implantar a INTEGRAÇÃO CONTÍNUA onde trabalham.

O que é INTEGRAÇÃO CONTÍNUA? Quais as vantagens? Quais as ferramentas? Como usar?

A INTEGRAÇAO CONTÍNUA é uma prática que consiste em integrar o código várias vezes ao dia, assegurando sua consistência ao final de cada integração.

Imagine só: a equipe onde trabalho é composta de sete membros. Cada um elabora casos de usos e envia o que foi produzido para o repositório. Antes disso, testamos o que foi gerado, mas é freqüente nos depararmos com erros na máquina do nosso colega.

A Integração Contínua é uma das práticas introduzida com o eXtreme Programming.

Se cada programador integrar o seu código pelo menos uma vez por dia, no final do dia teremos várias integrações.

Algumas vantagens da Integração contínua:

• eliminação de longas sessões de integração;
• os problemas de integração são detectados tão breve quanto o possível;
• as pessoas criam um sentimento de interdependência.

Para uma melhor prática da implementação da IC, Martin Fowler cita 10 práticas que são fundamentais:

1. Manter um repositório de código-fonte unificado;
2. Automatizar a construção do executável;
3. Usar testes automatizados;
4. Todos os membros da equipe devem atualizar o repositório diariamente.
5. Cada atualização do repositório deve iniciar a construção do executável;
6. Manter a construção do executável rápida;
7. Testar em um clone do ambiente de produção;
8. Tornar fácil que qualquer um obtenha o mais recente executável;
9. Transparência (qualquer um pode saber o que está acontecendo);
10. Implantação automatizada.

Para que a integração ocorra sem muitas dores, faz-se necessário o uso de algumas ferramentas. São elas:

* Ferramentas de build: essas ferramentas são utilizadas para agilizar o processo de build de um sistema, automatizando tarefas como: compilação do código do sistema, compilação e execução dos teste unitários e de aceitação; geração de relatórios dos testes, de cobertura e de análise estática do código; quaisquer outras atividades que sejam definidas como necessárias para o build.

* Ferramentas de controle de versão: ferramentas que armazenam e mantém a versão de todo código-fonte. É também conhecida como repositório. Essas ferramentas automatizam as seguintes tarefas: identificação de mudanças locais, exibição das diferenças entre o código de um arquivo local e uma de suas versões; identificação de quem realizou determinada alteração; incorporação de uma mudança em um arquivo armazenado no repositório; sincronização do código local com uma das versões do sistema ou de um arquivo armazenado no repositório. Temos alguns exemplos de ferramentas de controle de versão: Subversion, CVS, entre outros. Apesar de haver essas ferramentas, vale ressaltar que a integração só valerá a pena se não houver erros. Para tanto, faz-se necessário a automatização dos testes e que as ferramentas simplifiquem e automatizem o processo de integração contínua.

Há duas formas de se realizar a integração contínua:

• forma síncrona:não há a utilização de ferramentas que automatizem a integração. Cada programador integra seu trabalho de cada vez. Após o término da integração do código, o próximo programador poderá integrar o seu.
• forma assíncrona: Há a utilização de ferramentas que automatizam a integração. Alguns exemplos: CruiseControl, AnthillPro, Continnum, Team City, Luntbuild, Hudson, Scons, Bitten, Gump, TinderBox, Final Builder, Build Forge, Beetle Juice, entre outros. Essa prática só se torna viável quando a equipe mantém sempre o código fonte que existir no repositório funcionando.

A seguir, estão alguns links falando mais sobre IC:  Improveit, Programação, Analise de Sistemas e Gerencia de Projetos.

Clique aqui para saber como configurar o CruiseControl com o Subversion

No próximo dia 30 acontecerá o Café com Tapioca deste mês. O evento será na FLF iniciando as 09:00h com a primeira palestra.
Confira na página do evento todas as informações. Haverão sorteios de assinaturas das revistas JavaMagazine e WebMobile.