Salvador Dali, 1931 - The Persistence of Memory

Já conversei com pessoas que batem o martelo facilmente dizendo:

- É por tempo.  Eu programo em brainfuck há seis anos, logo sou sênior.

Será mesmo ?

Em tempos modernos, fica ainda mais complexo fazer uma avaliação deste tipo para programadores, arquitetos ou engenheiros de software, pois, não é somente uma linguagem de programação que está em análise. É todo um contexto que abrange desde a escolha do ambiente de desenvolvimento até relacionamento com stakeholders e domínio em metodologias e paradigmas de desenvolvimento.

Se temos a análise temporal como inválida, então o que espera-se de um dito sênior ?

Para tal, conversei com três pessoas que estão diretamente envolvidas com estes aspectos.

Creio que sim. Existem os profissionais seniores, porém muitas pessoas, e empresas, acabam confundindo o nível do profissional com o seu tempo de experiência.

Em minha visão, o tempo de experiência é importante, porém, não determinante para rotular um profissional, ou seja, é perfeitamente possível existirem seniores com 3 anos de experiência e juniores com 15 anos.

O profissional Júnior, é aquele que já desempenha as tarefas com certa autonômia, porém, necessita de um maior tempo de pesquisa e em alguns casos de orientação.

Por sua vez, o pleno já demora um tempo menor para realizar as mesmas tarefas além de não necessitar de orientações referente aquela tarefa. O que difere o pleno de um sênior é a visão holistica, ou seja, para ser um profissional sênior é preciso possuir habilidades complementares as necessárias para o desenvolvimento daquela tarefa, isso ajuda acima de tudo no desenho de uma melhor solução além de maior facilidade no tratamento de problemas.

Outro ponto que vale ser observado, é que muitas vezes o sênior é destacado para tarefas simples, que não exige um conhecimento avançado, como seguir um procedimento de criação de usuário. Esse fato, além de desmotivar o profissional, gasta recursos de forma imprudente, já que são os seniores que deveriam criar os procedimentos a serem seguidos, além de desenhar soluções para problemas e corrigir falhas críticas ou em serviços críticos.

Vinícius Bufoni, coordenador de engenharia web na Vex

Este é um assunto interessante. Na maioria dos lugares as pessoas usam “anos de experiência” como medida para classificar. Esta é, na minha experiência, uma das piores maneiras de se fazer este tipo de classificação. Uma pessoa que desenvolve em, digamos, JSP e Servlets Java por 10 anos não necessariamente tem 10 anos de experiência desenvolvendo software, ele tem experiência desenvolvendo JSP e Servlets! E mesmo assim, tempo gasto em uma tecnologia não está diretamente relacionado com proficiência nesta. Enfim, utilizar tempo para medir experiência é, normalmente, uma besteira.

A forma com que eu tenho lidado com esta relação entre níveis de desenvolvedores, atualmente, é usando algo chamado modelo Dreyfus de aquisição de conhecimento: http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition .

Normalmente eu tenho as áreas em que eu considero que meu time deve ser competente (este post: http://fragmental.tw/2009/11/24/i-wish-i-knew-that-before-getting-this-job-–-slides-and-long-notes da uma idéia sobre quais seriam estas áreas) e uso o Dreyfus para tentar entender onde cada um está nestas competências. Tem funcionado relativamente bem para mim mas ainda é, como sempre será, problemático e, por muitas vezes, injusto.

Phillip Calçado, consultor na ThoughtWorks

Do meu ponto de vista um profissional sênior é acima de tudo auto suficiente, é o tipo de profissional em que você não precisa passar o que deve ser feito, ele geralmente entende seu papel em uma equipe e como pode contribuir.

Um profissional Sênior consegue tomar decisões e assumir responsabilidades, ele não depende de alocações e precisa de muito pouca supervisão gerencial e técnica.

Geralmente um profissional Sênior também, está sempre atualizado e esta sempre ligado em tendências do mercado e em como adaptar estas novidades a sua realidade nos projetos em que esta envolvido.

“Tempo” de experiência na verdade não é tão importante, mas a diversidade e intensidade da experiência da pessoa é extremamente importante, se ele esteve envolvido uma grande diversidade de projetos e atuou em papeis dos mais diversos, um profissional sênior geralmente consegue se adaptar pois já trabalhou em diversos papéis e com diversos times.

No caso de grandes empresas de Internet, como o Yahoo!, é vital que o profissional sênior entenda de e tenha tido vivência com projetos de grande escala, e que entenda de Sistemas, arquiteturas e plataformas que funcionem com grandes volumes de acesso e demandam muita performance.

Não gosto muito destes rótulos, mas um profissional Pleno depende de um nível de supervisão/apoio maior. Um Pleno também tende a ser mais inseguro na tomada de decisões e definições mais complexas.

Mas a principal diferença é a experiência, bagagem de conhecimento. Em entrevistas sempre pergunto qual foi o maior desastre da carreira da pessoa, espero que ele me diga quais foram os erros e o que ele aprendeu com isso. Isso mostra maturidade em relação a tentativa/erro, onde não se deve temer cometer erros e que sempre devemos aprender com eles e continuar tentando. Isso é chave para ser inovador.

Antônio Carlos Silveira, diretor de Produto e Engenharia, Yahoo! América Latina

Cada um tem seus métodos de análise, mas ficou evidente que contar os dias no calendário já não é mais tão convincente como parecia

"Java printout por Ngọc Hà @ flickr"

Naquela época era claro para mim que programação era algo relacionado à área de exatas, pois criar uma aplicação é algo lógico tendo envolvimento direto com matemática e tudo mais.
Em coisa de um mês e pouco já conseguia fazer até uns “SQLs” e montava sites no estilo macarrônico de desenvolver. Aquilo para mim era fantástico! Tinha como objetivo aprender bem a linguagem para assim conseguir minha certificação da Zend, tornando-me assim um programador profissional.

Aconteceu porém, algo inesperado: comecei a “seguir” – não era no Twitter, até porque ele ainda era um protótipo de projeto na época – pessoas realmente profissionais em desenvolvimento de software e eu percebi assim que o buraco era mais embaixo e que eu ser excelente em uma linguagem era apenas um dos passos para tornar-me um programador profissional.

Abrindo um parênteses, eu li através do @sergioprado, não lembro onde agora, uma frase interessante e que tem como tradução algo como:

"O caminho para tornar-se mestre: siga o mestre; ande com o mestre;
torne-se o mestre."

Após começar eu a seguir os mestres, pude perceber que programação vai muito além da leitura de um requisito funcional de software e fazer daquilo algo sistêmico. Hoje, arrisco-me a dizer que programação não é algo somente relacionado à exatas. Possuí também, questões éticas – humanas – e artísticas.

A programação é relacionada a área de exatas

Isso é bem claro aos envolvidos em desenvolvimento de software. Você lê um problema descritivo, vulgo especificação funcional, ou visual (UML, rabisco na Moleskine, whatever) e faz daquilo algo sistêmico e que agregue valor ao negócio de seu cliente.

Como premissa você precisa aprender uma linguagem. Conhecer uma linguagem bem não é nada fácil. Você precisa empenhar-se para conhecer as intrínsecas e peculiaridades para aproveitar o melhor dela, tornando-se um especialista na linguagem. Eu valorizo mais um programador excelente em uma linguagem a um que já “trabalhou” com várias. Não é impossível uma pessoa ser excelente em mais de uma linguagem, mas isto, porém, demandaria muito tempo de dedicação para atingir tal nível.

A programação é relacionada a ética

Toda área tem suas condutas éticas e humanas, óbvio. Em programação, porém, vejo muitos ditos programadores ignorando isto. Quando você troca qualidade por falso ganho de tempo, você está sendo antiético. Quando não analisa corretamente as decisões que irá tomar em cima de algum problema, falta-lhe ética. Quando deixa de atentar seu cliente, o que inclui seu chefe, sobre a ausência de segurança, qualidade ou algum problema em cascata que venha a aparecer em decorrência de uma atitude, você está sendo antiético.

E isso acontece em demasia em nossa área! Seja por falta de interesse por parte do dito programador ou mesmo por medo de perder o emprego/projeto por “afronto” ao seu chefe ou cliente.

Para conhecer as técnicas, metodologias e artimanhas no desenvolvimento de software é necessário antes, ter uma boa noção de análise e projeto de software; arquitetura de aplicações; padrões e melhores práticas, para, após criticar uma atitude antiética de seu chefe/cliente, você ter total embasamento para propor a solução sem comprometer o projeto nem a aplicação. Isto será necessário também, para você ter um vocabulário comum para quando estiver numa roda de conversa entre os “mestres” da área.

Importante ressalvar que seu cliente ou chefe pode estar tomando uma atitude antiética, no ponto de vista de programação, inconscientemente. Afinal ele é especialista no negócio, o programador profissional é você!

A programação é também relacionada a artes

Há uma enorme diferença entre criar algo que funcione e criar algo que além de funcionar, transparece o domínio (regra de negócio).

Eu posso saber ler e escrever em português, mas há uma diferença gritante entre um poeta português e eu. Ele, diferentemente de mim, sabe utilizar muito bem as palavras e com elas, faz transparecer sentimentos, idéias e pensamentos sobre determinado tema, trazendo um enredo ao assunto abordado, envolvendo-nos em sua história.

Posso saber desenhar, mas isso não me torna um artista que emociona as pessoas com minhas obras.

Como programadores profissionais é fundamental conseguirmos fazer o mesmo ! É de nossa responsabilidade criar um código simples, legível e que conte toda a história da aplicação através de seus pacotes, classes, métodos, parâmetros, atributos e variáveis. Qualquer coisa diferente disso, não pode ser aceito como código profissional.

Pouco importa se a linguagem X é tachada como mais poluída que a Y. Você como profissional, tem que quebrar essa barreira e torná-la tão legível quanto qualquer outra, afinal, você é especialista na linguagem, lembra ?

Além de criar, é nossa responsabilidade cuidar para que o código continue sempre otimizado por tantas quantas forem as mudanças que nele ocorrer. Criar algo legível recai diretamente sobre isto, pois, no futuro outro profissional em programação poderá continuar seu trabalho sem danificar ou abandonar as premissas cruciais para um bom código. Andrew Hunt aborda o título: “Don’t live with broken windows”, onde resumidamente ele alerta para não descuidarmos da qualidade, pois, basta uma janela quebrada em uma casa para que ela transpareça o estado de abandono, fazendo assim, com que outras pessoas destruam mais janelas.

E como toda arte, não há uma receita para criar bons softwares. É necessário muito empenho, ler muitos códigos, revisar muitos paradigmas ao longo do tempo e claro, programar bastante. Não é possível tornar-se um programador profissional sem conhecimento teórico, tão pouco, sem vivência com erros e acertos.

Ao desenvolver a aplicação, não aceite nada menos do que seu melhor naquilo e atente-se para não cair na armadilha de criar softwares de forma sistematizada. Tenha autocrítica para fazer avaliações em seus próprios códigos e evitar assim, programar por coincidência.

Lembre-se de que será seu nome no @author.

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.

Com o recente lançamento do Windows 7 e seus vários comentários positivos sobre o tal, resolvi arriscar. Até demais ! Comprei uma licença do Windows 7 Home Premium para, digamos, testar.

Esse teste custou-me R$ 399,00 com frete grátis pela Fnac.

Instalação super tranquila. A instalação Microsoftana de sempre desde a era Windows XP. Umas perguntinhas aqui e ali e voilà, instalado !

Nem vou comentar o que todos os blogs tem falado por aí. Leia-se: barra de tarefas baseada em ícones e agrupadas por tipo; efeitos do Aero; Kernel (monotílico), mas com um baita refactoring; Indexação de arquivos para pesquisa; Usuários e Grupos herdados dos Windows versão Servidor (Unix, alguém ?).

O ponto principal é: após usá-lo por quase uma semana, travei ele apenas uma vez usando loop infinito, diga-se de passagem e assumo dizer que nem foi totalmente culpa do Windows. Tudo bem que ele como carro-chefe, deveria impedir loop do tipo “ao infinito e além” mas enfim (..).

Eu nunca gostei do desempenho do Windows. Fato ! Não conseguia deixar a máquina ligada e trabalhar sem perder um baita desempenho depois de algumas horas manipulando arquivos e alternando entre aplicações. No Windows 7, porém, foi diferente. Excelente desempenho. Eu como usuário Linux desde 2004, assumo: está usável, estável e “leve”. Leve entre aspas, pois está consumindo 1GB de ram neste momento. Mas como o notebook possui 4GB, isto não é um problema.

Segurança

Ainda não tive a oportunidade de colocá-lo à prova de fogo, mas só do fato de haver usuários e grupos – sim, existem desde a era NT, mas está BEM evoluída no Windows 7 – já livra uma boa !
Setei meu usuário diário como “usuário padrão” vulgo: limitado e criei uma conta “root” com senha e definida para Administrador e pronto. Tentei instalar programas, acessar áreas do Windows, remover aplicações ou até fazer um auto-update no Opera que ele exibe a caixa de aviso pedindo a senha do usuário “root” para poder continuar. Meu usuário não tem permissão de escrita no diretório C:\Windows, C:\Arquivos de Programas e etc.

Caso levado a risca, isso eliminaria o problema de vírus no núcleo do sistema e eliminaria boa parte das ameaças, uma vez que todos crackers querem colocar um msfoobar.exe dentro de \Windows\System32 =P

Recursos

Windows é Microsoft. Veio o Windows e algumas coisas básicas com o Paciência

Um recurso nice que encontrei foi o sistema de backup melhor desenvolvido pela primeira vez !
Ele detecta unidade de armazenamento removível e prepara todo um backup onde você pode definir os locais ou apenas aceitar os propostos pelo S.O. É possível agendar datas e fazer um backup recorrente.

O Paint foi melhorado. Uma aplicação largada ao vento desde o Windows 2000, foi finalmente melhorada com mais recursos úteis e vísiveis
Em adicional, criaram uma aplicaçãozinha voltada à screenshot. Gostei !

Sistema

O Prefetch funciona maravilhosamente bem. Deixa em memória (e também faz preload) das libraries mais utilizadas, facilitando assim o carregamento da mesma. Para poder aproveitar isto sem deixar a máquina ligada eternamente basta ter memória de gente grande (com 2GB você já poderá perceber a diferença – boa – no desempenho)

O sistema de Update e notificações está mais espertinho. Nada de extraordinário, mas está melhor.

Quanto à drivers para o meu hardware, sem problema algum. Funcionou bem. O som não foi detectado pelo Windows 7, mas com o driver para Windows Vista funcionou perfeitamente. Windows 7 talvez seja o SP2 do Windows Vista =P

Ele faz Ghost do estado do sistema operacional para poder recuperar caso algo de errado. A Microsoft teme que o Windows deixe alguém na mão, logo, já deixa isso ativado por padrão. Eu removi

Compatibilidade: com aplicações de meu uso, perfeito. Inclui: Office 2007; IDE de desenvolvimento em PHP (Zend Studio); Apache, PHP – que inclusive a Microsoft está tentando uma paz na guerra fria =X – PostgreSQL/MySQL, ferramenta de aúdio e vídeo, enfim.. não testei jogos, afinal, nem é minha praia esse tipo de coisa.

Como um usuário Linux há 5 anos, digo que o Windows 7 me surpreendeu muito. A empresa de Redmond finalmente criou algo de macho pra carilha ! É, não chega a tanto.

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 .

Você deve estar se perguntando: aonde você quer chegar ?
Simples: se tudo isso que citei é muito óbvio para você, meus parabéns ! Você deve ser um profissional preocupado com a documentação !

Sim, da mesma forma que você precisou ler para entender como funciona a API de reflexão nativa do PHP, o seu colega de projeto precisará ler a documentação daquele Webservice que você fez para o projeto.
Partindo da minha analogia, seu amigo precisa ter como pré-requisito: saber ler e conhecimentos em PHP para poder implementar x)

