Olá, hoje vou mostrar como fazer um DAO Genérico no Java (contendo SaveOrUpdate, Remove, FindAll, FindByID) que pode ser usado por todos os DAOs. Facilitando a criação de novos projetos, podendo ser usado com a integração com o Adobe Flex através do RemoteObject.

Isto é para quem não quer usar nenhuma espécie de Framework (ex: Spring, que faz isso de uma forma mais genérica).

Primeiramente criei minha classe contendo todos os métodos (save, update, delete, find), para minha classe ficar “genérica” ao invés de receber as entidades específicas, recebe Object (pode passar as Entidades que o java consegue reconhecer). Após criar esta classe contendo os métodos, é só criar os DAOs extendendo da classe genérica, com isso já terá todos os métodos implementados. Podendo fazer validações específicas para cada DAO.

Vamos a prática:

Este é minha classe genérica contendo todos os métodos.
GenericDAO.java
Leia mais…

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

Criando a camada WEB com Spring-WEBMVC – @Annotation

Spring WebMVC é uma ferramenta poderosa para criação de aplicação com uma camada web muito utilizada no mercado.
Algumas de suas características incluem uma separação clara entre camada de apresentação, negócios e modelo, e também uma distinção clara de papéis de controllers, validators, commands, forms, models, views etc. Também é um framework altamente customisável e adaptável, disponibilizando ferramentas para controle de todo o fluxo entre as páginas e se adaptando bem a maioria dos modelos de negócio. Outra característica que é quase obrigatória em todos os módulos do Spring, é o padrão Spring de se organizar e configurar as classes de negócio como beans gerenciados pelo container.
Além das características básicas, ainda estão disponíveis bibliotecas de JSP muito úteis no dia-a-dia de desenvolvimento que facilitam a contrução de interfaces. E ainda existe a possibilidade de configurar os escopos dos beans da aplicação de acordo com o lifecycle do HTTP request que está sendo feito para a aplicação.

Neste post veremos o básico de spring-webmvc e sua configuração feita por anotações, aprendendo os conceitos base do módulo e entendendo melhor como configurar e organizar seus beans de acordo com suas necessidades. Por fim veremos um screencast com um exemplo de aplicação web feita do zero e seguindo todo o caminho desde o modelo, passando pelo controller e terminando na view.

Entendendo o DispatcherServlet

O DispatcherServlet é de fato um servlet Java que é o ponto de entrada para as aplicações Web.

É encarregado de encaminhar as chamadas feitas a aplicação para seu respectivo controller, e uma vez que a resposta do controller foi recebida, encaminhas a resposta para a view correta. Mas como DispatcherServlet faz parte do Spring, para ele e seus beans, nesse caso controllers e suas dependências, estão disponíveis todas as outras features que o container disponibiliza, como gerenciamento de beans e injeção de dependências.

O DispatcherServlet seguem um Design Pattern conhecido como Front Controller. No site do spring está disponível o seguinte diagrama exemplificando o pattern:





No diagrama fica claro o papel do DispatcherServlet.
Uma chamada que acabou de chegar na aplicação, passa pelo DispatcherServlet, que por sua vez escolhe o controller correto para tratar a chamada e delega a mesma. Feito isso o controller devolve o resultado da operação para o DispatcherServlet que dessa vez se encarrega de encontrar a view correta para tratar a resposta. Após a view ter renderizado a página de resposta, o DispatcherServlet devolve para o dono da requisição a resposta.

Configurando o DispatcherServlet

Agora que entendemos que o DispatcherServlet é peça fundamental para nossa aplicação, precisamo configurá-lo. Para isso basta adicioná-lo ao seu arquivo web.xml da seguinte forma:

O que fizemos foi dizer ao server, que ele deve instanciar um novo servlet, que nesse caso é o DispatcherServlet, assim que a aplicação subir no servidor. Também estamos dizendo que todas as chamadas para a aplicação, que forem feitas em / devem ser delegadas para o nosso servlet com o nome servletName. Nesse campo você pode escolher o nome que mais fizer sentido para sua aplicação, e perceba que você pode criar mais de um servlet para tratar suas chamadas.

Agora vamos à integração com o IoC do Spring.

Como eu havia dito, esse é um dos benefícios do Spring-WebMVC, e portanto vamos ver como usá-lo corretamente para tirar maior proveito do mesmo.

Todo DispatcherServlet está associado a um contexto de beans do Spring. Tal associação é feita através do nome do servlet e um arquivo de beans padrão do spring. No momento em que o DispatcherServlet for criado, o classpath será percorrido em procura de uma arquivo que, neste caso, deve se chamar /WEB-INF/servletName-servlet.xml. Neste arquivo devem estar definidos os beans específicos para que os seus controllers referentes a este servlet funcionem corretamente. Note que se estiver definido mais de um DispatcherServlet, será necessário definir um arquivo com tais beans para cada um deles.

Controllers

