“A maré passou mas ainda há tempo para um cafezinho.”

Venha participar do primeiro Café Ágil em Belo Horizonte!

1. Programação

Cafe da manha: 8:30am – 9am
Palestra 1: 9am – 10am
Palestra 2: 10am – 11am
Palestra 3: 11am – 12pm
Coding Dojo : 12pm – 1pm

2. Palestras

Leia mais no post original aqui

Twitter!

Boas práticas e testes no nosso dia-a-dia de desenvolvimento

Testes unitários já foram vistos com maus olhos pela comunidade de desenvolvimento de software quando surgiram, e hoje em dia é uma das práticas obrigatórias no desenvolvimento da maioria dos sistemas. Mas afinal o que fez todo mundo mudar a maneira de pensar e trabalhar? O que motiva um desenvolvedor a “perder tempo” escrevendo testes unitários?

As respostas hoje em dia são bem claras na cabeça de muitos desenvolvedores, por isso vamos passar por temas que vão além dos testes unitários e abordar como nos beneficiamos a longo prazo com uma política de testes e boas práticas bem definida.

Testando sempre, corrigindo sempre

Já que todos concordam (a grande maioria pelo menos) que testes nos beneficiam, porque não testar em todo o processo de desenvolvimento? Uma dúvida que surge assim que a equipe resolve testar suas classes: devemos estimar também o tempo que levaremos para escrever os testes? A resposta é simples, sim e não. Sim porque com certeza o tempo para executar a tarefa será diferente quando resolvemos escrever testes para nossas classes, e não porque não devemos separar a estimativa, como se escrever testes fossem uma tarefa diferente. Inclusive deveríamos considerar que uma tarefa só é concluída se existem testes unitários que garantem o funcionamento da mesma, e que tais testes estejam passando.

Podemos pensar que se para cada funcionalidade que implementamos garantimos o funcionamento da mesma, estamos seguros para implementar uma nova funcionalidade sem interferir no progresso do sistema até então. A única maneira de garantirmos que toda funcionalidade nova estará de acordo com as já existentes é testando ao longo de todo o projeto. O mesmo vale para testes de uso, feitos por uma equipe de testes, pois se pensarmos que os testes unitários nos protegem de nossos próprios erros, ainda assim não estamos protegidos de erros de sistemas externos que serão usados par integração com o nosso projeto.

O fator mais crítico em se testar sempre, é que quando nos deparamos com um determinado erro, nossa cabeça ainda está no contexto da tarefa ao qual o teste falhou, e portanto está mais claro em nossas mentes como corrigi-la, acelerando a correção de erros e o desenvolvimento de novas tarefas mais futuramente.

Relatórios de Cobertura

Os relatórios de cobertura de testes a primeira vista parecem um ferramenta de controle sobre como estamos desenvolvendo. Muito pelo contrário, porque os relatórios de cobertura apenas expoem as linhas e blocos do código que são executados durante os testes, escondendo muitos outros fatores relevantes no desenvolvimento, além do que é bem fácil “roubar” no teste para obter uma cobertura alta.

O relatório de cobertura serve como ferramenta de alerta para a equipe como um todo, para que a qualquer momento, qualquer membro da equipe possa consultar o relatório e se certificar que dado a cobertura de testes, ele pode continuar o desenvolvimento de suas tarefas ou então, notificar toda a equipe que existem partes do código não testadas e que devem receber mais atenção para garantir uma evolução contínua do sistema.

FindBugs e PMD

O FindBugs é uma ferramenta que nos auxilia no desenvolvimento prevendo possíveis pontos problemáticos do sistema. O FindBugs funciona com o Java mas existem versões para diversas plataformas.

No mesmo espírito do relatório de cobertura, os possíveis bugs apontados pelo FindBugs servem como alerta para a equipe para pontos do sistema que talvez mereçam mais atenção, e da mesma forma é possível “roubar” e sempre deixar o FindBugs “contente”, por isso é essencial a consciência da equipe para manter o FindBugs dentro da linha.

O relatório gerado pelo PMD é mais um guia de boas práticas que deveriam ser seguidas durante a implementação do código. O PMD é bem menos intrusivo que o FindBugs no sentido de que a análise feita por ele é mais voltada a estilo de programação, e pode ser configurada e ajustada de acordo com o projeto e a equipe. O ideal seria que conseguíssemos estabelecer uma configuração do PMD e do FindBugs para a DClick, garantindo que se mudarmos algum desenvolvedor de equipe, o desenvolvedor iria estar familiarizado com as práticas e padrões do novo projeto, afinal seriam os mesmos padrões exigidos no projeto em que o desenvolvedor estava.

