RabbitMQ Exchange

Introdução

    Este artigo vem complementar o rabbitMQ conceitos iniciais escrito recentemente. Como uma séries de artigos referente ao RabbitMQ que irei apresentar no PHPConference dia 04/12/2015

Exchange

    No modelo AMQP, um produtor de mensagem envia mensagens para um exchange, que distribui a mensagens para queues. A exchange é um algorítmo que determina qual queues deve receber a mensagem.

Tipos

    Existe 4 tipos de algorítmos diferentes, que se diferem pelo algoritimo utilizado

Fonout

    É o tipo mais simples. Envia cada mensagem para cada fila ligada a troca.

Direct Exchange

    O Producer identifica a mensagem com uma chave de roteamento, que nada mais é do que uma string que indica o tipo de mensagem. O algoritmo de roteamento se preocupa em levar a mensagem para as filas cuja chave de ligação corresponde exatamente a chave de roteamento da mensagem.

Default Exchange

    Utiliza o nome da fila como chave de ligação. Se um producer envia uma mensagem e a chave de identificação é o nome da fila, por padrão o exchange envia esta mensagem para esta fila. Toda exchange deve ter um nome. Caso ela não o tenha, ela é considerada exchange padrão.

Topic Exchange

    É semelhante a uma troca direta. Entretanto usa chaves separadas por um delimitador, que deve ser uma lista de palavras, delimitada por pontos. As palavras podem ser qualquer coisa, mas geralmente especifícam algumas características ligadas à mensagem. A chave deve estar limitada a 255 bytes.

    

    Estas chaves pode incluir caracteres curingas, como exemplo temos o '#' que substitui uma ou mais palavras; ou '*' substitui exatamente uma palavra.

Headers Exchange

    A AMQP fornece uma headers exchange, que permite consultas símples em headers de uma mensagem. A ligação contém uma lista headers name, propriedades, e argumentos especificando se 'all' (todos os campos de cabeçalho devem corresponder) ou "any" (se qualquer campo corresponder).
Cada AMQP 0-10 corretor contém uma predeclared cabeçalhos trocar amq.match nomeado. Trocas de cabeçalho adicionais podem ser declarados como necessário.
    A AMQP permite implementar tipos de exchange que não estão definidos na norma. Neste caso falamos de Intercâmbios personalizados, eles não são pré-declarados. Para isso, o MRG Messaging fornece um Exchange XML, que pode encaminhar mensagens XML com base em seu conteúdo. As ligações para uma troca XML usar um Xquery, que é aplicada ao conteúdo e cabeçalhos de cada mensagem para determinar se a mensagem deve ser encaminhada.

Veja também RabbitMQ na prática com PHP

Referências

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_MRG/1.1/html/Messaging_User_Guide/chap-Messaging_User_Guide-Exchanges.html

https://www.rabbitmq.com/tutorials/tutorial-three-python.html
https://www.rabbitmq.com/tutorials/tutorial-four-php.html

RabbitMQ Conceitos iniciais

Introdução

    Este artigo é o primeiro de uma série de artigos que pretendo fazer para complementar o material que será apresentado na PHPConference 2015

    O RabbitMQ é um gerenciador de fila assíncrono, seu intuito é basicamente separar os enviadores dos receptores e funcionar como um intermediário de mensagens, garantindo a sua entrega em formato de fila. A mensageria é uma técnica que soluciona a comunicação entre sistemas diferentes de forma confiável, e um Barramento de Mensagens é o mecanismo que coordena o envio e a recepção de mensagens em uma fila.

    AMPQ (Advanced Message Queuing Protocol): É um protocolo sobre o qual trabalha o rabbitMQ, este foi criado para tentar unificar todas as tecnologias envolvidas em um sistema de mensagens, funciona como um protocolo de comunicação em rede, similar ao HTTP.

    Mensageria: sistemas que trocam mensagens por intermédio de um servidor que em geral é chamado de message broker. A razão para sua existência é a baixa confiabilidade das redes que interligam computadores. Este sistema garante que o receptor receberá a mensagem enviada.

    Fila (Queue) - É um buffer que armazena as mensagens dentro do RabbitMQ para ser consumida posteriormente.

    Consumidor (Consumer) - É quem recebe as mensagens,que estão na fila.

    Producer: Aplicações responsáveis por publicar mensagens nos exchanges.

    Exchange: Sua tarefa é receber as mensagens do producer e encaminhar as mensagens para filas;

    Queues: Armazenam as mensagens e encaminham elas para os consumers;

