CFML e Ajax com JSON (troca de selects)

On 23 de fevereiro de 2012, in CFML, jQuery, by andersonstraube

Para este post utilizarei a clássica troca de “estado e cidade” para exemplificar o uso do jQuery para requisições ajax com CFML retornando os dados em JSON.

Segue o código html simples:

Continue reading »

Tagged with:  

ColdFusion 10 e ColdFusion Builder 2.0.1 Public Betas

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

Já está disponível para download o ColdFusion 10 e ColdFusion Builder 2.0.1 Public Beta, veja abaixo as novidades desta versão:

  • Unique HTML5 built-in support to deliver richer interfaces without prior knowledge of HTML5
  • Improved web services support using revamped engine and built-in support for REST
  • Security enhancements to protect applications with new secure profile, improved authentication and encryption.
  • Scheduler improvements to manage application-specific tasks, event handling, grouping, and chaining of tasks
  • Built-in Tomcat server replacing Adobe JRun leading to performance improvements
  • Instant notification and One-click Hotfix installer for updates
  • Object Relational Mapping to build database independent applications without writing SQL
  • Bi-directional Java integration to dynamically load libraries and invoke ColdFusion components (CFCs) from Java

Mais detalhes em -> http://labs.adobe.com/technologies/coldfusion10/

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:  

MXUnit – funções setUp() e tearDown()

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

Continuando a série de posts sobre TDD (Test Driven Development), vamos explorar os métodos “setUp()” e “tearDown()”.

Na maioria dos frameworks de testes unitários temos esses dois métodos para a configuração do nosso teste:

setUp()

Este método é utilizado no início do processo de teste, ou seja, antes de executar cada teste nós preparamos o cenário com configurações anteriores a execução de cada caso de teste.

tearDown()

Este método é utilizado no final de cada caso de teste, ou seja, ele desfaz o que o setUp() criou.

Vamos ver na prática como utilizá-los:

Continue reading »

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:  

Como alterar a URL do seu repositório SVN no TortoiseSVN

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

Se você está migrando ou precisa alterar o endereço do repositório do controle de versões (Subversion) e usa oTortoiseSVN há 2 formas para tal:

1 – Através da linha de comando:

svn switch –relocate <da URL> <para a URL>

2 – Através da interface do TortoiseSVN:

Menu contexto: TortoiseSVN → Relocate

relocate svn

Pronto.

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:  

O manifesto ágil foi assinado em 2001 pelos principais profissionais veteranos na área de desenvolvimento de softwares engajados em discutir uma nova forma para melhor a velocidade no desenvolvimento de seus sistemas baseados em suas experiências de anos programando. Embora cada envolvido tivesse suas próprias práticas e teorias preferidas, todos concordavam que, em suas experiências prévias, os projetos de sucesso tinham em comum um pequeno conjunto de princípios. Com base nisso eles criaram o manifesto para o Desenvolvimento Ágil de Software, freqüentemente chamado apenas de Manifesto Ágil.

Valores do Manifesto Ágil:

  1. Indivíduos e iterações são mais importantes que processos e ferramentas;
  2. Software funcionando é mais importante do que documentação completa e detalhada;
  3. Colaboração com o cliente é mais importante do que negociação de contratos;
  4. Adaptação a mudanças é mais importante do que seguir o plano inicial.

 

1. Indivíduos e Iterações

  • O foco tradicional é em Processos e Ferramentas;
  • Quem produz software são pessoas, indivíduos  reunidos em equipes complementares;
  • Pessoas precisam aprender a trabalhar juntas, como numa banda, é necessário praticar uma ou mais vezes para aprender a tocar juntos e a executar a musica com perfeição.

2. Software Funcionando

  • O foco tradicional é desenvolver uma  documentação detalhada;
  • A quantidade e complexidade de detalhes de requisitos, arquitetura, design e  implementação só podem ser ajustados obtendo feedback, papel não consegue dar feedback suficiente para ajustar a estratégia.

3. Colaboração com Cliente

  • Entender as necessidades de negócio e propor soluções com objetivos voltados para dar resultados de negocio;
  • Ajustar entendimento do negocio e dos requisitos que fornecem valor.

4. Responder a mudanças

  • Requisitos mudam;
  • Negócios mudam;
  • Entendimento é aprimorado e mudam;
  • Abordagens mudam.

Princípios do Manifesto Ágil:

  • Nossa mais alta prioridade é satisfazer o cliente através de entregas continuas de software que agregue valor;
  • Entregar versões funcionais em prazos curtos;
  • Medir o progresso através de software funcionando;
  • Simplicidade é essencial;
  • De tempos em tempos, o time pensa em como se tornar mais eficiente e ajusta o seu comportamento de acordo;
  • Acolhemos mudança de requisitos, inclusive tarde no desenvolvimento. Processos ágeis permitem mudanças que contribuam para a vantagem competitiva dos nossos clientes;
  • Desenvolvedores e o pessoal de Negócios devem trabalhar juntos durante todo o projeto;
  • Construa projetos ao redor de indivíduos motivados. Ofereça o ambiente e suporte que eles precisam, e confie neles para ter o trabalho feito;
  • A forma mais eficiente e eficaz de fazer saber informação para e entre uma equipe de comunicação é face a face;
  • As melhores arquiteturas, requisitos, e projetos emergem a partir de equipes auto-organizadas.

Modelos Tradicionais x Métodos Ágeis

Modelos Tradicionais Métodos Ágeis
Resistir às mudanças Abraçar as mudanças
Planejar muito bem antes Planejar o tempo todo

Principais Características dos Métodos Ágeis

  • Entregar valor;
  • Ênfase em comunicação;
  • Eliminar desperdícios;
  • Entrega freqüente de código funcionando;
  • Aproveitar as habilidades das pessoas;
  • Alta qualidade;
  • Melhorar constantemente.

Principais Métodos Ágeis

Há um livro de XP muito interessante e de fácil entendimento, cujo nome é “Extreme Programming Explained” ou “Programação Extrema (XP) Explicada” (versão em português). Este livro foi escrito por nada mais nada menos que Kent Beck, o pai do XP.

Referências e leituras recomendadas:

http://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software

http://www.improveit.com.br/

Scrum Alliance articles

Revista Visão Ágil

http://manoelpimentel.blogspot.com/

http://blog.fragmental.com.br/

http://blog.aspercom.com.br/

http://amagno.blogspot.com/