Desenvolvimento ágil com XP (Extreme Programming)

Amigos e amigas hoje vou falar um pouco sobre mais uma metodologia ágil de desenvolvimento (a mais conhecida) XP.
XP nesse caso não é aquele sistema operacional da microsoft ok? Mas sim as siglas de EXTREME PROGRAMMING traduzindo Programação extrema

Talvez você esteja se perguntando; "Será que para desenvolver uma aplicação de maneira rápida eu vou precisar de um capacete e uma luva?" 

A resposta é não, mas se você quiser utilizar, eu acredito que os acessórios pouco importa com tanto que vc esteja preparado para a agilidade do XP rsrs...

Pv... me explica por favor oq é esse XP? XP significa Programação extrema (do inglês eXtreme Programming), ele é uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança, ou seja a melhor escolha para o mundo hoje em dia não acham? Na maioria dos casos os requisitos sempre são alterados e assim não é possível trabalhar sempre em cima de uma base de análise pois o que foi planejado ontem pode ser alterado, hoje em dia desenvolvimento de sistemas não é como antigamente em que um software era engessado.

Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software.

Breve histórico
Nascida nos Estados Unidos ao final da década de 90 por Kent Beck. Vem fazendo sucesso em diversos países, por ajudar a criar sistemas de melhor qualidade, que são produzidos em menos tempo e de forma mais econômica que o habitual. Tais objetivos são alcançados através de um pequeno conjunto de valores, princípios e práticas, que diferem substancialmente da forma tradicional de se desenvolver software.

O XP assim como outras metodologias faz parte do Manifesto ágil um manifesto iniciado nos Estados Unidos em que se prega novos e interessantes valores para o desenvolvimento de software como por exemplo:

• Indivíduos e interação entre eles mais que processos e ferramentas;
• Software em funcionamento mais que documentação abrangente;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.

Perceba que o manifesto ágil busca uma outra visão no desenvolvimento de software, busca a criação de um projeto de forma ágil e o que é muito importante falar atendendo expectativas.

TA MAS COMO UTILIZAR O XP?

'Utilizar' o XP no desenvolvimento de um projeto é mais fácil e simples do que parece basta entender seus valores e princípios e assim aplica-los no desenvolvimento.

Princípios básicos
Para o desenvolvimento ágil, é necessário entender que essa metodologia se baseia em principios básicos que são:

• Feedback rápido
• Presumir simplicidade
• Mudanças incrementais
• Abraçar mudanças
• Trabalho de alta qualidade

Ou seja é necessário feedback rápido da situação do desenvolvimento, módulos e funcionalidades tanto para o cliente como para a equipe. Programar, desenvolver e resolver problemas  complexos é uma tarefa perigosa pois para um problema pode ser encontrado diversas soluções mas qual é a melhor? A melhor é a mais simples, aquela clara e explicita por isso presumir simplicidade. Mudanças acontecem normalmente e devem ser encaradas e analisadas por isso Mudanças incrementais, as mudanças são bem vindas e é necessário abraça-las mas com um bom planejamentos por isso Abraçar mudanças e por ultimo desenvolver algo deve ser levado a sério, deve-se buscar a máxima excelência e qualidade no trabalho.

Valores
Os cinco valores fundamentais da metodologia XP são: comunicação, simplicidade, feedback, coragem e respeito.
Dentre as variáveis de controle em projetos (custo, tempo, qualidade e escopo), existe uma atenção principal no escopo. 

Por isso, recomenda-se priorizar funcionalidades que representam maior valor possível para o negócio, ou seja trabalhar na regra de negócio principal do software. E assim se for necessário a diminuição de escopo, as funcionalidades menos valiosas serão adiadas ou canceladas.

Práticas
Para aplicar esses valores e princípios no desenvolvimento, o XP propõe uma série de práticas. Há uma confiança muito grande na sinergia entre elas, os pontos fracos de cada uma são superados pelos pontos fortes de outras.

Jogo de Planejamento (Planning Game):

