eSeminário Flex e PHP

A Adobe está disponibilizando um seminário virtual sobre sua ferramente Flex.

Lee Brimelow, ira mostrar como criar uma aplicação Flex com PHP e o Zend Framework. Veremos ainda como executar nossa aplicação em um desktop com a ajuda do Adobe AIR runtime.

Mais informações:
http://www.adobe.com/cfusion/event/index.cfm?event=detail&id=462539&loc=en_us

Cheat Sheet PHP

Para quem é iniciante e acha uma tarefa hercúlea decorar os principais comandos em PHP, existem as cheat sheet.
São guias de referência rápida, tudo que você precisa em uma única página.

http://www.ilovejackdaniels.com/cheat-sheets/php-cheat-sheet/

Dump no Mysql em linha de comando

mysqldump -u [usuario] -p [banco] > [arquivo.sql]

Simples como a vida :)

ezPDF vs IE via SSL

Ao utilizar a classe ezPDF para gerar relatórios no php, tive um problema interessante, no IE6 e IE7 o pdf não funcionava, simplesmente apresentava erro no download via SSL. Certamente o cabeçalho HTTP estava sendo gerado de forma "incompatível" com os IEs. Mas no firefox estava tudo certo.

Como não era meu interesse alterar a classe, o que poderia gerar uma explosão de versões, simplesmente mudei a forma de utilização.

Código usado anteriormente:

include ('class.ezpdf.php');
$pdf = new Cezpdf();

... geração do relatório

$pdf->ezStream();

Código novo:

include ('class.ezpdf.php');
$pdf = new Cezpdf();

... geração do relatório

header("Cache-Control: cache, must-revalidate");
header("Pragma: public");
header("Content-Type: application/force-download");
header("Content-Disposition: attachment; filename=\"relatorio.pdf\"");
echo $pdf->output();
exit;

Minha idéia foi simples, forçar o download via http :)
Se quiser saber mais sobre a ezPDF use este tutorial Hello Word.

Como instalar Rails no Ubuntu

Como ter um ambiente de desenvolvimento para Ruby on Rails no Ubuntu? Simples:

Primeirio temos que instalar o interpretador Ruby:

sudo apt-get install ruby rubygems irb ri rdoc ruby1.8-dev build-essential

depois os gems do Rails:

sudo gem install rake activesupport activerecord actionpack actionmailer activeresource rails

Assim teremos a versão mais atual do Rails.

Mas ainda falta registrar os gems nas variáveis de ambiente.

sudo gedit /etc/bash.bashrc

inclua a linha

#Rails
export PATH=$PATH:/var/lib/gems/1.8/bin

Agora é só testar

rails -v

:)

Diretórios Virtuais no Apache

Hoje precisei criar uma diretório virtual, ou seja, uma url que não corresponde a um diretório no mapeamento padrão do servidor web, tudo isso usando Apache.

Ex:
http://www.google.com.br/maps
A pasta maps deve estar na raiz do diretório.
Mas se eu quiser colocar a pasta em outro local, como /meuDir/maps?

A tarefa bem simples. Basta editar o httpd.conf incluindo a seguinte entrada.

Alias /maps /meuD/maps

Não esqueça de dar um restart/reload para atualizar o httpd.conf.

40 sinais de que você realmente é um reles programador PHP

Eu estava trabalhando em uma lista de "pecados" para programadores PHP, mas o Reinhold Weber se adiantou. Melhor, porque a lista dele é bem maior que a minha :)
Resolvi fazer uma tradução livre. Vamos lá:

Isto é o que eu prefiro chamar de minha "lista de programação da vergonha".
Embora tendo uma educação universitária formal com aulas sobre engenharia de software, arquitetura de software empresarial e design de banco de dados eu tenho sido culpado por todas essas coisas uma vez ou outra.
A lista é completamente subjetiva e baseada no Eclipse.

Você é um reles programador PHP se:

1. Não comentar seu código apropriadamente com algo como phpDoc.
   


2. Não ver a necessidade e/ou benefício de uma boa IDE de programação
   como Zend Studio ou Eclipse PDT.


3. Nunca ter usado uma forma de controle de versão como Subclipse.


4. Não adotar algum padrão de código/nome e convenção geral e insistir com eles, pelo menos, ao longo de todo o projeto.


5. Não usar uma metodologia consistente.


6. Não escapar e/ou propriamente validar entradas ou consultas SQL.


7. Não planejar sua aplicação minuciosamente antes de começar a codificar.


8. Não usar desenvolvimento guiado a testes (TDD).


9. Não programar e testar com error reporting on.


10. Não ver os benefícios de um debugger.


11. Não refatorar seu código.


12. Não separar camadas diferentes usando algo como MVC.


13. Não saber o significado de: KISS, DRY, MVC, OOP, REST.


14. Não retornar conteúdo mas sim echo ou print de suas funções
    ou classes.


15. Nunca ter visto a vantagem de testes unitários ou teses em geral.


16. Retornar HTML, não dados, string ou objetos.


17. Mensagens e parâmetros de configuração hard code.


18. Não otimizar suas consultas SQL.


19. Não usar __autoload.


20. Não admitir manipulação de erros inteligente.


21. usar $_GET no lugar de $_POST em qualquer ação destrutiva.


22. Não saber como usar expressões regulares.


23. Nunca ter ouvido sobre SQL injection ou cross-site scripting.


24. Não permitir configuração simples, podendo ser parâmetros passados a um construtor de classe, métodos set/get chamados depois, ou constantes definidas em runtime.


25. Não entender os benefícios e limitações da programação orientada a objeto.


26. POO imprópria / tudo o que escrever, não importa o quão pequena é OO.


27. Pensar que reuso de software é igual/requer que seu código seja OO.


28. Não escolher padrões inteligentes.


29. Não ter apenas um arquivo de configuração.


30. Não querer que o conteúdo dos arquivos seja visto, mas para isso usar uma extenção .INC ao invés de .PHP.


31. Não usar camada de abstração de banco de dados.


32. Não manter o DRY, Don't repeat yourself(Não se repita). Se tem que copiar e colar ou duplicar algo no seu código seu design deve estar errado.


33. Não fazer uma função/classe/método fazer somente uma coisar e não faze-las interagir.


34. Não tentar usar as vantagens das características específicas da POO como classes abstratas, interface, herança, polimorfismo e modificadores de acesso.


35. Não otimizar o design da sua aplicação com padrões de projeto estabelecidos.


36. Não permitir seu usuário definir um diretório base se tiver múltiplos arquivos e/ou diretórios.


37. Popular o namespace global, uma opção é prefixar as funções na sua biblioteca com uma string em comum.


38. Não permitir um prefixo de tabela quando usar tabelas de banco de
    dados.


39. Usar um template engine separado.


40. Não dar uma olhada em frameworks estáveis para inspiração, muitos deles tem avançados conceitos de desenvolvimento web e boas práticas no código.

Como o post ficou grande, deixo os comentários com vocês.