Controllers são parte fundamental da arquitetura MVC (se referem so ‘C’ da sigla), e no Spring-webmcv não é diferente. Saber configurá-los e atribuí-los a suas chamadas específicas é muito importante no desenvolvimento da aplicação. Pensando nisso o Spring disponibiliza várias implementações de controllers que pode ajudar no dia-a-dia e várias ferramentas para associar as chamadas a tais controllers. Como o objetivo do post é tratar da configuração por anotações, não entrarei no detalhe de tais implementações e de tais associações. Iremos utilizar um serviço qualquer da aplicação para servir de controller, e a associação será feita através das anotações.

Para tornar uma classe um controller do spring, basta anotá-lo com @Controller da seguinte forma:

Repare que não é necessário extender nem implementar nenhuma classe ou interface específica, o que colabora bastante para desacoplar a lógica de view de nosso sistema.

Para habilitar esse nosso controller e associá-lo ao servlet, basta pedirmos ao Spring para scannear esse pacote e deixar o bean disponível no contexto do servlet. Para fazer isso adicione o seguinte no arquivo de beans do servlet:

Perceba que coloquei a tag do contexto do spring que habilita a configuração por anotações.

Agora precisamos definir um método para que o spring faça a chamada quando o request chegar na aplicação. Para isso vamos entender o papel do ModelAndView.

ModelAndView

O ModelAndView é responsável por descrever o modelo e a view (intuitivo? ) daquela chamada, portanto nele estão setados a view a qual a chamada está associada, e todos os atributos de modelo que devem chegar até a view. Tais atributos são guardados como em um Map associando chaves e valores. Veremos que esses valores ficam disponíveis em nossa view e podem ser usados nos JSPs da aplicação, mas agora vamos ao método do controller:

Muita coisa acontecendo aqui, mas vamos por partes. A primeira coisa a se notar é que o método irá tratar todas as chamadas feitas em nomeDaAplicação/chamada, isso porque nosso servlet está associado em / e nosso método está associado com chamada. Nós poderíamos também ter definido o caminha básico para o controller ainda na anotação do controller, por exemplo:

Assim nosso método trataria todas as chamadas feitas em nomeDaAplicação/base/chamada.

A segunda coisa a se notar é que nosso método só irá tratar requisições do tipo GET, podendo ser alterado para os outros tipos de requisição seguindo um modelo REST.

A terceira coisa a se notar é que nosso método devolve um ModelAndView, portanto saberemos a que view o DispatcherServlet irá direcionar, e também teremos alguns atributos do modelo disponíveis.

A última mas não menos importante, é que o método está esperando um parâmetro. Esse parâmetro foi anotado com @PathVariable, isso significa que a chamada ao controller deve esr da seguinte forma: nomeDaAplicação/chamada?var=teste e assim nosso método irá receber o valor teste. Faça alguns testes e repare que é possível configurar a obrigatoriedade do parâmetro, a validação do mesmo dentre outras coisas. Também poderíamos ter definido o parãmetro como @RequestParam, mas nesse caso a chamada deveria estar em um formato POST e o atributo deveria estar setado no request.

ViewResolver

A última configuração necessária para nossa aplicação funcionar é um ViewResolver. Vamos utilizar um bem simples para que possamos utilizar páginas em JSP em nossa aplicação. Para isso, basta adicionar o seguinte bean no contecto do servlet:

O que fizemos, foi dizer ao view resolver, que ele deve buscar na pasta WEB-INF/jsp por nossos arquivos JSPs antes de renderizar as páginas de resposta. Também estamos dizendo, que ele deve procurar através do nome da view que o controller devolver, por exemplo, se nosso ModelAndView possuir uma view com nome pagina, o view resolver irá buscar por um arquivo com nome pagina.jsp para renderizá-lo com os atributos setados no ModelAndView.

Existem muitos tipos de view resolvers, e muitas maneiras de configurá-los, mas para uma primeira experiência com o framework essa configuração já é suficiente.

Por @Gust4v0_H4xx0r

Fazer parsing de uma estrutura de dados como o XML é muito comum no desenvolvimento de aplicativos web, a maior parte dos sistemas desenvolvidos com o conceito de Web 2.0 implementam uma api de serviços para que o desenvolvedor possa utilizar e criar novos aplicativos, sub programas, relatórios e etc.

Estas API’s de serviços trabalham na maioria das vezes com formato de dados universais, como por ex, o JSON e XML. Portanto uma terefa comum quando estamos desenvolvendo um aplicativo “client” para estes serviços é interpretar estes dados para utilizar do modo desejado no software.

Existem diferentes modos de trabalhar com documentos XML’s e diferentes ferramentas para isso. Neste post vamos ver como isso funciona no desenvolvimento para IPhone.

Como funciona o parsing de XML?

Existem dois modos para fazer parsing de um documento XML, e muita diferença entre eles. Entender como cada modo funciona é fundamental para que esta tarefa não se torne um problema no seu projeto.

