Arquivo da categoria: Opiniões

Clientes de Debug para PHP [Atualizado]

xdebug-logoDias atrás, participei da PHP Conference. O evento foi melhor do que as minhas expectativas e voltei cheio de ideias e dicas para por em prática. Uma das dicas foi começar a usar o xDebug pra valer. Chega de fazer debug com var_dump!

Quanto à instalação do xDebug, não tive problemas. O complicado mesmo foi escolher o cliente do debug. Pelo que tenho visto em posts e eventos, a maioria dos programadores PHP faz debug em uma IDE, na maior parte, o Eclipse PDT. Teoricamente (ou seja, segundo o site do xDebug) existem várias outras opções. Tentei testar todas as opções para linux na prática, algumas não saíram da teoria.

Testei o protoeditor como plugin do Kate (meu editor de código atual) e não consegui compilar por falta de algumas bibliotecas. Dei uma chance para o Eclipse, mas a lentidão e a quantidade de bugs dele me tiraram do sério (por isso o Kate é meu editor atual). Tentei o plugin do Emacs, mas também não consegui fazer funcionar (acredito que seja por falta de conhecimento). Pensei no Netbeans, mas não tive paciência para baixar e instalar. Por último ou não, testei o plugin do VIM, este sim funcionou perfeitamente!

Eu ainda gostaria que houvesse um programa para linux parecido com o MacGDBp, mas o VIM está cumprindo o objetivo com louvor, principalmente depois que eu li o vimtutor.  Aliás, com o que eu aprendi do VIM, deu até vontade de passar a usá-lo mais regularmente. Talvez em um futuro próximo…

Para facilitar a vida

Criei uns bookmarklets para adicionar as variáveis de ambiente do xDebug na página atual do navegador (o código ficou tão pequeno que coube até em um tweet – Pena que não dá pra ler direito). Se quiser usar também, arraste o link abaixo para sua barra de favoritos:

[xDebug] Start Session

[xDebug] Stop Session

[xDebug] Profile

Para agilizar o debug de scripts php-cli, também pode adicionar estes dois “aliases” em ~/.bashrc (para que sejam recriados em novas sessões do terminal):

alias xdebug_debugger='export XDEBUG_CONFIG="remote_port=9000 remote_enable=1"'
alias xdebug_profiler='export XDEBUG_CONFIG="profiler_enable=1"'
alias xdebug_clean='export XDEBUG_CONFIG=""'

Atualização – 31/12/2009: Adicionei dois bookmarklets (profile e stop xdebug – aproveitei para reduzir ainda mais o código :)) e um alias para iniciar o profile em linha de comando.

Até a próxima!

Kubuntu 9.10: Desta vez acertaram!

Desde que escrevi o post sobre o Kubuntu 9.04, tive uma experiência muito mais completa com ele. Por isso, estava aguardando ansiosamente uma nova versão. Não que eu tenha achado o Jaunty (9.04) uma versão péssima, mas ao utilizá-lo fui me deparando com vários pequenos bugs que juntos deixaram o sistema meio “sem sal”.

Quando finalmente chegou o dia do lançamento do Kubuntu 9.10 (Karmic Koala), não sabia se depositava minhas expectativas nele ou me conformava pensando que o Kubuntu não teria a mesma atenção aos detalhes que o Ubuntu.

Instalei a versão 64 bits, tanto no notebook quanto no desktop citados no post anterior. Devo admitir que me surpreendi. O novo Kubuntu melhorou muito! Ao comparar com a versão anterior, imagino o gigantesco trabalho da equipe do KDE e da Canonical.

imagem1

Uma lista de novidades está presente neste link, mas eu gostaria de destacar alguns itens que me chamaram a atenção.

KDE 4.3

Esta nova versão do KDE está muito mais bonita e estável. Se você utilizou a versão anterior, deve ter passado por inconvenientes como o gerenciador travar e voltar para a tela de login, ou uma grande perda de performance quando os efeitos da área de trabalho estão ligados.