Site do FindBugs

Site do PMD

Checkstyle

Um dos principais objetivos de se empregar boas práticas de programação, é garantir uma linguagem comum entre equipes de desenvolvimento. Para facilitar tal compreensão, seria interessante que o código implementado independente da equipe, seguisse uma mesma identação e organização. Dessa forma um desenvolvedor novo no projeto consegueria “se encontrar” no código de maneira mais rápida, porque a estrutura adotada seria a mesma em todos os projetos.

Para facilitar e garantir que o padrão está sendo seguido, existe por exemplo, o plugin de ‘checkstyle’ do eclipse. O plugin nada mais faz do que colocar warnings no código, nos trechos em que o padrão de identação e organização definido não está sendo seguido. O plugin consegue ir um pouco mais longe do que meramente validar formatação de código, e consegue “cobrar” o emprego de algumas boas práticas mais básicas, como por exemplo encapsulamento e gerenciamento de variáveis.

Site Oficial do Checkstyle

Documentação

Se escrever código de maneira padronizada, organizada e compreensível é essencial para comunicação, o mesmo se aplica para a documentação das classes.

Por isso que existem ferramentas como o javadoc, que é uma das ferramentas mais difundidas na comunidade. Isso porque garante a geração de uma documentação livre de código de maneira automática e simples. O que deveríamos ter em nossas classes, é uma documentação na qual não seja necessário ler o código para entender o funcionamento da classe. A única maneira de garantir um nível de documentação desses, é sempre manter a documentação atualizada e constantemente mudá-la conforme desenvolvemos o sistema.

No Java existe o Javadoc que é tão difundido que já vem integrado com o Eclipse IDE, e existem versões disponíveis para todas as grandes plataformas, inclusive Flex.

De modo geral

Apesar de citar algumas tecnologias usadas no Java, o objetivo principal do post é mostrar que o emprego de tais ferramentas nos ajuda no dia-a-dia de desenvolvimento em geral, não importando a tecnologia utilizada. A idéia é atingir um nível de qualidade geral, independente de plataforma. Se atingirmos um nível aceitável e conseguirmos seguir um padrão, conseguiremos migrar entre projetos tendo que apenas entender a regra de negócio do projeto, já estando familiarizado com as práticas de desenvolvimento.

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.

A eXtreme Programmig (XP) proposta por Kent Beck [BECK, 2004] tem o objetivo de propor uma metodologia ágil para equipes de tamanho pequeno a médio, onde o desenvolvendo de software está inserido em um contexto de requerimentos vagos ou que mudam rapidamente.  O próprio autor descreve a Programação eXtrema como: “A XP é uma maneira leve, eficiente, de baixo risco, flexível, previsível, científica e divertida de desenvolver software”. [BECK, 2004].  Ainda segundo [BECK, 2004], a XP reconhece que os projetos precisam dedicar-se à obtenção da redução dos custos e tirar vantagem daquilo que foi economizado. Além disso, defende a não especialização dos membros do time, ou seja, todos participam de todas as atividades, em pares e com sistema de rodízio dos pares o desenvolvimento de infra-estrutura e frameworks durante o desenvolvimento da aplicação, e a comunicação face a face ou por meio de testes eficientes e código cuidadosamente escrito.

Segundo [BECK, 2004], a XP se distingue das outras metodologias por:

• Seu feedback antecipado;
• O planejamento incremental, que gera rapidamente um plano geral que evolui com o decorrer do projeto;
• Sua habilidade de implementar as funcionalidades de forma flexível considerando as necessidades mutáveis do negócio;
• Sua confiança nos testes automatizados;
• Sua confiança em comunicação oral;
• Sua confiança em um processo de projeto evolutivo que dura tanto quanto o sistema;

Risco: O Problema Básico

