br-net.org

A próxima versão do Internet Explorer ainda está sendo desenvolvida, mas o beta chamou bastante atenção de alguns.

Uma das coisas foi o melhor suporte aos padrões (passou até no Acid2 :P). Mas o que vai chamar atenção mesmo do usuário é a utilização de recursos do computador.

Claro, os teste foram feitos com a versão beta, mas mesmo assim os número são bem significativos, tendo o necessário para ser considerado o bloatware do ano.

Só para você ter uma idéia, ele consome mais memória RAM do que o Windows XP. Imagine, mais do que um sistema operacional completo. São cerca de 350~400 MB. Não satisfeito, nos testes chegou a utilizar cerca de 150~200 threads de execução .

Não cheguei a testar o beta, mas só de ver estatísticas, já fiquei sem vontade. Melhor esperar que eles lançem a versão final e que melhorem o desempenho do seu navegador web.

Foi divulgada a lista dos projetos escolhidos pela comunidade do SourceForge.net, em diversas categorias.

Projetos como OpenOffice.org, phpMyAdmin, Linux, Wine e eMule ganharam o prêmio em categorias diferentes, para quem quiser dar uma olhada, acesse aqui.

O legal foi a participação de qualquer projeto, não só os que estavam hospedados no SourceForge.net, como foi nos anos passados. Mais chances para premiar projetos interessantes. Só acho que ano que vem, tem que ter mais categorias, pois foram muito poucas.

Ontem apresentei minha proposta para o Trabalho de Conclusão de Curso da faculdade. A princípio, o objetivo é criar um painel de controle para servidores de webhosting.

O diferencial seria uma interface flexível para trabalhar com vários serviços e não utilizar somente um, como são os painéis atualmente. Se a configuração de cada serviço for feita por um módulo, é mais fácil criar um módulo para usar um serviço diferente.

Por exemplo, o Plesk usa o qmail, um software que eu não gosto. Outros sysadmins também podem não gostar. Só que se quiser usar ele, tem que viver com o qmail.

Como não tinha muitas idéias, dá pra dizer que essa foi praticamente a única coisa que eu podia fazer. Esse trabalho vai ser grande, espero ter tempo suficiente para terminar até o final do ano.

Pelo menos a proposta acho que os professores gostaram, espero que o trabalho final fique bom :)

Para quem não sabe, na versão 2.4 do Pidgin, um novo recurso foi adicionado: o de redimensionar automaticamente a caixa de texto para o tamanho da mensagem.

O problema é que muitos usuário não gostaram da idéia. Então alguém abriu um ticket no bug tracker solicitando que a mudança fosse revertida ou que fosse opcional.

O problema é isso gerou uma discussão imensa. O ticket virou praticamente uma thread de fórum. Até criaram um fork .

Eu, particularmente não me incomodei com o novo recurso, mas entendo que muita gente não deve ter gostado. Lendo os "comentários" do ticket, Sean Egan explica que a intenção original era de que a caixa de texto aumentasse conforme o necessário, mas que o usuário também pudesse definir um tamanho fixo. Só que o GTK+ não permite que o tamanho seja automaticamente redimensionado caso o usuário o tenha alterado manualmente.

De qualquer forma, devido ao grande número de reclamanções, deveria ser adicionada uma opção para desabilitar o redimensionamento automático. Se o funcionamento não estava com o planejado, porque incluir então? Na minha opinião, as duas opções deveriam estar disponíveis, mas por enquanto acho que vai continuar assim.

Mas também não faz sentido fazer um fork do projeto, só por causa da caixa de texto. Provavelmente esse fork vai sumir logo, já que o Pidgin parece ser um projeto difícil de manter.

Vamos esperar que os desenvolvedores e usuários encontrem a melhor maneira de resolver essa situação.

Perl é uma linguagem que é usada em vários ambientes, porém não é tão falada como as outras. Aqui no Brasil, muitos não conhecem, alguns só ouviram falar e outros acham que ele está "morrendo".

Algumas das coisas que dificultam a adoção da linguagem, é que existem alguns mitos muito divulgados, porém não são verdadeiros.

Alguns deles são mais conhecidos, como os citados por Tim Bunce (criador do módulo DBI, para interação com banco de dados).

Perl está morto

"Ainda se usa Perl?". Essa deve ser a mais comum. O fato é que, se Perl fosse eliminado da face da Terra neste exato momento, muito sites (grandes) iriam parar de funcionar, servidores com sistemas rodando em Perl, sistemas de missão crítica, entre vários outros...

No Brasil o Perl não é tão forte quanto em outros países, mas ainda é bastante usado. Muitas pessoas nem sabem que alguns dos seus sistemas funcionam utilizando Perl por baixo dos panos.

Veja abaixo um gráfico sobre empregos de diferentes linguagens de programação:


Você pode gerar este gráfico atualizado aqui .

Claro, Perl não é a mais usada, mas não é o que você chamaria de algo que está em desuso...

O CPAN, onde é centralizada a distribuição de módulos da linguagem, tem cerca de 620.000 visitantes únicos por mês. Fora os que já se acostumaram a usar o CPAN pela linha de comando, mais o perldoc. Além disso, o número de upload de módulos por mês só vem aumentando a cada ano.