Dica: Meu computador ficou ligado por muitos dias, aumentando muito o consumo de CPU do programa plasma-desktop. Usei o comando Shit+Alt+F12 para desabilitar os efeitos na área de trabalho e, logo em seguida, repeti a combinação para reabilitá-los. O uso de CPU voltou ao normal.

Amarok 2.2

O amarok da versão anterior era interessante e bonito, mas perdia muitas características se comparado com a versão 1.4 (para kde 3). A boa notícia é que algumas coisas da versão 1.4 voltaram a funcionar (Integração com a Last.fm, exibição de mídias em dispositivos conectados), outras funções foram melhoradas (Painel de contexto, lista de reprodução, personalização do layout), mas ainda sinto falta de algumas coisas (descrição nos episódios dos podcasts, equalizador). De qualquer forma, o amarok 2.2 já é meu player favorito.

Dolphin

Eu já gostava da versão anterior do dolphin. O que fizeram foi melhorar aquilo que já estava bom. E não foi pouca coisa, adicionaram preview das imagens nas miniaturas das pastas e agora também é possível ver um preview do video clicando em um pequeno botão play abaixo de sua miniatura.

Outros componentes também receberam melhorias consideráveis. É o caso do gwenview, kopete, network manager, kpackagekit (apesar de ainda estar confuso na hora de adicionar novos programas), etc. Ou seja, se você estava esperando o KDE 4 ficar maduro para sair do KDE 3 ou para experimentar o Kubuntu, a hora é agora.

Criptografar o código-fonte é uma boa ideia?

Usar uma linguagem de programação interpretada, normalmente, significa que o código-fonte terá que ficar no servidor de produção (no caso de softwares para a web). Em alguns projetos, isto é um problema. Uma solução para muitos é manter o código-fonte criptografado. Apesar de ser uma prática muito comum, acredito que para muitas pessoas esta não é uma ideia muito boa.

A pouco tempo, estava procurando por um módulo de uma ferramenta que estava personalizando. O módulo era gratuito e não foi desenvolvido pelos criadores da ferramenta, que é paga (desculpe por não poder citar o nome das ferramentas. Não se preocupe, isso não é muito importante). Instalei o módulo e quando fui usar, percebi alguns erros. Logo pensei: “Não me parece muito difícil de consertar, talvez eu possa consertar rapidamente e mandar as alterações para os desenvolvedores”. Como vocês já devem imaginar, o código-fonte estava criptografado.

Não consegui imaginar porque alguém criptografaria uma ferramenta assim. Ao ler a página dos desenvolvedores, descobri que a estratégia era cobrar uma mensalidade para obter suporte (ainda assim, sem o código-fonte). Não sou um militante do FOSS (acredito eu), mas acho que criptografar o código e cobrar o suporte, neste caso, é um tremendo tiro no próprio pé.

Imagino que os criadores do módulo não disponibilizam o código por medo de que algum “concorrente” venda ou ofereça suporte ao produto deles. Este risco existe. Mas esta ação não resolve o problema.

Meu primeiro pensamento quando não pude ter acesso ao código foi fazer minha própria versão. Da mesma forma que eu pensei, outra pessoa também. Tanto que ao fazer um pesquisa no google, encontrei um módulo com o mesmo propósito, mais atualizações, sem os erros que eu havia encontrado e com o código aberto.

Pra completar, ao procurar opiniões sobre o módulo de código fechado, a imagem da empresa estava sendo praticamente destruída em diversos lugares, justamente por não permitir que os usuários possam melhorá-lo. Ou seja, a empresa obteve várias desvantagens: Os “concorrentes” podem oferecer suporte da versão de código aberto, os usuários avançados não são incentivados a mandar feedback e corre um grande risco da “má reputação” da empresa chegar aos demais usuários.

Este não é o único caso que eu conheço onde criptografar o código-fonte pode acabar gerando problemas. Já vi venderem código-fonte de software GPL criptografado, por exemplo.

Não acredito que todos os softwares podem ter seus códigos abertos. Mas muitas empresas ao decidir por não compartilhar seu código, não pensam nas desvantagens que podem ter. É sempre bom lembrar que existem idéias muito boas por aí. Por que não estar receptivo a elas?