Transmição

    Basicamente uma mensagem é transmitida por 5 passos:

• Create - O remetente cria a mensagem;
• Send - O remetente adiciona a mensagem para um canal.
• Deliver - O sistema de mensagens move a mensagem do computador do remetente para o computador do receptor, tornando-o disponível para o receptor.
• Receive - O receptor lê a mensagem a partir do canal.
• Process - O receptor extrai os dados da mensagem.

    Neste diagrama entendemos alguns conceitos:

• Send and forget: Quando o Seding Application envia a mensagem para o canal de mensagem, uma vez que o envio estiver completo, o remetente não se preocupa mais com a entrega.
• Store and forward: Ao receber esta mensagem o canal de mensagens grava esta mensagem na memória ou no disco, e disponibiliza ao receptor até que a mensagem chegue ao seu destino.

    Desta forma cada sistema tem sua responsábilidade podendo encapsular da melhor forma sua lógica. Sem ter de se preocupar se a etapa seguinte já aconteceu. Componentes com responsabilidades bem definidas implicam em melhor reutilização.

RabbitMQ

    É uma aplicação open source para troca de mensagens desenvolvida em Erlang, construído no protocolo AMQP, mas também compatível com outros protocolos como HTTP, MQTT e STOMP. O projeto responsável RabbitMQ teve início em 2007 pela empresa Rabbit Technologies Ltd. e, posteriormente, foi incorporado pela VMWare passando a fazer parte da iniciativa Pivotal. O RabbitMQ é composto por três componentes, além do produtor e do consumidor: O Exchange, a Queue e o binding.

Exchange: Sua tarefa é receber as mensagens do producer e encaminhar as mensagens para filas;

Queues: Armazenam as mensagens e encaminham elas para os consumers;

    O exchange recebe a mensagem de um producer e encaminha para as filas de acordo com um critério pré-definido. Esse critério é chamado de binding. O exchange é basicamente um sistema de rotas, que inspeciona a mensagem e usando sua tabela de critérios decide como a encaminhar as mensagens, seja para uma fila de mensagem ou para outro exchange.

    O Canal (Channel) faz a conexão da aplicação cliente com o broker através do protocolo TCP. As conexões usam autenticação e podem usar conexões SSL. Conexões via TCP custam caro para o sistema operacional e, por isso, os canais existem. Os canais, dentro do protocolo AMQP, são “conexões leves que compartilham a mesma conexão TCP”, é necessária apenas uma instância de conexão para executar múltiplas ações.

Continua em RabbitMQ Exchange

Referências

https://www.rabbitmq.com/features.html

http://www.gta.ufrj.br/ensino/eel879/trabalhos_vf_2014_2/leonardo/intro.html

http://blog.concretesolutions.com.br/2012/01/rabbitmq-conceitos-basicos/

http://www.devmedia.com.br/introducao-ao-amqp-com-rabbitmq/33036

http://blog.concretesolutions.com.br/2012/01/introducao-a-mensageria/

http://www.enterpriseintegrationpatterns.com/patterns/messaging/Introduction.html

http://blog.andreiabohner.org/post/1/usando-o-rabbitmq-com-o-symfony2

http://www.ime.usp.br/~reverbel/students/master_theses/thadeu_de_russo_e_carmo.pdf

http://www.devmedia.com.br/integracoes-robustas-com-jboss-rabbitmq-e-qpid/31538

http://lerta.com.br/alta-disponibilidade-no-rabbitmq-warren/

http://nelsonsar.github.io/2013/10/29/AMQP-building-blocks.html

http://nelsonsar.github.io/2013/11/07/RabbitMQ-exchange-types.html

TDD. O que é, e como inicio no PHP Parte II