Os outros mitos citados, incluem "Perl é difícil de ler/testar/manter" e "Perl 6 está matando o Perl 5". Nenhuma das duas é verdadeira, assunto para outro post (você também pode ver na apresentação de Tim Bunce).

A verdade é que Perl é uma linguagem importante e tem uma comunidade muito ativa e organizada. A última versão estável é a 5.10.0, lançada em dezembro de 2007. Caso se interesse, pode aprender com um curso por e-mail.

Só não esqueça, Perl is alive! .

Hoje saiu a grade preliminar da programação do fisl. Quem quiser dar uma olhada pode acessar neste endereço.

Ela ainda não está completa, mas já tem muita coisa boa ai para assistir. Dando uma olhada por cima, essas são as que achei mais interessantes:

17 de Abril

- Can you survive a downtime? (Tirthankar Das)
- Uma Solução de Firewall Redundante com OpenBSD, CARP e PFSync (João Salvatti)
- Profissionalismo para nerds - Eu já sei o que eu vou ser quando crescer (Sulamita Garcia)
- The Postgres Application Server (David Fetter)
- Understanding the Kernel Network Layer (Breno Leitão)
- Network Forensic - Coleta e Análise de Evidências dos Ativos da Rede com Ferramentas Livres (Sandro Melo)
- Creative Commons and the Problem with Copyright Law (Maureen O'Sullivan)
- Multiterminais (Paulo Ricardo Zanoni, Luis Carlos Erpen de Bona)
- Fazendo Um Elefante Passar Debaixo da Porta (Fabio Telles)

18 de Abril

- Encontro Sul-americano de Perl - YAPC::SA::2008 (Flávio S. Glock)
- Engenharia de Software e Software Livre: tudo a ver! (Antonio Terceiro)
- Clonando Pinguins com System Imager (Cesar Augusto Domingos, Caio Candido)
- Backup prático, porquê precisamos evoluir ! (Solli Moreira Honório)
- Proposta de uma Metodologia de Migração de Software Proprietário para Software Livre com Foco no Usuário (Ramon Simões Abílio, José Monserrat Neto)
- Por trás das firulas do X (Tiago Vignatti)
- Segurança de Aplicações e Arquivos de Sistemas com AppArmor (Carlos Alberto Ribeiro, Vagner Farias)
- Liberdade educacional - o uso de softwares livres na educação (Frederico Gonçalves Guimarães)

19 de Abril

- Plenária Debian Brasil (Felipe Augusto van de Wiel)
- Software Livre na Educação Universitária : Os estudantes de computação e o software livre (José Honorato Ferreira Nunes, Adilson Barros Soares, Renata de Andrade Pereira)
- Keeping 200 firewalls on track (Ernesto Silva, Andres Tarallo, Enrique Verdes)
- Prevenindo XSS: Execute apenas o SEU código (Er Galvão Abbott)
- Jornalismo Livre: proposta de incorporação da liberdade na prática jornalística (Rafael Evangelista, Tiago Soares)
- Combining Linux High Availability Clusters with Data Replication (DRBD) (Mark Bilansky)
- Tradução de Software Livre (José Ernesto Mortara San Martin, Fabiano Sant'Ana)
- GGZ: Progresso na área dos jogos livres na internet (Josef Spillner)
- Port Knocking? Esqueça. Abrindo portas remotamente no iptables com Single Packet Authorization. (Jansen Carlo Sena)
- Uma solução de implementação do conceito de Rede Segura, utilizando o padrão IEEE 802.1x em ambiente híbrido (Luis Antônio Schneiders)
- O que é ODF e qual a sua importância (Jomar Silva)
- Fun and Software Livre! - Return of the Jedi! (Jon 'Maddog' Hall)
- VIM para desenvolver (Luiz Guilherme Ribeiro Sanches)

Tomara que eu consiga ir nos 3 dias dessa vez, já que ano passado em só pude ir no último. Senão, vou perder palestras bem legais, bem como o YAPC::SA::2008.

Depois da Microsoft decidir que o Internet Explorer 8 não iria utilizar os padrões atuais para renderizar as páginas, eles resolveram voltar atrás.

Como eu tinha dito anteriormente em um post, o certo seria por padrão, o IE 8 renderizar as páginas de forma mais compatível possível com os padrões atuais. Porém, eles queriam que os desenvolvedores especificassem fosse para usar a nova engine.

Isso não faz sentido, e eles resolveram mudar. Agora, por padrão o IE 8 irá renderizar da forma mais correta possível os padrões e os desenvolvedores que quiserem seguir utilizando as engines antigas, devem especificar explicitamente, como eu tinha sugerido no post anterior.

Claro, essa mudança pode ter acontecido juntamente com as decisões da Microsoft para melhorar a interoperabilidade, que foram anunciadas recentemente. Pelo menos já é mais um passo na direção certa.

Ultimamente, dá pra notar que aos poucos, a Microsoft vai se aproveitando de algumas das idéias da comunidade Open Source e de Software Livre, para de alguma forma incorporá-la nos seus produtos. Não esquece que as coisas sempre foram mais ou menos assim.

Mas agora, chegou a vez do Windows Server aproveitar os recursos dos sistemas Unix-like. Um post muito interessante, feito por Sam Ramji, Diretor de Tecnologia Estratégica Open Source, onde ele explica como o Windows Server 2008 foi influenciado pelo Open Source. O ISS 7 (servidor web) é mais modular, o ambiente permite a utilização de outras linguagens (não somente as da Microsoft), é possível fazer instalações mais simplificadas rodando somente serviços essenciais e também o PowerShell, que permitirá que um sysadmin possa fazer mais coisas (ao contrário do shell horroroso das outras versões).

Ou seja, a Microsoft está tentando aplicar agora, conceitos que os sistemas *nix usam a décadas. Será que isso não irá afetar como os administradores utilizam aos servidores? Será que eles vão se adaptar as mudanças? Esses é o problema do Windows, a cada versão você tem que reaprendê-lo. Em sistemas Unix-Like, geralmente são pequenas coisas que mudam, fazendo com que seja mais fácil uma possível migração.

Depois de algum alvoroço, a Microsoft está se aproximando muito do Open Source nos últimos dias. Depois de liberarem especificações de alguns de seus produtos para uso não-comercial, do site deles incentivar o desenvolvimento Open Source, agora eles querem fazer uma implementação do projeto GNU e suas ferramentas para o Windows, chamado UNG (apesar de não estar confirmado).

Quem deve estar se perguntando "o que está acontecendo?" é o Steve Ballmer, que é conhecido por sempre criticar e atacar a comunidade Open Source. Vendo essas coisas acontecerem deve ser um choque contra os ideais que ele tem. Depois dizem que os usuários de sistemas livres que são xiitas.

Será que a nova estratégia da Microsoft é se unir ao Open Source? Se o objetivo é a interoperabilidade, acho que é bom para os dois sistemas. Eles estão entrando no mesmo bonde, provavelmente pelo crescimento que os projetos livres têm tido nos últimos anos, bem como a popularidade de linguagens de desenvolvimento rápido que só vem aumentando. Será que a Microsoft realmente quer jogar junto, ou estão planejando alguma coisa? Vamos descobrir de um jeito ou de outro...

Sabe aquela famosa frase de Ghandi que as vezes é usada para referenciar a Microsoft ao Open-Source?

"Primeiro eles o ignoram.
Então riem de você.
Depois eles o combatem.
Então você vence." - Mahatma_Gandhi

Pois acredito que estamos em algum lugar entre a 3ª e 4ª parte. A Microsoft está tentando achar uma forma de combater o movimento Open-Source como um todo, ou pelo menos lucrar com ele.

Como dizem, uma imagem vale mil palavras, um artigo que saiu uns dias atrás no ZDNet, mostra o que o pessoal da Microsoft está "planejando":


Então, o que significa a imagem? Que a Microsoft planeja, além te rodar software open-source no Windows, que ele esteja ligado com seus ambientes proprietários, como o Active Directory, Microsoft Office e SQL Server. Tudo isso para atrair atenção de seus clientes para a sua solução.

Isso, além de dar motivo para manter empresas com o Windows ao invés de Linux, fará com que estas fiquem presas ao seu modelo proprietário, o que justamente o movimento do software livre/open-source luta contra.

Não sou contra o uso de FOSS no Windows, pelo contrário, acho ótimo que os desenvolvedores portem seus projetos para o Windows. O que eu sou contra é atar um software livre a um modelo proprietário.

Essa é a estratégia que devemos ver daqui pra frente. Mesmo parecendo estranho, trabalhar junto ao open-source parece fazer muito sentido para a Microsoft atualmente.

Ontem, foi o dia que o projeto GoPHP5 concluiu o seu objetivo. Fazer o máximo de projetos e grandes empresas de hosting a passar a suportar somente o PHP5.


Para projetos, isso faz muito sentido. Cortar o suporte do PHP4, força os usuários a utilizarem o PHP5, o que contribui para deixar de lado a versão antiga e que não é muito compatível com a nova. Uma data foi estipulada para que isso acontecesse (5 de Fevereiro de 2008), assim as empresas de hosting poderiam atualizar seu servidores.

Na época que foi lançado o PHP 5.2, poucas empresas de hosting o tinham disponível. O motivo era ser muito novo, e histórico ruim do PHP 5.0 e 5.1. Com o lançamento do 5.2, os problemas foram resolvidos e essa versão que deve ser usada, para permitir que a tecnologia avance.

Se os usuários e programadores ficarem presos a uma tecnologia antiga, mesmo que estável, impede que ela avance, fazendo com que ela fique "parada". O projeto foi uma ótima idéia para impedir que isso acontecesse.

Muitos projetos aderiram ao movimento, como DeluxeBB, Drupal, RoundCube, Moodle, PEAR, phpmyadmin, phppgadmin e diversos outros que podem ser vistos aqui.

Vamos ver até quando o PHP5 irá ficar na cena e se vai durar tanto quanto o PHP4.

O Internet Explorer sempre é muito criticado (e com razão), por ser o browser que mais dá dor de cabeça para os desenvolvedores web. A razão é não seguir os padrões web, para renderizar páginas que deveriam ficar iguais em todos os browsers.

Pois bem, o IE 8, que será mais compatível com os padrões (já até passa no teste Acid 2) terá três modos de renderização:

- "Quirks mode" - aquele que vem lá dá época do IE 5.5, que não utiliza uma tag DOCTYPE.
- "Standards mode" - o que está sendo utilizado no IE 7.
- Novo "Standards mode" - que irá usar a nova engine do IE 8.

Adivinhe qual será o padrão? Se achou que era a nova engine se deu mal, pois a Microsoft irá manter os modos de renderização do IE 7 como default. E como utilizar o novo IE 8? O desenvolvedor terá que utilizar uma tag <meta> para poder indicar o novo modo renderização:

<meta http-equiv="X-UA-Compatible" content="IE=8" />

E dessa forma, eles vão conseguir estender ainda mais esses sofrimento que é desenvolver sites que renderizam da mesma maneira em todos os navegadores. A idéia é migrar o software, continuando com a engine antiga, e habilitando pra quem quiser a engine nova. Deveriam ter feito o contrário: utilizar por padrão a nova engine e permitir a utilização da engine antiga para os sites que ainda estão para serem migrados.

O fato é que quando ele for lançado, não haverá mudanças no modo de renderização das páginas. Isso fará com que boa parte das novas páginas que sejam desenvolvidas tomando por ponto de referência a nova versão, estarão utilizando a engine antiga, fazendo com que os sites continuem fora dos padrões. Se fosse ao contrário, os novos sites já seriam mais compatíveis com os padrões atuais, diminuindo problemas no futuro, tanto para o Internet Explorer, quanto para outros browsers.

Num artigo sobre "Compatibilidade e o IE 8", Chris Wilson (IE Platform Architect) fala sobre a regra "Não Quebre a Web" que o time de desenvolvimento aplicou em 6 diferentes versões do IE. É possível dizer que mesmo essa regra existindo, dá a impressão que ela nunca foi aplicada, pois cada versão do IE acabou quebrando várias páginas, inclusive de grandes sites.

Talvez esse problema esteja diminuindo (lentamente), mas pelo menos é um passo na direção certa. Claro, na minha opinião poderia ser diferente, mas vamos ver até quando esse problema se estende.

A primeira versão do KDE 4 está marcada para ser lançada dia 11 de janeiro de 2008.

Uma das novidades é que o a nova versão está sendo portada para Qt 4, a biblioteca que é utilizada para os aplicativos dos vários projetos que envolvem o KDE.

Algumas números indicam que o consumo de memória diminuiu até quase 40%. Essas são ótimas novidades, e ainda possibilitou rodar "bem" utilizando 256MB de RAM e processador a 1Ghz (ainda com os efeitos 3D).

Aparentemente, parece que a biblioteca Qt4 ajudou bastante em relação à performance, mas em outros aspectos, as novas versões dos aplicativos estão aproveitando para melhorar também suas tecnologias.

O que tem se falado é a plataforma do KDE 4 e o que vai ser feito, assim que ela estiver pronta. Um post no blog do Amarok fala nesse assunto, inclusive dizendo que o verdadeiro potencial do KDE 4 (e conseqüentemente o Amarok2), só serão vistas depois que forem lançadas as próximas versões.

Ou seja, todo esse trabalho não é só para portar o KDE, e sim para melhorar e permitir que no futuro, ele possa evoluir. Estou bem interessado em saber como serão as coisas após o lançamento.

Espero estar compilando e instalando a nova versão do KDE assim que estiver disponível no portage (o que não deve demorar muito, espero). Assim que tiver testado ele, pretendo escrever sobre o que achei :)

PS: Para aqueles que tem interesse em rodar o Amarok no Windows, já podem ter esperança . Ainda precisa de trabalho, mas veja a screenshot abaixo:

Esse foi o tema do pôster que fiz para a oficina de iniciação científica na faculdade.

Depois de passar um bom tempo entendendo como o Inkscape funciona, cheguei à conclusão que ele não é tão difícil de utilizar. Na verdade, até gostei de fazer o pôster.

Os tutoriais que tem no site ajudaram bastante, e consegui fazer algo "decente" para alguém que não tem muitas habilidades gráficas como eu.

Se você quiser ver como ficou, coloquei o PNG reduzido que exportei do SVG (o original ficou com 3189x4252px):


Tem bastante coisa que não coloquei, mas como me faltava espaço e tempo, acabaram de fora do pôster.

Uma das coisas que pensei hoje antes de sair de casa foi exportar para PNG. Fiz bem, já que nenhum dos lugares que fui tinham o Inkscape (fui em uns 3 eu acho), só Corel. Nem sei se o Corel importa arquivos SVG, pois não tenho para testar.

Fica a dica, se você for imprimir um pôster em cima da hora: exporte para uma imagem antes. Assim não corre o risco de ficar sem nada!

Ontem fiz um mini-curso durante a 3ª Semana Acadêmica da UCPEL sobre a linguagem de programação Erlang.

Ela é uma linguagem multi-paradigma, dando suporte à programação funcional e concorrente. Foi originalmente desenvolvida pela Ericsson, e liberada como open-source em 1998.

Uma das diferenças é que ao invés de utilizar memória compartilhada, como na maioria das linguagens que suportam threads, cada "processo" iniciado possui sua própria memória, utilizando mensagens para se comunicarem (e eliminando problemas como os de deadlock).

A princípio, a sintaxe me lembrou bastante o Prolog, só que de uma forma que achei "não tão chata". Trocar mensagens entre os processo da linguagem também é simples, permitindo que vários processos se comuniquem de forma simples.

Uma das implementações mais conhecidas do Erlang, deve ser o ejabberd, um servidor XMPP (Jabber), que inclusive utilizo no meu servidor. Com ele, é possível montar clusters para o servidor ejabberd e utilizar diferentes banco de dados para gerenciamento de usuários e mensagens do servidor. Não é a toa que ele é o software utilizado para gerenciar o servidor oficial do jabber.org (e utiliza o PostgreSQL como banco de dados).

Acho que o estudo da linguagem é interessante, pela simplicidade da mesma. Se o intuito é de trabalhar com projetos que utilizam excessivamente a troca de mensagens (como por exemplo, um servidor de mensagens instantâneas), é uma boa linguagem pra fazer a implementação.

Esses dias me proporam propuseram um desafio: tornar o HTML e CSS do blog válidos.

Eu tinha feito isso no template original, mas como fui adicionando mais coisas e o módulo que uso para converter BBCode para HTML (HTML::BBCode) cria código como <br />, acabei me esquecendo de manter o HTML válido. Apesar do <br /> não ser "errado" em HTML 4.01 Strict, é melhor evitar, segundo a W3C.

Outro problema é usar a tag <center>, o que não é permitido nesse Doctype (HTML 4.01 Strict). Já alterei o CSS e logo irei utilizar tags <div> para centralizar o que for necessário.

Já com o CSS, o problema é diferente: eu uso duas propriedades de transparência no menu lateral, que não são válidas em CSS, mas são interpretadas pelo browser corretamente ("opacity: x" para Firefox e "filter:alpha(opacity=x)" para IE). Esses dias testei no Konqueror o blog e vi que a transparência do menu não funciona, já que o Konqueror é o browser que mais segue os padrões.

Não pretendo mudar os HTML dos posts antigos, para serem HTML válido, mas os próximos já estarei escrevendo com isso em mente. Muita coisa que adicionei no blod depois, como widget, link externos e coisas do tipo, que geralmente é daqueles que já fornecem o html, não são válidos em HTML 4.01 Strict, então também precisei adaptá-los.

Falta pouca coisa, espero conseguir validar o blog em breve, tanto o HTML quanto o CSS.

#!/usr/bin/perl
use threads;

Já tem algum tempo que quero brincar com threads em Perl, e hoje comecei a fazer alguns exemplos e escrever pequenos programas.

Achei bem interessante, principalmente podendo fazer mais de uma coisa ao mesmo tempo. Dependendo do tipo de programa, é possível obter uma boa melhora no desempenho utilizando threads.

Mas como já dizia Ben Parker, "grandes poderes trazem grandes responsabilidades". É preciso tomar cuidado com o acesso a data compartilhada, principalmente se mais de uma thread usa uma determinada variável.

Isso, porque durante uma leitura e escrita de uma variável, é possível que outra thread tenha alterado o valor da variável e isso causaria resultados indesejados.

$count++;

O código acima faz 3 operações: obtem o valor de $count, incrementa em 1 e salva novamente na variável. Se no tempo em que ele está incrementando o valor, outra thread tiver feito isso, ele não terá o novo valor, que será sobrescrito pelo seu (o que geralmente não é nada bom...).

Se alguém se interessa em usar threads em Perl, recomendo ler a documentação (perldoc perlthrtut), que foi o ponto de partida que usei para começar a usá-las.

Atualmente tenho visto muitos aplicativos que são muito complexos e que acabam atrapalhando a vida do usuário. Alguns tem uma implementação ruim, que só tende a piorar quando o software começa a crescer.

Estive lendo nesses últimos dias sobre o qpsmtpd, um daemon SMTP muito simples e flexível, escrito em Perl.

Ele é um software pequeno, simples, flexível, o que acabou resultando numa ferramenta poderosa. Ele somente "conhece" o protocolo SMTP, e todos os outros recursos são adicionados a partir de plugins (que também são escritos em Perl).

Uma das coisas que lembra ele é o bloqueio de spam. Ele consegue barrar várias coisas antes mesmo de serem processadas pelo servidor, de forma bem eficiente. Os servidores de e-mail do apache.org migraram para ele e diminuíram bastante a carga, podendo agora suportar sem problemas, cerca de 2 milhões de e-mail diários.

Outra coisa é que é extremamente fácil de escrever plugins para ele. Juntando isso com a facilidade do Perl para processar texto, temos uma ótima dupla.

Apesar de ser bom para receber e rejeitar e-mail, ele precisa de um MTA completo para poder funcionar. É possível mandar e-mail para um servidor externo, ou mandar mensagens diretamente para a fila do postfix, qmail, exim, etc...

Estou pensando em implementar ele para testar como ele se comporta recebendo e-mails e spams reais...

Achei um link bem interessante para uma página na Wikipedia num post do Slashdot, que de certa forma se refere ao assunto.

A página na Wikipedia faz uma comparação entre diversos frameworks web e seus recursos. Me arrisco a dizer que alguns dos mais conhecidos são o Rails (Ruby), Django (Python), Catalyst (Perl) e CakePHP (PHP).

Embora cada um tenha suas vantagens e desvantagens em um campo em especial. Desses 4, todos tem implementações próprias ou já existentes das partes de um framework
MVC.

De certa forma, todos valem a pena trabalhar, o melhor é usar um que você já conheça a linguagem, pois isso já ajuda bastante. Alguns também dependem de configuração adicional no servidor onde será hospedado.

O mais de fazer rodar provavelmente deve ser o CakePHP, já que praticamente todos os servidores possuem suporte a PHP e ele não precisa nada em especial. O mod_perl também é encontrado em vários servidores, facilitando o uso do Catalyst. Já o Rails e o Django precisam ter as linguagens instaladas (geralmente o Python já está, mas o Ruby é mais difícil), e também dependem de FastCGI ou um servidor web dedicado para isso.

Claro, existe a possibilidade de rodar qualquer um dos 4 como CGI, mas ninguém em sã consciência faria isso num ambiente de produção.

Eu comecei a usar o Catalyst faz quase um ano (uso moderado), e gostei muito dele. Uma das vantagens dele é a sua flexibilidade. Basta olhar na página na Wikipedia. Escolha não é o problema, veja alguns exemplos:

ORM - DBIx::Class, Rose::DB, Class::DBI::Sweet;
Template - Template::Toolkit, HTML::Template, HTML::Mason;
Sessões - arquivos, banco de dados, FastMmap, Memchached;
Autenticação - banco de dados, LDAP, Htpasswd;
Cache - FastMmap, Memcached, BerkeleyDB, FileCache;
Validação de formulários - FormValidator, FormBuilder.

Bastante coisa pra escolher, tenho gostado bastante de trabalhar com ele. Mas se quiser saber o melhor deles, leia mais sobre cada um para saber qual a melhor escolha para o que você precisa.

Hoje apresentei um trabalho na faculdade sobre a metodologia de desenvolvimento chamada Extreme Programming (XP).

Achei a metodologia bem interessante e também um pouco familiar. Nada de ficar fazendo diagramas e não sei o que mais. É melhor começar a trabalhar direto no projeto em si.

O conceito de programação em pares é interessante, já que dois são mais produtivos do que um. Pra resolver problemas e encontrar erros, melhor ainda.

Eu gosto dessa metodologias de desenvolvimento ágil, que partem direto para ação. Uma das vantagens em relação aos modelos tradicionais, é a simplicidade (pra que complicar?).

Vi outros trabalhos, mas entre eles, achei o XP mais vantajoso no geral. Claro, isso muda de acordo com a situação...

Escolher qual hospedagem usar, nem sempre é fácil. Umas tem os recursos que precisamos, outras não. Do mesmo jeito, algumas são boas e outras não.

Aqui no Brasil, a maioria dos blogueiros prefere hospedar seus blogs fora do país, pois assim podem aproveitar preços mais baixos, e maiores recursos (que no exterior, é comum). O problema é achar uma boa hospedagem.

O site Web Hosting Unleashed possui uma ferramenta bem interessante, para comparar diversas empresas que oferecem serviços de webhosting (por enquanto eles tem "só" 2.084 empresa cadastradas). Cada empresa de hosting cadastrada tem ao menos 1 review, seja ele positivo ou negativo. A vantagem é que é possível filtrar esse banco de dados pelo número de reviews, nível de recomendação, notas dadas para suporte e valor e as que possuem cupons de desconto. Para fazer uma busca, vá nessa página.

Outra coisa legal é o que o site também tem recomendações para quem busca coisa específicas, como hospedagem com Rails ou JSP. Também possuem recomendações para que quer um VPS, um painel de controle com sistema de revendas e até com sistema de faturamento.

Uma das coisas que eu senti falta, é a busca por recursos que cada hospedagem oferece, já que seria bem útil para buscar o que precisamos. É um recurso interessante que certamente devia ser adicionado. Enquanto a maioria só precisa de PHP e MySQL, outros (como eu) tem necessidades diferentes.

Por enquanto, vou mantendo meu blog no meu servidor "doméstico", enquanto não tenho necessidade. Se fosse tirar ele daqui, precisaria ter Catalyst instalado, mais Perl e FastCGI e não é todo mundo que oferece isso, infelizmente.

Allan Leinwand acha que o Google deveria comprar a Adobe, pois o seu futuro em relação ao mercado de vídeos depende de tecnologias como o Flash.

Com a Microsoft quase terminando o Silverlight e a Sun preparando o JavaFX, a guerra vai ficar acirrada, já que até agora, o único jogador era o Flash da Adobe.

As vantagens do Flash é que ele roda em várias plataformas, porém tem algum problemas (no Linux, a Adobe até hoje não resolveu o problema de transparência). O JavaFX também rodará em todas as plataformas onde o Java está disponível, porém não tem uma base tão grande como o Flash. O Silverlight vem com a vantagem de se poder usar qualquer linguagem disponível no framework .NET. A desvantagem é que o Silverlight não está disponível para Linux (surpresa?), somente para Windows e OS X.

Eu não tenho favoritos, nem preferidos nesse caso. O melhor pra mim seria a evolução e disseminação do AJAX, mas ele não foi feito para aplicações interativas ao nível do Flash por exemplo.

Porém, o JavaFX é GPL, isso já melhora, pois software livres podem ser implementados e portados com mais facilidade. A Microsoft disponibilizou partes do código no CodePlex, porém eles não tem plano de liberar todo o código. Sem isso, não há como ele ser portável e isso não é nada bom. Já o Flash é software proprietário, mas funciona (com alguns problemas) nos 3 sistemas operacionais mais usado (porém, não funciona em sistemas 64 bits, que aos poucos estão começando a ser usados).

No fim, fico na dúvida entre qual das tecnologias deveria apoiar. Mas pra mim, a opção "menos ruim" é a do JavaFX. O melhor seria algum padrão aberto, assim podia ser implementado facilmente em várias plataformas, de várias maneiras.

Vi esse post bem interessante no Slashdot que fala sobre o HTML 5 e dos vários novos elementos que serão adicionados.

O artigo é da IBM e eu achei bem interessante. O pessoal que gosta de Web Standards também vai achar legal.

E como mostrar exemplos é bem mais fácil do que ter de explicar, você pode ver vários exemplos de como seria o HTML de um blog (primeiro exemplo) em HTML 4 e HTML 5. Vejam no artigo do link acima.

Realmente, os novos elementos facilitam bastante o entendimento do código. Elementos como <section>, <article> e outros, irão fazer parte da sua estrutura.

Só basta saber se com isso o pessoal vai seguir os Web Standards. Eu ainda tenho que aprender bastante sobre isso, mas é um assunto interessante.

A algum tempo eu venho pensando em compilar uma distribuição para uso próprio, para não precisa gastar um bom tempo a cada vez que eu quiser reinstalar algo no micro.

O PC que uso para testes freqüentemente recebe instalações de diferentes distribuições e isso acaba gerando problemas quando quero voltar a usar outra (especialmente porque ele roda gentoo, na maior parte do tempo).

Estou pensando em compilar uma e deixar pronta, para que eu possa usá-la no meu e talvez outros PCs. Também é interessante para mostrar para os amigos, já que pretendo deixar tudo configurado (pra que fazer várias configurações novamente?).

Nisso, fiquei pensando: Gnome ou KDE. Realmente gosto dos dois, fica complicado escolher entre um ou outro. Parei para pensar um pouco sobre cada um e acabei escolhendo o Gnome (os motivos pode virar um post). Mas talvez minha opinião mude com o lançamento do KDE4 (que estou esperando para testar).

Bom, sei que vou ter bastante trabalho, mas trabalho bem feito uma vez vale por várias. Quem usa gentoo sabe disso :P

Hoje resolvi adicionar um novo recurso no blog. Se você está na página inicial, provavelmente não está vendo-o, mas se quiser, pode clicar no título do post ou no link "avaliar esse post" no fim dele.

O motivo pelo qual adicionei esse recurso é para receber o feedback sobre os posts, assim eu posso melhorá-los.

Preferi deixar somente quando o post é mostrado individualmente, assim deixo a home mais limpa. A princípio a programação foi simples e até usa um Ajax :P

Apenas precisei criar mais uma tabela, uma classe no DBIx:Class (model), outro método "feedback" no controller dos posts e alterar o template (view). Viva o MVC.

Vamos ver se isso vai prestar...

Meu player favorito está quase chegando à versão 2, o que provavelmente ocorrerá junto com (ou logo após) o lançamento do KDE4.

Atualmente, o Amarok é a única aplicação que me faz ter a biblioteca Qt instalada nas máquinas onde uso só Gnome/Gtk. Ainda não vi outro player do mesmo nível que ele.



Se você ainda não conhece o Amarok, eu recomendo. Existe um pacote nos repositórios do Debian e Ubuntu e uma ebuild para o Gentoo no portage também. Ainda não tem versão pra Windows, mas como (se não me engano) o KDE4 terá ports para ele, acredito que no futuro você também possa usá-lo.

O SimplyMEPIS é uma distribuição bem conhecida (mais no exterior), que fez uma transição de distribuição base do Debian para o Ubuntu. Porém, parece que irão voltar a usar o Debian.

O principal motivo, segundo Warren Woodford (fundador do MEPIS) é que o Ubuntu Dapper Drake não está sendo atualizado da maneira que seus usuários esperavam. Ele foi atualizado com correções de segurança, mas não com novas versões de softwares.

Outro motivo, segundo ele, é que o Ubuntu é praticamente compilado do zero, já que ele usa os pacotes dos repositórios experimentais do Debian. Por isso, não é possível utilizar a atual versão (7.04 - Feisty Fawn), já que ela provavelmente herda menos código estável do que o Debian.

Então eles decidiram que vão usar o Debian 4.0 (Etch) para a nova versão do MEPIS, além de um kernel personalizado.

Uma das coisas interessantes que ele comentou foi que apesar de o código do Ubuntu ser compatível com o do Debian, os pacotes binários não são mais tão compatíveis como eram antigamente.

Mais informações no DesktopLinux.com

Cada vez mais a Mozilla Corporation está se focando mais no Firefox e deixando de lado o seu outro produto, o cliente de e-mail Thunderbird.

Não sou um grande fã de clientes de e-mail. Não usaria um com minha conta do Gmail, pela falta de suporte a IMAP, mas uso (o Thunderbird) para o e-mail do domínio do blog (que utiliza o Google Apps), pois nesse caso não utilizo muito o webmail.

O fato é que dá muito problema usar o cliente de e-mail ao mesmo tempo, por causa da sincronização. Claro, se o seu provedor suporta IMAP, então não existe esse problema. Pena que o Gmail não suporta :(

Bom, mas voltando ao assunto, o Thunderbird pode ser abandonado pela Mozilla Corp., fazendo com que ele seja suportado por outro grupo/empresa/etc.

Eu acho que a Mozilla Foundation irá suportá-lo, mas a diferença é que a Mozilla Corp. utilizava seu lucro para pagar o desenvolvimento do Firefox e o Thunderbird, enquanto a Mozilla Foundation é uma entidade sem fins lucrativos (o que pode desaceler o desenvolvimento do Thunderbird).

Por outro lado, o foco no Firefox irá aumentar. Pensando bem, eu acho que é uma boa jogada. Acho que o desenvolvimento de um browser realmente precisa de mais atenção do que o de um cliente de e-mail. Até porque muito mais gente usa o browser do que o cliente de e-mail.

Ontem estava lendo um tutorial sobre a linguagem C++, que parece ser bom (o tutorial, não a linguagem) para quem já tem alguma noção de programação.

De início, já senti algumas coisas, como tipagem estática (que não gosto). A sintaxe em si, é bem parecida com Java (que aprendi esse semestre na faculdade), então acho que isso facilita pegar as coisas.

Claro, tem seus fortes e fracos. O que eu achei interessante, foi o sistema de ponteiros, realmente algo poderoso (e que tiraram no Java). No fim, estou achando C++ mais interessante que Java (vão dizer que sou louco, eu já sei :P).

Ainda não cheguei na Orientação a Objetos da linguagem, mas acredito que seja semelhante ao Java também (sem tirarem as coisas legais, como herança múltipla, que também não tem em Java). É o pŕoximo tópico do tutorial, então não falta muito.

Outra coisa que prefiro em C++ do que em Java: quando você atribui uma variável a outra, ela não passa uma referência dela e sim o valor. Acho isso beeeeem melhor, e pra quando se precisar, tem os ponteiros.

No final, ainda prefiro Perl, pela facilidade de codar. Escreve pouco, faz muito. Mas tenho que aprender C++ para ter uma base sólida para o desenvolvimento de jogos. Fazer o que...

Esse é assunto que tenho lido bastante nos últimos dias. Encontrei várias engines interessantes (e outras nem tanto), mas as que mais se destacaram, foram o Ogre3D e o Crystal Space.

O Ogre3D é uma engine gráfica, ou seja, é necessário bem mais coisas para desenvolver um jogo, pelo mais simples que seja. É preciso tratar a entrada (input) do usuário, colisões, som, rede (se for necessário), entre outras coisas.

O Crystal Space é uma engine para jogos, o que já traz tudo que o Ogre não traz, porém, parece não ser tão flexível quanto o Ogre. Pelo que vi nas galerias dos dois projetos, os gráficos gerados pelo Ogre parecem ser melhores, na maioria dos casos.

As duas engines são software livre, e as duas suportam o Blender. As duas tem pontos fortes e fracos diferentes, mas acho que vale a pena aprender alguma.

Mas não importa qual delas, se eu realmente for estudar alguma, uma coisa é necessária. Saber C++. Acho que essa é a base pra quem quer criar jogos. Nessa, terei que aprender a codar no C++ e deixar as facilidades do Perl de lado (mas só pra jogos, pois ainda usarei Perl para web, scripts e talvez algum programa quando necessário).

No final, ainda estou na dúvida. Porém, se fosse apostar minha fichas, seria no Ogre. O suporte da comunidade parece ser melhor, sem contar que tem até um livro sobre ele (que não sei se existe no Brasil). No final, se realmente decidir continuar, terei que aprender C++ também :(

Para quem não sabia, o projeto Compiz e o Beryl, se juntaram no Compiz Fusion e suportam o site opencompositing.org (já faz um tempinho).

Mas vi esse vídeo que o Vinícius postou, e tive que postar também. É incrível ver o que os desenvolvedores estão fazendo, coisa realmente de primeira.



No vídeo acima, são mostrados os últimos recursos do Compiz Fusion. Vai dizer que o desenvolvimento contínuo não é melhor do que outros softwares, que lançam "novidades" (isso é questionável, porque geralmente são coisas já bem conhecidas, as vezes, ultrapassadas) uma vez em anos e o troço fica estagnado depois disso.

Coisas que são novas para mim, é a possibilidade de selecionar várias janelas ao mesmo tempo, o efeito de reflexo do cubo, o efeito de fogo, e o que achei mais legal, a possibilidade de agrupar várias janelas em uma só. Isso deve ser bem legal, quando se trabalha com várias janelas semelhantes. Eu provavelmente vou usar isso para agrupar vários Scribes!

Nada como a evolução :D