imagem: johnath

Linux Kubuntu 9.04 com KDE 4.2: É para amar ou odiar?

Quem me segue no twitter já deve ter percebido que minha distribuição linux favorita é o kubuntu. Por esta predileção, instalei esta versão no dia do lançamento, muito animado. A impressão inicial não poderia ser melhor. Depois do primeiro dia, porém, comecei a ver que nem tudo era tão perfeito assim. Conheci a verdadeira face do sistema instalando em um segundo computador com dois monitores. Este post ao mesmo tempo encoraja e alerta quem está interessado nesta distro.

O primeiro computador a receber o kubuntu foi um notebook dell inspiron 1525 com processador intel core 2 duo e 4GB de RAM. Após a instalação de apenas 12 minutos, o sistema fez um boot de ótimos 27 segundos para uma interface muito bonita e cheia de efeitos. Como você pode conferir neste link, este notebook é certificado para rodar esta versão do ubuntu (eu nem sabia que isso existia).

Snapshot do Kubuntu 9.04

Snapshot do Kubuntu 9.04

Sobre esta instalação, não tenho grandes críticas. Já aconteceu um congelamento no sistema e o firefox simplesmente fechou algumas vezes. Isto me incomodaria muito se o boot não fosse tão rápido e tanto o KDE quanto o firefox não salvassem minha sessão. Ou seja, até então só tive boas impressões.

A segunda instalação foi em um desktop. Infelizmente, não me lembro de detalhes do hardware. Só sei que tem um processador intel com 2GB de RAM e placa de vídeo Nvidia. Tudo ocorreu muito bem, igual à instalação no notebook. Como tenho dois monitores, abri o nvidia-settngs e ativei os dois com X-Servers separados e Xinerama.

imagem2

Foi aí que os problemas começaram. Os efeitos na área de trabalho pararam de funcionar, as janelas começaram a deixar um grande rastro quando são arrastadas e, o pior, quando arrasto o mouse de uma tela para outra, o ícone do mouse não some da tela de origem. Ou seja, por causa do defeito do mouse, fico com um ponteiro em cada tela! Não sei se este problema é por causa do KDE, da placa de video ou outro fator qualquer.

A interface do KDE 4.2 é muito inovadora e bem instável. Ele é muito recomendado se você utiliza apenas um monitor e conseguir habilitar todos os efeitos da área de trabalho. Se você usa dois monitores, saiba que esta versão está muito melhor que a anterior, mas precisa melhorar muito. Quem sabe na próxima?

Múltiplos blogs no seu servidor com WordPress MU

Nas últimas semanas estive trabalhando no wordpress, wordpress MU para ser mais específico. WordPress é o popular gerenciador de conteúdo para blogs. WordPress MU é um projeto, de código aberto também, feito para possibilitar o gerenciamento de diversos blogs utilizando wordpress, a partir de apenas uma intalação (com resultado similar ao wordpress.com).

Se você não conhece o MU, faça uma visita ao site oficial. Segundo o próprio site, 95-99% do código do projeto é o próprio código do wordpress. Além disso, suporta a maioria dos temas, plugins, traduções e é usado em grandes projetos como os Blogs do Le Monde, o Edublogs e até o Blig (Hospedagem de blogs do IG).

O desenvolvimento para o MU possui o mesmo nível de dificuldade do WordPress. Isto é, se você já está acostumado a desenvolver plugins ou temas para o wordpress, tem muito pouco o que aprender. Apesar da menor quantidade, o MU possui o mesmo bom padrão de documentação.

Colocar o MU pra funcionar não é tão fácil quanto colocar o WordPress. Ele possibilita a instalação criando blogs como subdomínios ou subdiretórios. Se você não tem conhecimento ou acesso às configurações do seu servidor, recomendo que você use os subdiretórios.

