Usando o XDebug no Eclipse Indigo para debugar PHP

Pesquisei pra caramba e no final tinha pouco para fazer. Mas para os que ainda estão procurando abaixo eu descrevo passo a passo o que fiz para conseguir debugar codigo PHP dentro do Eclipse. Como existem outros (antigos) eu não vou mensioná-los. Vou ser especifico. Então, para começar... minhas informações:

O que estou usando como editor:

   Eclipse IDE for JavaScript Web Developers.
   Version: Indigo Release
   Build id: 20110615-0604
Para baixar esta versão clique aqui.

O que estou usando como servidor web:
   WampServer 2.1
       Apache Version:     2.2.17
       PHP Version:         5.3.5
       MySQL Version:   5.5.8


Se quiser baixar a ultima versão clique  aqui.


Como sistema operacional estou usando:
Windows xp sp3 (eu sei, desculpa)


Então.. Mãos a obra.


1º Tenha o Editor Eclipse. (Pode baixar se não tiver, o link está ai em cima)


2º Instale o PDT (PHP Developer Tool)
     OK. Não vou dizer para ninguem que vc não sabe como fazer. Então faz rapidinho para ninguém notar.
     Clica em "Help->install new Software ..." (Help é o menu lá em cima viu... o ultimo. Quando tu clicar nele é que       vai aparecer o "install new Software"). 
     Onde tem escrito "Work with" tu tens que adicionar os endereços abaixo (ou seja, copia e cola os endereços -- Um de cada vez -- naquele campo e depois clica no botão "add"):
http://download.eclipse.org/releases/indigo

http://download.eclipse.org/tools/pdt/updates/3.0/milestones/ 

ATENÇÃO: pode demorar um pouquinho para adicionar (tipo uns 5 min) então ESPERE.

Depois, clique APENAS na caixinha onde diz "PDT Development Tools All in One SDK", e então clique no botão "next".

PRONTO. ACABADO O PASSO 2.

3º Tenha o WampServer. (Pode Baixar e instalar. é do tipo next, next, next, finish)

4º Use a ajuda do Xdebug para saber qual dll precisa instalar.

    O link é esse. Se não souber ingles ai vai uma ajudinha. 

    Tem um quadrado branco naquela pagina e o que ele espera é que você cole o texto que esta na pagina phpinfo(). Tudo bem... você também não sabe onde é que esta essa pagina? então abra o seu navegador e escreva "localhost"  e aperte "enter". Provavelmente, se o seu wamp estiver rodando, o que vai aparecer é uma pagina do servidor e abaixo do texto "tools" vai ter um link "phpinfo()" clique em cima. vai abrir as informações necessárias do php.ini. Aperte "ctrl+A" para selecionar a pagina inteira e depois "ctrl+C" para copiar a pagina. Volte a pagina de download do link no inicio do passo 4, aquele que tem o quadrado branco) e cole naquele quadrado apertando "ctrl+V". La em baixo tem um botão que deve ser clicado para que a pagina de ajuda possa ser gerada.


Se vc já apertou o botão "Analyze My PhpInfo() output" deve estar vendo uma pagina com instruções de como instalar o XDebug. O Primeiro passo é baixar a "dll" indicada. O segundo passo é mover essa dll de onde vc baixou para o local indicado (para facilitar esse passo, copie o texto dele começando em "C:/" até o final. depois aperte Windows+R - isso vai abrir a caixa de Executar - então cole o que você copiou) .Lembre de trazer o arquivo que vc baixo para esta pasta. O terceiro passo é modificar a linha indicada com o texto indicado. (para facilitar, ao clicar com o mouse em cima do icone do wamp - perto do relogio - um menu vai se abrir. Clique em php e depois em php.ini. O texto que vc procura está perto do final.). O ultimo passo é reiniciar o servidor.


5º Na verdade.. ainda falta configurar.
    Encontre no Php.ini a sessão referente ao XDebug (provavelmente lah no final) cole esta instrução:

xdebug.default_enable = on

Isso vai fazer com que o xdebug fique ativo.

outras configurações seriam interessantes como:

xdebug.show_local_vars = 1

xdebug.auto_trace = 1 

xdebug.collect_return = 1 

xdebug.trace_output_dir = c:/tmp 

xdebug.trace_output_name = trace.%H

xdebug.profiler_enable = 1 

xdebug.profiler_output_dir = c:/tmp 

xdebug.profiler_output_name = cachegrind.out.%H%R

xdebug.remote_enable=On 

xdebug.remote_host=localhost 

xdebug.remote_port=9000 

xdebug.remote_handler="dbgp"

implicit_flush = On

Bem .. para dar o devido crédito, essa parte, eu peguei a maior parte no site do Aaron Saray 


Não esquece do Eclise:
A configuração que deve ser feita lah é assim:
No menu clique em "window->preference": Na tela que vai abrir procure por PHP->debug e adicione o xdebug na porta 9000.

Agora, clique em "Run->Debug Configurations", selecione X-Debug em server e desmarque a caixa de seleção onde tem escrito "Auto Generate".

Uma ultima coisa: Escolha um browser externo em "Window > Preference > General > Web Browser"

