Twitter!

Maven Archetypes

Quando começamos um novo projeto, sempre criamos configurações básicas que seguem basicamente o mesmo padrão em todos os aplicativos, tais como arquivos xml de configuração de log, arquivos de configuração de acesso a banco de dados, classes de suítes de testes, etc. Ao analisarmos a estrutura de um projeto novo padrão, percebemos que o trabalho de configuração é basicamente o mesmo e que muitos dos arquivos são copiados e colados na nova aplicação.
Percebendo uma oportunidade de generalização nessa parte, o Maven disponibiliza os chamados arqchetypes.
Archetypes são basicamente templates de projetos pré-definidos, com alguns arquivos e uma estrutura inicial já definida. Veremos no post com utilizar tais archetypes, e como criar os seus próprios.

Utilizando Archetypes

Já vimos anteriormente como utilizar o Maven para criar novos projetos:





Após executar o comanda, você verá uma saída parecida com esta:





Repare que existem uma infinidade de opções de archetypes. Todas essas opções ficam descritas em um arquivo de configurações presente no repositório ao qual seu maven aponta. No meu caso utilizo o repositório padrão do Maven, mais um do JBoss e o local. Na DClick ainda existe o repositório da empresa, aonde os archetypes criados internamente são disponibilizados.
O número que o maven sugere é o projeto padrão Java, sem nenhuma outra integração. Selecione este projeto e prossiga com a criação, escolhendo o número sugerido para a versão do plugin (no meu caso 6). Dê um nome ao grupo ao qual o projeto irá pertencer: group.teste, neste exemplo, dê também um nome para o artefato: teste, escolha a versão e dê um nome ao pacote.





Neste projeto já será criado uma pasta para as classes, com o pacote que foi descrito: group.teste, e outra pasta para os testes, também com o pacote descrito. Dentro destas pastas já será criado uma classe App.java e um outra AppTest.java para os testes. Também será criado o pom da aplicação, já com a dependência do JUnit 3.8.1.
Fácil criar um pojeto padrão do zero. Tente criar projetos com os outros archetypes, como por exemplo o projeto Java Web ou até mesmo um projeto com o archetype do FlexMojos que está disponível no repositório do próprio FlexMojos.

Criando seu próprio Archetype

Ainda que existam esses templates de projetos básicos, cada empresa possui algumas configurações próprias e utilizam alguns frameworks internos em todos os projetos. Sabendo disso, o Maven disponibiliza maneiras de criar seu próprio archetype.
Uma dessas maneiras é utilizar o próprio Maven para criar um projeto utilizando o archetype de projetos de archetype. Confuso? Mas é bem tranquilo. Nada mais é do que um projeto Maven que contém a descrição do template de criação do projeto que será criado utilizando esse archetype próprio.
Este projeto consiste de um pom com as dependências para o plugin de archetypes, um arquivo de configuração para o plugin contendo informações de arquivos e pastas que serão adicionados ao template e os arquivos propriamente ditos. O arquivo de configuração do plugin encontra-se em src/main/resources/META-INF/maven/archetype-metadata.xml. Sua estrutura é bem simples e de fácil leitura, contendo nomes das pastas que serão criadas com seus respectivos tipos, e uma lista com adições e exclusões de arquivos na pasta. Os arquivos utilizados no archetype ficam em src/main/resources/archetype-resources/.
Fato importante é que archetypes do Maven se comportam como qualquer outro projeto Maven, possuindo versão, grupo, nome e está disponível no repositório. É importante notar isso, pois a versão do archetype que está sendo utilizado pode alterar completamente o tipo de projeto que está sendo criado, mudando versões de dependências ou até mesmo organização das pastas.

Utilizando um Projeto já Existente

Uma segunda maneira de criar um archetype, é utilizar um projeto já existente. Pode não ser muito recomendável para projetos que já estejam muito avançados, mas para projetos recém criados se aplica perfeitamente.
A idéia é simples, basta criar um projeto básico com as configurações e a organização necessária, e utilizar o plugin de archetypes para criar o archetype:





O comando mvn archetype:create-from-project irá criar um projeto de archetype com o metadata descrevendo todos os arquivos existentes no projeto utilizado como parte do template em suas respectivas pastas. O projeto inteiro será adicionado aos resources do archetype e portanto podem ser modificados posteriormente.
Essa é a maneira mais fácil e rapida de se criar um archetype, mas devem ser tomados alguns cuidados. Por exemplo, as pastas do projeto de origem são mantidas no projeto que será criado usando o archetype, portanto será ignorado o pacote definido na criação. Pastas ou pacotes vazios no projeto de origem também serão ignorados e não farã parte do projeto criado utilizando o archetype.
Precauções a parte, venho utilizando archetypes do Maven praticamente em toda minha carreira com a ferramenta, e posso afirmar que nesses anos os archetypes me salvaram muito tempo e muita pesquisa no google. Recomendo o test drive com o plugin, mas já adianto que ainda existem alguns bugs e o archetype talvez não ficará perfeito com os padrões que você esteja esperando, mas ainda assim cerca de 90% do novo projeto estará configurado com apenas uma linha de comando.

Por @Gust4v0_H4xx0r

Twitter!

Maven – O que muda?

Vimos alguns tutoriais e posts que descreviam o funcionamento do maven, e tabmbém criamos alguns projetos com seus respectivos relatórios. Porém sempre utilizamos uma versão do Maven 2. Atualmente está disponível (não mais como beta) a versão 3 da ferramenta. Mas afinal, o que muda e como que sua aplicação construída utilizando Maven 2 irá se comportar com o Maven 3? Veremos!

Primeiras mudanças

A primeira coisa a se notar de diferente é a saída no terminal de comando gerada pelo Maven 3. Veja a saída em um projeto padrão maven criado para o exemplo:





Note que a divisão entre projetos está mais clara e que cada goal está explicitamente descrito com seus respectivos plugins, tornando mais fácil identificar possíveis problemas. Por exemplo vejamos o que forçarmos um erro no build:





Repare que ao executar o plugin maven-compiler-plugin do Maven na fase de compile ocorreu um erro que está descrito logo abaixo. Note também que agora o Maven sugere uma URL da documentação onde você pode encontar ajuda sobre a falha.
Caso mais de um erro tivesse ocorrido, seria descrito em ordem de ocorrência e se fosse possível sugerir ajuda, estariam descritas as URLs de ajuda.


