Diferentemente dos outros anos, em 2011 eu estarei na PHPConference como palestrante. Meu maior impasse era quanto ao tema, por fim, decidi submeter algo polêmico que foi aceito! Acredito conseguir abrir a mente de alguns possíveis espectadores com o tema:

Definir classe não é programar com orientação a objetos.

Do que não falarei:

• Como definir uma classe com PHP;
• Classe e Objeto no âmbito técnico do PHP;
• Parâmetros, métodos e objetos;
• Padrões de projeto (design patterns).

Do que falarei:

• Design (projeto) orientado a objetos;
• Princípios de orientação a objetos;
• Como não definir uma classe (code smell);
• Composição, agregação, value object e entidades;
• Ubiquitous Language (ourindo do Domain-Driven Design)
• Getters, setters burros;
• Ciclo de vida de um objeto.

O objetivo é abrir a mente dos presentes para uma orientação a objetos pura, legível e realmente manutenível. Minha palestra será na sexta-feira, 2 de dezembro às 11hs (de acordo com a grade atual). Interessou? Aparece por lá!

Você tem um sistema de upload e parser de imagens em seu sistema. Várias pessoas enviando imagens o tempo todo. Como fazer para não explodir sobrecarregar o servidor com múltiplos filhos e ainda não segurar toda essa gente na tela de upload do site ? Simples! Você pode criar uma fila de upload e parser! Toda requisição de upload é direcionada para um euqueue que receberá e colocará a requisição no final da fila. Do outro lado, há um (ou mais) Workers trabalhando para que os itens da fila sejam processados um a um por ordem de entrada na fila. Sem sobrecargas, sem esperas por atendimento, etc.

Quando precisei utilizar o Resque, busquei uma solução em PHP e felizmente, encontrei! PHP-Resque é um port fiel ao original Resque (Ruby). Vi o projeto e como funcionava. Tudo perfeito, exceto pelo fato de não ser separado com namespaces e não ter suporte ao Symfony. Buscando mais, encontrei um plugin para o Symfony 1.x, mas nada referente ao Symfony 2.x, daí, resolvi eu criar um bundle do php-resque para o sf2.

Na página do projeto, explico como funciona o PHP Resque Bundle com todo detalhamento possível. Tenho mais alguns itens a implementar no projeto como criar namespaces para as filas, algo possível no Resque (Ruby) mas impossível ainda no PHP-Resque – vide thread. Trabalharei nisto em breve, pois precisarei deste recurso também =D

Como o PHP-Resque não possui interface gráfica (como o Resque), uma alternativa é baixar o Resque e utilizá-lo somente para este fim – ou então, forkear o php-resque e implementar isto por lá!

Dúvidas, sugestões ou contribuições podem ser feitas diretamente no Github dos projetos. Happy hacking!

Com key em mãos, basta baixar um binário, típico installer.bin para Linux no site da Zend.

1. Instalação

Ao rodar o binário, é solicitado a versão do PHP que deseja instalar. Na versão que testei, Zend Server 5, PHP 5.2 ou PHP 5.3. Neste passo é possível também definir qual branch você irá utilizar: Developer Edition ou Community Edition (CE).

Para Linux, o binário funciona apenas com distros Debian-like ou RedHat-like. Para as demais, o choro ainda é livre nada ainda.

Instalação rápida e sem complicações. Após tudo instalado, você poderá controlar o daemon em /etc/init.d/zend-server (start|stop|restart|…)

2. Iniciando…

Basta acessar: http://server.me:10081 e aguardar o redirect para tela de autenticação do Zend Server.

Após logar, recebe-se o Dashboard que  contém um grande overview (óbvio) de tudo que ele poderá fazer por nós.

Os destaques são:

• Gerenciamento de eventos;
• Configuração do php.ini ultra-simplificada;
• Restart do container (Apache, PHP) na GUI;
• Profiler e code backtrace de todas URLs do server;
• Logs;
• Fila de atividades;
• Configuração de cache para conteúdos estáticos (html, css, javascript…);
• Ativação/desativação de módulos facilmente, e;
• Integração com Zend Studio para debugging em ambiente de produção.

Gerenciamento de eventos

Os eventos são completamente configuráveis e estão listados em Rule Management -> Monitoring .
As configurações incluem:

• Definir os alertas
• Definir os critérios (por tempo de carregamento em milésimos de segundo; ou tamanho da página em Kb)
• Setar ações (lançar email; salvar code backtrace; registrar apenas..)

Zend Server 5 - Monitoring

Para acompanhar cada evento, temos pelo dashboard (os últimos) ou diretamente na página dos eventos a listagem completa com data, etc.

Zend Server 5 - Monitoring details page

Ao clicar em show code tracing uma nova janela é aberta exibindo o trace da aplicação com várias opções de filtragem (mais do que no próprio Zend Studio na aba Profile).

Zend Server 5 - Code tracing popup

Configuração do php.ini

Todas as configurações do php.ini ficam em Server Setup -> directives.

Basta editar o campo desejado, salvar e depois reiniciar o webserver para recarregar com as novas configurações. Tudo graficamente !

Zend Server 5 - PHP.ini directives setup

Integração com Zend Studio para debug

Aqui não há muito segredo. O Zend Server vem com o Zend Debugger configurado e pronto para uso. O mesmo debugger que também já está facilitado o acesso pelo Zend Studio. A única coisa pendente é liberar acesso remoto do Zend Studio na sua rede no seu Zend Server remoto e voilà.

As configurações de liberação de acesso estão em Server Setup -> debugger. Basta adicionar o IP/range e salvar.

Resumo

Facilidades por todos lugares com o Zend Server 5. Como de praxe, a Zend enfia a faca nos preços, acredito eu que poderia ser mais acessível, assim, mais empresas – aqui incluem-se os freelas – teriam como pagar tranquilamente pela ferramenta, gerando mais receita à Zend.