TDD Conceitos Importantes

Introdução

    Em algumas postagens anteriores fiz a primeira parte desta série de artigos. A primeira praticamente ensinava uma das várias formas de instalação que para o phpunit e o xdebug. Agora vamos entender alguns conceitos do TDD

Argumentação para o TDD

    No TDD sempre devemos iniciar com os testes. Isso nos obriga a pensar exatamente o que desejamos que este pedaço do sistema execute. Acredito que uma boa forma de utiliza-lo é junto com alguma ferramenta ágil, como o scrum - por exemplo. O importante em dividir seu sistema em uma parte testável do dele, inicialmente criar o teste, e depois o código para que o teste passe. Resolvido esta parte podemos evoluir o código.
    Qualidade do código
    Um dos principais ensinamentos do TDD é que se algo não puder ser testado, este foi desenvolvido errado. Em pouco tempo utilizando testes começará a desenvolver de forma visivelmente diferente, ajudando o programador a desenvolver um código cada vez com mais qualidade. Pois, para atuar com o TDD, o programador é obrigado a forçar seu raciocínio de forma mais elevada para que o código tenha menos acoplamento e dependência.

    Documentação

    Os testes acabam sendo uma excelente documentação do software. Pois ao rodar o teste no modo verbose, uma "história" é contada do software que poderá ajudar a criar a documentação.

    Testes manuais custam caro

    Sem os teste unitários, a validação para garantir a integridade do software é praticamente impossível, pois o testes deveria testar todos os fluxos possíveis em diversas situações, para encontrar possíveis erros. Com os testes unitários, sobra apenas os testes mais práticos do fluxo que realmente foi alterado.

Passos do TDD
    O TDD baseia-se em três passos, vermelho, verde e refatora. O vermelho é o início, quando você apenas criou o teste, assim ainda não existe a classe a ser testada, e consequentemente o teste não passará. O verde é o momento em que a lógica criada passou no teste, assim o código já esta funcional, mas ainda carece de melhoras. Esta melhora ocorre na parte do refatoramento, que é a melhoria do código, onde se remove duplicações e o código vai ficando mais próximo de sua versão final. É importante em cada alteração do código, passar o teste, para garantir que a mudança não interferiu em seu funcionamento.
    Para o correto funcionamento é utilizado um conceito chamado baby steps ou passos de bebê, que consiste em realizar pequenos passos de um processo complexos. Para isso devemos utilizar os seguintes princípios:

• Os testes precisam ser rápidos;
• Devem ser isolados, devemos testar apenas uma unidade do sistema. O ideal é que os fatores externos não interfiram na unidade.
• Devem funcionar em qualquer ordem ou em qualquer valor. 
• Não deve ser interferido manualmente, devem funcionar sozinhos.
• O código deve ser desenvolvido após desenvolver o teste.

Conclusão

    Como vimos o Desenvolvimento baseado em testes é de vital importância para melhoria do código, refatoração sem erros, e facilitação da manutenção do sistema. Nos próximos artigos veremos como atuar mais na prática.

Domain Driven Design

        Diferenças entre Domain Driven Design e Model Drinven Design

Significa Projeto Orientado a Domínio e veio do livro escrito por Eric Evans. Como diz o Wikipedia é uma abordagem de desenvolvimento de software para as necessidades complexas, fechando a lacuna entre a realidade do negócio e o código.
A ideia principal do DDD é capturar o modelo para o código. Mantendo seu software voltado para o problema e não restrito à solução. Assim quando você procura algo importante sobre o domínio você saberá exatamente onde está.

Linguagem Ubíqua
É uma linguagem comum, com termos bem definidos, que fazem parte do processo de desenvolvimento. É importante para que todos falem a mesma língua, baseado na informação que puder conseguir do cliente. Como exemplo, se um cliente chama o dinheiro do caixa de numerário, sempre que nos referenciarmos ao dinheiro do caixa no software e nas reuniões, ele será numerário. Assim evita erros de interpretação.
É importante que todos os membros dentro do projeto estejam comprometidos com a linguagem Ubíqua, e tentar readequar sempre que for percebido que um termo tem mais de um significado.
Apenas desta forma poderemos ter o modelo abstrato como uma representação perfeita do domínio.