Pensamento óbvio o meu, claro, claro que sim ! Mas pensa aí rapidinho: quantos códigos nos últimos tempos você pegou totalmente sem documentação, isso sem falar em outros aspectos, como qualidade interna e blablablá [no bom sentido] que profissionais aptos a escrever grandes softwares fazem [Se essa última palavra não faz sentido para você, recomendo ler este livro para entender o que é um grande software]

Aquela velha estória de que quem manja mesmo lê o código e já era caiu por terra. Para um formmail até que pode ser, mas aplicações modularizadas com um modelo bem definido e aplicado e uma chuva de classes trabalhando neste modelo precisa muito mais do que uma simples leitura de código. O mínimo necessário são os comentários do tipo DocBlock além dos comentários inline e por fim e não menos importante Classes, atributos, comportamentos, variáveis locais e constantes com nomes reais do que fazem, recebem ou são.

Isto é um DocBlock retirado daqui !

Para fechar, eu recomendo fortemente que você caso não conheça, dê uma boa olhada e claro, passe lá e pegue sua cópia gratuitamente dele, o PHPDoc em PHPdoc.org. Não vou me prolongar em explicar o que ele tem ou o que faz. O site está lá completinho.

Veja você mesmo neste exemplo online onde foi gerado o manual do Smarty Template. Ele por si só já diz tudo. Agora é com você

Depois de um longo período de sofrimento com os benditos .svn na hora da publicação ou empacotamento do projeto eu tomei coragem e criei um script em shell para que me auxiliasse a acabar com esse problema.

Sem muito papo, o script é ultra simples: basicamente copia seu projeto para um diretório e dessa cópia ele remove todos .svn que ver pela frente. No final eu tenho o diretório do projeto intacto e a cópia limpinha sem .svn para eu mandar pro cliente, publicar na web e etc.

Fiz um sisteminha interativo com menu de ajuda e um texto explicando como funciona tudo legalzinho, pois, acho que não sou o único a sofrer com esse problema.

Para quem se interessou pelo script, disponibilizo o link para download do mesmo: http://gpl.hlegius.pro.br/linux/svnclean.sh
Baixe, dê permissão de execução e teste rodando o comando:

Se quiser um log, eu criei duas formas: log diretamente na saída do terminal, ou log em arquivo de texto.
Para o log direto, só adicionar -v no final; para o log em arquivo, adicione -vv

Para ajuda, digite:

Para aqueles que programam muito em Shell Script, realmente peço que não considere a qualidade e a quantidade de linhas, pois não uso muito o shell script =X

Fica aí a dica. Espero que ajude alguém