O ponto alto da ferramenta é realmente o Code Trace e facilidade nas configurações e eventos do sistema em produção. Aliado ao Zend Studio, fica ainda melhor !

Extra: Zend Server @ Amazon EC2

A Zend disponibiliza uma ISO Linux já com o Zend Server totalmente configurado no serviço de cloud da Amazon Elastic Compute Cloud na modalidade “small”. Essa instância Small da Amazon custaria no mínimo 60 dólares/mês rodando diariamente sem adicionais (disco, dns, etc). *A Zend dá a licença gratuitamente quando utilizado na Amazon. 

Deixei rodando em teste por dois dias e me custou 9 dolares. Cancelei e montei eu mesmo o Zend Server sob uma ISO Linux padrão na Amazon EC2, porém com uma instância “micro” que dada restrições, é gratuita. E mesmo que eu venha a pagar por mais disco ou núcleo de proc, será MUITO menos do que 60 dólares. Acredito que fique mais em conta do que uma VPS com 512MB de ram.

Antevejo ele, os Traits. E mais, consigo prever que será algo assim:

<?php
trait Hello {
 public function ola() {
   echo "Olá";
 }
}

class Mundo {
 use Hello;

 public function world() {
   echo "{$this->ola()} trait !";
  }
}

$ola = new Mundo();
$ola->world();
// Olá trait !

Ok, não sou bidu. Realmente os Traits estão na lista do possível-futuro PHP 5.4 e eu, baixei a build de 31/03/2011 para testar.

Traits

O PHP não suporta herença multipla – amém – e por este motivo, às vezes ficamos limitados em algumas decisões de projeto (design). O maior problema neste ponto é que toda herença até agora (PHP 5.3.x) é vertical, ou seja, se eu precisar de um nível de abstração diferente no meio do processo, ou precisarei adicionar a nova abstração e reescrever tudo abaixo dela, ou ainda, terei que duplicar o código pois não conseguirei satisfazer a herença.

É nesse ponto que os Traits aparecem. Diferentemente da herença (vertical), os Traits possibilitam-nos criar herenças horizontais.

Exemplo, dada a necessidade:  haverão Funcionários, Supervisores, Gestores e Diretores no sistema e estes possui em comum o fato de receber salário. (capitalismo). Uma possibilidade seria:

Pessoa > Funcionario
Pessoa > Supervisores
Pessoa > Gestores
Pessoa > Diretores

Tudo perfeito. Porém, chega outra necessidade: Gestores e Diretores tem a capacidade de demitir. Gestores precisam gerenciar cronogramas, assim como os Supervisores fazem.

Pessoa.demitir(pessoa) não faz sentido, pois afetiria todos.
Gestor.demitir(pessoa) e Diretor.demitir(pessoa) atende, mas duplicaria o código.

Pessoa > Supervisor > Gestor
Pessoa > Diretor

Shi, apareceu outro nível hierarquico. Traits auxilia exatamente neste ponto ! Vejamos:

Trait Cronograma
Trait Evil (que contém recursos para demitir uma pessoa)
Pessoa > Funcionario
Pessoa > Supervisor : Cronograma
Pessoa > Gestor : Cronograma : Evil
Pessoa >  Diretor : Evil

Note que o Pessoa > Supervisor : Cronograma – os dois pontos para indicar o Trait são de minha autoria – era o Pessoa > Supervisor antigo. Isso porque as atribuições para gerenciar cronogramas foram passadas para o Trait.

Neste pequeno exemplo, o Trait nos auxiliou com um problema de domínio. Acredito que ele também aplique-se e muito bem para problemas onde temos domínios transversais, pois, nele ficariam as atividades do outro domínio pode o domínio principal teria acesso aos recursos sem quebrar a SRP.

Traits em PHP

Como disse no começo, o futuro-provável PHP 5.4 virá com o Trait. Por enquanto essa implementação funcionaria:

<?php
trait Cronograma {
 private static $ATRASADO = "sempre";

 public function cobrarDe(Pessoa $funcionario) {
   $funcionario->definirPressao(self::$ATRASADO);
   $this->youTube();
 }

 private function youTube() {

 }
}

class Funcionario extends Pessoa {
}

class Supervisor extends Pessoa {
 use Cronograma;
}

$colaborador = new Funcionario();
$controlador = new Supervisor();
$controlador->cobrarDe($colaborador);

Os Traits possuem boas capacidades com métodos de instância e estáticos. Vamos explorar um pouco mais:

<?php
trait Hello {
 public function sayHello() {
   echo "Olá";
 }
}

trait World {
 public function sayWorld() {
   echo "Mundo";
 }
}

class View {
 use Hello, World;
}

$view = new View();
$view->sayHello();
$view->sayWorld();
// exibe: Olá Mundo

Pegando informações da Classe

<?php
trait QuemSou {
 public function eu() {
   return get_class($this);
 }
}

class Foo {
 use QuemSou;
}

$foo = new Foo();
echo $foo->eu();
// exibe: Foo

Usando Variáveis de instância da classe

<?php
trait World {
 public function help() {
   return "{$this->hello} world";
 }
}

class Hello {
 private $hello = "Hello";
 use World;
}

$hello = new Hello();
echo $hello->help();
// exibe: Hello world

Modificadores de acesso dos traits na classe

<?php
trait Hello {
 public function ola() {
   echo "Olá mundo";
 }
}

class Modificadores {
 use Hello { ola as private };
}

$ola = new Modificadores();
$ola->ola();
// Fatal Error....

Modificadores de acesso com alias para nome de método

<?php
trait Hello {
 private function ola() {
   echo "Olá mundo";
 }
}