Essa é a primeira mudança mais notável. Uma segunda mudança pode ser percebida também, mas é mais sutil: performance. A Apache diz que o Maven é muito mais performático que suas versões anteriores em muitos aspectos.
Eu trabalho com Maven a um bom tempo já e posso dizer por experência que sim, o Maven 3 é de fato mais rápido mas não o suficiente para impressionar e de fato afetar o dia-a-dia. Está mais rápido identificar alguns problemas que podem acontecer durante o build, isso sim eu acho que afeta mais no dia-a-dia.
Quanto aos downloads de artefatos, está melhor que nas versão anteriores, pois o download em paralelo está melhor implementado e portanto a banda é melhor gerenciado. Essa mudança também afeta no dia-a-dia de uma maneira positiva.
Outra melhoria de performance é com relação aos plugins externos. A Apache diz que a API de uso do Maven para plugins externos está muito melhorada, e que a integração está bem mais otimizada. Aqui na empresa utilizo bastante a integração com o plugin do Flex para o Maven (FlexMojos), e posso dizer que nesse ponto a mudança foi drástica. O build está de fato muito mais rápido que nas versão anteriores do maven e melhorou bastante no dia-a-dia do desenvolvimento.

Organização

A validação dos poms do projeto está mais bem estruturada e descrita pela ferramenta. Por exemplo, caso você repita uma dependência em um de seus poms, o build não será afetado, mas o Maven irá lhe alertar dos possíveis problemas:





Repare que é informada exatamente a posição do erro no pom do projeto e o que pode acontecer caso a inconsistência permaneça. Outro ponto para a versão nova da ferramenta. Muitos dos projetos que rodei o Maven 3 e estavam sobre o controle do Maven 2 apresentaram algum tipo de inconsistência que poderia interferir no controle de versões dos artefatos e até mesmo no funcionamento da aplicação.


Outra mudança na organização, é o controle do parent pom. Era comum criar projetos auxiliares aos projetos principais para guardar o pom que serviria de parent para os demais poms da aplicação. Era criado tal projeto para poder importá-lo no Eclipse como se fosse um projeto como qualquer outro. Dessa forma, o pom do projeto que agregava todos os sub-projetos servia apenas como descritor dos módulos presentes sendo que este também herdava do pom parent em um de seus sub-projetos. Temos um erro de consistência nesse caso, pois era necessário realizar o install deste sub-projeto antes de todos os outros, e no build com todos os projetos portanto, a versão do parent pom era sempre uma anterior a que está sendo instalada.
Na versão nova da ferramenta tal organização é ainda tolerada, mas é lançado um aviso de que existe tal inconsistência, e de que possivelmente as próximas versões do Maven não irão mais suportá-la. O único problema com essa organização é não poder importar o projeto no Eclipse de maneira simples, pois o projeto pai trará todos os filhos como sub-pastas do mesmo, mas é de fato melhor em termos de organização e facilita na manutenção do parent pom.


Muitas outras validações são feitas nos poms do projeto que são muito úteis para manutenção e controle das versões das bibliotecas da aplicação.

Reporting

Reporting no Maven 2 possui sua própria tag no xml do pom do projeto. No Maven 3 tal tag é ignorada e portanto seus projetos devem ser refatorados para que os relatórios ainda funcionem. Isso acontece porque agora o módulo de relatórios do maven está completamente independente da ferramenta, e portanto deve ser executado por um plugin. Portanto a descrição dos relatórios deve ser feita na tag de build do pom na parte de plugins.
A configuração mudou um pouco, pois agora os tipos de relatórios são descritos como configuração do plugin de geração de relatórios do maven, por exemplo um pom compatível com a versão 3 do Maven:

Nesta configuração estou gerando uma série de relatórios de cobertura e análise de código, assim como alguns de documentação também. Repare que é necessário utilizar o maven-project-info-reports-plugin, isso porque o site gerado pelo maven por padrão não gera um index.html que serve de agregador dos demais relatórios, por isso este plugin está presente na configuração.

Conclusão

Em conclusão o Maven 3 é mais um passo bem grande na evolução da ferramente que tem como objetivo tornar mais intuitivo o uso e menos intrusivo no dia-a-dia do desenvolvedor.
A integração com plugins externos está muito melhorada, o que acredit que possibilitará muitas outras integrações com diversas outras tecnologias em um mesmo projeto, facilitando muito o controle de versões e a manutenção dos projetos.
A parte de relatórios fiquei um pouco decepcionado com a mudança, pois a documentação ainda não deixa claro exatamente o que foi alterado e o que deixou de fazer parte da execução padrão, tive que chegar nessa configuração por tentativa e erro e buscando na internet por pessoas que passaram pelos mesmo problemas. O resultado obtido é exatamente o mesmo, exceto por um bug que não gera o site do pom parent linkando todos os seus filhos em uma mesma página. Este sim é um problema que afeta no dia-a-dia, principalmente se você executa o build de maneira contínua, gerando os relatórios para deixá-los disponíveis na empresa.
De resto acredito que o Maven ainda tem muito a oferecer, e existem outras melhorias as quais não abordei aqui no post, mas que assim que passar por elas irei postando aqui no blog.

Por @Gust4v0_H4xx0r

Neste post vou explicar como usar a API de Log para mostrar os logs de execução da aplicação e também como usar o componente TraceTarget, que é muito útil para poder recuperar as informações das chamadas para o servidor, facilitando a resolução de problemas.

No Flex temos duas opções para recuperar informações ou logs de execução de uma aplicação. Uma primeira maneira e a mais utilizada, é usar a função global trace(”) para mostrar informações no console do FlashBuilder. Essa abordagem sempre requer que a aplicação esteja sendo executada em modo de debug, o que exige a instalação de um FlashPlayer versão de debug. Lógico que para o ambiente de desenvolvimento isso não é um problema, já que a instalação do FlashBuilder já inclui a versão correta do FlashPlayer versão debug. Mais e quando a aplicação está em produção, ou seja, quando não contamos com a versão de debug do FlashPlayer? Ai que entra a segunda opção.Na segunda opção vamos usar a API de Logging do Flex, que vai nos permitir delegar para uma classe a função de logar informações, seja usando o trace(”), primeira abordagem, ou até mesmo customizando a forma de apresentação. Esta abordagem também nos permite controlar o que é exibido, utilizado categorias e nível de log.

A API de Logging do Flex é muito simples de ser usada. Toda vez que queremos usa-la, estaremos envolvendo duas partes:

1. O Logger, que possui os meios para enviar informações em diversos níveis (all, debug, info, warn, error e fatal) em uma determinada categoria para o Log Target. O Logger sempre irá implementar a interface ILogger, iremos utilizar a classe mx.logging.LogLogger, que já vem no SDK;
2. O Log Traget, que será responsável por registrar a informação usando o trace(”) ou outra implementação. Iremos utilizar a classe mx.logging.targets.TraceTarget.

Para ficar mais fácil de entender como usar a API, vamos imaginar que queremos logar quando a aplicação é pré-inicializado, inicializado e criado.Inicialmente iremos usar a função global trace(”) e depois usar as classes de Log.

Ler o resto…

