ZF1 para ZF2

Olá amigos(as), hoje vou apenas compartilhar aqui o video que foi o primeiro Webinar oficial da Zend feito em português pelo já conhecido e famoso Flávio Gomes Lisboa (Escritor dos livros de ZF1). Eu tive a oportunidade de assistir a transmissão ao vivo e achei muito produtiva em todos os aspectos.

Acho que o video tenta de uma forma simples comparar as diferenças entre os dois frameworks e mostrar os desafios que a Zend passou para criar esse framework tão robusto que é o Zend Framework 2.

Sendo assim segue abaixo o link do video:

http://www.zend.com/en/webinar/ZF/70170000000c4Mm-migrando-do-zf1-para-o-zf2-20130416.flv

Netflix no Linux Ubuntu

Esse pequeno artigo vai te ajudar rapidamente a rodar o Netflix no Linux Ubuntu.

Mas espera ai! O NETFLIX NÃO RODA NO LINUX? E A RESPOSTA É SIMPLES, O NETFLIX utiliza o Microsoft Silverlight....

Na boa, há um ano atrás eu vi algumas estratégias do NETFLIX sobre uso do HTML5 muito interessantes, e até imaginei que fosse uma empresa "estilo Google de pensar", mas depois que eu vi que além de utilizarem Silverlight não existe uma alternativa criada POR ELES DIRETO NO BROWSER achei uma baita palhaçada e descaso dessa empresa.
Sério, que ano eles pensam que estão? Será que é tudo da Microsoft? Será que a Microsoft ainda não aprendeu que quando vc tenta impor algo vc só tem a perder? Sei lá viu, algumas pessoas e alguns cargos na área de TI não deveriam simplesmente existir.

Enfim, deixando o desabafo de lado vamos falar da solução técnica para isso, um programador do EUA chamado Erich E. Hoover também ficou puto mas não apenas reclamou como arregaçou as mangas e foi desenvolver uma solução(PARA NOOOOOSSSAAA ALEGRIAA), e é bemmm simples pois é basicamente o programa que trabalha com o Wine em conjunto com o Firefox. E para vc e eu que queremos fazer o Netflix rodar sem muito esforço ficou perfeito(rs).


Abra o terminal e resolva isso com 3 comandinhos$ sudo apt-add-repository ppa:ehoover/compholio
$ sudo apt-get update
$ sudo apt-get install netflix-desktop


Depois de instalado é só chamar nosso amiguinho e pronto
$ netflix-desktop




Fonte http://www.compholio.com/netflix-desktop/

Arquitetura SOLID

Olá amigos, ultimamente ando com artigos mais conceituais pois meu intuito ultimamente é flexionar nosso cérebro para pensar  de uma forma mais ampla do desenvolvimento de software. Por isso hoje vou falar da consagrada Arquitetura de Software SOLID

Em meados de 2005, Robert Martin(Uncle Bob), publicou um artigo sobre 11 princípios de Design para desenvolvimento Orientado a Objetos. No artigo ele diz que não basta programar orientado a objetos, é necessário ter princípios de design para manter a qualidade. Os 5 primeiros princípios ficaram “mais famosos”, sendo estes os que formam o S.O.L.I.D.

O SOLID tenta mostrar de maneira simples como planejar algo limpo e de uso altamente flexível(afinal,  pq usar?). Vou dar uma acordada em vc ai, sabia que o famoso Zend Framework 2 usa SOLID? Pois é meu amigo e amiga o Matthew Weier cabeça do desenvolvimento do ZF2 buscou usar o melhor da atualidade para o framework e eles encontraram no SOLID uma forma de expressar o que eles queriam de fato que é o conceito de framework "USE O QUE VC QUISER E A VONTADE". Ta mais vamos ao ponto desse nome, veja a figura acima e acompanhe a explicação das siglas abaixo.

S – Single Responsibility principle: uma classe deve ter apenas uma responsabilidade.

O – Open/Closed principle: entidades de software devem ser abertos para extensão, mas fechadas para modificação.

L – Liskov substitution principle: objetos em um programa devem ser substitíveis por suas classes derivadas em qualquer ponto do código sem alterar a funcionalidade do programa.