class Modificadores {
 use Hello { ola as public aloha };
}

$ola = new Modificadores();
$ola->aloha();
// Olá mundo

Há outros vários recursos como métodos abstratos nos Traits, precedência, métodos estáticos, late static bindings, métodos mágicos, alias para nome de método do Trait ao usá-lo na classe. Para Rubistas ou Scalistas (?) as possibilidades são as mesmas dos Mixins e Traits de Ruby e Scala respectivamente.

• RFC do PHP Trait (offline por enquanto devido a problemas no servidor deles)



O pequeno livro de Sebastian Bergmann, autor do PHPUnit, começa falando sobre  o que é e para que servem os “testes automatizados” com um texto bem didático explicando tin-tin por tin-tin. Na sequência, ele apresenta sua ferramenta que resolve o problema apresentado no capítulo 2 e inicia-se alguns how-to com troubleshooting da instalação do PHPUnit em seu ambiente de desenvolvimento ou homologação.

Após instalado, Sebastian fala rapidamente sobre como criar e rodar um simples caso de teste com PHPUnit e no capítulo seguinte, ele faz a abordagem dos Fixtures, algo que em meu ponto de vista foi a melhor coisa que ele inseriu no livro. Motivos não faltam:

• Cedo ou tarde, desenvolvedores perguntam como manter um pré-estado no database para rodar a suite de teste;
• Afoitos por testar, muitos iniciantes não leem sobre esse excelente recurso disponível para a maioria – qualquer eu diria – xUnit;
• Fixtures é uma mão na roda;
• Fixtures são pré-requisitos para testes automatizados de verdade, quando há necessidade de utilizar dados persistidos, obviamente.

No capítulo 7 é explicado como validar Exceptions do domínio da aplicação de forma legível e de quebra mostra que o PHPUnit também pode realizar testes de performances perfeitamente.

Outro capítulo que eu gostei de ler, o nono, explica sobre o Test-First Programming e lá ele dá algumas dicas valiosas para quem está iniciando neste mundo.

Ele aborda como o PHPUnit faz Code Coverage do software testado e dedica um capítulo inteiro para falar sobre Stubs e boas práticas/funções de um caso/suíte de teste.

Para finalizar, ele explica como integrar PHPUnit com Phing – na real fica super na cara que rola igualmente com Ant – o qual eu utilizo atualmente com Jenkins e PHPUnit – e fecha o pocket book explorando e explicando sobre os internals do PHPUnit e sobre como evoluir seus test-case à partir de uma classe base da framework de teste.

É um livro pequeno e de grande valia. Excelente referência para desmistificar algumas sombras que ficam ao trabalhar com PHPUnit. Valeu os quase dez dolares pagos por ele.

Vex - Setores TI e Operações - Maio 2009

A “ideia” de trabalhar fora veio repentinamente, basicamente com um pseudoconvite de meu amigo de longa data @Otata, que já estava trabalhando por lá e disse-me não por uma, nem duas, mas algumas vezes, de que a Vex estava contratando mais developers para fechar o time e que era para eu enviar meu “currículo”.

Após enviar meu currículo para o pessoal, houve os tramites default de conversa por telefone, entrevista pessoal, a renomada provinha tira-teima e no final do dia após enviar meu currículo estava ingressando no time.

Algo que achei peculiar foi a rápida contratação – comigo pelo menos. Tudo bem que houve ele, o QI, mas fiquei surpreso com a confiança que recebi dos coordenadores, afinal eu era até aquele momento um freela de cabelo comprido e que morava há alguns quilômetros de distância da empresa.

Ambiente

Vex - Galere Web - Maio 2009

Obviamente, totalmente diferente do até então escritório-casa que eu trabalhava enquanto freelancer. A adaptação não foi um problema, pois na Vex eu também utilizo notebook para desenvolver plugado à um monitor externo quase nos mesmos moldes que tenho em meu home office.

Por não recebermos visitas de clientes no prédio, podemos ir com roupas menos formais. Isso não quer dizer que eu possa ir de bermudas ou chinelos igual já tentaram fazer por lá

No andar do desenvolvimento, há também o pessoal de sistemas embarcados e redes. O relacionamento com todos sempre foi bem tranquilo, mesmo quando saía uns flamewars do tipo: Python vs PHP; Zimbra não é Yahoo!; e todo mundo contra o @Otata.

Vex - Junho 2009

Durante esse período uma coisa ficou clara: a empresa movimenta-se bastante. Houve pessoas entrando; pessoas mudando de área, pessoas deixando a Vex e até, pessoas que saíram e estão retornando novamente. As saídas, do ponto de vista pessoal, são ruins, pois todos no andar tem um contato diário, uma amizade e que depois de sua saída o contato praticamente se extingue.

Os PHP’ers

Vex - Galere Webdev (@bufoni)

Vex - Galere Web (@Sugamele)

Se os developers geralmente não batem muito bem das ideias, essa turma bate menos ainda ! (haha, vão me matar com esse comentário). O pessoal na Vex é bem tranquilo e são bem espontâneos. O que surpreende nessa turma são as diferenças: cada um possui seu temperamento, opiniões – muitas das vezes bem diferentes – e suas especialidades. Mesmo com tantas diferenças, nós, que trabalhamos geralmente aos pares ou trios e raramente individualmente, temos um envolvimento excelente nos projetos.

Ao que estive olhando nos logs do controle de versão, passaram aproximadamente 12 pessoas (achismo mode on) pelo time Web durante um período de 4 anos.

Inclusive, o @esampaio, aqui conhecido como meu chefe, publicou um vídeo com o histórico do SVN de um de nossos projetos internos.

Vex - Webdev. @Sugamele e eu - Agosto, 2009