SAX ( Sequencial Access Parser )

Como o nome sugere, o parser que implementa o SAX irá fazer uma analise sequencial na estrutura do xml, o que isso quer dizer? Cada elemento do XML será analisado individualmente e em sequencia. Ele é baseado em um fluxo de eventos que são disparados para cada elemento do XML.

Exemplo

Dado o XML abaixo:

A sequência que o parser irá fazer é a seguinte:

• Começo de um novo elemento, chamado RootElement, com o atributo param = “value”
• Começo de um novo elemento, chamado FirstElement
• Um nó de texto com o data igual a “Some Text”
• Final do elemento chamado FirstElement

Quando utilizar?
Este tipo de parser é recomendado quando o tamanho do documento é muito grande ( algo em torno de 10MB ) e você pretende utilizar somente uma pequena parte do XML, pois ele não carrega o conteúdo do documento em memória ( isso acontece com os parser que implementam DOM ), porém o trabalho de desenvolvimento é maior.

DOM ( Document Object Model )
O parser que implementa o XML DOM, possibilita você acesse qualquer elemento diretamente sem a restrição de seguir uma seqüência baseado na hierarquia do XML.

Normalmente os parsers que implementam o modelo DOM também permitem que você defina a consulta no xml através de XPath. Isso torna muito mais fácil a maneira de filtrar ou agrupar os elementos do XML.

Para aqueles que estão acostumados a trabalhar com o flex, a maneira como o sdk lida com XML é através da implementação DOM, e a linguagem de busca dentro do XML é o E4X, portanto a curva de aprendizagem para aprender XPath será menor.

Para que o parser possa interpretar as consultas XPath e navegar de modo trasnversal entre os elementos para encontrar o critério de busca, o XML é carregado em memoria e transformado em uma estrutura de dados que facilita este tipo de tarefa. O ponto ruim disso é que em documentos grandes esta abordagem pode ocasionar problemas.

Exemplo

Dado o xml abaixo:

E o seguinte trecho de código:

O exemplo de código abaixo utiliza a biblioteca GDataXML para manipulação DOM do XML, está biblioteca é distribuida pela Google.

O método [doc nodesForXPath:@"//item":nil] irá percorrer todos os elementos do XML procurando pelos nós do tipo .

Quando utilizar?
O parser que implementa o XML DOM deve ser utilizado em documentos que não irão comprometer a memória ( algo menor que 10MB ), já que o gerenciamento de memoria no desenvolvimento de IPhone é um ponto que deve ser considerado. A manipulação de XML com DOM é muito mais fácil do que com SAX, uma vez que o acesso é direto.

Quais bibliotecas utilizar?

Existem várias bibliotecas que fazem parsing de XML, as mais conhecidas são:

• NSXMLParser É um SAX parser incluido por padrão no SDK do IPhone.
• libxml2 Este é um projeto Open Source que também é incluido por padrão no SDK do IPhone, ele é baseado na linguagem C, portanto é um pouco mais complicado de usar se comparado com o NSXMLParser. Esta biblioteca suporta tanto o modo SAX quanto DOM. O processamento SAX desta biblioteca é muito interessante pois permite que você faça a leitura/manipulação do XML durante o download, evitando o tempo que demoraria para baixar o documento todo.
• TBXML é um parser DOM XML muito leve desenvolvido para ser  muito rapido e consumir o minimo de memoria possível. Ele ganha tempo pois não faz validação, não da suporte ao XPath e possibilita somente acesso de leitura ao conteúdo do XML.
• TouchXML é um parser com mesmo estilo do NSMXL porem com DOM XML. Do mesmo modo que o TBXML ele permite acesso somente de leitura, entretanto possui suporte para XPath.
• KissXML muito similar ao TouchXML, inclusive foi feito com base no mesmo, entretanto possibilita edição do conteúdo do XML.
• GDataXML este parser é desenvolvido pela  Google como part de sua biblioteca Objectve-c. Ele suporta leitura e escrita , e também da suporte a XPath

Conclusão

O importante é ter em mente quais são as opções e modos de fazer o parcing do XML na sua aplicação, entender quais são as métricas que o ambiente da aplicação possui e leva-las em conta na decisão de como fazer o parsing. Estas métricas irão te encaminhar a uma das opções.

O link a seguir possui um conteudo complementar ao tema, e também apresenta uma comparação entre todas as ferramentas analisando performace e utilização de memória, vale a pena dar uma olhada: link

Referencias:

http://www.raywenderlich.com/553/how-to-chose-the-best-xml-parser-for-your-iphone-project
http://stackoverflow.com/questions/406811/iphone-development-xmlparser-vs-libxml2-vs-touchxml
http://www.saxproject.org/
http://en.wikipedia.org/wiki/Simple_API_for_XML
http://www.w3schools.com/Dom/dom_parser.asp
http://www.w3schools.com/XPath/default.asp