I – Interface segregation principle: interfaces muito específicas são melhores do que interfaces de uso geral.

D – Dependency inversion principle: módulos devem depender de abstrações.

Mais detalhes, clique aqui.

Bem é basicamente isso recomendo uma leitura na documentação do Zend Framework 2(aqui) e também na matéria do Bob(aqui)

Entenda o Domain Driven Design

Olá amigos e amigas tudo bem? Hoje vou resumir de uma forma mais "Mamão com açucar" O que é o DDD e imaginar exemplos utilizando o DDD para como resolver um determinado problema ok?

Provavelmente vc se lembra daqueles 3 gordinhos da Embratel não é? "pegue o seu d d dedo e disque o nu número da embratel, antes do ddd é 021..." Pois bem, eles não tem nada haver com o que eu vou explicar, mas fica ai como imagem de apresentação.


Existem duas maneiras de vc ter caído aqui no meu blog, a 1ª é vc conhecer meu blog e veio aqui para ver novos artigos(a grande menoria). A 2ª é pq vc está pesquisando sobre DDD e encontra muito artigo cheio de filosofia e acaba não absorvendo muito bem, e provavelmente vc não tem muito tempo para lêr o livro do Evans então chegas mais que vou resumir essa parada pra vc!

Antes de mais nada vamos ao entendimento básico, Domain Driven Design significa entre outras palavras Projeto Orientado a Domínio. Que veio do título do livro do Eric Evans. O livro do Evans é basicamente um catálogo de padrões baseados em experiências do próprio Evans ao longo de mais de 20 anos de desenvolvimento de software utilizando técnicas de Orientação a Objetos.

O DDD é basicamente o uso ideal da Orientação a Objetos(PRONTO ACABEI DE EXPLICAR TUDO PODE IR EMBORA).

Não fique bravo(a) comigo pois essencialmente é isso mesmo, DDD é o uso inteligente da orientação a objetos para resolver diversos problemas.

Vamos lá open your mind.

Os decoradores(entende-se pessoas que decoram) de Orientação a Objetos tem um problema grave com isso pois quando se fala em OO as primeiras coisas que vem na mente são "classes, herança, polimorfismo, encapsulamento, lalala...". Mas essa são as regras básicas e técnicas da OO, a grande sacada dela está em independência de tecnologia, mínimo de acoplamento, reutilização de código, alinhamento do código com o negócio, coerência em problemas reais... Olha só, agora sim estamos falando de OO resolvendo problemas reais e essa é a essencia campeonato(entende-se campeão).
 

Vamos ter um papo sério sem muita filosofia esse não é um artigo é mais uma conversa ok? Então vamos pensar, o Projeto Orientado a Domínio é essencialmente entendermos o negócio e tornar o código lógico a esse negócio, coeso a esse negócio, aquele papo de entity não pode ter lógica é justamente o OPOSTO do DDD pois sim vamos ter uma camada de domínio cujo qual minhas entidades são inteligentes! Separar a lógica em serviços que manipulam as entidades muitas vezes torna o reuso impossivel e é basicamente dizer eu sou um macaco que batuco o teclado com a intenção de gerar código....

O DDD não vai exatamente te impor como vc faz a arquitetura do seu software mas sim te abrir a mente sobre como dar funções para quem realmente merece afinal, vc não mandaria um engenheiro fazer uma cirurgia plástica não é?

Veja um exemplo do DDD por "cima":



Interface de Usuário – parte responsável pela exibição de informações do sistema ao usuário e também por interpretar comandos do usuário;

Aplicação – essa camada não possui lógica de negócio. Ela é apenas uma camada fina, responsável por conectar a Interface de Usuário às camadas inferiores;

Domínio – representa os conceitos, regras e lógicas de negócio. Todo o foco de DDD está nessa camada. Nosso trabalho, daqui para frente, será aperfeiçoar e compreender profundamente essa parte;

Infra-estrutura – fornece recursos técnicos que darão suporte às camadas superiores. São normalmente as partes de um sistema responsáveis por persistência de dados, conexões com bancos de dados, envio de mensagens por redes, gravação e leitura de discos, etc.