Pela quantidade de pessoas que ao longo desse período trabalharam em cima desse projeto em específico é um pouco previsível o que pode-se encontrar nele. Há coisas realmente muito boas – tanto código quanto solução para um problema – a própria engine de i18n é uma delas, porém, há também coisas desenvolvidas no estilo WOP. (Workaround-oriented programming).

O que me chamou a atenção nessa área é a real vontade do pessoal em evoluir e melhorar os pontos que hoje não estão bons. Quality of Code está literalmente em alta e o princípio “Don’t live with broken windows” (para mais leia o livro: The Pragmatic Programmer) tem feito sucesso.

Quando é necessário atualizar alguma coisa ou sempre que possível – mesmo não estando na lista de prioridades, os códigos obscuros do passado são atualizados, melhorando não só a leitura e documentação (leia-se PHPdoc), mas também o relacionamento daquele módulo com todo o resto. Anima muito ver uma equipe – o que inclui os coordenadores da área – interessados em adotar metodologias e princípios que visam melhorar o código e entendem que isto no final, traz benefícios não só para os developers, mas também para os usuários da ferramenta.

Vex - (@lfamorim e @sergioprado ao fundo) @Otata e @acidcode - Maio, 2009

Vex - @bufoni @esampaio e @sergioprado - Fevereiro, 2010

Vex Webdev - @bufoni e @Sugamele - Setembro, 2009

Trabalho em grupo

Por ter o costume de trabalhar sozinho na época dos freelas – claro, havia o designer @jorgeveteran – eu, achei no começo que seria algo complicado. E sim, é complicado ! Não guardar as ideias ou soluções contigo é uma das coisas mais complicadas. Deixar o pessoal que está contigo no projeto atualizado das ações, estabelecer uma linha e manter as coisas alinhadas durante todo o projeto é algo que eu precisei reeducar quando comecei na Vex. Mas até hoje não houve nenhum tipo de problema com o pessoal que já trabalhei em conjunto.

Um dos maiores problemas foi encontrar paciência para explicar as coisas técnicas para o pessoal. Não sou o melhor exemplo de paciência quando a tarefa é explicar coisas – que eu julgo claras e simples de entender – aos outros. Consigo explicar tudo numa boa, porém, dúvidas e erros que eu julgo primários me deixa meio: “Não acredito que você fez/perguntou isso !?”.

Outra particularidade é que dependendo da pergunta – na realidade, quase todas – eu não forneço a resposta pronta. Forneço links, materiais e até títulos de livros para que a pessoa leia, estude e tire suas próprias conclusões a respeito. Antes eu debater com ela aquele assunto à eu “formar robozinhos” que repetem tudo que eu julgo ser verdade até aquele momento. Se eles não entendiam o motivo pelo qual faço isso, agora eles ficaram sabendo !

Vex Webdev - Playground - Fevereiro, 2010

Esse período que é um pouco mais de um ano realmente está valendo muito. Ao que percebo de comentários – críticas, na realidade – dos developers nas empresas em que trabalham, é possível ter uma clara noção de que a Vex é uma exceção. Uma equipe jovem, de jovens líderes e com ideias muito boas. O setor de tecnologia está de parabéns !

Retratos que coleciono desde quando iniciei na Vex podem serem vistos aqui, ó !

Reparando bem, cada modelo tem suas particularidades, porém com mesma base. O Pecl2 e Zend Framework PHP >= 5.3, aqui chamado de Java/Sun/Oracle Coding Standard, tem o mesmo objetivo: atualizar o não-padrão para trabalharem com suporte a Namespaces. O que explico mais adiante.

Antes do namaspace, ou seja, antes do PHP 5.3 a Zend recomendava um padrão que eu sempre achei ridículo, mas pensando bem, não tinha muito como fugir disso:

Arquivo: /application/module/Object.php
Nome da Classe: Module_Object

Arquivo: /application/module/client/view/Json.php
Nome da Classe: Module_Client_View_Json

Funcional ? Sim, sem dúvidas. Elegante ? Bem…

Bonito fica quando encontramos coisas como:

Arquivo: /application/module/AObject.php
Classe: Module_AObject <<abstrata>>

A adoção do prefixo “A” para abstrações e do prefixo “I” para interfaces. Além de nada elegante, só atrapalha o uso de Domain-Driven Design onde, resumidamente falando, tem como foco: transparecer no código o que você ouve de seu cliente/stakeholder.

Salvo engano meu, vi isso em um destes padrões sugeridos para o PHP. Mas infelizmente não encontrei o link :/

E aí veio o PHP 5.3

Com a chegada oficial do PHP 5.3, os padrões ao invés de unificarem-se e sugerir algo em comum, resolveram o que ? Criar mais padrões (o que chega a ser irônico) para brindar a chegada do tão sonhado Namespace (ou pacotes, para os Javeiros).

A Zend sugere o seguinte agora:

Arquivo: /application/module/client/view/Json.php
Namespace: \module\client\view
Classe: Json

Sim, óbvio ! Temos assim o padrão Zend Framework v2 ou simplesmente, Java Coding Standards. E eu não estou brincando não. No próprio artigo proposto por Matthew Ratzloff, ele cita como referência o link para o site do Java. O foco de Matthew é acabar com um problema grave criado pela Zend Framework: abreviação de nomes devido a quantidade de caracteres.

O pessoal do Pecl, sugeriu algo bem parecido. Manteve as particularidades e adicionou o suporte à namespaces ao seu Coding Standard.

Porém, há os frameworks

Obviamente em meio a sopa de pseudo-padrões, cada framework tem o seu próprio como era de se esperar. symfony, Cake PHP, Zend Framework, Kohana, etc. Cada um com o seu próprio mesclando vários e criando um terceiro.

