Para mim, um diferencial entre programadores são os padrões de projetos, mais conhecidos por designer patterns. Como a própria wikipédia descreve padrões de projeto: “…descrevem soluções para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos”. Ou seja, programadores com conhecimento em Padrões de Projeto aplicam soluções em programação que facilitam a manutenção e o ciclo de vida do software. Infelizmente percebo que entre programadores PHP a utilização de padrões de projeto ainda não está tão bem difundida quanto em outras linguagens, como o java, por exemplo. Um pouco disso se deve ao fato de a linguagem ter ganhado um caráter orientado a objeto “recentemente”, cerca de 5 anos atrás, em sua quinta versão. Além disso, um outro problema que existe com relação a padrões de projeto em PHP é a literatura, que não está bem difundida para a linguagem. São bem poucos os livros que tratam de padrões de projeto utilizando PHP, mais raros ainda se forem procurados em nossa língua. Portanto caso um programador deseje conhecer mais a respeito de padrões de projeto, terá que estudar os tais em uma outra linguagem, mais especificamente, java. Para java existe uma gama inimaginável de livros que tratam do assunto. Outra fonte de informação importante sobre padrões de projeto é o website de Martins Fowler (http://martinfowler.com/). Ele trata de diversos padrões, principalmente voltado ao desenvolvimento de soluções corporativas. Além disso, trata de soluções de refatoração de código, tarefa que quase não acontece na vida de um programador =p . Entretanto, vale lembrar que nem todos os padrões podem ser efetivamente portados para o PHP sem sofrer alguma mudança. Cito, por exemplo, os padrões que utilizam polimorfismo para evitar-se condicionais no código (strategy). Pode-se ver exemplos desse tipo neste website: http://sourcemaking.com/design_patterns . Ele mostra como funciona os padrões em diversas linguagens e como muda a implementação entre uma linguagem e outra.
Categoria: Outros
Aqui está um assunto polêmico. Existem dois grupos óbvios nesta discussão: Os que defendem o desenvolvimento de sistemas em PHP utilizando a linguagem pura e criando componentes a partir desta e os que defendem que todo desenvolvimento deve ter um framework comercial como apoio para o sistema. Pelo tema deste post, eu estou no ultimo grupo.
O grupo que utiliza a linguagem pura e busca o desenvolvimento de seus próprios componentes utiliza vários argumentos para tanto. Segurança, performance da aplicação, designer de sistema proprietário, etc. Muitas vezes pessoas deste grupo montam seus próprios framework visando agilizar o desenvolvimento de softwares em busca da reutilização.
Eu, como defensor dos framework comerciais para o desenvolvimento cito algumas vantagens de se utilizar destes:
- Existe uma maior facilidade para a detecção de erros, visto que frameworks são peças mais concisas de software.
- Podemos nos concentrar mais com a abstração de soluções do problema que estamos tratando.
- Torna mais eficiente a resolução dos problemas.
- Como todos os itens acima ocasionam uma maior produtividade, podemos garantir que também teremos um maior lucro, pois teremos uma antecipação da entrega, e uma maior satisfação dos clientes.
- Otimização de recursos
Os pontos descritos acima foram retirados da wikipedia. Vou listar os meus pontos além dos citados acima:
- Padronização do sistema: Um sistema com a utilização de um framework tem um “esqueleto” no qual se apoiar, facilitando a padronização do desenvolvimento do sistema nos diversos pontos.
- Baixo acoplamento entre componentes: Sistemas que utilizam frameworks tem por natureza um baixo acoplamento. Isto se dá pelo fato de os desenvolvedores de frameworks serem bem genéricos para o desenvolvimento visando atingir um número maior de soluções.
- Documentação: Um ponto importante de um framework comercial é a sua documentação. Dado determinado problema no sistema, pode-se consultar uma documentação onde o problema é detalhado e é apresentado uma solução para o tal. Frameworks “caseiros” carecem de documentação em sua grande maioria, dificultando a reutilização de seus componentes.
Existe uma certa preocupação com relação a performance de aplicações que utilizam framework e essa preocupação é válida. Martins Fowler, em seus diversos livros comenta que aplicar designer patterns e refatoração podem impactar em performance da aplicação. Entretanto, ele próprio comenta que essa preocupação pode ser deixada de lado até que o sistema esteja desenvolvido e que ela realmente seja um problema. Nestes casos, em um sistema bem desenvolvido utilizando orientação a objetos e designer patterns de maneira correta, refatorações visando a performance da aplicação são rápidas e fáceis de serem realizadas. É claro que estamos falando de problemas de performance simples que não sejam requisitos do sistema. Por exemplo, uma query que demora 1 min para execução sendo que o tempo máximo deste requisito do sistema seja 3 segundos. Talvez uma refatoração nos leve ao ganho de alguns segundos na query. Entretanto este fator deve ser levado em conta na fase de análise do projeto. Talvez, neste ponto do sistema, uma solução de ORM de um framework seja menos efetiva. Mas a troca de uma solução de ORM para uma extração pura é bem simples. É claro que isso foi um exemplo simples. Existem outros problemas que podem aparecer com relação a performance de uma aplicação que utiliza framework. No entanto, tais problemas são bem pontuais.
Outro ponto que algumas pessoas alegam é com relação a segurança. Alguns dizem: “Vai que existe um bug comprometedor neste framework e a minha aplicação fique vulnerável a ataques”. Bem a afirmação é válida e tem importância sim. Mas essa preocupação é a mesma para quaisquer sistemas e aplicativos existentes na infraestrutura da empresa. Por exemplo, digamos que exista uma vulnerabilidade no mod_rewrite do apache. Posso desativar o módulo ou trocar o meu servidor web. Da mesma maneira, com frameworks posso desativar determinado componente. Posso trocar o framework ou, posso até mesmo consertar a vulnerabilidade. Afinal na maioria dos casos tem-se acesso aos fontes de um framework podendo dessa maneira corrigir a vulnerabilidade e/ou evitar que esta seja utilizada.
É uma tendência a utilização de framework em desenvolvimento, principalmente desenvolvimento WEB. Portanto, caso tenha algo contra, reexamine o porquê e veja se vale a pena perder todas as vantagens listadas aqui.
Fontes: http://pt.wikipedia.org/wiki/Framework
Controlar alterações em arquivos e diretórios é uma tarefa complexa porem necessária em algumas ocasiões. Este artigo mostra como utilizar o php-inotify, extensão do PHP que realiza a tarefa de monitação e alerta do filesystem. O sistema operacional utilizado é linux, Ubuntu 9.04.
Para iniciarmos, vamos baixar os fontes do PHP:
sudo apt-get update
sudo apt-get install php5-dev
Depois instalamos o pear para termos acesso aos pacotes pecl
sudo apt-get install php-pear
Depois instalamos o inotify
sudo pecl install -f inotify
Depois temos que habilitar o inotify no php.ini, para tanto
sudo vim /etc/php5/cli/php.ini
e no final do arquivo adicionamos a seguinte linha no final do arquivo
extension=inotify.so
Para confirmar a instalação utilize o seguinte comando
php5 -r 'phpinfo()' | grep inotify
Tendo instalado o inotify, os scripts para monitoração podem ser escritos da seguinte forma (nomeei como inotify neste exemplo):
#!/usr/bin/php5
<?php
//seta o tempo de execução ilimitado
set_time_limit(0);
//inicia a instancioa do inotify
$df = inotify_init();
//monta a regra de monitoramento
$monitor = inotify_add_watch($df,'/var/log',IN_ALL_EVENTS);
//cria um laço infinito
while(true){
//lê o evento
$evento = inotify_read($df);
print_r($evento);
}
//fecha a instancia do inotify
inotify_close();
Para a execução do script utilize o seguinte comando
chmod +x inotify
./inotify
Experimente dar uma listagem no diretorio
/var/log/
com um outro terminal enquanto em um terminal fica executando o inotify.
Para mais informações,php.net
Não são poucas as vezes em que estamos em um determinado sistema operacional e dependemos de determinada ferramenta ou caracteristica de outro sistema operacional. Só para citar como exemplo, quando se necessita de um servidor SSH para criar conexões tuneladas ou até mesmo para verificar como fica a aparência de um site em determinado sistema operacional.
Para resolver este problema existe as maquinas virtuais: sistemas que emulam um sistema operacional dentro de outro sistema operacional. E dentre alguns programas que se propõem a fazer isso, o que eu considero mais fácil de se lidar é o Virtual Box.
Logo após a sua instalação, aparece uma gama de sistemas operacionais que podem ser instalado no virtual box. Ele cria uma espécie de HD virtual para que seja instalado o sistema operacional. Além disso, compartilha grande parte dos periféricos do PC com o sistema operacional virtual que está sendo instalado.
Acessem ismaelvacco.com.br
Existe uma interessante evolução na maneira de se programar aplicações WEB. Com o surgimento de varias linguagens de programação e da necessidade de facilitar o desenvolvimento de sistemas emergiram varios padrões para o desenvolvimento de aplicações WEB. Um destes padões, é o MVC, ou, em uma tradução menos rigorosa, Modelo – Visão – Controle. O conceito pode ser aplicado a qualquer linguagem, mas ela é nativa de alguns frameworks, como o Ruby on Rails para ruby, Hibernate para java. Para php, existem diversos frameworks que trabalham dessa maneira, entre eles, o phpMVC, o Cake e o Zend Framework. Tenho preferência por este ultimo pela quantidade inúmera de ferramentas disponibilizadas. Em outros post discutiremos algumas dessas ferramentas. Em momento, vamos analizar como desenvolver um sistema WEB utilizando o Zend Framework e o conceito de MVC.
Em primeiro lugar, devemos baixar os arquivos do Zend Framework. Existem dois pacotes Full e Minimal. Eu recomendo baixar a versão full que contem o pacote completo e até ambientes de teste de aplicativos e ferramentas para criar o código automaticamente ( outra coisa que discutiremos em post mais a frente ). Apos baixar e descompactar, os arquivos devem ser copiados para uma pasta abaixo da raiz do seu site. Não se tem necessidade de deixar os arquivos expostos para o publico. Após copiado, temos que apontar a nossa aplicação para os arquivos ou dizer ao PHP onde ele deve ir buscar os arquivos. A primeira maneira pode ser feita declarando o comando ini_set(‘include_path’,caminho para os arquivos) no arquivo central de nossa aplicação que iremos utilizar o MVC. A outra maneira é abrir o php.ini, encontrar a linha include path e acrescentar o caminho para os aquivos.
No próximo post mostrarei como fazer isso de maneira mais prática.