Se você ficou com vontade de colocar a mão na massa com o MU, considere duas outras boas fontes de informações a respeito. A primeira delas é o WPMU Dev, que além de temas, plugins e informações, vende suporte, hospedagem e personalização. A segunda é o blog WPMU Tutorials, que fornece informações sobre plugins, configurações e o estágio de desenvolvimento do projeto. Inclusive, neste último, existe um e-book para te ajudar a fazer a instalação no seu servidor.

Estou desenvolvendo alguns plugins para o MU, se ficarem bons o suficiente para poderem ser usados por outrem, publico aqui no blog. A versão 2.7 acabou de ser lançada. É uma boa oportunidade para experimentar o MU, na minha opinião, este projeto tem futuro.

Pare! Você está reinventando a roda

Um dos conselhos que eu mais ouço, talvez por ser um o mais difíceis de seguir, é: “Não reinvente a roda”. Ou seja, não tente refazer aquilo que já existe e funciona bem. Eu imaginava que já havia superado completamente minhas tendências de reinventar a roda, mas não é tão fácil assim.

Nesta última semana estive desenvolvendo um site simples. Como me passaram o layout pronto, só precisava fazer o CSS, separar as imagens, montar o HTML, etc. Não era um layout com uma estrutura convencional (cabeçalho, rodapé e uma ou duas colunas no corpo). Pra minha surpresa, comecei a apanhar um pouco do CSS, o que me deixou um tanto frustrado.

Quem já montou algum layout em CSS sabe que ter algumas estruturas básicas já montadas ajuda muito, e era exatamente o que eu precisava. Me lembrei do YUI e de um projeto no meu computador que fazia uso dele. Após estudar um pouco o código e a Y!DN consegui escrever a folha de estilo utilizando 25% do tempo que havia dedicado até então.

Depois desta história, concluo 3 coisas:

1 – Temos sempre que ficar de olho na nossa “caixa de ferramentas”
Quando eu trabalhava mais frequentemente com CSS, era mais fácil criar estas folhas de estilo. Ainda assim, dificilmente começava uma delas do zero, sempre tinha à disposição referências e ajuda dos colegas de trabalho. Já sabia da existência de YUI antes de começar este projeto, mas ignorei porque pensava que poderia fazer o projeto com as minhas próprias ferramentas.

2 – Não tenha medo de testar novas ferramentas (mesmo que seja pra falar que ela não funciona)
Já contei a história de como demorei pra aprender Python no post anterior, aquela história demonstra como deixar de conhecer uma ferramenta nova pode ser ruim. A pouco tempo atrás aconteceu a mesma coisa. Comecei a aprender CakePHP porque não queria aprender Ruby on Rails, hoje percebo que isto não faz sentido. Ruby on Rails é um framework que está ficando cada vez mais famoso pela sua produtividade, não faz sentido deixar de experimentar. Se você realmente pensa que Ruby on Rails é somente um hype que vai passar, aprenda e depois fale o que quiser! Não estou falando mal do CakePHP, é um excelente Framework, foi ótimo ter aprendido. A questão é que me interessei por ele pelos motivos errados.

3 – Aprenda como as coisas funcionam. Na hora certa.
Outro motivo para que as pessoas não utilizarem certas ferramentas e fazerem as suas próprias do zero, é querer aprender como funciona. O mais interessante disso, é que quando você fica tentando fazer a sua própria ferramenta do zero, na maioria das vezes, aprende como as coisas NÃO funcionam. Se você quiser aprender como as coisas funcionam, comece a utilizar as ferramentas prontas, depois leia documentações, livros, códigos-fonte, blogs e o máximo de material do pessoal que fez. Imagine que eu quero aprender sobre sistemas operacionais modernos e apenas sei programar em C, se eu começar um sistema operacional do zero sem ajuda e sem ler o material que existe sobre o assunto vou fazer um SO melhor do que os que existem no mercado?

Vou tentar, daqui pra frente, fazer uma rápida pesquisa a respeito das tecnologias que pretendo utilizar, talvez isto faça com que eu reinvente menos. Ainda assim, a maioria das tecnologias que realmente valeram a pena para mim, fiquei sabendo através de referências de outros profissionais. Confie nos seus amigos, desconfie de você mesmo.