Em minha sincera opinião, acho o Coding Standard do symfony de longe o mais bizarro: tab com dois espaços e nome de classe iniciado por minúsculo e sufixado com .class.php de longe lidera a aberração.

Para piorar o autoload dele autoriza coisas como:

Arquivo: /apps/module/lib/myObject.class.php
Classe: myObjectClass

Isso não funcionará com namespaces. Fato.

Teremos um padrão ?

Gostaria eu que sim. Seria fundamental estabelecer, agora com o reaparecimento de namespaces no PHP – sim, existiu num passado sombrio – um padrão default e que fosse largamente adotado. Complicado é convencer muito ego por aí a fora a abandonar seus pseudo-standards – que de padrão não tem nada – e utilizar um único facilitando a colaboração entre projetos e utilizando o tempo no que realmente importa: criar bons e bem documentados softwares.

Resumidamente é um projeto criado pelo Fabien Potencier - para quem não o conhece é o criador do symfony framework – e salvo engano há rumores de que ele pretende integrar o Twig à versão 2.x do symfony removendo o PHP super verboso que rola nos templates do symfony desde seu lançamento. * carece fontes concretas

Recursos bacanas e uma sintaxe à lá Django nos templates me chamou muita atenção para não só mais olhar, mas sim, testar para ver melhor a ferramenta.

Não demorou para eu testar como ele se portaria diante de objetos no template e para minha tristeza, para ele ler um atributo, depende nada mais, nada menos do que __get() e __isset(). É possível também, assim como na JSTL ler um atributo iniciado por get. No template você deveria chamá-lo sem esse get. i.e: getFoo() no template seria apenas foo.

Imediatamente, o que vem a mente de quem trabalha com OO ? Quebra brutal de encapsulamento. Sim, __get() por mais fácil que possa parecer, quebra totalmente a segurança de uma variável membro, uma vez que os atributos da mesma tornam-se públicos.

Tentei entrar em contato com o Fabien para ver o motivo que o levou a implementar assim. Ele, bem receptivo - ironia mode on - disse-me: se tiver um patch mande-o, do contrário, peço que seja paciente.

Fiz o patch, revi algumas coisas e mantive compatibilidade com o __get() __isset() que o Twig originalmente aceita e criei um Fork do projeto no GitHub.

Features default

• Suporte a plugins
• Variáveis
• Leitura de arrays por índices int ou string
• Arrays multidimensionais
• Objetos (via __get() __isset() apenas)
• Objetos alinhados (Nested Objects) com __get() __isset() também
• Blocos de controle, loops, etc.

Mudanças

Métodos públicos começados por:

• get
• is
• has
• match
• contain

Podem ser chamados no template sem qualquer problema sem a necessidade dos métodos mágicos.
Abaixo exemplos funcionais:

//...
/**
 * SomeVar
 * @var string
 */
 private $baz;
 /**
 * Bar Object
 * @var Bar
 */
 private $bar;
 /**
 * Magic String with __get
 * @var string
 */
 public $magic;

 public function __construct() {
    $this->baz = "Value of Foobar::\$baz";
    $this->bar = new Bar();
    $this->magic = 'Magic methods still working !';
 }

 /**
 * @return string
 */
 public function getBaz() {
     return $this->baz;
 }

 /**
 * @return boolean
 */
 public function hasBaz() {
     return (!empty($this->baz)) ? true : false;
 }

 private function hasIamNull() {
     return false;
 }

 public function fakehasFoo() {
     return 'I will not be displayed !';
 }

 public function matchesWith($otherString) {
     return ('foo' === $otherString);
 }

 public function getBar() {
     return $this->bar;
 } // ....

No template teriamos:

<body>
 <h1>Meu título</h1>
 <p>Bar foo</p>

 {% if foo.hasBaz %}
 <p>{{ foo.getBaz }}</p>
 {% endif %}

 {% if foo.hasIamNull %}
 <p>{{ foo.getBaz }}</p>
 {% endif %}

 <p>{{ foo.getAbstractBaz }}</p>

 <p>{{ foo.getIamPublic }}</p>

 <p>{{ foo.fakehasFoo }}</p>

 <p>{{ foo.getBar.getHlegius }}</p>

 <p>{{ foo.getBar.getBarFoo.getTwig }}</p>
 <p>{{ foo.getBar.getBarFoo.tryToCallMe }}</p> <!-- private function, fails. -->

 <p>{{ foo.methodThatIsnotExists }}</p> <!-- without error -->

 {% if foo.matchesWith('foo') %}
 <p>Yeah, it's matches !</p> <!-- will matches -->
 {% endif %}

 {% if foo.matchesWith('baz') %}
 <p>Yeah, it's matches again :S !</p> <!-- will NOT matches -->
 {% endif %}

Métodos não permitidos, índices não existentes e outros tipos de erros são omitidos por default.

Ainda penso em melhorar e implementar mais coisas ao projeto. Minha ideia inicial é ir sempre atualizando do projeto oficial para não distanciar-se muito. O patch eu também encaminhei ao próprio Fabien, mas ainda ele sequer respondeu ao meu e-mail.

Quem já utiliza o Twig e quiser testar essa nova versão mais “Object-oriented friendly” farei questão de dar total suporte e apoio para mantê-la up to date
Há ainda, exemplos de uso e do que você pode fazer com o Twig que eu modifiquei. Detalhes você encontra no diretório examples do projeto.

Vejamos um exemplo nada científico que fiz:

Criei os seguintes exemplos:

<?php
class Estatico {

    public static function fazAlgumaCoisa() {
        $i = 0;
        while ($i < 10000) {
           echo Estatico::outraCoisa();
           $i++;
        }
    }

    public static function outraCoisa() {
        return "Conteúdo";
    }
}

Estatico::fazAlgumaCoisa();