A principal motivação da Programação eXtrema parte do princípio que o desenvolvimento de software tem falhas na entrega e falhas nos produtos entregues caracterizando o problema básico – o risco, portanto, produz-se software de baixa qualidade. Segundo [BECK, 2004], existem vários riscos associados ao desenvolvimento do software, como: (i) cronograma irreal; (ii) cancelamento do projeto por vários atrasos no cronograma; (iii) o sistema é descontinuado pelo alto custo de se fazer modificações ou a taxa de erros cresce tanto que o sistema deve ser substituído; (iv) o negócio é mal compreendido e o software desenvolvido não resolve o problema original; (v) as regras de negócio mudam antes que o software seja finalizado; (vi) funcionalidades inúteis. A missão da XP é aceitar o risco como problema a ser resolvido, onde o objetivo é encontrar a solução. Nesse sentido, a necessidade é criar um modelo de desenvolvimento de software que trate desses riscos.

Além de mitigar ao máximo os riscos, a metodologia XP advoga que quatro variáveis têm de ser controladas no projeto – custo, tempo, qualidade e escopo. Dessa forma, o modelo desenvolvimento de software é dirigido sob a perspectiva de controlar as referidas variáveis. Em um projeto, as referidas variáveis são restrições inerentes ao produto final. Eventualmente se o custo e/ou o tempo forem escassos, é muito provável que a qualidade do produto entregue possa estar muito inferior àquela esperada no escopo do projeto.  A XP cria valores, princípios de atividades básicas e práticas para tentar conduzir bem os problemas correlacionados à efetivação dos riscos do projeto. Esses valores podem ser caracterizados em:

1. Comunicação: deve ser extremamente aberta e franca. A XP dá uma ênfase especial à comunicação e é essencial para tudo o que acontece no contexto de um projeto. Segundo [BECK, 2004], “Os problemas nos projetos podem ser invariavelmente rastreados a alguém não ter conversado com alguém mais sobre alguma coisa importante”.
2. Simplicidade: é representada na XP pela busca pela “coisa mais simples que possa funcionar” [BECK, 2004]. O propósito é construir algo simples e direto que solucione problemas de hoje e ter certeza de que isso seja suficientemente flexível para ser refinado e expandido de modo a solucionar os problemas de amanhã, mas fundamentalmente não se preocupa hoje com os problemas de amanhã.
3. Feedback: seu objetivo é criar ciclos de realimentação que atuam em intervalos de tempos pequenos como dias e minutos, em relação aos testes de unidade, e, grandes semanas (dias, semanas) em associação a teste de aceitação de usuário, e,  planejamento e cronograma de projeto.
4. Coragem: é o valor que permite aos participantes da XP se aventurarem em projetos de alto risco e alta recompensa nas tarefas de desenvolvimento. Isso muitas vezes se manifesta na forma de desenvolvedores que constroem protótipos descartáveis durante a codificação.

Princípios Fundamentais da XP

De acordo com [BECK, 2004] os princípios fundamentais da XP são:

1. Feedback rápido: o princípio é obter o feedback, interpretá-lo e aplicar o que é aprendido no sistema o mais rápido possível, realimentando o que foi aprendido em dias ou semanas, em vez de meses ou de anos.
2. Simplicidade presumida: este princípio dita que a equipe deve pressupor que todo problema tem uma solução razoavelmente simples. Como conseqüência, o tempo poupado na maioria dos problemas para os quais isso é válido pode ser usado para abordar problemas que realmente necessitem de soluções complexas.
3. Mudanças incrementais: parte do princípio que grandes modificações feitas de uma só vez têm grandes chances de não dar certo. Assim, qualquer problema é resolvido por meio de uma série de mudanças menores.
4. Aceitação das mudanças: este princípio se apóia na premissa da XP que de desenvolver software no contexto de requerimentos vagos ou que mudam rapidamente. As idéias é que os membros da equipe devem simplesmente aceitar as mudanças como algo natural, diário, em vez de algo que ocorre eventualmente.
5. Alta qualidade: ninguém gosta de fazer um trabalho de baixa qualidade. Todos gostam de fazer um bom trabalho. A XP defende que se você não vai fazer algo bem, então não faça independentemente das restrições de cronograma e orçamento.

Atividades Básicas do Desenvolvimento

[BECK, 2004] define quatro atividades básicas associadas ao desenvolvimento de software utilizando XP, sendo elas:

1. Codificar: as práticas da XP utilizam o código como um mecanismo para atingir objetivos secundários incluindo o aprendizado rápido e uma melhor comunicação. Algumas das práticas citadas no tópico a seguir estão ligadas à codificação: refatoração, programação em pares e integração continua.
2. Testar: está fortemente relacionada à codificação. Os desenvolvedores devem escrever códigos de teste de unidade antes escrever o código e verificar se o código passa por todos esses testes antes de se tornar um sistema. O cliente também é envolvido nos testes funcionais, onde os mesmos devem confirmar se o sistema satisfaz as regras de negócio.
3. Escutar: refere-se à necessidade de estruturar a comunicação de modo que as conversas, sempre que possível, envolvam os problemas de hoje, não os de amanha, em um nível de detalhe apropriado.
4. Projetar: está associado a necessidade de criar uma estrutura que organiza a lógica dentro do sistema de modo a torná-lo robusto e possível de manter. Nesse contexto, a prática utilizada é projetar simples.

Práticas do XP

[BECK, 2004] lista algumas práticas que devem ser seguidas pela equipe de desenvolvimento para que os valores, princípios e atividades básicas da metodologia sejam alcançados, são elas:

1. O jogo do planejamento: determinar o escopo da próxima versão de forma que os requisitos mais importantes sejam contemplados e a entrega possa ser um praza não muito longo. Quando o planejado fugir do realizado, então o plano deve ser reajustado.
2. Entregas freqüentes: dividir o desenvolvimento em pequenos módulos de acordo com as funcionalidades de forma que possa ser rapidamente colocado em produção.
3. Metáfora: conduzir o desenvolvimento por meio de histórias simples, compartilhada por todos os envolvidos, sobre como o sistema deverá funcionar.
4. Projeto Simples: o sistema deve ser pensado e projetado de maneira simplista. Complexidades desnecessárias são removidas assim que descobertas.
5. Testes: os programadores escrevem os testes de unidade durante todo o desenvolvimento, o qual deve ser executado sem falha para o desenvolvimento continue.
6. Refatoração: os programadores se preocupam sempre em deixar o código estruturado removendo códigos redundantes, simplificando e aumentando a flexibilidade.
7. Programação em pares: todo o desenvolvimento é realizado por programadores trabalhando em pares.
8. Propriedade coletiva: todos podem alterar o código em qualquer trecho e em qualquer momento.
9. Integração contínua: integre e atualize as versões do sistema várias vezes por dia, cada vez que uma tarefa fora terminada.
10. Semana de 40 horas: como regra, trabalhe no máximo quarenta horas por semana, evitando fazer hora extra por duas semanas consecutivas.
11. Cliente presente: mantenha o cliente o mais próximo possível para responder a questões.
12. Padrões de codificação: os programadores escrevem código respeitando as regras que enfatizam comunicação através do código.

Referência:  BECK, Kent (2004). Programação eXtrema explicada: escolha as mudanças, Bookman, 2004.

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…)

Olá!

Como prometido para meus alunos, neste post vou mostrar um exemplo simples de como fazer teste unitário utilizando o junit. O JUnit é um framework criado por Erich Gamma e Kent Beck com suporte à criação de testes automatizados na linguagem de programação Java.

Não vou entrar muito em detalhes sobre o funcionamento do framework. Recomendo a leitura de:

• JUnit

• JUnit – Teste de Unidade

• Junit.org

• Criando testes com JUnit

Vídeo mostrando como criar uma Suite de Teste

Código fonte da classe TipoTrianguloTest

package triangulo;

import junit.framework.TestCase;

/**
 *
 * @author Edgard Davidson
 */
public class TipoTrianguloTest extends TestCase {

    public TipoTrianguloTest(String testName) {
        super(testName);
    }

    /**
     * Test of eTriangulo method, of class TipoTriangulo.
     */
    public void testETriangulo() {
        TipoTriangulo instance = new TipoTriangulo();
        assertTrue(instance.eTriangulo(2, 2, 2));
        assertTrue(instance.eTriangulo(2, 3, 2));
        assertTrue(instance.eTriangulo(4, 3, 5));
        assertFalse(instance.eTriangulo(4, 3, -5));
    }

    /**
     * Test of possuiValoresNulosNeg method, of class TipoTriangulo.
     */
    public void testPossuiValoresNulosNeg() {
        TipoTriangulo instance = new TipoTriangulo();
        assertFalse(instance.possuiValoresNulosNeg(2, 2, 2));
        assertFalse(instance.possuiValoresNulosNeg(2, 3, 2));
        assertFalse(instance.possuiValoresNulosNeg(4, 3, 5));
        assertTrue(instance.possuiValoresNulosNeg(2, 2, -2));
        assertTrue(instance.possuiValoresNulosNeg(2, -3, 2));
        assertTrue(instance.possuiValoresNulosNeg(-4, 3, 5));
    }

