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)

Annotation @author

Desde que comecei a programar no ínicio do segundo semestre de 2004, eu utilizo desse tal de arroba-aútor. Já vi algumas variantes dela, por exemplo:

Annotation @author Augusta edition

Há ainda aqueles que detalham no cabeçalho sua pog contribuição:

Blablabla no annotation (clique para ampliar - ou não)

Sinceramente eu nunca fui pesquisar se há uma convenção na utilização deste annotation. O fato é que meu uso com isto é descomplicado:

• Insiro meu nome em novos arquivos;
• Adiciono meu nome abaixo do último se eu fiz alguma adição ao arquivo, ou;
• Não adiciono quando faço pequenas modificações sem acrescentar algo de valor ao então domínio/objetivo/proposta do arquivo.

Mas mesmo assim, sempre coloco no formato Nome completo <email@provedor>

Porém, não pela primeira vez vejo um developer defendendo o não uso deste annotation. A última vez foi numa discussão – no bom sentido – entre @sergioprado e @lfamorim. Com isto, fui perguntar a eles – e alguns outros mais – a opinião pessoal em relação ao tal annotation. Confira:

Eduardo Guerra – @emguerra

Obviamente se o uso de @author nas classes for uma prática da equipe irei segui-la sem problemas, mas se a escolha for minha opto por não colocar. Esse tipo de marcação no meu ponto de vista atrapalha a propriedade coletiva do código por determinar explicitamente os autores da classe. No caso de erros na classe, sempre haverão dedos apontando o autor como culpado, mesmo se não foi ele quem introduziu o problema.

Como toda documentação não-executável, pode deixar de ser atualizado com a evolução de um projeto e muitas vezes o autor original não é mais quem mais contribuiu para a classe no seu estado atual. Adicionalmente, sou a favor de manter o código o mais limpo possível e esse tipo de coisa acaba deixando o código de todas as classes mais verboso.

Cainan Costa - @sryche via Jabber

[20:03:08] cainan.costa: não faz sentido, porque o VCS já mostra =P
[20:03:16] cainan.costa: quem é o maluco que fez a parada
[20:03:25] cainan.costa: aí tu usa um git blame
[20:03:33] cainan.costa: e já sabe quem encher de porrada

Lucas Fernando Amorim – @lfamorim

Hoje em dia a tag @author é tão obsoleta quanto respeitar um limite de colunas para seu código, mas ainda assim acho elegante e talvez até relevante.

Fica muito mais fácil para aqueles programadores que não usam a IDE XPTO verem o criador de determinado arquivo, método ou função sem ter que recorrer a um programa. É repetitivo você pode alegar, mas eu posso retrucar que a tarefa pode ser automatizada.

Eu aprecio muita essa tag, pois a partir dela posso usando minha humilde IDE identificar o criador de determinados códigos, antecipando os vícios do autor e me adaptando para a leitura. Tudo isso sem abrir a shell e digitar N^C comandos.

N = Familiaridade com o programa X de controle de versão.
C = Commits anteriores.

Christian Benseler - @chrisbenseler

Tenho uma visão que o negócio é “mais embaixo”. Antes de tentar assinar um script como seu, o desenvolvedor tem que se preocupar com outros assuntos mais importantes: é um projeto pessoal ou colaborativo? Está prestando serviços a alguém, outra empresa? Qual a política do seu cliente? Qual a versão do script? E qual o tipo de licensa que será adotada?
Só assinar o script não vai fazer a menor diferença se não tiver essas informações. E não vai fazer nenhuma diferença se a comunidade não parar de copiar o script feito por A, retirar os author notes do script e redistribuir o script sem dar esses créditos e/ou sem levar em conta o tipo de licensa adotado.

Carlos Duarte do Nascimento – @chesterbr

Antes de mais nada, você se refere a qual linguagem? Em Java, @author pode significar tanto uma anotação em si (e aí depende do contexto), tal como:

