Just Another Underworker

Muitas vezes temos pastas e arquivos que não queremos que entrem nos nossos repositórios ou, quando fazemos builds ou usamos linguagens compiladas não queremos dar commit do resultado sempre. Por exemplo, imagine-se trabalhando num projeto opensource e que você gera pacotes semanais, ou ainda está num projeto escrito em, por exemplo, java, e não quer que a compilação entre no controle de versões.

Nesses casos, você quer que os arquivos .zip, .tar.gz e .bz2 gerados pelo build, ou ainda os arquivos .class gerados da compilação, não apareçam na saída do seu comando de status (svn st).

O Subversion apresenta uma funcionalidade para evitar que esses arquivos sujem a sua saída ao pedir o status da sua cópia local. É a propriedade svn:ignore.

Para usá-la basta fazer da seguinte forma:

$ svn propedit svn:ignore diretorio

Isso irá abrir o editor configurado para o seu ambiente. Agora basta digitar os padrões que devem ser ignorados, por exemplo:

tmp/logs
tmp/cache
*.class
*.zip
*.tar.gz
*.bz2

Salve o arquivo e dê comit pasta:

$ svn ci diretorio

Pronto. Agora sempre que você tiver uma mudança no diretório ‘diretorio’ essa mudança não irá aparecer na saída do ’svn st’.

Uma dica rápida e simples, mas de grande ajuda (principalmente para mim =D).

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.

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

1
2
3
4
5

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

view

setError($this); ?>

e teremos um resultado assim:

1
2
3
4

<p class="errors">&nbsp;</p>
 
<p class="friendly_error">
    Ocorreu um erro no sistema!

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://charlesschaefer.net/projetos/cakephp/friendly_error/files/friendly_error.tar.gz