6º Saber se fez certo.
    Lembra daquela pagina em localhost? onde vc pode clicar em phpinfo()? pronto, essa mesma. Provavelmente vc vai ver algo do tipo...

Note que abaixo tem as informações referentes ao XDebug. Parabens. Agora é ir no IDE Eclipse, criar um projeto, colocar um break point em algum ponto do codigo php e apertar no botão onde tem um insetozinho (bug).
Me diga se gostou do que escrevi esta bem. Deixe comentário Para eu melhorar ou me sentir o cara se te ajudei.

KanBan Vs. Scrum

 Primeiro de tudo Scrum é um acrônimo para a frase: "Software Codificado Rapidamente é Uma Merda". Se você acreditou na primeira sentença eu peço encarecidamente que leia atentamente o resto deste post.

O Scrum e o Kanban referem-se a ferramentas, isso mesmo, ferramentas utilizadas em processos de desenvolvimento ágeis. O primeiro vem de uma analogia a uma jogada de Rugby onde todos os jogadores disputam a posição de reposição da bola (bola oval, esquisita). A jogada deve ser feita em equipe e se um dos membros da equipe falha, então todos falham. A analogia casa perfeitamente com o conceito por traz da utilização desta ferramenta (ou seja, SCRUM NÃO É UM ACRÔNIMO). O segundo, Kanban, refere-se a representação visual (que é a tradução literal do termo) do fluxo de trabalho de forma que as equipes envolvidas percebam rapidamente informações que lhe sejam uteis para o não "empacamento" do produto.

Como qualquer ferramenta, existe a forma certa para usá-la. De outra forma os benefícios mudam (mesmo que para melhor). Muitos desenvolvedores descobriram que ao usar as duas ferramentas juntas podem trazer grande beneficio ao processo de desenvolvimento ágil. Os dois possuem foco na entrega do produto de forma rápida e com qualidade assim como a contínua otimização empírica do próprio processo de desenvolvimento. Parece até contraditório dizer que não todas as prescrições das duas ferramentas devem ser observadas e ao mesmo tempo que se pode adaptar o seu uso de acordo com o projeto e a equipe. Mas a contradição fica desfeita ao usarmos como metáfora a mesma que Kent Beck utiliza em seu livro sobre Extreme Programming, aquela sobre aprender a dirigir. Ao dirigir um carro, esperamos ter quatro rodas, um acelerador, algum mecanismo de mudança de marcha, acelerador, freio... (leve em consideração os carros atuais comuns. Já existem carros sem marcha aparente e sem direção). Esta é a ferramenta, caso falte esses itens básicos, provavelmente não é um carro. Agora, a forma e o motivo para se usar um carro são diversos. Posso usar o mesmo para carregar mercadorias usando a mala, ou levar a namorada para o cinema (o que requer um carro legal para impressionar), ou mesmo utilizar mais a velocidade para ganhar uma corrida de formula 1.

Scrum possui mais regras que o Kanban, ou em termos padronizados... :-/, é mais prescritivo. As regras são: Possuir os papeis de Product Owner(PO), Scrum Master(SM), e Team; O product backlog deve ser priorizado; O produto deve ser dividido em tarefas menores de forma que possa ser entregue ao final de cada iteração (sprint) uma funcionalidade solicitada pelo Product Owner, isto também impede que qualquer funcionalidade seja adicionada a uma iteração já iniciada. Quando o PO solicita uma nova funcionalidade deverá esperar o inicio do proximo sprint para fazê-lo; Um quadro para cada projeto; Limitação do WIP (Work In Progress) por meio de tempo fixo, ou seja, se o sprint (nome dado a uma iteração) for de 1 mês, então todas as iterações serão de um mês; Equipes Multifuncionais e auto-organizáveis; Gráfico burndown, que é um gráfico de medição de velocidade para mostrar quanto trabalho é realizado por iteração e que permite estimar a data de entrega de um produto ou funcionalidade. Esses são os requisitos (se o leitor souber de outro, me avisa para não ficar feio) para usar Scrum de forma apropriada. se tiver menos do que isso então é melhor não dizer que esta usando Scrum, e sim algum outro termo como o indicado por Henrick, "Scrumish".

O Kanban por sua vez, não possui tantas prescrições. Na verdade, suas prescrições são apenas a de deixar o fluxo de trabalho em um quadro visivel (isso proporciona transparência ao processo), e a delimitar o numero de tarefas para os estados do fluxo que são criticos. Bem menor o parágrafo não é mesmo? A principal vantagem no uso desta é a de que o limite de trabalho proporcionam um tempo de resposta mais rápido quando ocorrem erros ou gargalos.

A semelhança entre essas duas ferramentas são realmente muitas. São Lean e Agile, permitem trabalhar em vários projetos simultâneos (embora o Scrum utilize um quadro diferente para cada equipe), usam controle de cronograma além de adaptarem-se facilmente a equipes pequenas. Para verificar o quanto essas ferramentas podem ajudar no processo de desenvolvimento do leitor então o mesmo deve testar enquadrar-se com as prescrições das ferramentas e determinar qual usar mais fortemente, quais adaptações usará e mesmo qual o beneficio que tal teste proporcionou ao processo.