O DDD basicamente começa por essa premissa básica de conhecer de fato o domínio, mas ele é muito mais amplo e mais complexo por isso eu tentei aqui dar a introdução desse mundo partindo do principio de entender essa ideia.

Existem alguns pontos importantes abordados no DDD que são o uso da mesma linguagem, evitar traduções indevidas, quebrar o problema em camadas, entender entidades, agregados, objetos de valor, fábricas, serviços, repositórios, módulos entre outros.


Segue aqui a primeira versão de um slide da minha palestra sobre Domain Driven Design

Domain Driven Design no PHP from Paulo Victor Gomes

Caso vc queira se aprofundar nos estudos então é melhor ler o livro do Evans http://www.informit.com/store/domain-driven-design-tackling-complexity-in-the-heart-9780321125217



Até a próxima.

Testando suas classes com PHPUnit

Hoje vou replicar um post do meu irmão(http://developer-v.blogspot.com.br), sim meu irmão também tem um blog e ele é da minha area. 

Hy, folks!!!
E ai galera, finalmente vamos fazer um post, mão-na-massa, o que seria isso ???

????????????????????????

Simples um teste em classes, vamos usar agora o PHPunit para fazer um teste que ira funcionar realmente.

O que é Unit Testing?

- Testes para pequenos trechos de código (unidades)
- Verifica se o comportamento de classes e funções é o esperado
- Caso erros são encontrados exceções são lançadas
- Não interfere com o seu código-fonte

Qual a vantagem?

- Os testes são automatizados
- Eles são executados continuamente durante o ciclo de desenvolvimento
- Detectam falhas tanto de digitação e lógica e também comportamentos inesperados

Exemplo

1. class Classe1
2. {
3.     public function somar($a, $b)
4.     {
5.         return $a+$b;
6.     }
7.        
8.     public function subtrair($a, $b)
9.     {
10.         return $a-$b;
11.     }
12. }
14. // Teste da classe
16. $foo = new Classe1();
18. $soma = $foo->somar(2, 2);
19. $subracao = $foo->subtrair(2, 2);
21. echo '2 mais 2 = ' . $soma;
22. echo '2 menos 2 = ' . $subtracao;
24. // Funciona conforme esperado!

Apesar do exemplo simples, ilutra uma prática bem comum: a de inserir vários echo() e print() para confirmar o funcionamento de uma classe ou função.

O PHPUnit é uma framework que tem como objetivo automatizar e padronizar a forma como nosso código é testado.

"Whenever you are tempted to type something into a print statement or a debugger expression, write it as a test instead." -- Martin Fowler

Ou seja: "Toda vez que sentir vontade de escrever um print ou outra expressão de debug, pare e crie um teste!"

1. // Especifique o caminho do PHPUnit
2. require_once '/usr/share/php/PHPUnit/Framework.php';
3. // Especifique o caminho da classe a ser testada
4. require_once 'Classe1.php';
6. // Como a classe a ser testada se chama "Classe1", a classe de teste deverá se chamar "ClasseTest" e (neste caso) irá herdar de PHPUnit_Framework_TestCase
7. class Classe1Test extends PHPUnit_Framework_TestCase
8. {
9.         // Funções de teste devem ter o prefixo "test"
10.         public function testSoma()
11.         {
12.                 // A classe a ser testada é instanciada
13.                 $foo = new Classe1();
14.                 // Testamos a afirmação que "4" é o resultado de passar "2" e "2" (ou seja, 2 + 2 = 4)
15.                 $this->assertEquals('4', $foo->somar(2, 2));
16.         }
17.        
18.         public function testSubtracao()
19.         {
20.                 // idem (veja função acima)
21.                 $foo = new Classe1();
22.                 $this->assertEquals('0', $foo->subtrair(2, 2));
23.         }
24. }

O resultado:

1. PHPUnit 3.3.16 by Sebastian Bergmann.
3. .
5. Time: 0 seconds
7. OK (2 tests, 2 assertions)
9. // Funciona conforme esperado!

O que aconteceu?
Criamos uma classe (Classe1Test) de teste para testar a nossa classe (Classe1) e usamos o PHPUnit para testar o funcionamento esperado

Não é mais complicado?
- Sim e não! Inicialmente pode parecer bem mais simples inserir alguns print() ou echo() e verificar manaulmente, mas ao longo prazo usar o PHPUnit traz diversas vantagens:
- Os testes ficam separados do código, assim não corremos o risco de esqueçer testes no meio do código. Devido à separação também não é necessário ficar voltando e comentando e descomentando as linhas de teste inseridas manualmente.
- Para aplicações um pouco mais complexas (por exemplo com várias classes interagindo juntas ou com AJAX) as vezes não é possível colocar echo() ou print() em qualquer lugar. Até mesmo o FirePHP gera erros de 'header'!
- Usando o PHPUnit criamos vários testes e sempre que desejarmos podemos rodá-los novamente para testar modificações.
- E o melhor de tudo, não precisamos fazer nada na hora de colocar a aplicação no ar. Simplesmente não fazemos o upload da pasta de testes! O código-fonte original segue intacto.

Como funciona?
- Crie uma classe de teste para testar uma classe já existente
- Excute os testes no terminal (ou prompt de comando) e veja os resultados
- A melhor maneira da aprender isto é através de exemplos então vamos instalar o PHPUnit e criar alguns testes!

Instalação do PHPUnit

Quem usa o linux pode fazer facilmente:

1. # se não tiver o PEAR instalado
2. apt-get install pear
3. # descubra o canal do PHPUnit
4. pear channel-discover pear.phpunit.de
5. # instale o phpunit
6. pear install phpunit/PHPUnit
8. # Ele fica instalado por padrão no /usr/share/php/PHPUnit
9. # Agora é só incluir o framework nos arquivos de teste e começar!

Quem usa windows procure no google! Não deve ser muito complicado... (se não me engano ele já vem incluso no pacote XAMPP)

Guia para criar Unit Tests

- Os testes para a classe "Classe1" (Classe1.php) deverão ser localizados dentro da classe "Classe1Test" (Classe1Test.php), sempre use o sufixo "Test" (NomeDaClasseTest)
- Na maioria dos casos a classe de teste irá herdar (extends) da classe PHPUnit_Framework_TestCase
- Os testes deverão ser funções públicas com o prefixo "test" (testSomar, testSubtrair, etc)
- Os testes são baseados em afirmações, ou seja: afirmamos que o resultado esperado da função X é Y, e testamos a afirmação pra ver se ela procede.
- Usamos funções como assertEquals() para testar afirmações (exemplos a seguir)

Algumas Afirmações disponíveis (Funções de Teste)

- Existem dezenas (veja a documentação http://www.phpunit.de/manual/), seguem algumas das mais comuns:
- assertEquals($valor, funcao()) (afirma que o valor retornado da funcao é igual a $valor)
- assertNotEquals($valor, funcao()) (afirma que o valor retornado da funcao não é igual a $valor)
- assertSame($valor, funcao()) (testa se o objeto retornado é igual a $valor)
- assertTrue(funcao()) (afirma que o valor retornado é === true)
- assertFalse(funcao()) (=== false)
- setExpectedException (avisa sobre uma exceção que deverá ser lançada)

Como rodar os testes

Através do terminal (ou prompt de comando), no diretório do arquivo de teste digite:

1. phpunit NomeDaClasseTest
2. # para rodar os testes contidos no arquivo NomeDaClasseTest.php

Vamos ver alguns exemplos na próxima página.
O test seguinte usa a função assertEquals() para checar o retorno de um método:

1. // Especifique o caminho do PHPUnit
2. require_once '/usr/share/php/PHPUnit/Framework.php';
3. // Especifique o caminho da classe a ser testada
4. require_once 'Classe2.php';
6. class Classe2Test extends PHPUnit_Framework_TestCase
7. {
8.     public function testCumprimentarSemParametro()
9.     {
10.         // O comportamento esperado é que retorne "Olá fulano", testa esta afirmação
11.         $this->assertEquals('Olá fulano', $foo->cumprimentar());
12.     }
14.     public function testCumprimentarComParametro()
15.     {
16.         // Instancia a classe e passa "Alex" ao construtor
17.         $foo = new Classe2('Alex');
18.         // O comportamento esperado é que retorne "Olá Alex", testa esta afirmação
19.         $this->assertEquals('Olá Alex', $foo->cumprimentar());
20.     }
21.    
22.         // Funções de teste também podem ser identificados pela anotação @test no DocBlock
23.         /**
24.          * @test
25.          */
26.          public function vaiDarErrado()
27.          {
28.                  // Instancia a classe e passa "ciclano" ao construtor
29.                 $foo = new Classe2('ciclano');
30.                 // O comportamento esperado é que retorne "Olá ciclano", mas vamos afirmar que retornará outro valor para forçar um erro
31.                 $this->assertEquals('Olá Alex', $foo->cumprimentar());
32.          }
33. }

Outro teste simples que retorna o seguinte:

1. PHPUnit 3.3.16 by Sebastian Bergmann.
3. ..F
5. Time: 0 seconds
7. There was 1 failure:
9. 1) vaiDarErrado(Classe2Test)
10. Failed asserting that two strings are equal.
11. expected string <Olá Alex>
12. difference      <     xxxx???>
13. got string      <Olá ciclano>
14. /caminho/para/o/arquivo/Classe2Test.php:35
16. FAILURES!
17. Tests: 3, Assertions: 3, Failures: 1.

Ou seja, quando um teste falha ele informa o arquivo e linha onde ocorreu o erro.
Explica também qual foi o erro:
- O valor esperado era "Ola Alex"
- O valor retornado foi "Ola ciclano"
E ele ainda mostra a diferença ( xxxx???)

Fornecendo valores para os testes

- As vezes não basta só um teste com um valor estático
- Podemos criar uma função para alimentar o teste usando vários valores (e nada impede que sejam de fontes externas)
- A função é identificada através da anotação @dataProvider no DocBlock

Exemplo:
Uma versão um pouco mais complicada para explicar o uso do data provider em testes:

1. // Demonstração de "Data Providers"
2. class Classe3Test extends PHPUnit_Framework_TestCase
3. {
4.     // Informa o nome do forneçedor de dados (@dataProvider) para a clase de teste
5.     /**
6.      * @dataProvider provider
7.      */
9.     // Recebe 3 parâmetros
10.     public function testCombine($a, $b, $c)
11.     {
12.         // Afirma que o valor do terceiro parâmetro é igual a concatenação dos primeiros dois separados por um espaço
13.         $this->assertEquals($c, $a . ' ' . $b);
14.     }
16.     // A função fornecedora de valores
17.     public function provider()
18.     {
19.         // retorna um array contendo 3 grupos de valores a serem testados
20.         return array(
21.             array('Hello', 'World', 'Hello World'),
22.             array('É', 'Nois', 'É Nois'),
23.             array('Deu', 'Errado', 'Deu Certo')
24.         );
25.     }
26. }

Valor retornado:

1. PHPUnit 3.3.16 by Sebastian Bergmann.
3. ..F
5. Time: 0 seconds
7. There was 1 failure:
9. 1) testCombine(Classe3Test) with data set #2 ('Deu', 'Errado', 'Deu Certo')
10. Failed asserting that two strings are equal.
11. expected string <Deu Certo>
12. difference      <    xxxxx?>
13. got string      <Deu Errado>
14. /home/alex/Documents/aw/Articles/PHPUnit/Classe3Test.php:16
16. FAILURES!
17. Tests: 3, Assertions: 3, Failures: 1.

Resumindo...

- O assunto é bastante extenso e realmente fica difícil cobrir todas as possibilidades (que são quase infinitas)
- É possível criar testes para testar se Exceções são lançadas conforme esperado, para testar classes de acesso ao banco de dados e muito mais
- O ideal seria implementar isto em uma aplicação que esteja desenvolvendo, ou seja, crie uma pasta para os testes e vá criando testes para as suas classes nela

Todo o código-fonte para os exemplos e outros exemplos mais complexos (todos bem documentados) estão disponíveis:

Espero que tenham gostado e que eu tenha introduzido bem este assunto que é frequentemente subestimado e importantíssimo quande se trata de desenvolvimento.

Este post, foi melhorado para uma linguagem mais visual e facíl de entender =D...
Fonte PHPbr