Foi lançada a nova edição da revista PHP Review e conta com um artigo meu, sobre frameworks.
O download do PDF pode ser feito no site oficial da revista
Elton LuÃs Minetto
Site pessoal de Elton Minetto
Filed under docs …
E-book Zend Framework na prática
Estou tirando da gaveta um projeto antigo, fazer um e-book. E o assunto que eu escolhi foi Zend Framework
Para mais detalhes sobre o projeto, o site é http://www.zfnapratica.com.br
Processando arquivos de profiling do Xdebug no MacOSX
O Xdebug é uma das ferramentas mais úteis que conheço para quem trabalha com PHP. Eu escrevi um resumo das suas funcionalidades em um post anterior.
Uma das funcionalidades que mais uso é a geração de “profiling” de aplicações. Ajuda muito na hora de encontrar “gargalos” de performance. O único problema é que eu precisava usar o Kcachegrind ou o Webgrind para analisar os arquivos gerados pelo Xdebug.
Como eu uso MacOSX eu procurei uma forma mais rápida de processar essas informações, sem ter que acessar uma máquina virtual Linux ou configurar o Webgrind.
Para isso eu usei a dupla xdebugtoolkit e graphviz. O primeiro analisa o arquivo gerado pelo Xdebug e gera um arquivo .dot, que eu posso abrir com o graphviz.
Para instalar o xdebugtoolkit é preciso acessar o Terminal e executar os comandos:
svn co http://xdebugtoolkit.googlecode.com/svn/tags/0.1.5/xdebugtoolkit/ xdebugtoolkit
e
cd xdebugtoolkit/
Ele é um programa desenvolvido em Python, que vem instalado nativamente no MacOSX.
Com o xdebugtoolkit é possÃvel converter o arquivo de profiling em uma imagem no formato .dot. Para isso é preciso executar o comando:
./cg2dot.py cachegrind.out.5398 > cachegrind.dot
Agora basta usar o graphviz para abrir o arquivo cachegrind.dot. A instalação segue o formato .DMG do MacOSX e não apresenta nenhum mistério.
Abaixo um exemplo de arquivo gerado por esse processo, e exportado para JPG.
No arquivo é possÃvel ver toda a árvore de execução da página, com seus respectivos tempos de processamento, ajudando a encontrar partes que estejam comprometendo a performance.
Com certeza não é tão avançado quanto o Kcachegrind, mas tem me ajudado bastante.
Post no Linha de Código
Meu texto sobre como ser um bom profissional de TI foi publicado no site Linha de Código
Monografia sobre CouchDB
No primeiro semestre de 2010 eu tive o prazer de orientar o acadêmico Kassiano Matteussi no seu Trabalho de Conclusão de Curso, na Unochapecó, onde sou professor.
O trabalho intitulado “Desenvolvimento de uma interface WEB com PHP para gerenciamento de banco de dados CouchDB” está disponÃvel em PDF, bem como a sua versão resumida, em forma de artigo.
Se alguém tiver interesse de ver os códigos é só mandar um e-mail para o Kassiano.
Parabéns novamente ao Kassiano pelo trabalho.
Material da palestra no PHPSC Conf 2009
Finalmente me organizei e fiz o upload dos slides da palestra que ministrei no PHPSC Conf 2009.
Coloquei no Slideshare. Se alguém precisar do arquivo em outro formato é só me avisar.
Melhorando a performance de aplicações com o uso do MemCache
Meteriais das palestras em Xanxerê
Estou disponibilizando o material das duas palestras que ministrei na Unoesc Xanxerê
Zend Framework
Desenvolvendo aplicações Web escaláveis
Reportagem sobre CakePHP
Foi publicada na segunda edição da revista TIdigital uma reportagem sobre o framework CakePHP.
Foi feita uma entrevista com um dos criadores do framework, John David Anderson e profissionais brasileiros que usam a ferramenta: Jhony Maiki Maseto, Tulio Vitor Machado Faria, Oberaldo Büll Junior, João José Carvalho Pedrini e eu.
O PDF da reportagem está disponÃvel neste link
Lock em arquivos usando SVN e Subclipse
Outra novidade para mim ao usar o Subversion foi o controle de Locks.Â
Eu sempre usei o CVS integrado ao Eclipse para gerenciar os projetos que eu trabalhava e com essa duplinha é bem fácil configurar para evitar que dois programadores alterem o mesmo arquivo.
Com o Subversion e o Eclipse (usando o plugin Subclipse) eu não encontrei essa opção. A solução que encontrei foi configurar o cliente do subversion para quando criar novos arquivos marcá-los com um flag. Este flag indica que, para editar o arquivo é preciso que seja feito o “lock” antes. No momento de criar o lock o Subclipse também verifica a versão do arquivo e avisa caso a versão local seja inferior a que consta no repositório. Desta forma eu garanto que o programador sempre tenha a última versão do arquivo e evito que duas pessoas alterem o mesmo arquivo ao mesmo tempo. Existem formas de corrigir isso usando práticas de merge, mas eu acho mais fácil evitar o problema do que resolvê-lo 
O que eu fiz foi alterar o arquivo config no diretório do usuário:
mate ~/.subversion/config
Eu estou usando o Textmate no MacOSX. Mas o mesmo passo vai funcionar no Linux. No Windows XP o arquivo encontra-se no diretório
c:\Documents and Settings\usuario\Dados de Aplicativos\Subversion\config
Neste arquivo eu altereiÂ
# enable-auto-props = yes
para
enable-auto-props = yes
E adicionei alinha abaixo na seção  [auto-props]
* = svn:needs-lock
Desta forma, assim que o programador criar um novo arquivo e realizar o primeiro commit é adicionada esta flag ao arquivo. Todos que forem alterá-lo vão passar pela fase “lock-edit-commit”, com um “update” caso seja necessário.
Deploy automático do SVN
Estou iniciando um novo projeto e aproveitei para mudar do CVS para o Subversion.Â
Uma das coisas que achei interessante é o esquema de “hooks“. É um conceito parecido com “triggers” de bancos de dados. Você pode programar alguns scripts para serem executados em momentos especÃficos do ciclo gerenciado pelo SVN. As opções são:
post-commit.tmpl
post-lock.tmpl
post-revprop-change.tmpl
post-unlock.tmpl
pre-commit.tmpl
pre-lock.tmpl
pre-revprop-change.tmpl
pre-unlock.tmpl
start-commit.tmpl
Os nomes são auto-explicativos. Por exemplo, o script post-lock vai ser executado sempre após algum usuário ter feito o lock de um arquivo.
Estes arquivos estão armazenados no diretório hooks do repositório do projeto.
O que eu fiz foi alterar o post-commit.tmpl
É preciso remover a extensão do nome e dar permissão de execução no arquivo, então:
cp post-commit.tmpl post-commit
chmod +x post-commit
O conteúdo do arquivo ficou assim:
REPOS="$1"
REV="$2"
PROD="/var/www/html"
#pega todas as alteracoes
svnlook changed $REPOS --revision $REV >> /tmp/lixo_$REV
#pega cada alteracao e salva
for i in `cat /tmp/lixo_$REV|cut -c 5-1024` ; do
  svnlook cat $REPOS $i > $PROD/$i
done
#apagar arquivo
rm /tmp/lixo_$REV
Desta forma cada vez que um programador faz o commit do fonte ele é automaticamente salvo no htdocs, onde fica acessÃvel para a equipe de testes.Â
Lógico que esse script pode ser melhorado e isso está sendo executado em um servidor de desenvolvimento e não o de produção. Além disso eu comecei a usar o SVN somente agora, por isso, se alguém encontrar um problema ou erro na lógica me avisem