@author(“chester”)
public foo(int bar) {
…

quanto (o que eu imagino que você queira dizer) a anotação feita em um doclet, i.e.:

/**
 * Um elemento coberto por JavaDoc.
 * @author chester
 */
public foo(int bar) {
...

No segundo caso, eu gosto de @author devido à facilidade em lidar com a autoria coletiva: ela permite anotar classes inteiras ou métodos/atributos particulares; você pode colocar múltiplos autores, e
o Eclipse pode ser facilmente configurado para adicioná-la automaticamente. No PHP, se me recordo, é possível usar algo
equivalente (phpdoc) em cabeçalhos de código, mas não sei se é válido colocar em métodos/atributos, ou se é possível ter múltiplas declarações no mesmo escopo.

Em qualquer caso, vale notar que sistemas de controle de versão como svn e git são mais eficientes para descobrir quem efetivamente contribuiu com uma classe/método do que esse tipo de tag. Além disso, elas não são suficientes para notas de copyright (ou seja, teriam que ser replicadas apropriadamente para o correto licenciamento do código, independente da licença utlizada), o que limita de fato sua utilidade prática.

Sérgio Prado – @sergioprado

Há muito tempo atrás, as ferramentas disponíveis aos programadores eram escassas e limitadas.

<oldschool>Já programei em Assembly com um DOS rodando num x86 e monitor CGA de 80 colunas x 25 linhas </oldschool>

Nesta época, ferramentas de controle de versão não eram tão comuns, nem monitores de 21 polegadas. Foi então que surgiram alguns paradigmas. Eram consideradas boas práticas de programação usar no máximo 80 colunas por linha de código (limitação causada pelos monitores da época), e incluir informações no cabeçalho do arquivo como @version, @author, @date, @changes etc.

O problema é que para muitas pessoas estes paradigmas perduram até hoje, por herança, por gosto (ou mazoquismo mesmo). Qualquer ferramenta decente de controle de versão pode te trazer, desde sua criação, todo o histórico de alteração de um arquivo. Além de ser mais seguro e confiável. Se eu usar no código-fonte “@author pica-pau”, grande parte das pessoas não irá perceber, porque ninguem lê o cabeçalho do arquivo. Também não existe garantia de que o nome documentado no código-fonte é realmente o do desenvolvedor. Já com uma ferramenta de controle de versão esta garantia existe.

Eu mesmo usava @author nos cabeçalhos uns tempos atrás, mas parei de usar depois que comecei a criticar alguns paradigmas que tinha. É tudo questão de delegar para ferramentas o que pode ser automatizado e buscar novas soluções para os mesmos problemas.

Fábio Miranda – @fabiolnm

Não uso por pura falta de hábito – nunca trabalhei em um projeto onde essa prática fosse adotada.
Mas acho interessante, não só o autor, como o email / github tb.

Pode ocorrer de ser necessário dar manutenção em determinado código cuja compreensão não seja trivial, e a possibilidade de contactar o autor, mesmo que remota, deve ser considerada e viabilizada.
Não vejo razão para ser contra.

E pra finalizar, os comentários fundamentados de Hanneli Carolina Tavante @hannelita – sobre o uso de @author e muito mais:

Bom, vou dar minha opinião sobre comentários no código antes de qualquer coisa…. Também utilizarei algumas metáforas e exemplos reais.

Eu já trabalhei com códigos de sistemas legados – Mainframes e sistemas bem antigos – , envolvendo C e Assembly. Vou contar uma coisa – quando abríamos um código e víamos infinitas linhas de comentário, já sabíamos que vinha coisa ruim pela frente. Tudo bem para aquele tipo de código sempre achei necessário comentar – Há algumas subrotinas do inferno que precisam de explicação. E o cara que fez isso tem idade pra ser meu pai, já faleceu ou se aposentou. Portanto, códigos assim são “legíveis” graças aos comentários deixados para trás. Já peguei código em Assembly sem comentários. E fiquei quase 10 dias só pra entender por cima o que o programa fazia.

Mas atualmente estamos em uma época onde encontramos linguagens extremamente expressivas, como Ruby e Python. E pra ajudar ainda tem uns framewroks tipo Sinatra, incorporando DSLs. Ou seja, hoje é possível escrever códigos que HUMANOS são capazes de ler. (humanos comuns, quis dizer hehehe). Se você escreve códigos em Ruby que humanos não entendem, então sinto muito, meu amigo, vá ler o Clean Code ou aprender a programar de forma limpa. Aliás, práticas de TDD ou BDD, por exemplo, influenciam e praticamente geram um código limpo e legível dadas as etapas que sugerem na construção da aplicação. Por exemplo, o famoso “Vermelho, verde, refatorar” do TDD – O refatorar ocasiona um cógido extremamente mais compreensivo. Construído tal código sólido e bem estruturado, eu questiono – comentários para que? Eles perdem o sentido. Por exemplo, você se depara com a seguinte expressão em Ruby:

 unless valor == 0
  puts "Valor diferente de zero!"
 end

Bem expressivo, certo? Pra que um comentário então? Uma das coisas que me irrita um pouco é encontrar códigos assim:

public class Pessoa {
  private String nome; //define o nome da pessoa
  private int idade; // define idade da pessoa
}

Ou pior, bem pior que isso:

public class Pessoa {
  private String a; //define o nome da pessoa
}

Ambos os casos eu considero inapropriados. O primeiro por gerer redundância – é ÓBVIO que o atributo “nome” faz menção ao nome da entidade pessoa! O segundo exemplo nos remete a alguém que não fez uso de bom senso de orientaćão a objetos para definir o nome do atributo. O comentário era necessário porque não houve refatoração e uso de um nom esclarecedor ao campo. De qualquer forma, isso é incorreto no meu ponto de vista.

Então quando usar comentários? Costumo usar comentários quando, por exemplo, utilizei algum recurso pouco conhecido da linguagem. Por exemplo, o uso de Fibers no Ruby – poucas pessoas sabem o que são Fibers; coloquei um comentário no meu código extremamente sucinto explicando o que era e onde achar mais informações. Ou se você utilizar alguma magia-negra no código, embebida por metaprogramação, por exemplo, acho que é bom deixar um comentário sucinto do que aquilo quis dizer. Esse tipo de comentário ajuda programadores juniors a adquirir experiência e ajuda até memso os seniors a captar a idéia geral de um método/bloco que possui lógica complexa.
E há alguns casos que comentários podem ajudar a leitura do código fluir e ficar mais agradável. Pra Java, por exemplo, existe uma API – GAG => http://code.google.com/p/gag/ – Google Annotations Gallery, da qual já fui colaboradora. Essas anotações dão emoćão ao código; de vez em quando acho interessante utilziar algumas delas; tornam o coódigo mais expressivo. Novamente, acho que se deve usar sem abusos =)

Sobre o uso do @author – Aí já acho que é uma cosia meio pessoal. Eu não coloco. Saber que sou colaboradora/commiter do projeto já está bom pra mim. A ligaćão entre eu e o código fonte vai muito mais além que um @author. Claro, tem o lado bom de se colocar; todos que tiverem o fonte saberão o responsável por aquela ciração, e poderão parabenizá-lo, encontrá-lo no Twitter ou no Facebook e coisas do gênero. Ou poderão xingar sua mãe com vontade. Mas acredito que há outras formas de se descobrir e pedir ajuda sobre algum fonte que não são através do @author.

Bom, essa é minha visão geral da coisa! =D

E aí, é contra ou a favor do @author ?

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.