Durante o ando de 2010 diversos leitores me escreveram solicitando alguma forma de “receita de bolo” para a criação de projetos em Flex. Estavam buscando uma maneira de criar uma aplicação de forma que fosse mais correta e mais fácil, baseada em padrões de projeto e definida através de uma estrutura que facilitasse o desenvolvimento.

No início de 2011 comecei a pensar mais no assunto, pois irei implementar estas regras nos próximos livros, chegando a uma série de “regras” das quais estarei apresentando neste artigo. Inicialmente, queria dizer que eu não sou o dono da verdade, e estou longe de criar alguma regra que se não usada irá causar o seu insucesso. Estou disposto a receber críticas que sejam construtivas, com o intuito de melhorar o sistema cada vez mais, possibilitando assim que a comunidade tenha em mãos um bom documento para consulta.

PHP ou Java?

Uma das perguntas que mais recebi ao longo de 2010, por isso estarei discutindo um pouco sobre qual linguagem de servidor usar. Inicialmente você deve saber que não é a linguagem que vai fazer você ter sucesso ou não em um sistema, e sim o quanto você conhece a mesma. Por exemplo, se você conhece muito bem PHP, porque aventurar-se em Java se dá conta do recado? O mesmo vale para o Java, mas não recebi emails de nenhum programador Java querendo mudar para php… (sic.. hehe).

O que? é fato nesta “briguinha” é que, não existe melhor ou pior. Java é mais complexo que php, exige mais atenção mas traz muitos benefícios, até financeiros (sim você ganha mais). PHP é mais fácil, você cria tudo mais rápido e com isso fica mais feliz Qual você vai escolher? Escolha a que te faz mais feliz.

Zend_AMF ou AMFPHP ?

Outra dúvida muito comum entre os programadores PHP. Eu costumo selecionar um ou outro dependendo do projeto em sí. Se o seu projeto vai usar alguns recursos do Zend Framework, e são muitos, utilize o Zend_AMF. Caso contrário, use AMFPHP.? Aqui chegamos a um impasse do qual julgo ser mais importante do que a briga entre Zend e AMFPHP: você ainda pensa em criar um projeto sem o Zend Framework? Você irá criar tudo que precisa “na mão” ou vai usar componentes de terceiros? Falo isso porque se um projeto em PHP é iniciado, o uso do Zend Framework irá acelerar muito o processo do mesmo. Rotinas como enviar email, acessar a sessão do php, gerenciar usuários com ACL, persistência de dados, acesso ao twitter… são todos muito bem implementados com o Zend e o Zend Framework é mantido pela mesma empresa que mantém o PHP, então não existe biblioteca mais segura em termos de continuidade do que esta.

E quais tecnologias vamos usar nas “melhores práticas” ?

Agora que discutimos as duas perguntas mais perguntadas em 2010 vamos a esta solução que julgo, pessoalmente, ser muito boa:

No cliente:

• Adobe Flash Burrito e Flex SDK 4.5 (Basta baixar e instalar o Flash Burrito: http://labs.adobe.com/technologies/flashbuilder_burrito/).
• SWIZ Framework (http://swizframework.org/)

No servidor:

• PHP
• Zend Framework (http://www.zend.com/community/downloads)
• WAMP Server (para rodar o PHP na própria máquina – http://www.wampserver.com/en/download.php)
• Netbeans ou Eclipse PDT – Eu estou gostando mais do Netbeans, então vou usá-lo.? (http://netbeans.org/downloads/index.html? – Versão PHP)

?

Certifique-se de ter tudo instalado, para que possamos dar prosseguimento no artigo.

Estrutura de pastas e projetos

Outra dúvida comum dos usuários, é definir a estrutura de pastas do projeto. Como instalamos o WAMP Server, ele nos fornece uma pasta onde é possível ter acesso pelo nacegador, através do endereço “localhost”. Isto é, ao acessarmos http://localhost/ o WAMP Server cuida de apontar para o diretório c:wampwww (que é o que chamamos de “document root”). Para que possamos entender a estrutura do projeto, é necessário compreender uma particularidade do Flex. Diferentemente do PHP, os arquivos que estão dentro do projeto Flex não precisam ser enviados ao servidor (os arquivos mxml, as, etc). veja que o Flex compila todos os mxml/as do projeto e gera um único arquivo swf. Este arquivo sim DEVE estar no diretório web do projeto!

Vamos então criar o projeto “melhoresPraticas” da seguinte forma:

1. Crie a pasta c:wampwwwmelhoresPraticas Este é o diretório público do projeto, acessado através de http://localhost/melhoresPraticas?????????
2. Crie a pasta c:wampwwwmelhoresPraticasclasses Este é o diretório onde iremos criar as nossas classes PHP
3. Crie a pasta c:wampwwwmelhoresPraticasvos Este é o diretório onde as classes VOs serão criadas
4. Crie a pasta c:wampwwwmelhoresPraticasZend Aqui você copia/cola o Zend framework, de forma que o arquivo melhoresPraticasZendLoader.php esteja acessível
5. No Flash Builder, crie o projeto “melhoresPraticas”. Você pode deixar o DefaultLocation como está. Não clique em Finish, clique em Next, até chegar na configuração do “Compiled Flex application location”. Ou seja, aqui você irá informar para onde os aquivos compilados do flex irão ficar. Coloque o seguinte caminho: c:wampwwwmelhoresPraticasbin-debug. Não clique em Finish, clique em Next, e em Library Path, adicione a biblioteca swiz (o arquivo swc). Em “Output folder URL”, coloque: http://localhost/melhoresPraticas/bin-debug
6. Com o projeto pronto, clique no botão RUN. Deve então surgir uma página em branco no endereço: http://localhost/melhoresPraticas/bin-debug/melhoresPraticas.html
7. No Netbenas ou no eclipse, crie o projeto php apontando para c:wampwwwmelhoresPraticas

Testando a conexão

Com os projetos prontos, iremos inicialmente realizar uma simples conexão entre o Flex e o PHP. Isso é útil para que possamos começar com trabalho “pesado”. Para conectarmos o Flex no PHP, preciamos criar uma classe de conexão no Flex, que iremos chamar de ServiceBase, e um arquivo que recebe esta conexão no PHP, que chamaremos de gateway.php.

Para criar a classe ServiceBase, use o Flash Builder e acione o menu File > New > ActionScript Class e crie a classe de acordo com a imagem a seguir:

Classe ServiceBase:

package services
{
??? import mx.controls.Alert;
??? import mx.rpc.events.FaultEvent;
??? import mx.rpc.remoting.RemoteObject;
???
??? public dynamic class ServiceBase extends RemoteObject
??? {
??????? public function ServiceBase(classe:String)
??????? {
??????????? super(“zend”);
???????????
??????????? /*
???????????? * Como o arquivo swf está na pasta bin-debug,?
???????????? * precisamos subir um nível para chegarmos ao
???????????? * arquivo gateway.php
???????????? */
??????????? this.endpoint = “../gateway.php”;
???????????
??????????? this.source = classe;
??????????? this.addEventListener(FaultEvent.FAULT,OnFault);
??????? }
???????
??????? protected function OnFault(e:FaultEvent):void
??????? {
??????????? Alert.show(e.fault.faultString,”Erro” );
??????? }
??? }
}

Esta classe tem como principal objetivo estabelecer o endpoint, que é o gateway.php que ainda vamos criar. O atributo source define qual a classe que iremos acessar na pasta classes. Também adicionamos um listener genérico caso haja alguma falha na conexão. Veja que a classe é dinâmica (dynamic), ou seja, podemos chamar métodos da classe sem que eles estejam implementados na classe. Isso é útil pois os métodos chamados nesta classe serão os métodos remotos do PHP.

No servidor, temos que criar o arquivo gateway.php, com o seguinte código:

//Adiciona o autoloader do Zend Framework
// Assim todas as classes do framework
//? serão carregadas quando precisarem
require_once “Zend/Loader/Autoloader.php”;
Zend_Loader_Autoloader::getInstance()->setFallbackAutoloader(true);

//Instancia o servidor Zend_AMF
$server = new Zend_Amf_Server();

//Habilita o modo de desenvolvimento, retornando
// mensagens de erro. Comente esta linha quando
//?? estiver em modo de produção
$server->setProduction(false);

//Adiciona este diretorio como um diretorio de
// classes que podem ser usadas pelo Flex
$server->addDirectory(dirname(__FILE__).”/classes”);
set_include_path(dirname(__FILE__).”/vos”);

//TODO: Adicionar VOs

//Dependendo da requisição do Flex, irá
// chamar a classe correspondente, respondendo
//?? em formato AMF o que a classe responder.
echo $server->handle();

//Não fechar a tag PHP, nunca !!

?

O arquivo gateway.php é o ponto de entrada para as classes em PHP. Veja que inicialmente fazemos um include do Autoloader.php para que todas as classes do Zend Framework sejam instanciadas sem a necessidade de realizar requeires. Criamos então a instância do Zend_AMF_Server, que irá cuidar para que o flex consiga conversar com o PHP via AMF. Adicionamos o diretório classes como um diretório do AMF, onde as classes serão expostas ao flex e usamos o set_include_path para adicionar as classes que estão na pasta “vos” no path global do php, para que não precisamos fazer include das mesmas. Depois adicionaremos mais código sobre as classes VOs.

Na pasta “classes”, criamos a classe Teste, e o método sayHelloWorld. O nome do arquivo tem que ser o mesmo nome da classe, ou seja, Teste.php.

class Teste {
??? public function sayHelloWorld($name)
??? {
??????? return “Hello World $name”;
??? }
}

//Não feche a tag PHP!

?

Agora voltaremos ao Flex para que ele possa acessar a classe teste. No arquivo melhoresPraticas.mxml, adicionamos o seguinte código:

?

http://ns.adobe.com/mxml/2009″
?????????????? xmlns:s=”library://ns.adobe.com/flex/spark”
?????????????? xmlns:mx=”library://ns.adobe.com/flex/mx” minWidth=”955″ minHeight=”600″>
???
??????? ??????????? import mx.controls.Alert;
??????????? import mx.rpc.events.ResultEvent;
???????????
??????????? import org.swizframework.utils.services.ServiceHelper;
???????????
??????????? import services.ServiceBase;
??????? ]]>
???
???
???
??????? ???????????
??????????? var testeService:ServiceBase = new ServiceBase(“Teste”);
??????????? var serviceHelper:ServiceHelper = new ServiceHelper();
???????
??????? serviceHelper.executeServiceCall(
??????????? testeService.sayHelloWorld(“Daniel”),
??????????? function(e:ResultEvent):void{
??????????????? Alert.show(e.result.toString());
??????????? });
???????
??????? ]]>
???
???

?

Como estamos realizando um teste, fazemos o acesso ao PHP no evento creationComplete da aplicação. Criamos a variável testeService que é do tipo ServiceBase, repassando o parâmetro que é o nome da classe no PHP, ou seja, “Teste”. Também criamos a variável serviceHelper que pertence ao Swiz e é um facilitador de acessos ao PHP. Usamos no serviceHelper? o método executeServiceCall, que irá chamar remotamente o método sayHelloWorld repassando o parâmetro “Daniel” e quando concluído, executará a função que está no segundo parâmetro, realizando um Alert.

Ao executar esta aplicação, quando é carregada surgirá a mensagem de retorno do PHP:

?

Criando as classes em Service

Com o teste de conexão realizado, podemos avançar mais no código! A primeira refatoração que faremos é em relação as classes que estão na pasta service. Até agora criamos o seguinte código:

??? var testeService:ServiceBase = new ServiceBase(“Teste”);

Ao invés de criar a instância de ServiceBase repassando uma string que é o nome da classe, iremos criar a classe TesteService, da seguinte forma:

package services
{
??? public dynamic class TesteService extends ServiceBase
??? {
??????? public function TesteService()
??????? {
??????????? super(“Teste”);
??????? }
??? }
}

Veja que, ao criarmos a classe TesteService, podemos alterar o código da aplicação principal da seguinte forma:

var testeService:TesteService = new TesteService();

Implementando o SWIZ

Um dos melhores benefícios que o SWIZ traz é a possibilidade de separar todo o código Flex em camadas, assim como é feito no padrão MVC. Se você ainda não conhece SWIZ, é melhor conhecer, pois se está lendo este artigo está procurando criar aplicações com uma qualidade melhor e não há como chegar a esse nível sem um framework. O Swiz é o o melhor em termos de custo/benefício, porque nao é o mais fácil de aprender nem o mais complicado, e nao é o mais simples e nem o mais completo. É o meio termo em tudo.

Para usarmos o SWIZ, preciamos estabelecer algumas pastas dentro do projeto Flex, que serão nossas camadas. São elas:

• config: contém os arquivos que chamamos de “bean”, que são os arquivos que fornecem informações para serem injetadas em outras classes
• controllers: contém os arquivos que “ditam” a dinamica da camada de visualização
• services: contém os arquivos que fazem o acesso ao PHP
• events: contém eventos que podem ser disparados e mediados pelo flex
• valueObjects: são os VOs que iremos usar na aplicação
• views: contém os formúlários, é a camada de visão

Na pasta config, iremos criar o arquivo Bean.mxml, com o seguinte código:

??? xmlns:fx=”http://ns.adobe.com/mxml/2009″
??? xmlns:s=”library://ns.adobe.com/flex/spark”
??? xmlns:swiz=”http://swiz.swizframework.org”
??? xmlns:services=”services.*”
??? >
???
???
???

?

Neste bean, criamos a variável “testeService”, que é o tipo TesteService. Atenção quando ao uso de letras maiúsculas e minúsculas.? Sempre voltaremos no Bean.mxml para adicionar mais variáveis e com isso, injetá-las nos formulários e controllers da aplicação. Precisamos ainda configurar o Swiz no projeto principal da aplicação (melhoresPraticas.mxml):

http://ns.adobe.com/mxml/2009″
?????????????? xmlns:s=”library://ns.adobe.com/flex/spark”
?????????????? xmlns:mx=”library://ns.adobe.com/flex/mx”
?????????????? xmlns:swiz=”http://swiz.swizframework.org”
?????????????? minWidth=”955″ minHeight=”600″ xmlns:config=”config.*”>
???
???
???????
???????????
???????????????
???????????
???????????
???????????
??????????????? ??????????????????? eventPackages=”events.*”
??????????????????? viewPackages=”views.*”
??????????????????? />
???????????
???????????
???????????
???????????????
???????????
???????????
???????
???

???

?

Esta configuração, adicionada dentro do fx:Declarations, realiza uma configuração padrão no SWIZ. Basicamente adicionamos o Bean que criamos e definimos onde as classes relacionadas a eventos e formulários ficarão. Também definimos um LOG que será apresentado na aba Console do Flex se estiver rodando em modo de Debug.

Após a configuração

Podemos por exemplo criar a tela de login, e outras telas do sistema. Deixarei o código fonte da aplicação para que você possa olhar com calma.

Pegue o código fonte aqui

Conclusão

A lista a seguir é um resumo de melhores práticas que julgo importantes

• Use módulos/sub applications somente se precisar mesmo. Não comece um projeto de 10 telas querendo usar módulos para cada tela.
• Separe sua aplicação em camadas. Você escreve mais e cria mais artigos, mas o projeto fica mais consistente.
• Você não precisa criar o arquivo services-config.xml para conectar sua app no servidor. Pode-se criar uma classe cujo o endpoint é um caminho RELATIVO ao gateway.
• Use o caminho RELATIVO sempre, para faclitar o deploy da sua app. Isto é, use “../gateway.php” ao invés de “http://localhost/gateway.php”.
• Injete o controller na view, para passar dados à ela. Se deseja enviar mensagens para a view, então use eventos
• Não injete a view no controller.
• Use o dispatcher do SWIZ.
• Use o serviceHelper do SWIZ.
• Quando criar um formulário na view, faça o databind com uma variável do controller.
• Use eventos com moderação. Particularmente eu uso os eventos para notificar a view de alguma mudança, nunca para passar dados, que é função do controller.
• Se você quer chamar um método da view pelo controller, use eventos.
• Mais?

BDD – Behavior Driven Development

BDD está ficando mais conhecido ultimamente e muitas pessoas estão adotando a prática no dia a dia de desenvolvimento. Mesmo assim BDD é tão antigo quanto o próprio TDD (Test Driven Development).
BDD nada mais é do que trazer ao código, e principalmente ao código que testa os casos de uso da aplicação, um pouco mais da lógica de negócio e do problema que está sendo resolvido no nível do usuário.

Melhorando a comunicação

Quando escrevemos algum teste unitário, normalmente damos um nome ao teste para que possamos entender os resultados quando gerarmos um relatório após a execução dos mesmos. Também damos nomes que façam sentido, para facilitar a comunicação da equipe de desenvolvimento, pois se outra pessoa da equipe precisar dar manutenção no teste, torna mais fácil a compreensão do que o teste está encarregado de testar sem que seja necessário ler muitas linhas de código.


Nos tempos atuais falamos bastante de aumentar a integração da equipe com o cliente ou a área que entende do negócio da aplicação. Também falamos em uma maior colaboração de ambas as partes no desenvolvimento de software. Para quebrar essa barreira que existe entre desenvolvimento e análise, algumas equipes empregam uma programação mais voltada a resolver os casos de uso propostos, ao invés de resolver problemas de baixo nível e compor uma aplicação final.


BDD prega que o problema que será resolvido deve estar bem claro para a parte quem entende do negócio (chamarei de cliente, mesmo que algumas vezes não seja necessariamente um cliente), e quem desenvolve a aplicação em si. Para isso são escritos casos de testes baseados nos casos de uso do sistema, e tais casos de teste usam uma linguagem comum para ambas as partes.


Como normalmente o cliente não é técnico, fica muito difícil se comunicar com ele via testes unitários em código, e fica mais difícil ainda que o cliente colabore com a melhoria e a escrita de tais testes. Porém, os testes unitários e automatizados são a melhor ferramenta do desenvolvedor para testar a aplicação e garantir que a equipe mantenha o código funcionando.


Para suportar ambas as necessidades, e implantar o BDD de fato, uma das soluções é associar o problema de cada caso de uso, a um teste unitário que irá se certificar que aquele caso de uso está sendo corretamente executado.


Por exemplo, em java podemos dar nomes a nossas classes de teste de acordo com o caso de uso que aquele teste se refere. E podemos também nomear os métodos como a execução específica daquele caso de uso:

Dessa forma quando o cliente ver o resultado dos testes e perceber que este teste falhou, ao invés de ler algo como “O serviço de usuário voltou null.”, ele conseguirá ler “No teste de cadastro de usuário, ao testar que um usuário novo está sendo cadastrado, o teste falhou pois o usuário não possui um nome válido, logo não foi cadastrado.”


Parece pouca coisa, mas para o cliente é um informação muito importante nas discussões sobre prioridade de correção de bugs e melhorias do sistema. Isso porque fica claro para o cliente quando o desenvolvedor descreve o teste exato que falhou e o cliente sabe exatamente a qual caso de teste se refere e qual o problema que está sendo resolvido. Não é informação pertinente ao cliente como que tecnicamente se corrige o problema e como que o sistema está implementado para que o erro ocorre-se, esse é o papel do desenvolvedor.

Simples e Efetivo, mas não é a Silver Bullet

Existem muitos frameworks para facilitar a empregação do BDD. Vimos aqui que mais do que um framework, BDD é uma cultura e pode ser empregado sem o uso de qualquer ferramenta, pois o importante é manter a comunicação entre os níveis técnicos diferente na mesma equipe.


Muitos correm atrás da implantação do BDD nos projetos com a esperança de que os problemas na resolução de bugs e na comunicação da equipe serão resolvidos. Isso não é verdade e seu projeto irá dar tão certo quanto ele daria antes da adoção de BDD. BDD é um mudança de comportamento na equipe onde todos devem estar empenhados na causa de melhorar a comunicação, e tentar entender os problemas de verdade que o sistema se propõe a resolver.


A mudança de comportamento tem que partir do lado do cliente também, pois é necessário a compreensão de que os erros que estão claros para ele agora, não surgiram do nada. Na verdade eles sempre estiveram presentes no sistema, só que protegidos pela barreira que impedia a comunicação entre de desenvolvimento e análise.


Espero ter sido claro, qualquer opinião sobre o assunto será bem vinda.


Por @Gust4v0_H4xx0r

Ontem a Adobe lançou a última versão do Adobe Flash Player, a 10.2, essa versão recebeu atenção especial com relação a exibição de conteudo de video (com a nova classe StageVideo), visando melhorar a performance e diminuir o consumo de CPU. Foram lançadas as versões para Mac, Windows e Linux.
Entre outras novidades temos a opção de usar fullscreen em multiplas tela e também a possibilidade de usar cursores personalizados.
Atualize seu Flash Player e acompanhe o resto das novidades diretamente do blog dos produtores do Flash Player.
E para quem é desenvolvedor, segue o link das versões debugger do Flash Player 10.2 http://www.adobe.com/support/flashplayer/downloads.html

A dica Flex de hoje é a respeito de um objeto muito utilizado quando trafegamos dados entre o Flex e o back-end da nossa aplicação. Estamos falando dos Value Objects, também chamados de Data Transfer Objects (DTOs) ou apenas Transfer Objects, que têm como principal função o armazenamento de dados e que, ao contrário de outros componentes, estão livres de qualquer lógica de negócio. Os Value Objects são implementados como classes ActionScript.

Vamos supor que estamos desenvolvendo em nossa aplicação uma tela onde deveremos listar todos os usuários do sistema. Ao chamar um serviço no back-end recebemos a lista de usuários, sendo que cada um dos elementos dessa lista é representada por um Value Object como mostramos abaixo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
package vo

{

    [Bindable]

    public class UsuarioVO

    {

        public var nome:String;

        public var email:String;

        public var senha:String;



        public function UsuarioVO()

        {

        }



    }

}

Repare que no trecho de código acima criamos um package chamado “vo” e dentro deles criamos uma classe ActionScript chamada “UsuarioVO.as”. Repare que a tag “Bindable” é utilizada antes da definição da classe, justamente porque queremos garantir que todos os atributos do nosso Value Object possam utilizar o data binding, ou seja, que suas alterações possam ser monitoradas por componentes do Flex. Lembrando que também poderíamos definir o data binding individualmente para cada atributo dessa classe ao invés de definir para a classe toda.

Uma outra dica interessante é definir o método toString() nas nossas classes, dessa forma toda vez que você utilizar seus Value Objects em lugares que o Flex precisa mostrar uma String, esse método será invocado automaticamente pelo Flash Player. Essa dica pode auxiliar nos traces e debugs da sua aplicação.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
package vo

{

    [Bindable]

    public class UsuarioVO

    {

        public var nome:String;

        public var email:String;

        public var senha:String;



        public function UsuarioVO()

        {

        }



        public function toString():String

        {

            return "Usuário: " + this.nome;

        }



    }

}

Espero que tenham gostado e até a próxima!

Este artigo visa explicar a User Interface do Android, voltado principalmente para o design, portanto vamos abordar aqui a documentação do Android que trata desse assunto.

Em pesquisa intensa pela internet percebi que poucos abordam as especificações do Android para fazer a aplicação de uma skin, a discussão está mais voltada a desenvolvedores, otimização, xml etc, quase nada trata de fontes, ou padrões visuais. Então muitos designers se perguntam como fazer uma skin para uma app Android, já que não é somente abrir o Photoshop ou outro software gráfico e começar a desenhar.

Eu vou tratar aqui exatamente desse tema, não só deixando a mão as fontes (TTF) para você, mas como toda pesquisa que for feita sobre o assunto, haverá PSDs para baixar, ícones e muito mais, material para você começar a produzir sem qualquer complicação. Portanto deixe esse link nos seus favoritos pois ele será atualizado semana a semana, conforme eu for criando novos posts eu vou inserir o link dos temas nesse artigo, assim ele será um guia para você encontrar o que deseja.

Estarei postando aqui a UI Guidelines e comentando-a onde for pertinente, e alguns desenvolvedores poderão fazer uso já que estará tudo mastigado e com isso quem quiser se aventurar em criar algumas skins para suas apps não terão tantos problemas, mesmo assim aconselho, contrate um bom designer, pois ele saberá discutir não só como fazer uma skin, mas como criar um visual atraente e funcional, discutindo inclusive seu wireframe.

Vamos começar entendendo o que é a UI Guidelines, ela é separada na plataforma Android por:

.

Icon Design (design dos ícones)
.

.

App Widget Design (componentes da interface da app)

.

• Padrão anatômica de um widget
• Projetando um widget
• Padrão de tamanho de um Widget
• Padrão de frames de um Widget
• Padrão de sombras de um Widget
• Widget – dicas e truques gráficos
• Widget – formato de arquivo gráfico

.

Activity and Task Design (atividades e tarefas, ou seja, os comportamentos)

.

• Entendendo de forma geral as tarefas
• Dicas de design

.

Menu Design (todo o comportamento do menu)

.

• Opções do Menu
• Contexto do Menu e atalhos

.

Talvez você se pergunte porque é necessário saber isso e não apenas pegar um PSD Guideline e começar a criar. A resposta é bem simples, se você quer criar um app que realmente as pessoas vão usar você deve respeitar e entender esses padrões, saber dos recursos que são suportados por essa plataforma e suas limitações.

Afinal por ser um sistema aberto, qualquer um pode subir uma aplicação na AndroidMarket, por mais bugada que seja, porém o que vai definir o sucesso da sua app será os cuidados que tiver em respeitar a Guideline, o seu conceito, e o seu design.

FONTES

Droid Serif

Droid-Sans

Droid-Sans-Mono

_________________________________________

Eduardo Horvath é UX Specialist e Designer na DClick.
Formado pela Faculdade Impacta de Tecnologia no curso Design de Mídia Digital ele atua na área de Design a mais de 15 anos.
@eduardohorvath

Twitter!

Aprendendo Scala

Estou começando uma série de posts sobre Scala para divulgar as minhas experências com a linguagem e suas aplicações. Vou tentar passar o funcionamento da linguagem e seus recursos, assim como também um pouco do paradigma de programação funcional, e tentar chegar em aplicações práticas no ambiente de desenvolvimento.

Existem alguns tutoriais disponíveis na internet bem interessantes mas que as vezes jogam muito conteúdo sem dar tempo para assimilar os conceitos. Nessa série de posts tentarei colocar os conceitos e ferramentas de Scala e linguagens funcionais de uma maneira natural, conforme eu mesmo for evoluindo na linguagem e também dando exemplos e exercícios para que você possa assimilar o que está sendo passado. Vou tentar explicar também conceitos mais teóricos do paradigma funcional, para que a linguagem que estamos falando seja a mesma.

Minha experiência com Scala é algo bem próximo do zero, por isso estou escrevendo esta série de posts com o intuito de me forçar a estudar a linguagem e também ajudar a divulgar uma das possíveis alternativas ao Java, afinal se trata de uma linguagem nova e que ainda não foi muito difundida na comunidade. Tratarei bem do básico nos primeiros posts com exemplos bem trivias apenas para ajudar na compreensão dos conceitos básicos. Também colocarei algumas bibliografias de onde se pode encontrar documentação sobre a linguagem.

Linguagens funcionais e Scala

Não é nova a ideia de se programar em um paradigma funcional. Linguagens funcionais existem a quanse tanto tempo quanto existe linguagens de programação. Com certeza na sua faculdade você viu, ou verá, linguagens como LISP, Scheme, Erlang, Clojure, etc… e atualmente que está ficando bem conhecida: Scala que roda em cima da JVM, a virtual machine do Java. Linguagens funcionais mudam o paradigma para focar em ‘funções’. Assim como em linguagens orientadas a objeto onde a unidade básica é uma intância de um objeto, em linguagens funcionais a unidade básica é uma função. Uma função nada mais é do que uma operação que recebe parâmetros, executa alguma ação e devolve um resultado. O funcionamento é muito parecido com o dos métodos em linguagens orientadas a objeto.

O interessante sobre Scala, é que a linguagem permite uma mescla do paradigma funcional com orientação a objeto. Existem conceitos de ambos implementados na linguagem e que fazem sentido quando aplicados em conjunto. Por exemplo, em scala existe o conceito de classe e de instâncias de classes, que são os objetos. Também existem funções que independem de uma classe para existirem. Se trata de um conceito muito poderoso, pois possibilita toda padronização e controle do design do sistema que as linguagens orientadas a objeto permitem, sem restringir o uso do dinamismo e abstração da linguagem funcional.

Mas claro que Scala e linguagens funcionais tem seus problemas. Por exemplo, não existe uma IDE sólida como o Eclipse ou o NetBeans para Scala. O que dificulta no momento de trabalhar com projetos muito grandes, com uma equipe com vários programadores. O dinamismo da linguagem também impede uma análise de código que por exemplo o PMD, ou o FindBugs disponibilizam no Java. Dessa forma, deveríamos garantir que as boas práticas e o design está sendo seguido com nossos testes unitários.

Chega de filosofar sobre a linguagem, vamos para a parte prática.

Instalando Scala

Para instalar o Scala basta acessar a página oficial de download neste link, e fazer o download de acordo com sua plataforma. Feito isso, descompacte o conteúdo em alguma pasta na sua máquina e adicione a pasta ‘bin‘ ao path do seu sistema operacional. Para se certificar que foi tudo instalado corretamente, abra um console e digite ‘scala‘, o terminal do scala deve abrir e aparecer uma tela como essa:

Agora que o terminal está sendo executado, digite ‘1 + 1‘ e repare na saída:

É uma saída um tanto quanto confusa, mas que faz sentido no contexto do Scala. O que está acontecendo é que a unidade básica em Scala é uma função, portanto a operação + também é uma função, que foi executada no objeto ‘1‘, passando o parâmetro ‘1‘. Para se ter uma idéia melhor desse funcionamento, digite o seguinte no terminal:

e aperte Enter. Repare na saída:

Com exceção do tipo que era int e agora é Double, o funcionamento é exatamente o mesmo. Tal sintaxe já deve estar bem claro na cabeça da maioria dos programadores, mas a primeira sintaxe é só uma maneira difetente de se fazer a mesma chamada.

Conceitos básicos da linguagem

Vamos definir uma função para entender um pouco mais da sintaxe. Digite o seguinte:

Aqui estamos definindo uma função com o nome ‘a‘ que não recebe parâmetros, e devolve o resultado da soma ‘2 + 2‘. A palavra restrita return não é necessária, o compilador consegue inferir que a última expressão da função será o valor devolvido. Repare também que não precisamos definir o tipo que a função devolve, o qual também foi inferido pelo compilador. Portanto ao contrário do que possa parecer, Scala é uma linguagem tipada em tempo de compilação, portanto o seguinte trecho não compila:

Repare que o compilador inferiu que o tipo da variável ‘b‘ é String (note que é o String do java), e que o tipo devolvido por ‘a‘ é Int, logo o código não compila. De certa forma esse comportamento é bom, pois garante uma maior integridade do código, sem que você tenha que programar para “deixar o compilador feliz“, ou seja, não existem tantas regras na escrita do código, porque muitas podem ser deduzidas a partir do contexto.

Um outro conceito de Scala é a diferença entre chamada por valor, e chamada por nome. Na chamada por valor é feita a evaluação da expressão assim que o código é executado, mesmo que não seja necessário usar o resultado da chamada. A vantagem é que evitamos executar outras vezes a expressão para obter o resultado, pois este já foi determinado. Na chamada por nome a evaluação da expressão ocorre apenas quando o resultado da chamada será usado, tendo um comportamento mais lazy. A desvantagem é a execução da expressão várias vezes para se obter o mesmo resultado, mas a vantagem é não fazer a execução quando não for necessário. Vamos ver um exemplo da diferença entre a chamada por valor e por nome. Volte no terminal e defina a seguinte função:

Agora defina uma função que recebe dois inteiros e devolve o primeiro:

Agora execute a chamada passando ‘loop‘ como segundo parâmetro e se prepare porque seu console irá travar na execução =):

