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.

Desde quando comecei a fazer programas venho usando algumas ferramentas para desenvolver em PHP.
Na categoria Editor / IDE, na minha mão (ui) já passaram Quanta Plus, KDevelop, Eclipse PHP IDE, Netbeans for PHP e agora estou utilizando o Zend Studio. Com exceção do último, todos free ou opensource.

Netbeans é muito bom, porém o que me chamou a atenção no Zend Studio foi o all-in-one que ele traz por default. Listando rapidamente:

• Editor PHP
• Integração SVN/CVS/Git
• PHP Debugging já integrado ao Zend Debugger
• PHP Profiling
• Database Management e Debug
• Um ToDo simples
• Facilidade em achar as coisas nos projetos
• Zend Toolbar integration para Firefox e IE – mas quem liga pro IE afinal
• etc…

Claro que não é impossível configurar toda essa penca de coisa no Eclipse nativo ou Netbeans, só que isto demandaria tempo.

Destaque para PHP Debug, Profiling e Zend Toolbar. Isto me chamou MUITA atenção quando estava olhando reviews e também nos trinta dias de testes.

Além do feijão com arroz temos:

1. Call Hierarchy / Type Hierarchy / Open Type Hierarchy

Ajuda um bocado na localização nas relações entre classes e métodos dentro do projeto. No exemplo tenho um método que chama outro e esse outro chama outro. No caso, tudo dentro de mesma classe, mas funciona perfeitamente em qualquer parte do sistema – incluindo libs no Include Path:

Já o Type Hierarchy mostra a relação entre uma classe e suas relações com classes pai ou interfaces:

E o Open Type Hierarchy (Ctrl + Shift + H) auxilia a localização de objetos, arquivos e métodos dentro do projeto.

Ainda na área de localização de elementos, há uma pesquisa mais completa (Ctrl + H) que permite localização de métodos, arquivos, classes separando por tipo e muito mais:

Após encontrar um resultado, a tab search é exibida/focada:

2. Indentação e Marcação (diff) no código:

Outra coisa interessante – e que existe em qualquer IDE decente – é a possibilidade de trazer o que é chamado de Quick Diff. Este recurso permite mostrar de forma simples o que você alterou, removeu ou adicionou no código. Funciona com SVN, CVS e cópia do disco local. Selecione o tipo e as cores e voilà !

Embora muito comum, a indentação de código é algo interessante de manter ajustado (tab com 4 espaços) e suas preferências quanto a espaço entre os elementos; posição de chave de abertura e etc;

Nessa tela é possivel você definir praticamente tudo sobre indentação de código ! Depois de configurar ao seu gosto (ou padrão) pode exportar para XML e usar em qualquer outra ferramenta que leia o formato – qualquer Eclipse, por exemplo =P

Depois de configurado, você pode selecionar o trecho a ter a indentação ajustada selecionando o trecho e  Ctrl + i – obrigado, Otávio pela dica; Pode formatar todo um arquivo usando Ctrl + shift + F – valeu Toscano pela tip – ou ainda, formatar TODO o projeto: Selecione o Projeto no PHP Explorer, Source -> Format – obrigado hlegius

Note que todos atalhos funcionam no Eclipse também

3. PHP Debug

Não é um recurso muito usado pelos developers PHP, principalmente aqueles que começaram com PHP, como eu, mas sem dúvidas revoluciona a forma de como você desenvolve. Após adotar o debug você não quer mais saber de var_dump() ou print_r() com aqueles: ‘estou aqui’ para verificar o que pegou na aplicação.

Como o PHP é baseado em Web, seria fundamental ele poder ser debugado como se estivesse sendo carregamento pelo browser, não ? E é exatamente isso que permite o Zend Debugger – o Xdebug também =~

Ambas engines de debug podem ser integradas ao Zend Studio, porém, no pacote do Studio já vem a versão mais recente do Zend Debugger e tudo já meio que ajustado para rodar com ele

É possível debugar um script PHP Modo terminal e claro, o PHP Web Debug. Para este último você fornece a URL que quer debugar e ele abre a sessão de debugging parando na primeira linha.

Utilizando os breakpoints você pode acompanhar o fluxo da aplicação, valores das variáveis, propriedades dos objetos instanciados e etc.

Claro que nossas aplicações vão muito além de uma simples URL. Temos chamadas com POST, GET e até chamadas em Ajax. O Zend Studio provê uma extension para o Firefox chamada Zend Toolbar. Essa toolbar, permite que você diga ao browser para chamar a sessão de Debug ou Profiling do Studio na próxima página; página atual; Qualquer submit POST ou ainda em qualquer ação no browser. E o pior: funciona !

A configuração do Zend Debugger na sua máquina é simples, mas acho ser digna de um post inteiro sobre isto. Vou tentar preparar um material e publico aqui a configuração e uso dele no Zend Studio.

4. PHP Profile

Além de debuggar, seria interessante analisarmos o desempenho da aplicação. Ok, segue:

Chamadas, quantas vezes chamou; quem demora mais; quem é mais rápido; quem chama quem;

E ele, o fluxo da aplicação:

A Zend Toolbar também provê acesso simples ao Profiling. Basta clicar em Profile na toolbar e pronto. O Studio é chamado e o profile da página é feito.

5. Database Management

Para fechar, gerenciamento dos databases. Possui ponte para vários databases incluindo Oracle, MySQL, PostgreSQL e MSSQL.

Por ele é possível adicionar valores, editar, remover, rodar Queries SQL, backup de estrutura e valores e ele também armazena suas Queries para re-executá-las com um clique quando quiser.

6. Outros

SVN, projetos remotos – incluindo acesso SMB ou FTP; WebServices; Históricos locais, SVN, diff, suporte a Git e suporte a quaisquer plugins que rodem no Eclipse, afinal o Zend Studio tem como base o Eclipse.

Já o configurei no Ubuntu lá na Vex, Windows 7 e Arch Linux aqui no escritório pessoal. Tudo muito tranquilo, sempre.

7. Preços e licença

O custo da licença eu acho alto demais para uma IDE de desenvolvimento. Atualmente são US$ 400,00 por ano para ter suporte e atualização sempre. Caso queira, pode comprar a licença por um ano e depois não comprar mais. Neste caso você ficaria com a última versão antes da expiração de seu suporte ilimitado. Em miúdos: enquanto você paga, recebe atualização da versão.

Comprei em setembro, na versão 7. Em Setembro de 2010, vamos imaginar que esteja na versão 9. Terei as licenças para 7, 8 e 9. Expirou e não renovei, mas saiu update da versão 9, a 9.1, por exemplo. Tenho update dela, pois a licença é a mesma da 9. Porém, no lançamento da 10, eu precisaria comprar uma nova licença para ter direito de baixar e usar a o v10.

Minha opinião final: gostei e tenho usado apenas ele desde quando comecei a testá-lo em meados de Setembro de 2009. Tem muita coisa boa e que ajuda muito e mesmo com o alto custo, vale cada centavo pago até o presente momento.

#notamental não é post patrocinado, tão pouco trabalho na Zend, certo ?

Topei ! Respondi 8++ questões as quais podem ser vistas acessando o blog dele.

Agradeço o convite e deixo aqui um convite formal para um bate-papo numa (un)conference qualquer. o/

O check-in para a prova é um pouco tenso colocando ainda mais medo em quem vai fazer a prova. Documentos em inglês, assinar em três lugares diferentes, marcar hora de entrada, guardar itens no guarda-volumes e entrar liso, apenas com o crachá da instituição em uma baiazinha apertada de 1x1 metro quadrado onde mal cabe você e o computador.

Essa baia tem um além do PC - totalmente travado e rodando Windows 2000 - um fone para os ruídos externos não atrapalhar-te durante a prova. Bem acima há uma câmera filmando todas suas ações e a única coisa permitida é utilizar o teclado, mouse e uma folha de anotações com apagador e canetão para lousa.

Na minha prova, resumidamente caiu: PHP 4, 5, diferenças entre 4 e 5 e uma pergunta de PHP 3. Design patterns caiu umas quatro ou cinco questões. Admito que era necessário pensar, não era perguntinha boba como do tipo: "o padrão que faz tal coisa é : ..., ..., ...". Era necessário analisar a melhor solução com as patterns lá descrimidas e fazer sua escolha. Gostei dessa parte

Havia perguntas cabulosas onde era alterada várias vezes e de várias formas um objeto copiando, referênciando e tudo mais; para no fim ele requerer a saída de todas variáveis que aquele objeto teve durante o ciclo de vida.

Caiu coisas sobre segurança, PDO, SQLite, perguntas específicas de banco de dados - coisas como definir transação, prepared-statements, ... - comparação de tipos, coisas sobre arrays e refatoração de código. Neste último ele fornecia um código legado em PHP 4 e pedia a versão em PHP 5. Nada complexo, coisas simples, somente para testar se você conhece PHP4

O tempo de prova é excelente. 90 minutos para 70 questões. Eu finalizei a prova restando pouco mais de 40 minutos. Super tranquilo. Fiz sem pressa, na calma, lendo e pensando nas soluções.

É totalmente permitido pular questões e depois voltar nelas, porém, não fiz isto. Fui na sequência. Direto !

Ao fim, ele mostra as questões que possívelmente não tenham sido respondidas e pergunta se você quer finalizar a prova. Clicando que sim, ele confirma novamente e informa que não há mais volta :O

Ao confirmar novamente, aparece uma barrinha de "loading...". Ela ficou por alguns segundos, que mais pareciam uma eternidade. Respirei fundo e olhei para a tela novamente. Vi em negrito e em h1: Congratulations ! You passed (..) [alguma coisa a mais que eu nao lembro]

Respiro de alívio e ao mesmo tempo ergui as mãos e falei meio que sem voz: Eu consegui !

Saí da salinha mais do que depressa e ao chegar na recepção já havia um "comprovante" da prova informando que eu havia passado, com data, hora e meu código da prova.

Agora estou esperando chegar a certificação pelos correios e pelo que andei olhando no Flickr, junto virá um adesivo Zend Certified PHP 5 para eu colar na testa onde quiser.