Neste post vou compartilhar um pouco dos meus experimentos para tornar o suite de testes do Cifras mais rápido.

No atual estado do serviço eu tenho por volta de 800 testes automatizados usando Rspec 1.3 e Rails 2.3.9.

Estes testes cobrem o sistema praticamente todo e a são única forma ter a confiança necessária para trabalhar em novo recursos, correções de bugs e etc.

Este número de tests tem crescido consideravelmente desde que comecei a utilizar o Steak para testes de aceitação. Testes de aceitação possuem um papel muito importante em certificar que a funcionalidade é aceitável para o cliente em faz os testes em estado mais macro. Desta forma tenho coberto o sistema praticamente todo usando o Steak nas últimas semanas.

No entanto eu me vi em uma situação que já era perceptível mas começou a se tornar insuportável. Meu suite de testes (ainda com 800) estava demorando por volta de 4.5 minutos para ser executado. O mais estranho é que 800 testes é muito pouco para poder demorar tanto.

Arquitetura de um Saas

Cifras é um Saas que envolve pagamentos e múltiplos usuários dentro de um conta. Eu já trabalhei em vários outros Saas’s e todos que envolvem algum tipo de assinatura e vários usuários acabam tendo uma arquitetura muito parecida nos models.

Normalmente você possui os seguintes models: conta, usuário, assinatura, plano de uso, preferências e o uma associação para proprietário da conta. Além destes 5 models também existe um processo que insere alguns dados iniciais como categorias assim que uma conta é criada.

Fica claro que qualquer signup vai disparar uma criação em cadeia de uma conta com uma assinatura que possui um propietário (que é um usuário) e depois preencher as categorias e etc. Este processamento é bem rápido mas multiplicado por 800 (ou mais) acaba sendo um problema.

Eu não quero reduzir o número de models reunindo tudo no model de conta pois acredito que seria uma arquitetura bagunçada além de uma alteração que envolva tanto o banco de dados ser extremamente perigosa.

Eu não queria tocar em nada do código da aplicação apenas para fazer os testes se tornarem mais rápidos. Do contrário acredito que estaria ocorrendo um inversão das responsabilidades, fazendo os testes guiarem o desenvolvimento mais de uma forma errada.

1º passo: Logger

Comecei o trabalho de otimização analisando o log de test. Para ter certeza de onde cada query vinha e o tempo gasto, adicionei um plugin chamado query_trace.

É um plugin bastante antigo mas ainda funciona muito bem. Assim que instalei, fiz algumas anotações de todas as queries que ocorriam com frequência em meus tests e de onde elas vinham.

Mas o mais interessante que ao instalar o plugin a performance dos meus testes caiu drasticamente. A única razão para isto é que o plugin escrevia toneladas de textos no meu log, ou seja, operações que envolvem muito IO.

O que fiz foi anotar as coisas que me interessavam e remover o plugin, no entanto uma otimização que já poderia ser feita é alterar a estratégia de log do ambiente de tests para :info ao invés do padrão.

Apenas esta alteração tornou meu suite de testes quase 50 segundos mais rápido.

No arquivo config/environment/test.rb:

1
    config.log_level = :info

2º passo: Evitando consultas

Analisando o resultado do query_trace não havia nenhuma consulta extremamente lenta que ocorresse com frequência. Como eu já utilizava bibliotecas como SlimScrooge, Oink e NewRelic eu já tinha encontrado estas queries e resolvido a mais tempo.

No entanto, uma coisa que muitas vezes não nos lembramos é que qualquer validação de unicidade e associação do Rails vai disparar um consulta. Sim, uma micro consulta que normalmente gasta 0.3 ms e não incomoda em nada em ambiente de produção. Mas nos tests isso pode significar muito.

Como eu utilizava apenas factories (com FactoryGirl) cada spec acabava precisando de um before ou um let do Rspec que fazia uma chamada a Factory account que consequentemente criava todas outras factories associadas e ainda executava as validações.

As criações associadas não me incomodavam ainda pois eu estava atacando apenas as validações. A melhor alternativa que encontrei para remover os 0.3ms de cada validação foi usar fixtures.

Fixtures são carregadas apenas uma vez e não passam pelas validação, então em todos os momentos que eu precisava dos dados base como conta e usuário para fazer os outros testes eu passei a usar fixtures.

Por exemplo, nos testes de categorias eu precisava criar uma conta antes para associar uma categoria a ela. Este processo rodava em um before o que tornava os testes bem mais lentos, a partir de agora tudo é previamente carregado por fixtures.

No final, terminei com uma fixture para cada model base e criei helpers para o Rspec. Algo assim:

1
2
3
4
5
6
7
8
9
10
11
    def account

      accounts(:apple)

    end



    def subscription

      subscriptions(:apple)

    end



    def user

      users(:sjobs)

    end

E meus specs passaram a ficar assim:

1
2
3
    let :bank_account do

      Factory :bank_account, :account => account

    end