Vamos fazer uma pequena modificação na definição de ‘primeiro‘ para tornar possível a execução de tal código:

O que definimos agora foi que o segundo parâmetro de ‘primeiro‘ será uma função que devolve um Int. Assim seu resultado só será obtido quando for feita a chamada direta na expressão. Agora conseguimos fazer a chamada em nossa função:

Nossa função executou e finalizou sem problemas dessa vez, isso porque não foi necessário utilizar o segundo valor para obter o resultado. Essa é chamada por nome, e o primeiro exemplo é a chamada por valor.

Até agora vimos como invocar funções, como definir funções (def) e como definir variáveis (var). Vimos também o básico de inferência de tipo pelo compilador do scala e os primeiros conceitos da linguagem. Mas como eu havia dito, Scala também tem conceitos de orientação a objetos, portanto vamos definir nossa primeira classe em Scala:

Lembre-se que não somos obrigados a definir o tipo devolvido pela função caso esteja explícito e também não precisamos da palavra reservada ‘return‘. O que fizemos foi definir uma classe que se chama ‘AcumulaSoma‘ que tem um atributo, que por padrão do Scala é de acesso privado, que se chama acumulado e que o compilador inferiu o tipo inteiro baseado no valor atribuído. Também definimos para a classe a função ‘acumula‘ que recebe um inteiro, guarda o valor acumulado até então da soma com o parâmetro passado e devolve tal valor. Vamos instanciar um objeto da nossa classe e fazer a chamada ao método:

Algumas diferenças com o Java (supondo que estamos mais acostumados com a sintaxe do Java) já podem ser notadas. Além da inferência do tipo de ‘ac‘ para ‘AcumulaSoma‘, criamos ‘ac‘ com a a palavra reservada ‘val‘, ou seja, estamos dizendo que diferente de ‘var‘ onde criamos uma variável, estamos criando um valor e estamos garantindo em tempo de compilação que este valor não pode ser alterado no código. No Java teríamos que usar a palavra ‘final‘ para obter o mesmo comportamento, em Scala temos que “satisfazer menos o compilador“. Também não foi necessário usar ‘()‘ para invocar o construtor de AcumulaSoma, e assim como no Java toda classe em Scala tem por padrão o construtor que não recebe parâmetros com acesso público. Continuando o exemplo:

Nada de novidade aqui, estamos invocando a função ‘acumula‘ no objeto ‘ac‘. Porém ‘acumula‘ é uma função que recebe um único parâmetro e devolve um valor. Dessa forma podemos executar a chamada da nossa função da outra forma que vimos anteriormente:

No Java conseguimos definir classes estáticas. Em Scala não existe exatamente o conceito de classes, atributos e parâmetros estáticos, porém existe um conceito mais bem definido: ‘object‘. Criamos um ‘object‘ igual criamos uma classe, com a diferença de que não é possível instanciarmos um object, afinal estamos definindo o próprio. Com essa diferença, estamos garantindo em tempo de compilação que o design do código, em que foi tomada a decisão de restringir a existência de apenas uma definição para determinada classe seja seguida. Em Java também é possível garantir tal critério em tempo de compilação, mas demanda a escrita de bem mais código e de uma compreensão um pouco maior do funcionamento e limitações da linguagem. Um exemplo de object:

