Strategy Pattern em ColdFusion

On 17 de abril de 2012, in CFML, Design Pattern, by andersonstraube

Strategy é um padrão de projeto de software (do inglês design pattern). O objetivo é representar uma operação a ser realizada sobre os elementos de uma estrutura de objetos. O padrão Strategy permite definir novas operações sem alterar as classes dos elementos sobre os quais opera. Definir uma família de algoritmos e encapsular cada algoritmo como uma classe, permitindo assim que elas possam ter trocados entre si. Este padrão permite que o algoritmo possa variar independentemente dos clientes que o utilizam.
Fonte: http://pt.wikipedia.org/wiki/Strategy

Motivação para usar o Padrão Strategy?

– Quando um sistema possui vários componentes que têm semelhança estrutural porém com comportamentos diferentes;
– Quando tem um algoritmo cujo cálculo pode variar dependendo dos parâmetros fornecidos;
– Você não quer que o componente principal seja alterado e/ou “inflado” toda vez que um novo modo (estratégia) é desenvolvida/solicitada.

Continue reading »

Tagged with:  

Observer Pattern em ColdFusion

On 11 de abril de 2012, in CFML, Design Pattern, by andersonstraube

O Observer é um padrão de projeto de software que define uma dependência um-para-muitos entre objetos de modo que quando um objeto muda o estado, todos seus dependentes sejam notificados e atualizados automaticamente. Permite que objetos interessados sejam avisados da mudança de estado ou outros eventos ocorrendo num outro objeto.
O padrão Observer é também chamado de Publisher-Subscriber, Event Generator e Dependents.
Fonte: http://pt.wikipedia.org/wiki/Observer

Motivação para usar o Padrão Observer?

– Definir uma dependência um-para-muitos entre objetos para que quando um objeto mudar de estado, todos os seus dependentes sejam notificados e atualizados automaticamente;
– Quando um objeto deve ser capaz de avisar outros sem fazer suposições sobre quem são os objetos. Ou seja, sem criar um acoplamento forte entre os objetos;
– Conseguimos reduzir o uso do relacionamento bidirecional por meio de interfaces e classes abstratas, separando a abstração para ter um alto nível de coesão e baixo acoplamento.

Continue reading »

Tagged with:  

cfqueryparam com lista de valores para a cláusula “IN” do SQL

On 4 de abril de 2012, in CFML, SQL, by andersonstraube

Vamos ver como usar uma lista de valores na cláusula “IN” do SQL utilizando o cfqueryparam do ColdFusion.

Não preciso nem comentar sobre o uso do cfqueryparam, para mim isso é obrigatório por questões de segurança e vários outros fatores.

No código abaixo ele lista os clientes cujo nome está na lista:


<cfquery name="q_Clientes" datasource="#dsn#">
  SELECT 
	*
  FROM 
	clientes
  WHERE 
	nome IN ('Anderson','Maria','João','Zeca')
</cfquery>

Continue reading »

Tagged with:  

Cache de Query no ColdFusion

On 28 de março de 2012, in CFML, by andersonstraube

Em sistemas críticos (de alta carga) é fundamental termos otimização de SQL’s e principalmente sistema de cache. O ColdFusion tem um recurso muito interessante que é utilizado para fazer o cache de query.

Em consultas largamente utilizadas no sistema e onde o resultado raramente muda como por exemplo: listagem de estados, cidades e bairros – não precisamos recorrer ao banco de dados para recuperar tais informações, nestes casos podemos poupar o banco armazenando o resultado dessa consulta em cache na própria aplicação:

Continue reading »

Tagged with:  

Singleton em ColdFusion

On 2 de março de 2012, in CFML, Desenvolvimento, Design Pattern, by andersonstraube

Singleton, é um padrão de projeto de software (do inglês Design Pattern). Este padrão garante a existência de apenas uma instância de uma classe, mantendo um ponto global de acesso ao seu objeto.
O termo vem do significado em inglês quando se resta apenas uma carta nas mãos, num jogo de baralho.
Muitos projetos necessitam que algumas classes tenham apenas uma instância. Por exemplo, em uma aplicação que precisa de uma infraestrutura de log de dados, pode-se implementar uma classe no padrão singleton. Desta forma existe apenas um objeto responsável pelo log em toda a aplicação que é acessível unicamente através da classe singleton.
Fonte: http://pt.wikipedia.org/wiki/Singleton

A maioria das classes/instâncias do ColdFusion (CFC) podem ser transformadas em um singleton, vamos ver como isso funciona na prática:

Continue reading »

Tagged with:  

Para quem deseja customizar as páginas de erros do Railo, seja ela de programação (erro 500 ) e/ou de página não encontrada (erro 400) é muito simples, basta seguir os passos:

1 – Acesse o Web Admin do Railo: http://dominio.com /railo-context/admin/web.cfm

2 – No menu da esquerda selecione a opção “Error” na seção “Settings” e depois informe o path dos arquivos conforme a imagem abaixo:

Settings error Railo

#FicaDica

Tagged with:  

Trabalhando com Custom Tags no Railo

