O projeto, liberado sob a licença GNU General Public License 3.0 (GPLv3), está no Launchpad.

Deseja utilizar ou testar o chat? Para executar logo o programa, que dá a opção de rodar o servidor e/ou o cliente, abra este pequeno arquivo com o Java Web Start. Se a configuração de sua máquina estiver correta para o Java Web Start, a aplicação deverá ser automaticamente baixada e executada logo. Talvez seja questionado que a assinatura digital do arquivo não pode ser verificada e, nesse caso, basta clicar no botão “Run”.

Pode ainda salvar este arquivo DalTuxChat.jnlp em sua máquina (clique com o botão direito sobre o link e em “Salvar o destino” ou algo assim) e executar o programa a partir dele. Esta forma é interessante porque sempre o Java Web Start verifica se existe uma versão mais nova disponível on line e atualiza o programa mas, mesmo se o site estiver indisponível, a aplicação existe localmente e é executada.

Também é possível baixar o arquivo DalTuxChat.jar (atualmente 45KB) e executá-lo com java -jar DalTuxChat.jar ou apenas clicando-o duplamente, se seu sistema estiver devidamente configurado associando os arquivos JAR (Java ARchive) com o Java.

Este programa vem sem ABSOLUTAMENTE NENHUMA GARANTIA; veja detalhes na cláusula n. 15 da Licença.
Isto é software livre, e você pode redistribuí-lo sob certas condições; veja os detalhes na Licença.

Encontrei a dica em http://www.guj.com.br/posts/list/50295.java

Outra dica que sugiro, pelo menos a quem está acostumado ao Eclipse, é configurar o NetBeans a utilizar o perfil de atalhos de teclado “Eclipse”: menu Tools > Options > aba Keymap > combobox Profile (selecionar “Eclipse”). Eu não estava suportando usá-lo até descobrir essa opção.

Aliás, alguém saberia por favor dizer, se é que existe, qual é o atalho, ou pelo menos via menu, para comentar uma ou várias linhas de uma só vez? No Eclipse é Ctrl+Shift+C. Não acho isso em lugar algum do NetBeans.

A decisão do Debian de incluir Mono em seu principal método de instalação do GNOME em prol do Tomboy, que é um aplicativo escrito em C#, leva a comunidade a uma direção arriscada. É perigoso depender de C#, então devemos desencorajar sua utilização.

O problema não é exclusivo de Mono; qualquer implementação livre de C# levantaria a mesma questão. O perigo é que a Microsoft está provavelmente planejando retirar a força todas as implementações livres de C# resistentes algum dia empregando patentes de software. (Veja http://swpat.org e http://progfree.org.) Trata-se de um risco sério e apenas os tolos o ignorariam até o dia que de fato isto ocorrer. Precisamos tomar precauções agora para nos protegermos desta ameaça futura.

Isto não é afirmar que implementar C# seja uma coisa má. Implementações livres de C# permitem que os usuários executem seus programas C# em plataformas livres, o que é bom. (O Projeto GNU também tem uma implementação de C# chamada Portable.NET.) Idealmente, gostaríamos de providenciar implementações livres para todas as linguagens que os programadores têm usado.

O problema não é nas implementações de C#, mas sim no Tomboy e em outras aplicações escritas em C#. Se perdermos [o direito a] o uso de C#, perderemos as aplicações também. Isso não as torna antiéticas, porém significa que escrevê-las e utilizá-las é tomar um risco desnecessário.

Devemos sistematicamente nos organizar para depender das implementações livres de C# o mínimo possível. Em outras palavras, devemos desencorajar as pessoas de escreverem programas em C#. Assim sendo, não devemos incluir implementações de C# nas instalações padrão de distribuições GNU/Linux ou em suas formas principais de instalação do GNOME, e devemos distribuir e recomendar aplicativos não-C# ao invés das aplicações C# equivalentes sempre que possível.

Uma versão anterior deste artigo expressou incorretamente que o Mono seria agora instalado por padrão no Debian. Corrigimos este texto e nos desculpamos pelo erro.