Model Driven Design (MDD)
A ideia por trás do MDD é a de que o seu modelo abstrato deve ser a representação perfeita do seu domínio. Seu processo de maturação deve ser contínuo. Este modelo servirá de guia para a criação do código e, ao mesmo tempo, o código ajuda a aperfeiçoar o modelo. Este contato contínuo trará aos programadores um insights para a refatoração.

Blocos de Construção do MDD
Precisamos isolar o modelo das demais partes. Essa separação sera feira utilizando-se de arquitetura em camadas:

• Interface de Usuário: É a parte de interação com o usuário e interpretação dos seus comandos;
• Aplicação: É uma camada sem lógica de negócio, responsável por conectar a interface as camadas inferiores
• Domínio: Responsável por toda a regra de negócio, Todo o foco do DDD esta aqui. 
• Infra-estrutura: Responsável por fornecer os recursos para suporte as camadas superiores. São as partes de dados e persistência em geral.

Conclusão
Diante desta introdução ao DDD percebe-se que a ideia que gira em seu turno, e montar sua aplicação baseada no que o cliente deseja. Compreendendo exatamente as funções do sistema, abrangendo esta compreensão inclusive na linguagem utilizada pelo cliente. Fica evidente também que o MDD (Model Driven Design) é a parte maior, e uma das camadas (a camada de lógica) é que abrange o DDD (Domain Driven Design)

Referências
http://www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-design/
http://en.wikipedia.org/wiki/Domain-driven_design
http://www.agileandart.com/portfolio/mdd-model-driven-design/
http://msdn.microsoft.com/pt-br/magazine/dd419654.aspx
http://www.inf.ufsc.br/~ricardo/publications/Asoo97.pdf

TDD. O que é, e como inicio no PHP

    TDD Desenvolvimento Baseado em Testes
    Hoje inicio uma série de artigos referentes ao TDD. Farei um apanhado de várias bibliografias com o intuito de agrupar importante conhecimentos e encorajar mais desenvolvedores a atuarem por esta solução. A ideia é tentar ser o mais prático possível, encontrei diversas teorias em artigos em português, mas a prática mesmo é encontrada em artigos em inglês. Pois tenho visto poucos desenvolvedores realmente atuando com este paradigma.

    O que é Test Driven Development - TDD.

    Em português quer dizer Desenvolvimento orientado a teste. A ideia, segundo Kent Beck, que é considerado um de seus inventores, é: 

• Não escreva uma linha de código a menos que você tenha escrito um teste de acerto e um teste de falha para a funcionalidade;
• Elimine as duplicações

    Vantagens
    A grande vantagem é que os testes contém asserções que podem ser verdadeiras ou falsas. Após as mesmas serem consideradas verdadeiras os testes confirmam o comportamento correto, permitindo os desenvolvedores evoluir e refatorar o código.

    Como iniciar
    Vou fazer um breve roteiro de instalação do phpUnit, e do X-debug, que considero ser uma forma de iniciar o Desenvolvimento orientado a testes no PHP. Fiz um roteiro para debiam. Verifique como funcionará no seu sistema operacional.

• Baixe o PHPUnit

wget https://phar.phpunit.de/phpunit.phar

• Mude a permissão

chmod +x phpunit.phar

• Mover para o bim

mv phpunit.phar /usr/bin/phpunit

• Pegamos o Composer

php -r "readfile('https://getcomposer.org/installer');" | php

• Escrever o composer.json

vim composer.json

{

    "require-dev": {

            "phpunit/phpunit": "4.2.*",

            "phpunit/php-invoker": "*",

            "phpunit/dbunit": ">=1.2"

    },

    "autoload": {

            "classmap": [

                "src"

            ]

}

}

• Rode o composer

composer install || composer update

• Instale o X-Debug

apt-get install php5-dev php-pear // PECL estará neste pacote

pecl install xdebug

• Acesse o PHP.ini e configure o X-Debug inserindo estas linhas:

zend_extension=/usr/lib/php5/20100525/xdebug.so

xdebug.remote_enable=on

xdebug.remote_handler=dbgp

xdebug.remote_host=localhost

xdebug.remote_port=9000

Conclusão

Este seria um pequeno roteiro de instalação do PHPUnit, esta instalação seria apenas para os sistemas Debian. Se este não for seus sistema operacional, pegue um tutorial para instalação no seu Sistema Operacional ou considere as adaptações, a parte mais importante é acostumar a escrever os testes antes de escrever o código. Iremos testar alguns exemplos de aplicação nos próximos tutoriais.

Referências
https://phpunit.de/manual/current/en/installation.html
http://tableless.com.br/phpunit-como-iniciar-sem-dores/
http://br.phptherightway.com/#xdebug
http://xdebug.org/docs/install
Test-Driven Development By Example - Kent Beck
http://blog.thiagobelem.net/aprendendo-tdd-ou-desenvolvimento-orientado-a-testes/

Um Pouco de teoria. O que é SOA?

SOA é Service Oriented Architecture - descreve duas coisas distintas. As duas primeiras expressam uma metodologia para desenvolvimento de software. A terceira palavra é um panorama de todos os ativos de software de uma empresa. SOA é uma linguagem orientada à serviço. Trata-se de um conceito. É uma metodologia que permite a integração de novos sistemas com sistemas antigos. Um estilo de arquitetura de software cujo princípio preconiza que as funcionalidades implementadas devem ser disponibilizadas na forma de serviço disponibilizados via web.
Além da perspectivas estritamente técnico, a arquitetura orientada a serviço também se relaciona com determinadas políticas e conjuntos de "boas práticas" que pretendem criar um processo para facilitar a tarefa de encontrar e gerenciar os serviços disponibilizados.
Sua grande vantagem é a redução do tempo no desenvolvimento das novas aplicações de negócios. Neste caso os prazos são encurtados porque a área técnica não parte do zero, já que sua filosofia prega a integração entre diferentes tecnologias.
No ponto de vista de SOA, o serviço é uma função de um sistema computacional que é disponibilizado para outro sistema. Sendo que funcione independente do estado de outros e possuindo uma interface bem definida. Normalmente, a comunicação entre o sistema cliente e aquele que disponibiliza o serviço é realizada através de web service.
Serviços são porções de software construídas de forma que possam ser facilmente vinculadas a outros componentes. No centro deste conceito esta a idéia de que é possível definir partes dos códigos de software em porções significativas o suficiente para serem compartilhadas e reutilizadas em diversas áreas da empresa, automatizando assim algumas tarefas
A revolução da SOA está mudando o modo como pensamos que os negócios podem ser estruturados e gerenciados. Mas será preciso mais do que apenas tecnologia para chegarmos à empresa do futuro. Na verdade, a adoção da SOA está criando novos desafios sobre como a orientação de serviços deveria ser governada, como deveria ser adotada, como afeta culturalmente uma organização e outras questões. Com a abordagem, as ferramentas e os recursos certos, a empresa do futuro pode estar aqui mais rápido do que você imagina.

Projeto Imóveis

  Esta é minha primeira postagem. Por isso, venho discursar um pouco do que aprendi nestes anos. Alguns projetos desenvolvidos.
  Trabalho com programação desde 2005, atuo já com desenvolvimento desde sistemas simples até sistemas complexos. O mais recente e mais gostoso de ser feito foi o projeto de uma imobiliária virtual.
 Este trabalho começou a ser projetado quando procurava um imóvel e não achava um lugar onde tivéssemos tudo centralizado. Para encontrar algo, precisava buscar diversos sites, e diversas imobiliárias.
 Assim a missão do site (que hoje se encontra pronto), é de unir todos os imóveis em um só lugar. para tal o site http://imoveis.mundobrasil.com.br , indexa imóveis das maiores imobiliárias do pais, mas também recebe anúncios de imóveis. podendo optar por planos de maior destaque, ou de destaque convencional. Os parceiros indexados, também podem optar por planos de maiores destaques, e assim firmar parcerias para que possam aparecer na frente.