Pretendo migrar o servidor de testes e de gerenciamento do projeto para minha própria rede interna, onde continuarei mantendo o servidor do projeto e controlando os tíquetes de suporte. Em caso de dúvidas, notificação de bugs ou requisição de tarefas etc., encaminhe sua mensagem através do formulário de contato.

O presente blog, embora não esteja mais tão ativo quanto outrora, deverá ser movido para outro servidor mais barato ou mesmo gratuito. Ele pode ficar fora do ar por algum tempo, contudo. Aceito sugestões de hospedagem gratuita que aceite bem o sistema Wordpress.

Lembrando ainda que aderimos ao microblog: http://identi.ca/daltux ou http://twitter.com/daltux, onde postamos com frequência.

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)

Estou escrevendo hoje para pedir seu suporte à campanha Toque Ogg (http://playogg.org).

Você está cansado de ser constantemente perturbado para baixar software proprietário e plugins para conseguir tocar os vídeos e ouvir as músicas que você deseja? Está farto de ver novos aparelhos que usam apenas formatos incompatíveis e restritivos de áudio e vídeo? Sabia que a causa disso não é a falta de conhecimento tecnológico, mas sim patentes de software e outras restrições legais?

Companhias de software proprietário tais como Microsoft, Apple e Adobe estão progressivamente empurrando formatos de vídeo e áudio que restringem o acesso e restringem os desenvolvedores de software, porém há uma alternativa que pode ser tocada em todos os computadores sem restrições: Ogg.

Ogg fornece formatos de multimídia de nível profissional. Ogg é utilizado extensivamente por projetos de software livre, artistas e um crescente número de distribuidores de música e vídeo.

Em breve, mais de um milhão de crianças e seus familiares receberão o computador XO, do projeto One Laptop Per Child, projetado para tocar e criar arquivos Ogg. Defendendo o Ogg agora, podemos ajudar a garantir que essas crianças ganharão acesso, ao invés de desnecessariamente terem restrições, a milhares de recursos e materiais educacionais na web.

Junte-se a nós agora na defesa do direito ao Ogg com quatro passos fáceis: instale o tocador multimídia VLC; entre para a lista de e-mail de defesa do PlayOgg; procure e compartilhe sites amigáveis ao Ogg; e coloque Botões PlayOgg em seu site ou blog. Após tudo isso, se você ainda quiser fazer algo mais, considere encorajar outros a fazerem o mesmo.

Comece aqui: http://playogg.org

Ogg na Wikipédia: http://pt.wikipedia.org/wiki/Ogg ]]> http://blog.daltux.com/2009/07/toque-ogg/feed/ 0 http://blog.daltux.com/2009/06/a-gripe-cesumar-sob-suspeita/ http://blog.daltux.com/2009/06/a-gripe-cesumar-sob-suspeita/#comments Fri, 26 Jun 2009 12:42:37 +0000 Dalton http://blog.daltux.com/?p=399 Segundo o jornalista Ângelo Rigon no Twitter:

Assim como a UEL, o Cesumar suspendeu aulas [do curso de Turismo] ontem por causa de suspeita de gripe suína com uma aluna de Turismo que esteve na Argentina.

Achei estranho, pois não ouvimos nem rumores sobre isso ontem durante a aula. Até fizemos piada, ao comentar sobre a UEL,

» Leia o artigo completo

saca-rolhas

vinho

Open a Wine Bottle on a Toilet Seat – Watch more Funny Videos

O que faz o desespero para tomar um gole, não?
Ponto para o fabricante da garrafa!

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á.

O navegador e várias de suas extensões utilizam bases de dados SQLite. Periodicamente, principalmente com o tamanho incrementado a cada vez que utilizamos o browser –histórico, cookies, trocentas extensões, o diabo a 4, etc.–, a base de dados necessita certa manutenção. Para esse caso, existe um processo de reorganização, desfragmentação, compactação ou seja lá o quê, chamado “VACUUM“. Isso também costuma ser feito em alguns bancos de dados mais robustos, como por exemplo o PostgreSQL. Entretanto, enquanto no PostgreSQL é possível automatizar isso (autovacuum), no SQLite não.

Segue a instrução de como proceder no Ubuntu ou em outras distribuições GNU/Linux. Presume-se que o pacote sqlite3 esteja instalado. Para se garantir caso faça algum excremento, obviamente é recomendável um backup do diretório de configurações do Firefox antes. Depois, quando tudo estiver preparado, execute algo como isto:
for f in ~/.mozilla/firefox/*/*.sqlite; do sqlite3 $f 'VACUUM;'; done

Se for o caso, substitua o caminho “~/.mozilla/firefox/*/“. Trata-se do diretório onde ficam as suas configurações do Firefox.

A dica foi obtida do artigo “Performance tip of the day” do blog Savanne.be. O autor estava tendo problemas de lentidão ao usar a “AwesomeBar”, nova barra de endereços do Firefox 3. O pequeno artigo originalmente foi escrito visando apenas o minúsculo script para shell de GNU/Linux, conforme supracitado. Em seguida, entretanto, outras pessoas enviaram comentários com receitas do bolo de Maçã e mais para o final um tal Derek A. Munzel e outros escreveram como ver isso através das Janelas de Redmond. Se a sua praia for alguma dessas, veja lá como proceder.

Essa operação é provavelmente algo de certa forma desconhecido. Tomamos conhecimento apenas acidentalmente, seguindo a linha de alguém no Identica ou no Twitter. Não lembramos mais quem foi mas, mesmo assim, fica a homenagem.

Cara, eu estou com inveja do autor original! Queria ter sido eu o criador de semelhante texto. Muito bom! Ilustra incrivelmente bem meu sentimento.

Considero um absurdo a prepotência de boa parte dos profissionais da área que acha que utiliza o único possível sistema que existiria, sendo que nem cumpre o papel básico de um sistema operacional, tampouco oferece a segurança necessária a ambientes multiusuário e de rede e sequer vem com aplicações úteis, etc.

Esse texto serve para que todos entendam que qualquer ambiente operacional é difícil para quem não está acostumado com ele, qualquer que seja. Mudança de paradigma envolve resistência. Isso vale também para os que utilizam “aquele” acreditando que todos o acham fácil.

Vou passar para todos esse artigo, em especial quando não me compreendem e acham que o modo deles de operar um computador é sempre melhor ou mesmo o único.

Em minha humilde opinião, se alguns especulam que os sistemas “tipo Unix” tentam chegar à “usabilidade” de Redmond na interface gráfica, pode-se afirmar que na arquitetura interna do sistema é o contrário. Redmond tenta cada vez adaptar seu sistema para que se torne mais parecido com Unix em suas características internas, mas isso vai ainda demorar muito enquanto não desistam e façam como a Maçã que largou mão de seu sistema próprio para adotar a arquitetura Unix oriunda do BSD, podendo focar em sua especialidade: a casca externa do sistema, ou seja, a interface do usuário, decisão muito feliz. Hoje, Mac OS X é a interface gráfica, tal qual o Gnome ou o KDE nas distribuições de GNU/Linux mais comuns, rodando sobre o Darwin (BSD). Quem permite isso é a arquitetura, proveniente de um sistema (Unix) que desde seu início, projetado por na década de 1970, é multiusuário e desenvolvido em camadas, ao contrário de Redmond que é desenvolvido em gambiarras.

Redmond poderia tentar fazer o que a Maçã fez.