<?php
class Instancia {

    public function fazAlgumaCoisa() {
        $i = 0;
        while ($i < 10000) {
            echo $this->outraCoisa();
            $i++;
        }
    }

    public function outraCoisa() {
        return "Conteúdo";
    }
}
$objInstancia = new Instancia();
$objInstancia->fazAlgumaCoisa();

Os resultados após rodar quatro vezes cada foram:

Ou seja: 91.09 ms para o estático contra 90.07 para a versão non-static. Obviamente foi apenas um teste sem qualquer relevância, pois rodei em minha máquina pessoal com várias outras aplicações rodando em background. É perceptível porém, que a diferença não é absurda que compense o uso de estático por este motivo.

Deixando a questão de “performance” de lado, partimos para questões arquitetônicas:

• Identidade
• SoC – Separation of Concerns (Principio de Separação das Responsabilidades)
• Encapsulamento
• Estado
• DRY – Don’t Repeat Yourself
• Associações – sejam elas composições ou agregações

Ao perder Identidade e Estado as possibilidades daquele método – ou da classe inteira, caso use estático em tudo – tem o leque de utilidade reduzido para:

• Service
• Facade
• Factory
• Helpers – no âmbito de serem apenas funções que realizam determinada tarefa na aplicação sem qualquer valor ao Domínio

Com isso, perdemos também o Princípio de Separação das Responsabilidades, ou seja, a classe perde o controle sobre a integridade dos dados que ela deveria controlar e proteger contra acesso ou alteração indevidos.

Listei o DRY também por um motivo simples: com métodos estáticos, perdemos a grande chance de usar as variáveis de instância da classe à favor da mesma. Exemplo:

class UsuarioEstatico {

    public static function login($usuario, $senha) {
        // valida o usuário e zaz
        $autenticador = new Autenticador();
        $autenticador->autentica($usuario, $senha);
    }

    public static function logout($usuario) {
        // verifica se a sessao está aberta
        $autenticador = new Autenticador();
        $autenticador->fechaSessaoPara($usuario);
    }
}

class Usuario implements Autenticavel {
    private $autenticador;

    public function __construct($usuario, $senha) {
        // manipula os dados de entrada
        $this->autenticador = new Autenticador($this);
    }

    public function login() {
        return $this->autenticador->autentica();
    }

    public function logout() {
        return $this->autenticador->fechaSessao();
    }
}

Repare no modelo estático: foi necessário instanciar o antenticador por duas vezes em pontos diferentes. Opa, repetiu ! Mesmo que o autenticador fosse estático, teriamos duplicação, pois teriamos que certificar que o usuário existe e tudo mais. Isso porque não comentei como ficaria o lado cliente dessa implementação estática. O cliente – seja Controller, WebService ou qualquer classe em outra camada no domínio – teria que conhecer muita coisa sobre implementação dessa classe para poder manipulá-la.

Como bônus, repare que perdemos neste caso também o Polimorfismo, uma vez que eu poderia ter esse Autenticador() como base de autenticação para qualquer tipo (Usuário, Funcionário, Gerência, Administradores…)

O uso de métodos ou funções – sim, há diferença – estáticas pode ser bem-vindo nos itens já enumerados. Alguns developers porém, ainda que nestes casos são contra o uso por achar a ideia estática demasiadamente anti-oo.

É um processo teoricamente simples e sem mistérios, porém, o que muito vejo são pessoas com dificuldades em utilizá-lo da maneira correta. Acho que falta as vulgas tips para reduzir tais incidentes.

Vou dividir a configuração básica em duas partes. São elas:

1. Configurando o Zend Debugger no Windows
2. Configurando o Zend Debugger no Linux

Após a configuração particular em cada ambiente, teremos:

• Configurações no Zend Studio (comum para ambos ambientes)
• Configurações na Zend Toolbar
• Exemplos de uso
• Troubleshoot

Note que após baixar o Zend Studio, você não precisará de mais nada pois o pacote de mais de 300MB trás consigo além do Zend Studio os itens:

• Manual do PHP
• Manual do Zend Studio
• Zend Debugger (vamos precisar)
• Zend Toolbar for Mozilla Firefox, Internet Explorer e Google Chrome (vamos precisar)
• PHP 5.2 e PHP 5.3
• PHPUnit plugin
• Ambiente JRE (Java Runtime Environment - para rodar o Zend Studio)
• Todos plugins que o Zend Studio tem por default

Nota: desative quaisquer outros debuggers. Isto inclui o famoso Xdebug. Ao final explico como deixar ambos ativados – e falo o porque de ambos ativos antes que alguém me xingue =P

1. Configurando o Zend Debugger no Windows

Vou usar aqui a variável $ZEND_DIR para designar o caminho até a instalação do Zend Studio. No meu caso é: C:\Program Files\Zend\

Misteriosamente no Windows a biblioteca ZendDebugger.dll que acompanha o Zend Studio não funciona. Também não é para menos: a disponível no site tem 893kb, contra 132kb da que acompanha o Studio. No Linux isto não ocorre, tornando tudo mais estranho ainda. De qualquer modo, perguntei para eles o motivo.

Então, nosso primeiro passo é baixar o ZendDebugger do site . Após baixar, descompacte o conteúdo em um diretório temporário e copie apenas a biblioteca ZendDebugger.dll para o diretório que você vai criar: $ZEND_DIR\debug. Deverá estar assim:

Procure seu arquivo php.ini – caso não saiba onde esteja um php -i ou rodar o phpinfo() no servidor pode ajudar

Ao final dele você deve colocar:

; The section name is optional, but it's always a good idea to add it,
; especially if you are not using a separate file
[Zend]

; This directive needs the full path to the Zend Debugger DLL.
zend_extension_ts="C:\Program Files\Zend\debug\ZendDebugger.dll"

; This directive allows Zend Debugger to start a debug session with:
; 127.0.0.1/32 - Zend Studio on the same computer
; 192.168.0.1/32 - Zend Studio on a computer with IP address 192.168.0.1
; 10.0.0.0/8 - Zend Studio on any computer with IP starting with 10.
zend_debugger.allow_hosts=127.0.0.1/32

; This directive allows Zend Debugger to expose itself
; upon request (this is used in some service functionality).
; The possible options are:
; never - do not expose (default)
; always - expose to whoever wants to know
; allowed_hosts - expose only if the request comes from an IP listed above
zend_debugger.expose_remotely=always

Certifique-se do caminho correto em zend_extension_ts e em allow_hosts, caso queira adicionar mais IPs, apenas coloque uma virgula separando-os.

Agora procure por:

; Implicit flush tells PHP to tell the output layer to flush itself
; automatically after every output block.  This is equivalent to calling the
; PHP function flush() after each and every call to print() or echo() and each
; and every HTML block.  Turning this option on has serious performance
; implications and is generally recommended for debugging purposes only.
implicit_flush = On

Certifique-se que esteja On. Reinicie seu Apache, Lighttpd, IIS,…

Acessando seu phpinfo() novamente, você deverá ver a entrada do Zend Debugger:

Com isto a instalação do Zend Debugger está concluída. Em caso de problemas, certifique-se do caminho até a DLL do ZendDebugger ou ainda tente desativar os debuggers que você possa ter instalado ou ainda extensions adicionais para cache, performance e etc.

2. Configurando o Zend Debugger no Linux

Diferentemente do Windows, a instalação no Linux não requer baixar o ZendDebugger do site, pois a versão que acompanha o Zend Studio funciona perfeitamente igual

Assumindo $ZEND_DIR como diretório base do Zend Studio. No meu caso é: /usr/local/Zend/

Localize seu php.ini . Como eu instalo tudo separado, o meu encontra-se em /etc/php/php.ini. Você pode usar o comando # find / -name php.ini para localizá-lo ou ainda, rodar o phpinfo() que também serve.

Ao final do arquivo, coloque:

[Zend]
zend_extension="$ZEND_DIR/ZendStudio-7.1.1/plugins/org.zend.php.debug.debugger.linux.x86_64_5.3.7.v20091116/resources/php5/ZendDebugger.so"
zend_debugger.allow_hosts=127.0.0.1
zend_debugger.expose_remotely=always
[Debugger]
zend_extension_manager.debug_server_ts="$ZEND_DIR/ZendStudio-7.1.1/plugins/org.zend.php.debug.debugger.linux.x86_64_5.3.7.v20091116/resources/php5/"
zend_debugger.expose_remotely=allowed_hosts

O caminho não há quebra de linha

Note a versão do meu Zend Studio. Isto pode acabar mudando a versão do plugin também.

 org.zend.php.debug.debugger.linux.x86_64_5.3.7.v20091116

O seu pode ser bem diferente disto. até o .linux deverá ser semelhante. Depois disto, vem a arquitetura do sistema operacional (aqui é 64bits) a versão do Debugger e por fim a versão de atualização. Com um ls no diretório de plugins você acha a versão correta ao seu caso.

Procure ainda no php.ini por:

; Implicit flush tells PHP to tell the output layer to flush itself
; automatically after every output block.  This is equivalent to calling the
; PHP function flush() after each and every call to print() or echo() and each
; and every HTML block.  Turning this option on has serious performance
; implications and is generally recommended for debugging purposes only.
implicit_flush = On

Certifique-se de que esteja On. O comentário acima do comando já diz o porque temos que deixá-lo ativado =P
Salve e reinicie o Apache ou Lighttpd.

Acesse seu phpinfo e você deverá encontrar as seguintes entradas:

Com isto sua configuração no Linux está concluída

3. Configurações no Zend Studio

Assumindo que seu Zend Debugger está devidamente instalado, vamos as configurações no Zend Studio:

Certifique-se de possuir uma configuração semelhante.

Na linha PHP Debugger, clique em Configure…
Selecione o Zend Debugger na listagem e  clique em Configure

Mantenha essa configuração. Muito provavelmente você não precisará editar nada. Atenção apenas para o Client Host/IP:

Retornando à primeira tela, agora na linha Server: clique em PHP Servers…
Selecione Default PHP Web Server e clique em Edit

Muita atenção nesta parte: tudo que estiver listado ali será reconhecido pelo Zend Debugger como parte do projeto e portanto passível de debugar. O que não constar ali ele simplemente terá como “ok” e mesmo que você venha a colocar um breakpoint no código que não está contido no Path Mapping, ele irá ignorá-lo.

Por padrão, todo projeto que você cria no Zend Studio, ele automaticamente seta o próprio projeto na lista, e cada projeto tem o seu próprio Path Mapping. Por isso mesmo eu com 6 projetos setados na minha Workspace ele apenas está listando o projeto que está atualmente aberto. Caso eu abra e peça para ele debugar outro projeto, ele adiciona a lista esse meu outro projeto automaticamente.

Certo. Se ele adiciona automaticamente porque tenho que saber disto ?
Simples ! Você pode estar usando bibliotecas de terceiros ou usando sua própria biblioteca e não tê-la incluida ali significa que o Zend Studio não irá debugá-la.

Para finalizar, copie o conteúdo que coloquei online e salve-o como dummy.php na raiz de seu Servidor HTTP. Ele deverá estar acessível através do http://seuip/dummy.php e não é necessário colocar um em cada projeto, porém se você usa virtualhosts deverá ser um por virtualhost. Sem isto, o Debugger não funciona. A Zend disponibiliza este arquivo porém eu não me recordo se vem com o ZendDebugger ou se eu o peguei de outra fonte no site deles.

Neste ponto você já pode debugar um Script PHP ou uma URL que você forneça. Explicarei isto mais abaixo na parte Exemplos de uso.

4. Configurando o Zend Toolbar

Durante a instalação ele configura a Zend Toolbar para o Internet Explorer. Para configurá-la no Firefox é simples:

Com o browser aberto acesse o caminho: $ZEND_DIR/ZendStudio-(sua_versao)/toolbars e clique em ZendFirefoxToolbar-2.2.xpi.
Instale e reinicie o Mozilla Fx.

Após reiniciar o Firefox e com o Zend Studio aberto, vá na ZendToolbar em Extra Stuff -> Settings

Certifique-se do caminho setado em Zend Studio Executable que geralmente vem errado e o Zend Studio Broadcasting Port que deverá ser igual ao meu.
Após isto, clique em Test e o resultado deverá ser:

Com isto a configuração do Zend Studio, Zend Debugger e Zend Toolbar estão concluídas.

5. Exemplos de uso

Para exemplificar melhor, vamos criar um pequeno projeto no Zend Studio.
New -> PHP Project

Coloque o nome Zend ou qualquer outro e finalize.

Ele terá três arquivos: São eles: Foobar.php Finaliza.php e index.php . Salve-os em seu projeto.

Acesse http://seuip/projeto/index.php com o Mozilla Firefox. Deverá aparecer na tela o conteúdo:

Uma string qualquerFinalizando

Agora, clique em Debug na Zend Toolbar. Talvez ele pergunte sobre abrir a perspectiva de Debugging. Marque para sempre tomar esta ação e dê ok.

Note que ele está parado na primeira linha do arquivo:

Suas opções são:

• F5: entra no método/classe que esteja dentro do seu Path Mapping. Caso não esteja, ele executa a ação normalmente e vai para a próxima instrução.
• F6: executa a linha corrente e segue para a próxima instrução
• F7: executa a linha corrente e sobe um nível (usando quando você aperta F5 sem querer :p)
• F8: executa todo até encontrar um breakpoint
• Ctrl + F2: mata a sessão de debugging sem finalizar o script.

Estas opções que listei, você encontrará na barra que está na aba Debug.

Aperte F6 até ele ficar sobre a linha 6, $objFoo = new Foobar(); e então, aperte F5.Note que ele abriu a classe Foobar e parou sobre a primeira linha dentro do construtor da classe. Repare na aba Variables que até aquele ponto, a variável membro baz está nula.

Pressionando novamente F5 ou F6, você será enviado para a linha que contém a chave que fecha o método construtor. Neste ponto, baz possui o valor bar que contém três caracteres.

Apertando F6 ou F5 novamente, ele retornará a index.php sob a linha $objFoo->finaliza(). Caso decida pelo F5, ele entrará no método. Caso F6, ele executará a ação do método (e seus subníveis) e passará para a próxima instrução – que em nosso caso seria a próxima linha.

Siga com F5 ou F6 até o término do script para acompanhar a evolução e modificação das variáveis.

Breakpoints

Quem nunca usou um debug, talvez não conheça o que venha a ser um breakpoint. Ele na forma literal é um ponto de parada do debug

Vamos como exemplo, setar um na classe Foobar na linha 20. Para tal, você pode clicar duas vezes ao lado do número que identifica a linha ou então, com o cursor sobre a linha usar Ctrl + Shift + B

Um ponto ficará ao lado da linha identificando que há um breakpoint ativo. Novamente clique em Debug na toolbar. Ao abrir o Debug na primeira linha, pressione F8. Ele deverá parar sob nosso breakpoint.

Na aba Breakpoints você pode desativar ou remover os breakpoints setados sem necessitar abrir arquivo por arquivo para removê-los.
É possível definir condição para que o Debugger pare sobre determinado breakpoint. Para definir a condicional, clique com o botão direito sobre o breakpoint e vá em breakpoint properties.

Ao lado do botão Debug na Zend Toolbar, há o Debug Menu . Nele há quatro opções: Current Page; Next Page; All forms (POST) in this site; All pages in this site. Recomendo que crie formulários, teste em chamadas Ajax, iframes (argh!), redirecionamentos HTTP e tudo mais que use no seu dia-a-dia. O Debugger pega qualquer ação no browser

E como brinde por ter configurado o Zend Debugger, você tem o Profile da página atual. Bastando para tal clicar em Profile.

Enjoy

6. Troubleshoot

Habilitando o Xdebug junto com o Zend Debugger

A utilidade disto é que o Xdebug fornece recursos como: highlight de variáveis var_dump() – que não vamos mais usá-la como debugger – controle contra loopings infinitos, o trace completo quando encontramos Warning ou Fatal Errors e alguns outros mimos que o Zend Debugger não trás – ou eu os desconheço

Para habilitar ambos, abra seu php.ini. E mude a entrada do Xdebug de:

;zend_extension=php_xdebug.dll

para

extension=php_xdebug.dll

O mesmo vale para a versão Linux, mudando apenas para .so

Ele não para sob os breakpoints que setei

Verifique o Path Mapping se o mesmo contém seu projeto listado. Caso não, adicione manualmente o projeto ao Path Mapping e tente novamente.

Uso biblioteca externa – Propel, Symfony, Zend.. e toda vez que chamo o debugger recebo a tela:O problema é novamente o Path Mapping. Adicione o caminho da sua lib externa ao Path Mapping (veja como na sessão de configuração do Zend acima) e tente novamente.

Para finalizar…

Há um excelente artigo em inglês que explica como configurar o ZendDebugger no Linux e Windows e ainda explica o funcionamento do Debugger sobre a aplicação web. Vale a pena a leitura.