    /**
     * Test of obterTextoTipoTriangulo method, of class TipoTriangulo.
     */
    public void testObterTextoTipoTriangulo() {
        TipoTriangulo instance = new TipoTriangulo();
        instance.atribuirLados(2, 2, 2);
        assertEquals("O triângulo é equilátero.", instance.obterTextoTipoTriangulo());

        instance.atribuirLados(2, 3, 2);
        assertEquals("O triângulo é isósceles.", instance.obterTextoTipoTriangulo());

        instance.atribuirLados(4, 3, 5);
        assertEquals("O triângulo é escaleno.", instance.obterTextoTipoTriangulo());

        instance.atribuirLados(4, 3, -5);
        assertEquals("Os valores não formam um triângulo.", instance.obterTextoTipoTriangulo());

        instance.atribuirLados(4, 3, 50);
        assertEquals("Os valores não formam um triângulo.", instance.obterTextoTipoTriangulo());
    }

    /**
     * Test of obterTipoTriangulo method, of class TipoTriangulo.
     */
    public void testObterTipoTriangulo() {
        TipoTriangulo instance = new TipoTriangulo();

        instance.atribuirLados(2, 2, 2);
        assertEquals(TipoTriangulo.EQUILATERO, instance.obterTipoTriangulo());

        instance.atribuirLados(2, 3, 2);
        assertEquals(TipoTriangulo.ISOSCELES, instance.obterTipoTriangulo());

        instance.atribuirLados(4, 3, 5);
        assertEquals(TipoTriangulo.ESCALENO, instance.obterTipoTriangulo());

        instance.atribuirLados(4, 3, -5);
        assertEquals(TipoTriangulo.INEXISTENTE, instance.obterTipoTriangulo());

        instance.atribuirLados(4, 3, 50);
        assertEquals(TipoTriangulo.INEXISTENTE, instance.obterTipoTriangulo());
    }
}

Código fonte da classe suite

package suite;

import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;

/**
 *
 * @author Edgard Davidson
 */
public class Suite extends TestCase {

    public Suite(String testName) {
        super(testName);
    }

    public static Test suite() {
        TestSuite suite = new TestSuite();
        suite.addTestSuite(calculadora.CalculadoraTest.class);
        suite.addTestSuite(triangulo.TipoTrianguloTest.class);
        return suite;
    }
 }

O código fonte inteiro do projeto está disponível aqui.

No mês passado concluímos mais um projeto. O tempo anda um pouco corrido por aqui, então acabamos divulgando hoje aqui no blog. Desta vez o projeto foi o blog Ameixa Japonesa (ameixajaponesa.com.br), onde o cliente queria melhorar radicalmente o blog antigo, que já fazia bastante sucesso.

Foi um projeto bem interessante e com um tema muito agradável. Uma das principais exigências foi a capacidade de suportar imagens grandes, além de ser possível o cliente administrar tudo com conhecimento técnico zero.

Nosso papel foi migrar do Blogger para algo mais profissional, com um layout renovado e moderno mas “clean”. O resultado foi a transformação do blog abaixo:

Para este novo:

Como foi desenvolvido

Como o blog original estava hospedado no Blogger, nem cogitamos a idéia de mante-lo lá devido às dificuldades de customização da plataforma, o painel administrativo fraco, além de não termos muito controle sobre o servidor.

Codificar um sistema de blog inteiro não estava dentro dos planos, então muitos poderiam argumentar o uso de algum CMS em Ruby. O grande problema é que Ruby possui bons CMS’s, mas nada ideal para blogs quando o objetivo do cliente é algo profissional com vários posts ao dia.

O projetos minimalistas com Enky estavam totalmente fora de cogitação já que o cliente não é técnico e seria preciso algo mais robusto. Mephisto (o que usamos para o nosso próprio blog) é interessante mas está muito abaixo das funcionalidades do WordPress. O Typo parece ter voltado a ser uma plataforma interessante e em constante desenvolvimento, inclusive atualizado para o Rails 2.3.5 e Ruby Enterprise Edition. Porém não chegamos a testá-lo novamente pois já tivemos problemas com ele anos atrás (mas assim que sobrar um tempo vamos voltar a experimentá-lo).

Nós honestamente gostaríamos muito que tivéssemos algo tão robusto em funcionalidades e simples de se usar como WordPress, porém escrito em Ruby. Mas como esta não é a realidade, nos restará apenas o WP.

Antes que comecem a argumentar que o WP é muito bom, nós dizemos que, de fato ele é muito bom se você vai apenas pegar um template pronto e colocar um blog default online. O grande problema do WordPress é a confusão que é o código fonte do projeto, além de ser quase impossível encontrar plugins de qualidade. Então, se você precisa criar um template próprio ou acrescentar funcionalidades na administração, você está por sua conta e de pouco adiantará os milhares de plugins.

Como o serviço é muito bom e a forma como o cliente administra o blog é sem dúvida uma das melhores do mercado, não sobra outra alternativa. O grande problema é que como desenvolvedor Ruby, estamos acostumados com dezenas de boas práticas do mundo Rails como: divisão de ambientes, deploy automatizado, testes automatizados, organização em arquitetura MVC e etc. Este tipo de organização e prática passa bem longe do WordPress.

De qualquer forma, é possível contornar esta situação e criar algo razoavelmente simples de manter. O que fazemos é evitar ao máximo os plugins e criando métodos para ignorar práticas ruins (incentivadas pelo WP) como pegar posts por ID da categoria.

Colocando online

Mais uma coisa que consideramos inaceitável é atualização de plugins e do próprio WordPress direto pelo site. Por isso sempre trabalhamos com atualizações e qualquer alteração localmente. É uma pena não existir esta cultura e o WP não ter sido feito pensando assim. Para remediar o caos que pode ser o deploy, adaptamos uma receita do Capistrano, transformando o deploy tão trivial quanto em Ruby.

Criamos a receita abaixo e versionamos o projeto com Git:

O que ocorre acima é nada mais do que configurar algumas coisas como domínio, repositório git e caminha do projeto no servidor (nada diferente de Rails). A diferença está nas pastas compartilhadas entre cada deploy. Mantemos avatares, uploads, cache e ads em uma pasta compartilhada.

Nós não versionamos o wp-config.php que contém as senhas do DB, então criamos uma tarefa para fazer o upload deste arquivo.

Com tudo configurado agora colocamos as alterações online rodando apenas o famoso comando: cap deploy

Resultado final

O apanhado final do projeto foi um template customizado, feito a partir do zero (sem os lixos como posts por ID da categoria). Quase não usamos plugins, e os existentes foram bem analisados e/ou fizemos vários ajustes. Utilizamos uma forma própria de deploy automatizado via Capistrano com Git. E para terminar, um arquivo de funções gigante que reproduz coisa muita que estamos acostumados no Rails (métodos link_to, image_tag, etc).

Desta forma temos um projeto simples de manter e bem organizado além de atender às expectativas do cliente.

Internet Explorer

Não é novidade que a maior pérola da internet é o Internet Explorer. É incontestável a inferioridade do navegador. E para este projeto seguimos a tendência atual da internet de evitar as versões mais antigas do IE.

No Ameixa seguimos o que já explicamos neste post . O site é compatível com IE6 e IE7 e contém todos os hacks para o layout ficar perfeito nestes e nos demais navegadores. Ao acessar o site com os IE6 e IE7, o usuário é avisado que existe uma nova versão do navegador e que ele deveria atualizá-lo.

O mais interessante é que IE6 não representa nem 5% do usuários do site. O IE representa no geral apenas 30% do tráfego total (mas ficando em 2º lugar). O primeiro colocado é o Firefox, o terceiro o Chrome e o Safari também possui uma boa fatia de acessos.

Este screencast demonstra como utilizar o agente customizado AutoQuick para gravar e reproduzir iterações de um usuário em uma aplicação Flex.

O mais interessante deste agente é poder gravar um script e salva-lo para posteriormente ser utilizado em testes ou apresentações. Eu não entrei no detalhe para modificar o comportamento da biblioteca, com por exemplo, adicionar pausas ao script. Se alguém precisar de ajuda por favor deixe seu comentário.

Vocês vão precisar:
1. da aplicação FlickrDemo feita pelo Beck Novaes;
2. dos arquivos fonte do projeto AutoQuick

Vocês podem consultar a documentação sobre este projeto no live docs.

Veja o vídeo

Teste a aplicação FlickrDemo!

Clique aqui para fazer o download em alta resolução.