Existem os tipos primitivos básicos em Scala como Int, Long, Boolean, Float, Double, Short, Byte, Char e String, sendo que String é a String do ‘java.lang‘. Um fato interessante sobre Scala é que como a linguagem roda em cima da JVM, todas as bibliotecas disponíveis para Java também estão disponíveis para Scala.

O tipo que não vimos ainda é o ‘void‘. Em Scala não existe o conceito de void, toda função devolve um valor e quando não há um valor explícito a ser devolvido o compilador se encarrega de devolver um valor do tipo ‘Unit‘. Exemplo:

‘print’ é uma função que imprime um valor no terminal e não devolve valor, logo nossa função ‘imprime‘ também não devolve valor, portanto o tipo devolvido é ‘Unit‘, que também pode ser expressado/escrito como ‘()‘. A diferença básica entre void e Unit, é que Scala permite criar valores e variáveis do tipo Unit, e em Java por exemplo não é possível criar uma variável do tipo void. Também é possível analisar o valor devolvido por qualquer função mesmo que a função não devolva um valor definido e neste caso será um Unit. Um exemplo trivial de como usar este comportamento:

O tipo ‘Any‘ é análogo ao ‘Object‘ do Java, portanto pode ser qualquer valor, função ou objeto.

Nessa função estamos usando um tipo de switch case para obter o mesmo comportamento do ‘instanceof‘ em Java, afinal não existe tal operação em Scala. O que está acontecendo é que a função verificaUnit recebe uma função que não recebe argumentos e devolve um valor qualquer. A função ‘f‘ é então evaluada e o resultado da função é testado nos cases da operação ‘match‘. Caso seja do tipo Unit, imprimimos “Eh Unit!”, e no caso padrão imprimimos “Nao eh Unit!”. Repare que diferente do ‘switch‘, no ‘macth‘ não temos que chamar a operação ‘break‘ para não executar os outros casos. Para testar verificaUnit vamos fazer a chamada usando nossas outras duas funções que foram definidas:

Um exemplo mais prático

Vamos implementar um exemplo um pouco mais prático que calcula a raiz quadrada aproximada de um número. Para isso vamos usar o método de Newton de aproximações sucessivas. A idéia é bem simples, nada mais é do que uma busca binária entre os palpites que se aproximam cada vez mais da raiz quadrada do número passado. Vamos começar definindo uma função que diz se a raiz encontrada é boa o suficiente para ser o resultado:

O bloco if é igual a sintaxe usada no Java, o mesmo vale para o else e o else if. Na segunda função estamos verificando se o número elevado ao quadrado é próximo o bastante do original. Agora vamos definir a função que faz um palpite melhor:

O que fizemos foi pegar um número para palpite que está entre o nosso palpite anterior e x dividido sobre o palpite anterior, onde x é o número que queremos obter a raiz quadrada. O método de Newton garante que para x >= 1 essa aproximação é sempre válida. Vamos agora a função que executa o método de Newton propriamente dito:

Estamos calculando a raiz quadrada de modo recursivo até que o resultado seja bom o suficiente. Agora basta definir uma base para nossa função, para isso iremos pré-definir um valor para o palpite base, guardando a chamada nesse escopo em uma outra função:

Pronto, basta brincar com algumas chamadas para nossa função que calcula a raiz quadrada =).

O resultado obtido não é muito preciso, mas também essa não é a melhor maneira de se calcular a raiz quadrada, inclusive para números muito grandes o algorítmo não funciona por restrições com a precisão do Double.

Algumas Considerações

A grande moda das linguagens funcionais está surgindo porque acreditasse que elas são o futuro para a programação concorrente e paralela, de que se o seu programa foi escrito em uma linguagem funcional você terá ganho o benefício da execução concorrente sem grandes esforços, bem, isso não é verdade. Linguagens funcionais como qualquer outro paradigma necessitam que o programa seja escrito de maneira que seu design seja voltado para execução concorrente ou paralela, a difenrença é que a sintaxe e as ferramentas disponíveis nas linguagens funcionais facilitam tal design.

Existem algumas técnicas de programação que surgiram com linguagens funcionais, como por exemplo Recursão em Cauda, que não entrarei no mérito nesse post mas que vale a pena pesquisar sobre o assunto. Tais técnicas facilitam a vida do compilador no momento em que for possível ser feita algum tipo de otimização.

Uma comparação que logo surge na cabeça dos programadores é: qual linguagem é melhor, Scala ou Java? A resposta é fácil… nenhuma. Cada linguagem tem um escopo e paradigma de atuação diferente, não tem como comparar ambas. O que talvez faça sentido comparar sejam fatores mais fora do domínio da linguagem, como por exemplo o tamanho da comunidade que utiliza efetivamente a linguagem, o tipo de suporte, a documentação disponível, as restrições de uso, mas em geral depende do caso de uso específico para o seu problema, e principalmente do gosto do programador.

Por enquanto é isso, em um próximo post tratarei de alguns outros tipos de funções e falarei um pouco mais sobre currying. Também darei exemplos de tipos diferentes de declarações de classes e objetos.

Referência: Scala By Example, Martin Odersky