O desenvolvimento é feito em ciclos semanais. No início da semana, desenvolvedores e cliente reúnem-se para priorizar as funcionalidades. O nome dessa reunião é Jogo do Planejamento. Nela, o cliente identifica prioridades e os desenvolvedores dão um prazo provavel. A principal peça desse 'jogo' é o cliente pois ele define funcionalidades, fica sabendo o que está acontecendo e o que vai acontecer no projeto. Como o escopo é reavaliado semanalmente, o projeto é regido por um contrato de escopo negociável, que difere significativamente das formas tradicionais de contratação de projetos de software. Ao final de cada semana, o cliente recebe novas funcionalidades, completamente testadas e prontas para serem postas em produção.

Pequenas Versões (Small Releases): Liberar versões funcionais auxilia muito na aceitação por parte do cliente, que já pode testar uma parte do sistema que está comprando.

Metáfora (Metaphor): Busca facilitar o entendimento na comunicação com o cliente, por exemplo um processo de 2 semanas para um advogado é algo rápido, enquanto que gerar boletos em 2 semanas é algo extramamente lento para um banqueiro, e ambos são lentos para um select que um programador espera o retorno. Sendo assim o intuito dessa prática é entender o que algo significa para o cliente.

Projeto Simples (Simple Design): Simplicidade é um príncipio da XP, ou seja fazer conforme a necessidade manda, buscando clareza e padronização. Desenvolver simples significa pensar claro, alcançar objetivos e otimizar sempre a realização. Por exemplo se você pretende reutilizar uma classe Pessoa com um método Programar pense bem e veja se não é melhor criar uma classe Programador que extenda da Pessoa e assim colocar esse método pois um programador é uma pessoa mas só ele programa, uma pessoa é uma pessoa e nem sempre ela programa. Atingir o objetivo simples e desenvolver com lógica faz parte desse princípio.

Testes de Aceitação (Customer Tests): São testes construídos pelo cliente e conjunto de analistas e testadores, para aceitar um determinado requisito do sistema.