On 16 de fevereiro de 2012, in CFML, by andersonstraube

Neste post irei mostrar com criar, configurar e usar uma Custom Tag no Railo.

Custom Tags são trechos/templates de códigos escritos em CFML e são projetados para serem reutilizados. Custom Tags podem poupar muito tempo de desenvolvimento quando os códigos são usados com certa freqüência, além de serem fáceis para adicionar/remover funcionalidades.
Custom tags também podem ser desenvolvidas em C++, Java, whatever… Neste post eu apenas mostrarei como desenvolvê-lo através de código CFML.

Mais sobre Custom Tags,  neste post  do  Pedro Claudio .

O primeiro passo é configurar o Web Admin do Railo para indicar a pasta a qual conterá suas custom tags.

1 – Acesse o Web Admin do Railo: http://dominio.com /railo-context/admin/web.cfm

Continue reading »

Tagged with:  

TDD com ColdFusion – Parte 1 (Instalação do MXUnit)

On 15 de fevereiro de 2012, in TDD, by andersonstraube

Salve pessoal.

Começarei uma série de posts sobre TDD (Test Driven Development) com ColdFusion.

Como de início não poderia ser diferente, vamos começar com a instalação do framework de teste bem como o plugin para o Eclipse.

*Existem vários frameworks para teste unitário em CFML, no entanto para os exemplos utilizarei o MXUnit por ser muito simples, prático e funcional.

Why MXUnit?
At its core, MXUnit grew around the concept of making things easier for the person writing the tests. We believe people shy away from unit testing because the perception (sometimes justified!) is that it’s too inconvenient. We sought to change that.

Instalação do Framework:

1 ) Baixe a última versão do MXUnit => (https://github.com/downloads/mxunit/mxunit/mxunit-2.1.1.zip);

2) Descompacte o conteúdo dentro do webroot (“domínio/mxunit”);

3) Teste a instalação no http://<seu_servidor>/mxunit/index.cfm. Deve aparecer uma tela semelhante à abaixo:

Instalacao MXUnit

Instalação do Plugin para Eclipse:

1) Com o Eclipse aberto, clique no menu “Help > Install New Software”;

2) Clique em Add e depois insira o Nome e Location respectivamente: mxUnit e http://mxunit.org/update (conforme imagem abaixo):

Instalação Plugin MXUnit

3) Feito isso clique em “OK” e siga o trivial “NNF” (next -> next -> finish);

Nos próximos posts pretendo explorar a parte de codificação.

Até a próxima.

Att,
Anderson Straube

Tagged with:  

Snippet – Templates de código para o CFEclipse

On 15 de fevereiro de 2012, in CFML, Desenvolvimento, by andersonstraube

Um recurso muito interessante no CFEclipse é a possibilidade de criar templates de códigos. Isso é muito útil para aqueles códigos onde você os utiliza com certa freqüência, além disso é bem interessante para criar uma padronização na sua equipe, ex.: templates para comentários (estilo javadoc, phpdoc…), templates para testes unitários, consulta ou conexão com o banco de dados, atalhos para algum framework, etc… Isso evitará que o desenvolvedor perca tempo procurando ou digitando algum código que poderia estar em um lugar de fácil acesso de maneira prática e rápida.

Bem, a propaganda já foi feita… vamos ver na prática como ela funciona:

Para utilizar este recurso é necessário ter instalado o plugin do CFEclipse, caso não saiba como instalar, veja aqui: Instalando Eclipse + CFEclipse.

1 – Abra a perspectiva do CFEclipse;

2 – Selecione “Snip Tree View”=> Window > Show View > Snip Tree View;

3 – Vamos criar uma pasta (package) para nossos snippets (vamos chamá-la de “MySnippets”):

4 – Vamos criar um novo snip (selecione a pasta que acabaste de criar e clique no botão “+”  ou com o menu de contexto);

5 – Insira os dados conforme a figura abaixo:

Snippet name: nome do snippet
Trigger text: é usado como se fosse um atalho (mais adiante você verá)
Snippet Description: descrição do snipet (aqui não pode contar acentos nem o cedilha)
Snippet starting block: é o código propriamente dito, aqui vai o código inicial do *bloco
Snippet closing block: *bloco final do código
*Bloco inicial e final do código (starting/closing) nós veremos mais adiante como utilizá-lo.

Em Snippet start block vamos inserir nosso template de código HTML (depois pressione OK):

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>
<html>
<head>
<title>$${title:Insira o titulo da pagina aqui}</title>
</head>
<body>

</body>
</html>

Onde “$${title:Insira o titulo da pagina aqui}“: significa que ao inserir esse snippet será solicitado uma caixa de diálogo (mais adiante você verá sua utilização).

6 – Pronto, nosso snippet já está criado:

Agora vamos testá-lo:

Crie um arquivo cfm (File New > CFML Page), com este arquivo aberto dê 2 cliques no nosso snippet recém-criado.

Será mostrado uma caixa de diálogo conforme a figura abaixo:

Lembra do “$${title:Insira o titulo da pagina aqui}“, pois é, ele é utilizado justamente exibir essa caixa da figura.