• Cópias e distribuições literais deste artigo inteiro são permitidas no mundo todo, sem royalties, em qualquer meio, desde que esta nota esteja preservada.
• O texto original em língua inglesa “Why free software shouldn’t depend on Mono or C#” está disponível no site da Free Software Foundation (Fundação Software Livre)

O seguinte texto foi na realidade uma mensagem postada hoje por mim no fórum interno do curso de pós-graduação em Desenvolvimento Orientado a Objetos em Java. Achei interessante deixar o registro no blog, principalmente por considerar que seu conteúdo possa ser útil a alguém, embora o assunto seja bastante técnico e específico para quem lida com a linguagem Java.

No meu trabalho de conclusão de curso da graduação, assumi desde o início um padrão onde sempre retornava o Iterator no getAlgumaColecao() dos objetos de domínio. Isso inspirado por lições da disciplina Linguagem e Técnicas de Programação III, no ano passado, ministrada pelo prof. Arthur Zavadki, que desde então já pregava a idéia de evitar expor a coleção. Depois de um tempo, como isto não era muito conveniente por não poder utilizar p. ex. for(“each..”), passei a retornar a própria coleção como Iterable, mas isto também não era interessante por ainda permitir que a coleção seja diretamente manipulada por quem invoque o método, bastando um typecast para Collection. Aliás, a rigor isto também pode ser considerado um problema com o retorno de Iterator, que permite remoção de elementos durante a iteração.

Como sugerido pelo prof. Cesar Moro na última aula (turma 1), uma alternativa é criar uma nova coleção contendo referências para os mesmos elementos, tendo que percorrer a coleção original para tanto. Data venia ^[1], achei que isso não era muito prático, então lembrei na mesma hora do método clone(), disponível em diversas classes, que [em tese] faz aquele mesmo trabalho.

Fui mexer hoje em uma parte da implementação do meu TCC onde um «Bean» possuía o método public Collection<Posse> getPosses(). O atributo posses é um HashSet. Fiquei curioso e corri atrás de outras possíveis soluções.

Deparei-me primeiro com o método toArray(T[]) da interface Collection, que poderia ser utilizado da seguinte forma:
public Posse[] getPosses() {
return posses.toArray(new Posse[0]);
}
Encontrei uma discussão a respeito do toArray() em um site, levantando inclusive questões sobre sua utilização em multi-threading.

Outra solução que encontrei em seguida, bem interessante, é o método estático Collections.unmodifiedCollection(Collection), que escolhi utilizar da seguinte maneira:
public Collection<Posse> getPosses() {
return Collections.unmodifiableCollection(posses);
}
Portanto, é como costuma dizer o prof. Cléber Lecheta (graduação):

Existem mil maneiras de preparar Neston: escolha a sua.

Enfim, a maneira que escolhi é realmente adequada? A idéia é encapsular a coleção para que não seja alterada fora da classe à qual pertence. E quanto a questões como performance e escalabilidade, o que diriam? Se os professores e os demais colegas puderem participar, desejo ouvir a voz da experiência e agradeço desde já.

.NET

Novell

Eis a apresentação que, tal qual suas fontes de informações e imagens (site do Mono e Wikipedia), publicamos nos termos da GNU Free Documentation License:

• Apresentação – Projeto Mono (PDF, 777kB)
• Apresentação – Projeto Mono (Flash)

Deve ser útil como uma pequena fonte de informações iniciais sobre esse importante projeto.

Para quem quiser experimentar uma versão release candidate (candidata a lançamento), vá ao site de download. No momento da redação deste post, está disponível a versão RC3. Faça sua escolha, já que há considerável diferença de peso: o pacote “Eclipse IDE for Java Developers” é para programação geral em Java. Já o pacote para Java EE, bem maior, é destinado a quem também vai programar para a Web.

De qualquer forma, como a versão final deve ser lançada nas próximas semanas, ainda convém ter algum cuidado ao utilizar em ambiente de produção estes pacotes de previsão.

Java

Ubuntu

Pois bem, descobri sem querer querendo, pela “ajuda” (Javadoc) da classe java.sql.DriverManager, a razão de funcionar o carregamento do driver JDBC (do PostgreSQL, no caso) mesmo sem o prévio Class.forName("org.postgresql.Driver"). Pode testar: comente essa linha e deve funcionar normalmente.

É que no JavaSE-1.6 isso não é mais necessário. Eis o que diz o Javadoc da classe java.sql.DriverManager:

Applications no longer need to explictly load JDBC drivers using Class.forName(). Existing programs which currently load JDBC drivers using Class.forName() will continue to work without modification.

When the method getConnection is called, the DriverManager will attempt to locate a suitable driver from amongst those loaded at initialization and those loaded explicitly using the same classloader as the current applet or application.

O negócio é mágico agora então?

O arquivo do programa JUDE é para a Plataforma Java (Sun J2SE 1.4 no mínimo), independentemente do sistema operacional. Após descompactá-lo, para rodá-lo em sistemas tipo Unix (qualquer distribuição de Linux, Mac OS X, Solaris, FreeBSD, HP-UX etc.), conceda-se permissão de execução do script jude e o execute. Em sistemas de Redmond, execute o script jude.bat.

E, a propósito de algo que foi comentado pela Prof. Aline, convido os colegas a darem uma olhada em algo que escrevi em meados do ano passado: Curiosidades sobre testes de software.

• Artigo publicado originalmente em simaringa.com

Engenharia de Software

Ele já funciona e calcula corretamente o valor de FP de seu projeto (isto foi conferido pela professora), podendo ser utilizado normalmente, porém com algumas ressalvas. Existe pelo menos um bug conhecido que permanece nessa versão 1.0: ao fechar a janela dos ajustes de complexidade e abri-la novamente, alguma variável ainda não identificada está sendo acumulada, fazendo com que o cálculo seja modificado. Por enquanto, o jeito é clicar em Arquivo > Novo projeto, para zerar tudo.

Ficamos receosos de publicar o código-fonte do programa, por vergonha, pois foi feito com a maior pressa para ser entregue em um dia. Apenas depois foi anunciado que poderia ser entregue posteriormente, mas daí já estava praticamente tudo feito. Mesmo sendo desenvolvido com POG, mudamos de idéia, então distribuímos o programa sob os termos da GNU General Public Licence, versão 3, tal como publicada pela Free Software Foundation.

Download

O programa funciona em qualquer sistema operacional, contanto que esteja instalado o Java Runtime Environment 1.6.0 (“Java 6 JRE”) ou mais recente.

Binários (Java bytecodes)

Java Web Start

É a maneira mais ágil de executar o programa, se o ambiente de sua máquina estiver devidamente configurado. Clique aqui e mande abrir com o Java Web Start.

A maneira mais ágil de executar o programa seria clicar neste link, porém o servidor onde o arquivo se encontra ainda não está configurado corretamente para associar o arquivo com o Java Web Start. Contudo, ainda é possível utilizá-lo: basta salvar o pequeno arquivo em sua máquina como PontosPorFuncao.jnlp e abri-lo com o Java Web Start. Uma alternativa ainda pode ser, através do seu terminal de comandos (p. ex., se for no Gnome: Aplicações / Acessórios / Terminal; se for no Windows: Iniciar / Executar / cmd), digitar:
javaws http://blog.daltux.com/dist/PontosPorFuncao/launch.jnlp

Tradicional (JAR)

• PontosPorFuncao_1.0_dist.7z – 179kB, comprimido com o 7-zip.

Se o seu ambiente de trabalho estiver devidamente configurado para abrir arquivos JAR com a Máquina Virtual Java, abra o diretório descompactado. A partir daí, geralmente, basta um clique duplo sobre o ícone do arquivo launch.jar para executar o programa. Contudo, se isso não ocorrer, verifique com seu distribuidor do sistema operacional como fazer isso.

Código-fonte

• PontosPorFuncao.tar.gz – 366kB, projeto para NetBeans 6.