Ritmo Sustentável (Sustainable Pace): Trabalhar com qualidade, buscando ter ritmo de trabalho saudável (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras são permitidas quando trouxerem produtividade para a execução do projeto. Outra prática que se verifica neste processo é a prática de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o ambiente de trabalho e a motivação da equipe devem estar sempre em harmonia.

Reuniões em pé (Stand-up Meeting): Reuniões em pé para não se perder o foco nos assuntos, produzindo reuniões rápidas, apenas abordando tarefas realizadas e tarefas a realizar pela equipe.

Programação em Pares (Pair Programming): é a programação em dupla ou seja, duas pessoas em um computador, normalmente um é o 'piloto' e o outro o 'co-piloto' os dois desenvolvem juntos sendo que um fica codificando e o outro analisando e falando, assim é a atenção de duas pessoas em um desenvolvimento garantindo muitas vezes boa qualidade, e ganho de tempo pois os dois estão focados em um objetivo, assim um puxa o outro.

Padrões de Codificação (Coding Standards): A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. Desta forma parecerá que todo o código fonte foi editado pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros.

Desenvolvimento Orientado a Testes (Test Driven Development): Conhecido como TDD onde primeiro se cria os testes unitários (unit tests) e depois cria-se o código para que os testes funcionem. Esta abordagem é complexa no início, pois vai contra o processo de desenvolvimento de muitos anos. Só que os testes unitários são essenciais para que a qualidade do projeto seja mantida.

Refatoração (Refactoring): É um processo que permite a melhoria continua da programação, com o mínimo de introdução de erros e mantendo a compatibilidade com o código já existente. Refabricar melhora a clareza (leitura) do código, divide-o em módulos mais coesos e de maior reaproveitamento, evitando a duplicação de código-fonte;

Integração Contínua (Continuous Integration): Sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema. Isto só aumenta a possibilidade de conflitos e a possibilidade de erros no código fonte. Integrar de forma contínua permite saber o status real da programação.

Conclusão
A XP é uma metodologia que é um reflexo do mundo hoje em dia, padronizar, agilizar, melhor e atender são objetivos que as práticas e valores do manifesto ágil busca atingir e a metodologia mais estável e renomada para isso é a XP.

Referências

Agile Software Development, Principles, Patterns, and Practices (ISBN 0135974445)

Extreme Programming Explained: Embrace Change (2nd Edition) (ISBN 0321278658)

UFA! Essa é a base do XP. Obrigado pela atenção e até a próxima!

Expressões regulares de forma simples

Boa tarde amigos e amigas tudo bem? Hoje vou mudar um pouco o assunto, vou falar de expressões regulares!

EXPRESSÕES REGULARES

Ta mas oq são as expressão regulares? Pq e onde são uteis? Vou realmente usar essa trollagem?

Vamos as respostas uma a uma. Expressão regular é um meio preciso de se fazer busca em determinadas posições de uma string (texto) podendo assim criar diversar funcionalidades como validar uma entrada de dado, verificar se um arquivo é de uma extensão e tantas outras funcionalidades.

Ou mais ‘técnicamente falando’ uma expressão regular, define um padrão a ser usado para procurar ou substituir palavras ou grupos de palavras. É um meio preciso de se fazer buscas de determinadas porções de texto.

Por exemplo, se o conjunto de palavras for {asa, carro, jardim, ovos, terra} e a expressão regular buscar por um padrão rr, obterá as palavras carro e terra.

Existem diferentes formatos para definir-se expressões regulares, porém com algumas noções gerais é possível entender boa parte das expressões.

Como desenvolvedor você sempre vai precisar de uma expressão regular, seja para validar uma entrada de dado, seja para ler um arquivo ou ainda montar uma URL... ou seja saber expressão regular esta para o desenvolvimento assim como chutar esta para o futebol, portanto expressão regular É importante, mas como entender essas coisas de forma simples? O objetivo dessa série de posts é esse...

Vamos voltar no tempo em que jogavamos Alex Kidd no Master System se lembra? Pois é algumas vezes vc olhava para a fase em que estava e pensava de inicio que era muito dificil...

Mas com alguns segundos analisando bem vc percebia que nem era tão dificil assim, era só raciocinar um pouco...

Pois é meu amigo se vc já fez isso talvez foi ai que você aprendeu que seria um programador. As expressões regulares são iguais esse jogo sabe pq? Presta atenção nisso aqui:

^[a-z]{4,20}$

Aparentemente isso é o lobo mal mas não é a verdade veja bem;
o operador ^ (chapéuzinho rsrs) obriga iniciar com algo que vem adiante dele que nesse caso é [a-z] a regra fica dentro dos colchetes ou seja nesse caso ele aceita apenas letras de a até o z que são minusculas, adiante é definido a chave com o número 4 e o 20 {4,20} e isso significa que para o conteúdo obrigatório a quantidade de caracteres deve ser de no mínimo 4 e no máximo 20 e por fim um $ que define que o valor deve terminar com essa regra também olha que simples não é?

Baseado nessa dica veja 8 expressões regulares para o PHP consideradas uteis pelo site Devolio

Validar nome de usuário

Essa regra é para permitir usuários com nome de 4 a 28 caracteres, alfanuméricos e acentuados:

$string = "userNaME4234432_";
if (preg_match('/^[a-z\d_]{4,28}$/i', $string)) {
    echo "example 1 successful.";
}

Números telefônicos

Essa regra é para validar números de telefone, e os números devem ser escritos da seguinte maneira (###)###-####:

$string = "(032)555-5555";
if (preg_match('/^(\(?[2-9]{1}[0-9]{2}\)?|[0-9]{3,3}[-. ]?)[ ][0-9]{3,3}[-. ]?[0-9]{4,4}$/', $string)) {
echo "example 2 successful.";
}

Endereços de e-mail

A regra para validar e-mails é a seguinte:

$string = "first.last@domain.co.uk";
if (preg_match(
'/^[^0-9][a-zA-Z0-9_]+([.][a-zA-Z0-9_]+)*[@][a-zA-Z0-9_]+([.][a-zA-Z0-9_]+)*[.][a-zA-Z]{2,4}$/',
$string)) {
echo "example 3 successful.";
}

Códigos Postais

Permie utilizar números no seguinte formato: xxxxx e xxxxx-xxxx

$string = "55324-4324";
if (preg_match('/^[0-9]{5,5}([- ]?[0-9]{4,4})?$/', $string)) {
echo "example 4 successful.";
}

Endereços IP

Não é necessário efetuar PING ou qualquer coisa do tipo, essa regra é válida para verificar se os IPs foram escritos corretamente, como esse exemplo 255.255.255.0:

$string = "255.255.255.0";
if (preg_match(
'^(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]\d|\d)(?:[.](?:25[0-5]|2[0-4]\d|1\d\d|[1-9]\d|\d)){3}$',
$string)) {
echo "example 5 successful.";
}

Cores Hexadecimais

Você também pode verificar valores hexadecimais em suas 2 formas, a normal e a abreviada: (#333, 333, #333333 o 333333) com o símbolo # opcional

$string = "#666666";
if (preg_match('/^#(?:(?:[a-f\d]{3}){1,2})$/i', $string)) {
echo "example 6 successful.";
}

Buscar comentários multi-linha

Uma forma simples de buscar e eliminar comentários multi-linha em PHP, CSS e outras linguagens:

$string = "/* commmmment */";
if (preg_match('/^[(/*)+.+(*/)]$/', $string)) {
echo "example 7 successful.";
}

Datas

Um formato de data típico MM/DD/YYYY e sua validação é a seguinte:

$string = "10/15/2007";
if (preg_match('/^\d{1,2}\/\d{1,2}\/\d{4}$/', $string)) {
echo "example 8 successful.";
}

Bem amigos, se você tem mais interesse em ER recomendo o livro de Aurélio Marinho que aborda Expressões regulares de forma divertida.

http://www.novatec.com.br/livros/expressoesregulares/

Valeu

HTML5 Palestra ETEC São Vicente

Boa noite gente tudo bem? No dia 14/10/2011 eu ministrei uma palestra sobre HTML5 na ETEC de São Vicente - SP e como prometi para os alunos estou disponibilizando aqui os slides

HTML 5

E ainda para download aqui 

Obrigado e até a próxima!

Integrando o Doctrine com o Zend Framework

O Doctrine é uma ferramenta de mapeamento objeto-relacional (ORM) para PHP 5.2.3+. Um de seus principais recursos é a opção de escrever consultas de bancos de dados em um dialeto SQL proprietário orientado a objetos chamado Doctrine Query Language (DQL), que foi inspirado na Hibernate Query Language (HQL) do framework Hibernate para Java. Isso fornece aos desenvolvedores uma alternativa poderosa ao SQL, que mantém a flexibilidade sem duplicações desnecessárias de código.

Os Models gerados pelo Doctrine estendem da classe Doctrine Record, onde todos eles herdam métodos típicos de um Active Record, como os métodos save, delete, etc, além de permitir que o Doctrine participe e monitore o ciclo de vida dos registros. Outros componentes do Doctrine fazem os trabalhos mais pesados, como por exemplo a classe Doctrine_Table. Essa classe possui os métodos típicos de um Data Mapper, como, por exemplo, createQuery, find, findAll, findBy* etc.

No Doctrine, as consultas são baseadas em classes ao invés de tabelas, para demonstrar um exemplo, considere a seguinte consulta:

FROM Usuario
LEFT JOIN u.Enderecos WHERE u.id = 1

Com ela pode-se notar o seguinte:

• É feita uma seleção do Model Usuario, e não da tabela;
• É possível referenciar os campos do Model;
• São feitos joins com associações;
• Não existe condição de join, as associações entre as classes e como elas estão no banco de dados são conhecidas pelo Doctrine.

Essas informações foram traduzidas do Manual Oficial do Doctrine, com algumas modificações para clarear o entendimento.

Definição do Projeto com o Zend Framework

Agora que já foi feita uma breve explicação sobre o Doctrine, é hora de gerar um projeto de exemplo com o Zend Framework. O projeto criado será bem simples, apenas para exemplificar algumas operações com o Doctrine. Neste ponto, presumo que você, leitor, tenha o Zend Framework e sua ferramenta de linha de comando configurados em seu sistema operacional. Caso não tenha feito isso, recomendo o tutorial do Adler Medrado, onde ele ensina como fazer essas configurações.

O primeiro passo é criar a estrutura do projeto com o comando:

zf create project zf_doctrine

Caso nenhum erro ocorra, esse comando gerará a seguinte estrutura:

Estrutura básica de um projeto Zend Framework

A pasta application será onde o código específico da aplicação será armazenado. Esse código inclui as configurações da aplicação para ambiente de desenvolvimento, produção ou demais ambientes configurados; os Controllers responsáveis por intermediar o fluxo entre as Views, que cuidam da apresentação ao usuário, e os Models responsáveis pela lógica de negócio da aplicação.

A pasta docs é utilizada para armazenar as documentações da aplicação e dos componentes. library é onde ficam armazenados os plugins, componentes e demais bibliotecas de terceiros. Ela é utilizada para armazenar o Doctrine e toda estrutura de classes do Zend Framework. A pasta public é a pasta acessível pelo servidor web, onde é feita toda a chamada para inicializar a aplicação, seguindo o padrão Front Controller. E a pasta testes é onde são armazenados os testes unitários.

Integração

A primeira coisa a se fazer é o download do framework Doctrine. Na data em que este artigo foi escrito, a última versão estável era a 1.2.1. Você pode baixá-la neste link. Após ter efetuado o download e extraído o pacote, é necessário copiar todo o conteúdo da pasta lib para a pasta library do projeto Zend Framework criado, resultando na seguinte estrutura:

Estrutura com o Doctrine extraído

Após isso, é necessário criar a pasta db e dentro dela as seguintes pastas:

• fixtures - Pasta que armazenará arquivos de definição de dados para popular o banco de dados;
• migrations - Arquivos de migração entre diferentes versões de banco de dados;
• schema - Definição de toda estrutura do banco de dados, seguindo o formato YAML;
• sql - Armazena a estrutura SQL que define o banco de dados.

Depois de criar essas pastas, também pode ser criada a pasta para armazenar os scripts de linha de comando do Doctrine. Dentro de application é criada uma pasta com o nome de scripts. Após criar todas essas pastas, a estrutura será a seguinte:

Estrutura final de diretórios

Após toda a estrutura estar definida, é hora de começar a configurar o projeto. A primeira coisa a se fazer é abrir o arquivo application/configs/application.ini e acrescentar o seguinte conteúdo nele, na seção [production]:

autoloaderNamespaces[] = "Doctrine"
doctrine.dsn = "mysql://usuario:senha@host/banco"
doctrine.models_path = APPLICATION_PATH "/models"
doctrine.data_fixtures_path = APPLICATION_PATH "/../db/fixtures"
doctrine.migrations_path = APPLICATION_PATH "/../db/migrations"
doctrine.sql_path = APPLICATION_PATH "/../db/sql"
doctrine.yaml_schema_path = APPLICATION_PATH "/../db/schema"
; Conservative Model Loading
doctrine.model_autoloading = 2

Nessas linhas é definido o Namespace utilizado pelo Doctrine para o autoLoader carregar as classes automaticamente. Logo em seguida, é definido um Nome de Fonte de Dados (Data Source Name - DSN) para a localização do banco de dados. Depois são definidas as pastas onde são armazenados os models, as fixtures, a sql, e o schema, e, por último, é definida a forma como o Doctrine carregará os Models. Neste caso, é utilizado o Conservative, que carrega os Models conforme eles sejam necessários.

Logo abaixo da linha doctrine.model_autoloading, é necessário definir algumas configurações para a ferramenta de linha de comando do Doctrine (Doctrine Cli), basta colocar o seguinte conteúdo:

[doctrineCLI : production]
doctrine.generate_models_options.pearStyle = true
doctrine.generate_models_options.generateTableClasses = false
doctrine.generate_models_options.generateBaseClasses = true
doctrine.generate_models_options.baseClassPrefix = "Base_"
doctrine.generate_models_options.baseClassesDirectory =
doctrine.generate_models_options.classPrefixFiles = false
doctrine.generate_models_options.classPrefix = "Model_"
; Agressive Model Loading
doctrine.model_autoloading = 1

Nesse ambiente é necessário configurar as formas como os Models serão gerados. A primeira linha configura a nomenclatura no formato PEAR, onde o nome da classe contém como prefixos a estrutura de diretório onde ela está localizada, por exemplo, Model_Produto, estará na pasta model/Produto.php, no caso da nomenclatura do Zend Framework, a pasta models terá como prefixo Model_, seguindo o padrão do Autoloader do framework. A segunda linha indica ao Doctrine CLI para não gerar as classes Table automaticamente. A terceira linha configura o Doctrine CLI para que gere classes base, onde a quarta linha configura o prefixo das classes Base e a linha seguinte define um diretório vazio, fazendo com que as classes geradas sejam armazenadas no diretório models/base ao invés de models/Model/Base. A próxima linha indica que os nomes de arquivos não devem conter prefixos, e a outra linha indica ao prefixo das classes geradas, que deverá ser Model_, como explicado. A última linha define que a forma de carregar os Models será Agressive, ou seja, eles são carregados na inicialização do Doctrine.

Após definir toda essa estrutura, é hora de configurar a inicialização do Zend Framework para que ele carregue e configure corretamente o Doctrine e as demais classes necessárias pela aplicação. Para isso, basta abrir o arquivo application/Bootstrap.php e colocar o seguinte conteúdo nele:

<?php
class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
        protected function _initAutoload()
        {
                $autoloader = new Zend_Application_Module_Autoloader(array(
                        'basePath' => APPLICATION_PATH,
                        'namespace' => ''
                ));
                return $autoloader;
        }
        protected function _initDoctrine()
        {
                $this->getApplication()->getAutoloader()
                                                                ->pushAutoloader(array('Doctrine', 'autoload'));
                spl_autoload_register(array('Doctrine', 'modelsAutoload'));
                $doctrineConfig = $this->getOption('doctrine');
                $manager = Doctrine_Manager::getInstance();
                $manager->setAttribute(Doctrine::ATTR_AUTO_ACCESSOR_OVERRIDE, true);
                $manager->setAttribute(
                        Doctrine::ATTR_MODEL_LOADING,
                        $doctrineConfig['model_autoloading']
                );
                Doctrine::loadModels($doctrineConfig['models_path']);
                $conn = Doctrine_Manager::connection($doctrineConfig['dsn'], 'doctrine');
                $conn->setAttribute(Doctrine::ATTR_USE_NATIVE_ENUM, true);
                return $conn;
        }
}

O primeiro método configura o Autoloader do Zend Framework, para que ele cuide do carregamento das classes necessárias na aplicação. O segundo método configura o Doctrine. Primeiramente ele adiciona o Autoloader do Doctrine ao Autoloader do Zend Framework, permitindo ao Doctrine carregar as classes específicas de seus componentes. A próxima linha configura o Autoloader de Models do Doctrine, para que o Doctrine também cuide do carregamento de seus Models, conforme for necessário na aplicação. As linhas seguintes cuidam de:

• Pegar as configurações definidas no arquivo application.ini;
• Definir os atributos do Doctrine, onde o primeiro atributo definido é a sobrescrita de acessores e o segundo é a forma como os Models são carregados;
• Carregar os Models, conforme a forma definida na linha anterior;
• Gerar uma conexão ao banco de dados, baseada na dsn definida no arquivo de configuração;
• Utilizar a forma nativa de ENUM.

Com isso, o arquivo de inicialização do Zend Framework está devidamente configurado. A última etapa é criar a ferramenta de linha de comando do Doctrine. Para fazer isso, basta criar o arquivo application/scripts/doctrine.php e colocar o seguinte conteúdo nele:

<?php
//Caminho para a pasta da aplicação
defined('APPLICATION_PATH')
    || define('APPLICATION_PATH', realpath(dirname(__FILE__) . '/..'));
//Ambiente em que a aplicação será executada
defined('APPLICATION_ENV')
    || define('APPLICATION_ENV', (getenv('APPLICATION_ENV') ? getenv('APPLICATION_ENV') : 'doctrineCLI'));
//Adiciona a "library" no include_path
set_include_path(implode(PATH_SEPARATOR, array(
    realpath(APPLICATION_PATH . '/../library'),
    get_include_path()
)));
require_once 'Zend/Application.php';
//Cria a aplicação, faz o bootstrap e a executa
$application = new Zend_Application(
    APPLICATION_ENV,
    APPLICATION_PATH . '/configs/application.ini'
);
$application->getBootstrap()->bootstrap('autoload');
$application->getBootstrap()->bootstrap('doctrine');
$config = $application->getOption('doctrine');
$cli = new Doctrine_Cli($config);
$cli->run($_SERVER['argv']);

Esse arquivo irá definir a pasta da aplicação, o ambiente doctrineCLI, para pegar as configurações específicas da ferramenta de linha de comando, conforme definido no arquivo application.ini, adicionar a biblioteca de componentes no include_path, inicializar a aplicação, assim como o Autoload do Zend Framework e o Doctrine, pegar as configurações definidas em application.ini, e, finalmente, chamar o Doctrine CLI para cuidar de todo o resto. Por último, é necessário criar o arquivo executável responsável por chamar esta ferramenta definida. Para isso, basta criar o arquivo application/scripts/doctrine e colocar o seguinte conteúdo nele:

#!/usr/bin/env /usr/bin/php
<?php
chdir(dirname(__FILE__));
include('doctrine.php');

O próximo passo é dar permissão de execução a este arquivo:

$ chmod a+x zf_doctrine/application/scripts/doctrine

Testando

Antes de mais nada, a primeira coisa a se fazer é testar o cliente de linha de comando. Para isso, em um terminal, execute o seguinte comando:

$ zf_doctrine/application/scripts/doctrine

A saída deste comando deverá ser a seguinte:

Doctrine Command Line Interface
doctrine.php build-all
doctrine.php build-all-load
doctrine.php build-all-reload
doctrine.php compile
doctrine.php create-db
doctrine.php create-tables
doctrine.php dql
doctrine.php drop-db
doctrine.php dump-data
doctrine.php generate-migration
doctrine.php generate-migrations-db
doctrine.php generate-migrations-diff
doctrine.php generate-migrations-models
doctrine.php generate-models-db
doctrine.php generate-models-yaml
doctrine.php generate-sql
doctrine.php generate-yaml-db
doctrine.php generate-yaml-models
doctrine.php load-data
doctrine.php migrate
doctrine.php rebuild-db

Se preferir, adicione essa ferramenta no include_path de sua aplicação, seguindo a mesma idéia explanada pelo Adler Medrado. Caso o comando retorne a saída demonstrada acima, a ferramenta da linha de comando deverá estar funcionando corretamente. Agora é hora de criar um banco de dados chamado carros_doctrine. Após criá-lo, crie o arquivo db/schema/schema.yml, e coloque o seguinte conteúdo nele:

Carro:
  connection: 0
  tableName: carro
  columns:
    id:
      type: integer(4)
      fixed: false
      unsigned: true
      primary: true
      autoincrement: true
    nome:
      type: string(150)
      fixed: false
      unsigned: false
      primary: false
      notnull: true
      autoincrement: false
    cor:
      type: string(150)
      fixed: false
      unsigned: false
      primary: false
      notnull: true
      autoincrement: false

Nesse arquivo, é feita a definição de uma tabela chamada "Carro" para o banco de dados, onde a tabela terá as colunas:

• id - Que será um campo do tipo Inteiro, chave primária, não aceitará valores nulos e nem valores negativos (unsigned) e será um campo auto-incremental;
• nome - Será um campo do tipo String, com o tamanho de 150 caracteres e que não pode ser nulo;
• cor - Será um campo do tipo String, com o tamanho de 150 caracteres e que não pode ser nulo.

Após criar o banco e definir esse arquivo, basta executar a ferramenta de linha de comando para que ela gere o banco de dados e os Models. Para isso, basta executar o seguinte comando:

$ zf_doctrine/application/scripts/doctrine build-all-reload
build-all-reload - Are you sure you wish to drop your databases? (y/n)
y
build-all-reload - Successfully dropped database for connection named 'doctrine'
build-all-reload - Generated models successfully from YAML schema
build-all-reload - Successfully created database for connection named 'doctrine'
build-all-reload - Created tables successfully
build-all-reload - Data was successfully loaded

Após executar esse comando, basta verificar se a pasta models está devidamente preenchida com o arquivo Carro.php e Base/Carro.php.

Agora, caro queira gerar o SQL da aplicação, basta executar o seguinte comando:

$ zf_doctrine/application/scripts/doctrine generate-sql
generate-sql - Generated SQL successfully for models

Após isso, o arquivo db/sql/schema.sql será criado e conterá a SQL do banco de dados, como o trecho a seguir:

CREATE TABLE carro (
        id INT UNSIGNED AUTO_INCREMENT,
        nome VARCHAR(150) NOT NULL,
        cor VARCHAR(150) NOT NULL,
        PRIMARY KEY(id)
) ENGINE = INNODB;

Agora, o último teste para verificar se tudo está corretamente integrado é fazer algumas chamadas no Controller e verificar se tudo é executado corretamente. Dentro do arquivo application/controllers/IndexController.php, existe o método indexAction(), basta defini-lo como a seguir:

public function indexAction()
{
        $carro = new Model_Carro();
        $carro->nome = "Ferrari";
        $carro->cor = "Vermelha";
        $carro->save();
        $query = new Doctrine_Query();
        $query->from('Model_Carro c');
        $query->orderBy('c.id DESC');
        $this->view->carros = $query->execute();
}

Nesse método, é criado um novo carro com o nome "Ferrari" e a cor "Vermelha", e então é inserido esse carro no banco de dados. Após isso, uma consulta de todos os carros do banco de dados é executada e, então, essa consulta é passada para a View, onde é feita uma listagem desses carros e apresentada ao usuário.

Para fazer essa listagem, altere o arquivo application/views/scripts/index/index.phtml e deixe-o com o seguinte conteúdo:

<?php foreach ( $this->carros as $carro ): ?>
<h1>Carro #<?php echo $carro->id; ?></h1>
<p>Nome: <?php echo $carro->nome; ?></p>
<p>Cor: <?php echo $carro->cor; ?></p>
<hr />
<?php endforeach; ?>

Nele é feito um laço para percorrer todos os carros imprimindo os dados de cada um ao usuário. Agora basta ir ao browser e acessar o projeto, que o seguinte conteúdo será exibido:

Listagem dos Carros

Caso todo esse processo ocorra sem erros, o Doctrine está devidamente integrado ao Zend Framework.

Conclusão

O Doctrine é uma ferramenta robusta e consistente para mapeamento objeto relacional. Ao unir todas as suas funcionalidades com os componentes do Zend Framework, é possível obter uma arquitetura altamente consistente e com ferramentas de alto nível. Apesar de ser uma solução minimalista, a integração se mostra devidamente eficaz, provendo todas as funcionalidades das ferramentas de linha de comando e dos componentes de ambos os frameworks. Existem diversas formas de se integrar o Doctrine com o Zend Framework, esta pode não ser a melhor, porém funciona sem maiores problemas. Logo abaixo, coloco alguns links com outras formas de integração, assim como o screencast que utilizei como base para elaborar este artigo. Até a próxima.

• Deep Integration between Zend and Doctrine 1.2
• Zend Framework and Doctrine - Part 1
• Autoloading Doctrine and Doctrine entities from Zend Framework
• Zend Framework
• Doctrine

Matéria copiada desse link: 

http://imasters.com.br/artigo/16673/zend/integrando_o_doctrine_com_o_zend_framework/ com o objetivo compartilhar o uso do doctrine.

Valeu