A desvantagem é que novos desenvolvedores terão que entender que o account é um helper já que ele é incluído pelo spec_helper.

Outra coisa que fiz foi incluir as fixtures base como globais para evitar ter que carrega-las manualmente nos specs.

1
2
    Spec::Runner.configure do |config|

      config.global_fixtures = :users, :plans, :accounts, :settings ...

Em vários casos o uso de fixtures para a base do sistema eu tive ganhos de mais de 100% em velocidade. Então a partir disso toda a base do sistema (5 models) utilizam fixtures nos models associados e factories em seus próprios models.

Por exemplo, no model User eu faço os specs usando a Factory user mas a sua conta é trazida de uma fixture e vice versa com os outros models base. No caso de Transações eu carrego usuário, conta, plano, assinatura e preferência através das fixtures enquanto as transações são criadas com factories.

3º passo: Evitando chamadas remótas

Uma coisa irritante da comunidade Rails são as modinhas. Por um lado é bom, pois as coisas se atualizam MUITO rápido por outro lado fixtures se tornaram diabólicas de um dia para o outro, também ocorreu com attachment_fu por exemplo e etc. O mesmo vale para mocks.

Se você vai fazer uma integração com uma API, você DEVE usar um mock para não fazer o request, essa é a regra. Eu simplesmente descordo!

Se sua aplicação depende da API para existir, eu considero totalmente errado fazer um mock disso pois você nunca saberá se por algum motivo a API mudou ou parou de funcionar, ou mudou de endereço.

Apesar de óbvio que uma API deve ter versões e não mudar dessa forma, nem sempre isso ocorre, ainda mais as API’s brasileiras.

Por esta razão os testes do Cifras executavam requests para o sandbox do MOIP, o que fazia eu ter a segurança que o meu código continuava funcionando com a API deles. Eu NÃO iria fazer um mock dessa parte e ponto final.

Isso causava uma demora de mais ou menos 1 min nos testes. Mas era um preço que eu preferia pagar.

Com uma dica do meu amigo Jeffry Degrande conheci uma ferramenta que resolve isso. O ephemeral_response faz o request para a API e armazena um cache com o retorno por um prazo pré-determinado. Defini que este prazo no Cifras seria de um dia.

Com este passo reduzi mais um minuto do meu suite.

4º passo: Trabalho de formiga

O último passo seria de fato passar spec por spec e olhar o que poderia ser otimizado. Em alguns pontos stubs faziam mais sentido, outros apenas um Factory.build ao invés de create tornava o test mais rápido.

Outras duas técnicas muito boas é utilizar Factory.attributes_for :meu_model e Factory.stub :meu_model.

Este passo não reduziu muito o tempo pois eu já utilizava desta forma, mas em alguns pontos eu tinha deixado passar então tive uma pequena melhoria.

Conclusão

O resultado final foi que de 5min eu consegui reduzir para 1.5 min. Ainda existe espaço para otimizações, mas por enquanto isso deixo de ser prioridade e será melhorado usando aos poucos seguindo The Boy Scout Rule.

A minha conclusão é que fixtures são excelente para alguns casos e factories também, então não existe nenhum motivo para este ódio contra fixtures. Você pode usar tanto fixtures quanto factories no mesmo projeto e tirar o melhor dos dois mundos.

Outra dica é quanto ao log e o ephemeral_response e sempre ficar atento para usar Factory.build e Factory.stub quando possível.

Se você tiver alguma outra dica, compartilhe nos comentários.

Há muito tempo venho acompanhando o fórum de Silverlight do MSDN Brasil, tirando dúvidas e ajudando outros desenvolvedores com problemas. Por ser bastante ativo nesse fórum acabei sendo nomeado como um de seus moderadores, o que me dá acesso para fazer algumas coisas como mover questões, editar e bloquear posts de outras pessoas, marcar perguntas como respondidas, etc…

Após um tempo a gente começa a notar certos padrões, e um que fica bem evidente para quem acompanha fóruns é que a grande maioria das pessoas não sabe usá-los corretamente. Fóruns são uma base de conhecimento com dúvidas e respostas para ser consultada e utilizada em caso de necessidade. Veja como um fórum é normalmente usado:

• Usuário encontra um problema ou tem uma dúvida
• Acha o site de fóruns do MSDN (ou qualquer outro)
• Acha a tela de postar dúvida, preenche a descrição, preenche o título e envia
• Aguarda uma resposta e depois não volta mais

O que há de errado nesse comportamento? Esse usuário não tirou proveito da ferramenta em vários pontos chave e usou o fórum como se fosse um sistema de suporte.

1. Esse usuário não pesquisou para ver se a dúvida/problema dele já estava no fórum. Talvez alguém já houvesse passado por isso e ele já conseguisse a resposta na hora.
2. Ao postar a dúvida ele começou preenchendo a descrição do problema e deixou o título para depois (talvez nem tenha percebido o campo e tenha preenchido só quando a validação da tela informou que era obrigatório). O problema disso é que o título acaba sendo preenchido com qualquer coisa, o que não ajuda para que a dúvida seja encontrada e respondida logo. Há também casos que são ao contrário onde a pessoa faz uma pergunta bem genérica no título e não detalha o cenário na descrição. Não podemos também esquecer dos casos em que a pessoa submete a dúvida no tópico/categoria errada do fórum.
3. Após ter sua pergunta respondida o usuário muitas vezes simplesmente utiliza a resposta e não atualiza o fórum informando que aquela é a resposta. Na maioria dos casos o usuário só voltará ao fórum se a resposta não resolver o problema dele.

Esse tipo de comportamento é ruim para os fóruns pois acaba gerando informações redundantes, retrabalho e inconsistência nas respostas. Eis como o fórum deve ser usado:

• Usuário encontra um problema ou tem uma dúvida
• Acha o site do fórum (MSDN/Stack Overflow ou qualquer outro)
• Verifica se há uma busca geral e faz uma busca com as palavras chave sobre a questão que tem
• Se encontrar uma pergunta igual ou semelhante, verifica se ela está respondida e resolve o problema. Se estiver e resolver, vote na resposta para indicar que foi útil. Se não estiver respondida ou não resolver seu problema, poste um comentário ou pelo menos assine a pergunta para poder receber uma alerta por email quando houver atualização.
• Se a sua dúvida não estiver no fórum ainda, ache a sessão do fórum referente ao assunto da dúvida. Ex.: Se a dúvida de sobre como filtrar uma query no banco de dados, você não deve postar no fórum de Silverlight só porque sua aplicação é feita em Silverlight. Você deve postar sua dúvida no fórum de SQL nesse caso.
• Coloque a questão central do seu problema no título, da forma mais clara e concisa possível. Quem estiver lendo tem que ser capaz de identificar pelo menos o escopo da pergunta lendo apenas o título. Um título bem feito ajuda para que outras pessoas possam tirar proveito no futuro da solução ao seu problema e também faz com que se obtenha uma resposta mais rápido pois uma pessoa pode simplesmente bater o olho no título e falar “ei, eu sei responder isso”, ao invés de ter que abrir a pergunta e ler a descrição para saber do que se trata. Exemplos de títulos ruims: “Dúvida?”, “Problema com relatório”, “Acesso ao banco”, “Silverlight”, etc…
• Preencha a descrição da pergunta com mais detalhes sobre o seu cenários. O que você está tentando fazer? Que tecnologias está usando? O que sua aplicação faz? etc. Quanto mais informações você puder passar, mais chances têm de ter uma resposta precisa e rápida. Coloque o que faz sentido no seu caso e que seja útil para quem for tentar responder.
• Se alguém responder sua questão fazendo mais perguntas ou pedindo mais detalhes, responda assim que puder.
• Se alguém der uma solução que funcione, marque como resposta para que outros possam tirar proveito.
• Se ninguém responder e você conseguir resolver o problema, responda você mesmo à questão e marque sua resposta como resposta da questão. Outros usuários vão agradecer.

Quase todas as questões nesses fóruns são respondidas por pessoas como eu e você, não por funcionários da Microsoft (ou da empresa relacionada à tecnologia/fórum em questão). Estamos fazendo isso em nosso tempo livre para ajudar a evoluir nossa comunidade de desenvolvedores e as tecnologias que usamos. Lembre-se disso ao usar os fóruns.

Seguem mais algumas dicas que também podem ser seguidas:

• Seja educado ao fazer sua pergunta.
• Seja educado com quem está tentando te ajudar. Lembre que, normalmente, ele não é pago para isso e realmente só quer ajudar.
• Não use o tópico de uma pergunta para discutir uma técnologia. Abra um novo tópico de discussão
• Evite fazer mais de uma pergunta em um único tópico
• Não faça propagandas em fóruns, a não ser que o produto em questão resolva a dúvida de alguem.
• Se tiver um tempo, contribua com o fórum tentando responder dúvidas de outros usuários.

A comunidade agradece.

Nesta última parte da série “Criando uma aplicação WPF”, vamos inserir as funcionalidades de cada botão, ou seja, a execução dos processos de inclusão, alteração e exclusão de registros, no inicio da classe ContatoViewModel, adicione as variaveis do tipo RelayCommand , conforme abaixo:

        //Suporte ao ICommand        private RelayCommand _updateCommand;        private RelayCommand _deleteCommand;        private RelayCommand _insertCommand;        private RelayCommand _saveCommand;