Legal, nosso template está funcionado

Snippet inserido no nosso código

Lembra do Trigger text?

Digite “html” no arquivo cfm e pressione “Ctrl+J“…  🙂

Experimente usar esse snippet abaixo e veja como fica a janela de diálogo:

<!———
* Function: set$${Variable Name:}
* @return $${Return Type:any|array|binary|boolean|date|guid|numeric|query|string|struct|uuid|xml|void}
———>
<cffunction name=”set$${Variable Name:}” access=”public” returntype=”void” output=”false” displayname=”set$${Variable Name:}” hint=”Seta o valor da variavel $${Variable Name:}”>

</cffunction>

 

<!———
* Function: get$${Variable Name:}
* @return $${Return Type:any|array|binary|boolean|date|guid|numeric|query|string|struct|uuid|xml|void}
———>
<cffunction name=”get$${Variable Name:}” access=”public” returntype=”$${Return Type:any|array|binary|boolean|date|guid|numeric|query|string|struct|uuid|xml|void}” output=”false” displayname=”get$${Variable Name:}” hint=”Pega o valor da variavel $${Variable Name:}.”>

</cffunction>

Já deu para ter uma noção de como criar e utilizar os snippets, agora é só usar e aproveitar os benefícios dele.

Fica aí a dica.

Um abraço.

Tagged with:  

TDD – Desenvolvimento Guiado por Testes

On 15 de fevereiro de 2012, in Desenvolvimento, by andersonstraube

Desenvolvimento Guiado por Testes (Test Driven Development), ou simplesmente TDD, consiste numa técnica de desenvolvimento de software onde primeiro são criados os testes abrangendo a melhoria desejada e/ou novas funcionalidades e somente depois é implementado o código necessário para passar por eles. A disponibilidade de testes antes do código propriamente dito garante um desenvolvimento rápido e um feedback sobre qualquer mudança. Não somente maximiza a qualidade do seu código, como também simplifica o processo de desenvolvimento além do aumento da produtividade.
O TDD é uma das práticas do XP (Extreme Programming), e foram formuladas por Kent Beck e Ron Jeffries a partir de suas experiências. O Extreme Programming (XP) é uma metodologia de desenvolvimento de software que visa criar sistemas de melhor qualidade e produzidos em menos tempo. As idéias gerais por trás do XP são simplificar o processo de desenvolvimento de software e manter um processo contínuo de desenvolvimento em um ciclo curto, ou seja, desenvolver entregáveis em períodos curtos (iterações) que forneçam um feedback constante do estado do software.  (Nos próximos post’s pretendo abordar a filosofia e algumas práticas do XP).

Vejamos como é o ciclo do TDD:

  1. Crie um teste: cada nova funcionalidade deve começar com um teste escrito. Este teste deve falhar antes mesmo da funcionalidade ser implementada. Por isso é importante conhecer claramente os requisitos e especificações da nova funcionalidade. (Isso também vale para correção de bug’s onde se deve sempre escrever os testes primeiro, para só então alterar o código propriamente dito).
  2. Execute todos os testes: você saberá que a rotina de testes está funcionando corretamente e que o novo teste não passou sem que o teste da funcionalidade tenha sido implementada.
  3. Escreva o código: escreva o código que irá passar naquele teste que você criou na etapa anterior. Não se preocupe muito com o “design” do código neste momento, é muito importante que este código implementado reflita somente o teste escrito.
  4. Execute novamente todos os testes: se todos os testes passarem, você terá certeza que o código atende todos os requisitos testados e que esta nova funcionalidade não afetou outras partes do sistema.
  5. Refatore o código: vá ajustando/otimizando o código se for necessário. Lembre-se de executar os testes constantemente durante esta etapa, pois só assim saberá se o sistema não foi modificado da maneira incorreta. Mantenha o hábito da refatoração constante em seus códigos e não tenha medo das mudanças, afinal os testes existem para isso.

TDD é um processo iterativo e você repete estes passos inúmeras vezes até que fique satisfeito com o novo código.

A maneira que o TDD trabalha é através de requisitos, ou casos de uso que são decompostos em um conjunto de comportamentos que são premissa para atender o requisito. Para cada comportamento do sistema, a primeira coisa a se fazer é escrever um teste unitário que irá testar este comportamento. O teste unitário primeiro, portanto temos um conjunto bem definido de critérios que podemos utilizar para mensurar a quantidade de código necessário que foi escrito para implementar este comportamento. Um dos benefícios de se escrever o teste primeiro é que ele ajuda a definir o comportamento do sistema de uma maneira mais clara e responder algumas perguntas do modelo.

Quando se implementa testes unitários depois do código estar pronto, você tende a implementar testes de baixa qualidade, pois você inconscientemente escreve um teste para rodar no código produzido, e o correto seria o contrário, seu código é que deveria passar no teste previamente implementado.

Os testes, quando devidamente escritos, oferecem uma certa “garantia” de que a aplicação está funcionando da maneira como deveria.

E não esqueça: “Se testar é bom, vamos testar toda hora!”.

Tagged with: