Uma dica rápida para os programadores brasileiros

Todos sabemos bem quem é que nos ajuda quando estamos em apuros com PHP (isso mesmo, quem, a personificação da utilidade). Pois bem, o nosso bom e velho manual (quase) nunca nos deixa na mão, não é verdade? Acho que todos concordamos com isso. Mas ainda assim vou me arriscar a apontar um pequeno problema nele.

Conheço alguns programadores que ainda não sabem fazer uma leitura básica num texto escrito em inglês. Uns dizem que não têm tempo, outros que dá pra se virar com o que há em português sobre programação. Afinal de contas o nosso bom e velho manual tem boa parte de seu conteúdo traduzida para o português. Pra quê aprender inglês?

Nosso querido manual é realmente traduzido para o português, apesar de a documentação de algumas funções ainda não terem sido traduzidas ainda. Mas faço uma pergunta: se por um acaso não pudermos confiar nem no manual do PHP, será que poderemos confiar em algo mais?

Não estou dizendo, de forma alguma, que o manual é uma fonte não confiável para os programadores. Só queria apresentar uma parte dele que não é tão confiável para os brasileiros, principalmente aqueles que não sabem nada de inglês (fui um destes por um tempo também :} )

O motivo deste post? Veja:

http://br2.php.net/manual/pt_BR/function.socket-bind.php

http://br2.php.net/manual/en/function.socket-bind.php


Entende agora o que eu quero dizer ao apontar o manual em português como "confiável mas nem tanto"?

O primeiro link (tradução do manual para português BR) traz um aviso medonho dizendo para usar a função por sua própria conta pois sua estrutura ou nome podem ser mudados ou o suporte a ela descontinuado. Agora quando você visita o manual em inglês vê que não há nada disso. Isso ocorre provavelmente porque a versão do manual em inglês é bem mais nova que a versão traduzida para o português.

Esse problema de desatualização não acontece somente em funções remotas como a socket_bind(). Veja aqui o manual da função file():

http://br2.php.net/manual/pt_BR/function.file.php

agora em inglês:

http://br2.php.net/manual/en/function.file.php


Novamente isso não é, de forma alguma, uma crítica ao manual (que ainda é a fonte mais confiável de informações) nem aos tradutores (que devem estar atolados de trabalho e não tiveram tempo de atualizar algumas funções). Quero apenas alertá-los, principalmente os mais novos na linguagem, que quando você viu o manual da função em português uma coisa, testou e não funcionou como esperado, dê uma lida nela em inglês para ver se não há nenhuma diferença. Pode estar nessa diferença o detalhe que irá evitar de fazê-lo gastar todo o seu dia procurando uma solução.

Vou mandar os links para o pessoal do manual do PHP, que agora conta com um novo editor: Philip Olson

Tenho certeza de que corrigirão o mais rápido possível.

Até a próxima.

Criando um sistema de erros amigáveis para o CakePHP

Por mais simples que seja, uma aplicação sempre terá uma mensagem dinâmica a passar para o usuário. Sempre damos um jeitinho de mandar a mensagem de formas diferentes em arquivos diferentes. Isso torna o sistema de erros da nossa aplicação uma coisa inextensível e de manutenção custosa.

O CakePHP, apesar de toda sua facilidade, não possui um sistema integrado para exibição de mensagens para o usuário. Para isso criei um pequeno sistema de mensagens amigáveis, composto por um componente, um helper e um elemento. Chamo-o de FriendlyError.

Com o FriendlyError você poderá mostrar três níveis de erro para o seu usuário: message, warning e error (mensagem, aviso e erro, respectivamente).

Seu uso consiste da definição, no controle, da mensagem a ser exibida, e sua captura para exibição, na view.

Exemplo:
controle

try{
// ...
} catch (Exception $e) {
$this->FriendlyError->setError($e->getMessage);
}

view

<?= $friendlyError->setError($this); ?>

e teremos um resultado assim:

<div class="errors">
<div class="friendly_error">
    Ocorreu um erro no sistema!
</div>
</div>