A classe RelayCommand é uma das classes de apoio escritas por Josh Smith, em seguida vamos implementar o suporte a ICommand e criar os métodos que executarão as chamadas de cada processo.

        #region Comandos

        public ICommand UpdateCommand        {            get            {                if (_updateCommand == null)                {                    _updateCommand = new RelayCommand(param => Update());                }

                return _updateCommand;            }        }

        public ICommand DeleteCommand        {            get            {                if (_deleteCommand == null)                {                    _updateCommand = new RelayCommand(param => Delete());                }

                return _updateCommand;            }        }

        public ICommand InsertCommand        {            get            {                if (_insertCommand == null)                {                    _insertCommand = new RelayCommand(param => Insert());                }

                return _insertCommand;            }        }

        public ICommand SaveCommand        {            get            {                if (_saveCommand == null)                {                    _saveCommand = new RelayCommand(param => Save());                }

                return _saveCommand;            }        }        #endregion

        #region Métodos

        public void Update()        {

            _base.Update(contatoSelecionado);

            _base.Save(contatoSelecionado);

        }

        public void Delete()        {            _base.Delete(contatoSelecionado);

            _base.Save(contatoSelecionado);

            listaContatos.Remove(contatoSelecionado);

        }

        public void Insert()        {

            contatoSelecionado = new Contato();            contatoSelecionado.Id = 0;

            _base.Add(contatoSelecionado);

            OnPropertyChanged("ContatoSelecionado");

        }

        public void Save()        {

            listaContatos.Add(_base.Save(contatoSelecionado));

            OnPropertyChanged("ContatoSelecionado");

        }

        #endregion

Twitter: @atsh2

INTRODUÇÃO

Boa noite galera!
Veremos neste post, como se trabalhar com validações de campos no Silverlight 4. Há várias maneiras de se validar um campo no Silverlight, seja por DataAnnotations , ou através da interface IDataErrorInfo, que nos fornece métodos para validar dados de forma personalizada.

PREVIEW

Abaixo, temos o exemplo que será demonstrado. Os campos validados serão, campo “Nome” e “Idade”, sendo que a regra aplicada, teremos:

Nome ::    Será um campo obrigatório.
Idade ::    Aceitará somente valores maiores que zero.

Observe na imagem abaixo, o momento de validação de um dos campos, e o feedback ao usuário pelo erro encontrado.

CÓDIGO C#

Abaixo, temos o código em C# que irá constituir a classe Cliente, sendo que ela terá duas propriedades, “Nome” e “Idade”. A classe Cliente implementa a interface IDataErrorInfo, que nos fornece métodos para validação de dados.
Abaixo temos um método que valida as propriedades da Classe, nele passamos como parâmetro qual a propriedade que desejamos validar, e posteriormente criamos nossas regras de negócio referente a mesma, retornando uma “string” do erro personalizado que adotarmos.

    public class Cliente : IDataErrorInfo
    {
		//Propriedades da Classe
        public string Nome        { get; set; }
        public int Idade          { get; set; }

		//Método implementado através da
		//interface IDataErrorInfo
		//Retorna uma mensagem de erro indicando o que
		//está errado com esse objeto.
        public string Error
        {
            get { return null; }
        }
		//Método implementado através da
		//interface IDataErrorInfo
		//Através dele, passamos o nome da propriedade
		//que desejamos validar
        public string this[string columnName]
        {
            get
			{
                switch (columnName)
                {
					 //Validando a Propriedade Nome
					 //e retornando a mensagem de erro
                     case "Nome":

							if ((Nome.Length == 0) || Nome.Trim() == "")
                                   return "O campo Nome é obrigatório.";
                            else
                                   goto default;

					//Validando a Propriedade Idade
					//e retornando a mensagem de erro
                    case "Idade":
                            if (Idade < 0)
                                    return "O campo Idade deve ser maior que 0.";
                            else
                                    goto default;

					//Por padrão, retorna null
                    default:

                                     return null;

                }
             }
        }
    }

CÓDIGO XAML

No código XAML abaixo, temos os dois elementos TextBox que serão validados, observe que o primeiro elemento, o “textBoxNome”, está com a propriedade “Text” vinculada através de Binding, com a Propriedade “Nome”, da classe Cliente; E a propriedade “Text” do elemento “textBoxIdade”, vinculado através de Binding, com a Propriedade “Idade”.
Ambos os elementos estão com as meta-propriedades do Binding, “ValidatesOnDataErrors” e “ValidatesOnExceptions”, setados para “True”, pois é através dessa ativação, que os controles estarão aptos a utilizar os recursos de validação do Silverlight.

		 <!-- Elemento TextBox, vinculado
		  por Binding, a propriedade Nome -->
		<TextBox x:Name="textBoxNome"
				Margin="80,40,16,0"
				Height="25"
				VerticalAlignment="Top"
				Text="{Binding Nome,
					   Mode=TwoWay,
					   ValidatesOnDataErrors=True,
					   ValidatesOnExceptions=True}"
				d:LayoutOverrides="GridBox" />

		  <!-- Elemento TextBox, vinculado
		  por Binding, a propriedade Idade -->
		<TextBox x:Name="textBoxIdade"
				Margin="80,90,190,34"
				Height="25"
				Text="{Binding Idade,
					   Mode=TwoWay,
					   ValidatesOnDataErrors=True,
					   ValidatesOnExceptions=True}"
			   d:LayoutOverrides="GridBox" />