A prova exige que você tenha vivência com a linguagem. Não adianta "decorar", comer livros ou fazer cursos de verão. Esqueçam. Precisa saber o que acontece quando as coisas dão certo e principalmente: o comportamento das coisas quando dão errado. Como por exemplo:

Você pode - e deve - pesquisar por simulados online e realizar testes com a linguagem. A melhor coisa que você pode fazer é ler o manual do PHP. Melhor fonte para aprender bem o PHP. Há também o Zend Self-test que você poderá tentar também.

Sabe aquelas vezes em que você precisa realizar tarefas demoradas no browser do cliente e então você lembra do maravilhoso Cron Jobs ? Pois é, uma excelente ferramenta a nossa disposição. Entretanto, às vezes, certas empresas de hosting (Locaweb é uma) define um horário para funcionamento destas "tarefas agendadas". No caso da Locaweb é das 2 às 3 da matina apenas.

Mas, mas e agora ? Como executar a tal sonhada tarefa "em background" quando não há o Cron Jobs como opção ?

Um pouco de história

Sabemos muito bem que o PHP é server-side e isso significa que o PHP roda no servidor e não no cliente como o Javascript, por exemplo. Entretanto, logo quando eu comecei a programar com PHP eu me perguntava o motivo pelo qual o script era interrompido ao clicar no botão Stop do browser ou então quando eu o fechava já que a ação era no cliente e não no servidor. Tempos depois descobri que nestes eventos, era enviada uma informação ao servidor PHP (via TCP, claro) que de o usuário "abortou" a conexão com ele e o PHP bem esperto que é, parava aquela tarefa.

Entretanto...

O PHP nos permite manipular esse comportamento, ou seja, posso dizer ao PHP que eu quero continuar executando o script mesmo se o cliente nos deixar na voz ! Como uma imagem vale mais do que mil palavras, deixo aos senhores um pequeno vídeo que fiz demonstrando o funcionamento:

Perceba que caso queira redirecionar o usuário para outra página e continuar trabalhando naquela tarefa, você precisa manipular o buffer e os headers da página da forma como coloquei no script, caso contrário, ele irá processar todo o conteúdo e depois sim, redirecionar. Isto por quê, como não estamos enviando nada diretamente ao browser, o Apache espera uma quantidade de dados enviados antes de processar quaisquer headers. Com as funções de buffer do PHP nós podemos mudar também esse comportamento, forçando-lhe a obedecer o header (Location).

Deixo abaixo o código dos dois arquivos usados no vídeo:

E também, o vídeo original no formato OGV.

Mais informações:

• http://br.php.net/ignore_user_abort
• http://br.php.net/manual/en/features.connection-handling.php

Nota: o programa usado para gravar foi o qt-RecordMyDesktop para Linux.

Pense numa rotina que desenvolveu. Qualquer uma ! Agora tente se recordar de quantas formas ela poderia ser quebrada pelo usuário, gerando assim algo inexperado na sua aplicação fazendo com que você retornasse um erro para o cliente.

E qual é a forma que você utiliza para retornar estes erros ? Veja, eu posso ajudar a recordar você:

Com isso lá na sua Action você fica fazendo malabarismo para encontrar o erro retornado e gerar a mensagem para o usuário. Não demorará muito para você criar sua tabela de erro:

• -1 para erros de entrada
• -2 para erros de máscara
• -3 para calcúlos errados
• -4 para usuário não logado
• -5 ....
• -7634 ....

Realmente, bem simples assim né ? Só consultar a tabela e mandar bala.

Eu realmente não entendo o motivo de muitos não utilizarem a classe nativa de exceções do PHP. É simples, é funcional e de grátis você não precisa montar sua tabelinha de códigos de erro.

Veja o mesmo código reescrito utilizando a tal classe:

Com isso na sua Action, simplesmente:

Assim, você pode ter 1, 2, 3, n mensagens de erro em n camadas da aplicação sem a necessidade de se preocupar em tratar uma a uma também na Action. Fica ultra-transparente na Action além de economizar seus dedos refazendo coisas que já estavam prontas camadas a dentro.

Nota: Não esqueça disso nunca : jamais lance como exception uma mensagem de erro do PHP. Isso é feio - porque vem em inglês -, você será xingado por 3 gerações futuras de programadores além de permitir que os usuários vejam detalhes sobre sua aplicação.

Como detectar os erros sem lança-los ao usuário ?

Bem simples. Persista-os - eita mania - em arquivos de log. Mas calma, antes de sair criando algo com fopen(), leia isto: o PHP também traz o cara que salva - persiste - erros ! Ah sim, o PHP é excelente eu sei. Voltando ao exemplo...

Sim, ele, o error_log() salva o log para ti. E pior, digo, melhor: caso queira ele pode enviar a notificação no seu e-mail. Certo, em boa parte dos casos isto definitivamente não é uma boa ideia. Mas pode ser útil algum dia, penso.

Resumo do dia: use ao máximo as Exceptions e as funções para tratamento de erros do php .