Para a utilização do FriendlyError você deve fazer alguns ajustes na sua aplicação. O primeiro é indicar o uso do componente e do helper nas variáveis $components e $helpers do seu controller. O segundo é copiar o elemento friendly_error.ctp para a sua pasta de componentes. Se precisar, pode modificar a forma como o elemento exibe os erros.

Feito isso, basta utilizar o componente no seu controller. Os métodos possíveis são setMessage(), setError() e setWarning(). Eles não são declarados no componente, mas são interpretados pelo método __call() (PHP5).

Se precisar de mostrar outras mensagens você poderá utilizar os outros argumentos ($error_array, $warning_array e $message_array) do método setError() do helper para poder exibir suas mensagens junto com as mensagens que estavam na sessão.

O FriendlyError é compatível apenas com o PHP5.

Download: http://schaefer.dreamhosters.com/files/cakephp/friendly_error.tar.gz

Frameworks

O mundo dos programadores é cercado de palavrinhas estranhas desde o começo da carreira. Para programadores autodidatas (como eu), muitas vezes, entender estas palavrinhas é uma tarefa um tanto quanto difícil, principalmente quando não se acha uma definição para elas no seu dicionário, que nunca o havia deixado na mão (até então) :p

Ultimamente tem-se falado muito em utilização de frameworks. Frameworks para desenvolvimento em PHP, em javascript e para ambos ao mesmo tempo; frameworks baseados no padrão MVC, frameworks com ORM (Object Relational Mapping – essa faz parte de um outro mundo obscuro na programação: as siglas), Active Record, etc.

Mas afinal de contas, o que diabos é um framework?

Joãozinho: Hum, ham, é um conjunto de classes que resolvem cada uma um problema específico, evitando assim que o programador escreva muitos códigos?

Aeh Joãozinho, finalmente algo que presta hein!

Mas hoje em dia, um framework tornou-se mais do que uma série de classes que nos ajudam a resolver um problema específico. Um framework hoje, mais do que ajudar a resolver problemas, dita uma forma específica, padronizada de resolvê-los.

Assim o programador pode se desligar das decisões de como uma determinada tarefa será aplicada, como realizar o acesso aos dados, de que forma exibir estes dados, etc. Tudo o que o programador precisa saber é como resolver o seu problema. O resto, é por conta do framework.

Nos dias atuais, onde o tempo controla a vida das pessoas e das organizações, qualquer que seja a ajuda para poupar tempo será bem-vinda. Não poderia ser diferente com os frameworks. Desenvolvedores de todas as partes do mundo discutem diariamente sobre o uso de frameworks, qual usar, por quê usar, por quê não, quando usar, etc. E estas discussões estão muitas vezes pautadas nas reuniões para implementação de projetos dentro das empresas também.

As organizações precisam poupar o máximo de tempo, mesmo que para isso, as vezes, seja necessário se perder um pouco do desempenho dos sistemas que se desenvolve. E é essa a tarefa de um bom framework: poupar o máximo de tempo possível de um programador.

Mas nem sempre os frameworks irão realizar com sucesso a sua árdua tarefa, principalmente se forem mal escolhidos para determinado projeto. É necessário saber com precisão o que será necessário desenvolver para saber a quem/que recorrer. Além disso é necessário saber também as peculiaridades de cada framework disponível no mercado (ou pelo menos os mais famosos) para conseguir prever os problemas oriundos da adoção deste framework, conseguindo assim subsídios suficientes para a escolha do melhor.

Para nós, programadores PHP, há uma infinidade de frameworks. Eu, particularmente, recomendo os baseados no Ruby on Rails, framework para Ruby que “revolucionou” a forma como se programa para a web. O que mais me agrada é o CakePHP, mas temos ainda o Symphony, o Zend Framework, o PHP on TRAX, entre outros facilmente encontráveis pelo google.

Para você que precisa decidir qual deles escolher, este link pode ser de grande ajuda: http://www.phpit.net/article/ten-different-php-frameworks/.

Ele possui uma tabela comparativa com as características de alguns frameworks para PHP disponíveis no mercado.

Até a próxima!