CÓDIGO C#

No código C# abaixo, vamos carregar o DataContext da nossa MainPage, através de alguns dados de exemplo, utilizando a classe “Cliente” implementada, para que os elementos TextBox possam ter suas propriedades “Text”, carregadas e possam utilizar os recursos de validação personalizada que implementamos.

	public partial class MainPage : UserControl
	{
		public MainPage()
		{

			InitializeComponent();
			//Adiciono objeto ao DataContext, para
			//carregar elementos que estão na View,
			//por Binding
            DataContext = new Cliente() {	Nome="Robson Fernandes",
				                            Idade = 21
				                        };
		}
	}

APLICAÇÃO – RUN

Abaixo temos a aplicação final executando.

DOWNLOAD

Fontes Silverlight Completo-> DataValidationApp

Abraços pessoal!

Robson Fernandes

Pós Graduação em Engenharia de Software Centrada em Métodos Ágeis

Objetivo do Curso

O curso de pós-graduação lato sensu em Engenharia de Software Centrada em Métodos Ágeis tem como objetivo principal especializar profissionais para o desenvolvimento de softwares de qualidade. Este curso busca capacitar os participantes para uma visão abrangente e atualizada de engenharia de software e, em especial, capacitá-los em métodos ágeis focalizando nas tecnologias correntes para o desenvolvimento de software. O curso contempla tópicos como métodos ágeis, programação orientada a objetos, padrões de projeto, engenharia de requisitos ágeis , usabilidade, arquitetura e teste de software bem com o desenvolvimento aplicações WEB e RIA (Rich Internet Application). Durante o curso, os alunos exercitarão práticas ágeis integradas às outras disciplinas, proporcionando a transversalidade de conhecimento entre os conteúdos. No final, o aluno estará capacitado a implantar, integrar, liderar equipes ágeis de desenvolvimento de software aplicando técnicas e tecnologias atuais de mercado.

Público Alvo

Profissionais de nível superior das áreas de Sistemas de Informação, Ciência da Computação, Análise e Desenvolvimento de Sistemas e Engenharia que atuam no mercado e que desejam se especializar no desenvolvimento de software com qualidade, flexibilidade e visando o máximo retorno sobre o investimento nos projetos de software, ampliando seus conhecimentos nas metodologias, tecnologias e processos que suportam o desenvolvimento ágil de software.

Resultados Esperados

O resultado esperado do curso é que no final o aluno esteja capacitado a:

• Identificar quais são as vantagens e desvantagem de se adotar uma abordagem formal ou ágil para desenvolvimento de software.
• Implantar processos ágeis em equipes de desenvolvimento de softwares, aplicando práticas ágeis no dia a dia do desenvolvimento e possibilitando que o conceito de auto-gerenciamento funcione.
• Liderar equipes que utilizam métodos ágeis de desenvolvimento.
• Gerenciar projetos com práticas ágeis como o Scrum.
• Desenvolver projetos de software em um em equipes ágeis com tecnologias Web e de Rich Internet Application (RIA)
• Ser um profissional crítico, formador de opinião, que entenda de tecnologia, e que estejam capacitados a integrar equipes ágeis contribuindo para a melhoria da qualidade de software nacional.
• Agregar valor no produto de software por meio da Integração disciplinas de engenharia de requisitos, usabilidade, padrões de projeto, arquitetura e teste de software

Diferenciais do Curso

Entre os principais diferenciais do curso de Engenharia de Software Centrada em Métodos Ágeis da UNA está no seu corpo docente, composto por professores com ampla vivência no mercado de trabalho, sua grade curricular composta de disciplinas teóricas e práticas, com conteúdo em acordo com as exigências do mercado, sintonizado com o pensamento ágil, e, sobretudo, que é o único curso pós graduação lato senso em Engenharia de Software de Belo Horizonte totalmente focado na filosofia ágil.

Estrutura Curricular

(mais…)

Boa noite pessoal!

Esta noticia com certeza vai ajudar muita gente interessada nos novos recursos do SL4. Foi disponibilizado um treinamento online do Silverlight 4.
O curso explica as novas funcionalidades, que o Silverlight 4 trouxe para o ambiente de aplicações RIA. Vocês encontrarão 8 unidades com um total de  25 vídeos que irão auxiliar qualquer desenvolvedor Web a construir aplicações com o Silverlight 4.





Abordagem:


- Trabalhando com vários sandboxed,
- elevação de recursos do navegador,
- Controle RichTextBox,
- Style implícito,
- Drag and Drop,
- Multi touch,
- Validação,
- Autenticação,
- MEF,
- WCF RIA

E muito mais!
Acesse aqui, e conheça os recursos clique aqui.

Obrigado Pessoal!

Robson Fernandes