Archive

Archive for the ‘Desenvolvimento’ Category

Longevidade para seu código

No inicio de dezembro, em um periodo próximo ao do JavaOne Brasil, aconteceu o já famoso BelJungle, encontro anual do grupo de usuário Javas do estado do Pará. E como eu andava meio, pra não dizer muito, afastado dos eventos e encontros por rasões obvias [3 mil km de distância faz disso obvio, não?] , resolvi dessa vez ajudar um pouco mais. Claro que toda a parte da divulgação e corrida por patricinio, colaboradores, não foi feito por mim. Mas aproveitei pra compartilhar algumas das experiências que eu andei vivenciando nesse meio tempo que eu passei programando.

Aproveitando a dica, coloco os slides a disposição. Eles estão bem intuitivos, mas qualquer duvida ou questionamento, só usar o blog 🙂

ps: Caso os slides demorem mais que o habitual para carregar, talvez seja melhor baixar a apresentação neste link: http://bit.ly/hg6nB4. É seguro, prometo 🙂

Categorias:Eventos, Java, TI Tags:, ,

Python Brasil chegando

Pessoal, pra quem não conhece, a Python Brasil é um dos maiores eventos sobre Python, e filiados, da América Latina, e nesse ano, como no ano passado, vai ser sediado em uma cidade mega fria: Curitiba. Sempre no fim do inverno, mas a tempo de aproveitar um bom vinho (isso pra aqueles que não são de lá, porque frio só é legal pra turista). Pra mim, uma pena, pois alguns poucos meses depois que eu voltei da terra das araucárias, o mesmo departamento que eu trabalhava vai receber e sediar o evento.

Bom, mas se eu não vou, porque eu to fazendo propaganda? Simples, pelo empenho que eu tenho visto de todos da lista grupy-pr.  Não vou citar nomes (pois posso cair naquele velho problema de deixar alguém de fora), mas um precisa ser lembrado, que é  o Ramiro, que desde a candidatura, tem feito um excelente trabalho, tanto em levantamento de recursos, datas, locais, agências de viagens, palestrantes convidados, palestras iniciais, assim como foi o aquecimento pra Python Brasil, o PythOnCampus.

Pra todos, espero que tenham um grandioso evento, com muita troca de networking e de experiências, e é claro, não deixem de conhecer Curitiba, a tal da cidade modelo. Uma dica de passeio rápido e low cost é procurar o ônibus da linha turismo. É bem legal.

E, se der certo, ano que vem nos encontramos novamente, quem sabe ainda em uma terra um pouco mais quente 🙂

Grails from scratch

Alimentando o já movimentado assunto sobre frameworks para desenvolvimento web, hoje eu apresento uma opção que, acredito eu, será realidade no mercado de software nos próximos anos: Grails. O motivo? Agilidade. Principalmente no presente momento em que todo mundo quer (leia-se precisa) ser ágil.

Em alguns cenários, o principal empecilho pra dar uma acelerada no processo de desenvolvimento/entrega de algum produto, está relacionado com a tecnologia em uso, além é claro de problemas como maturidade da equipe, elevada curva de aprendizado, etc. Quando se foca em tecnologia, algumas questões precisam ser respondidas, como: É possível elevar a produtividade sem, necessariamente, aumentar o esforço? Quais os ganhos eu terei, a curto prazo, com o framework x? Terei como utilizar o código legado com essa nova aplicação?

Em muitos casos, é capaz de você mesmo ter criado a sua solução from scratch para responder essas perguntas. Por outro lado, se você ainda está pesquisando quem poderia melhor sanar essas dificuldades, eu lhe indicaria fortemente o uso do Grails.

O porque de toda essa confiança vem nos próximos slides que apresentam um step-by-step bem básico pra criação do esqueleto de uma pequena aplicação, que utilizei em um minicurso na última semana. Aproveitando a deixa, fica pra quem também tiver interesse.

Lembrando que os exemplos foram todos retirados do livro Getting started with grails.

Dica em JSF: não coloque negócio nos métodos gets/sets

junho 16, 2010 1 comentário

Esse problema começa, primeiramente, com a péssima prática de criar gets/sets indiscriminadamente. Essa é uma cultura que vem de casa, ou melhor, das universidades que ensinam os alunos a criar os objetos sem comportamento, os POJO como são mais conhecidos. Até então não há nada de errado, até porque essa é uma das maneiras mais simples de entender a orientação a objetos. O problema só ocorre quando você leva esse conceito para objetos que não deveriam ser tratados como um POJO.

Vejamos um exemplo: Temos uma classe Estoque, com um atributo capacidadeTotal. Em que momento você usaria o método setCapacidadeTotal no dia-a-dia da aplicação? A não ser que o espaço físico tenha aumentado, é pouco provável que esse método seja invocado. É preciso restringir esse tipo de liberdade para não causar problemas futuros na implementação. A dica por hora é a seguinte: Só crie gets/sets que você tem certeza que serão utilizados no presente momento.

Esse é um problema que poucas pessoam encaram realmente como um problema, visto que não causa danos no código. E como esse é um caso que volta e meia aparece na lista de JSF, esse post serve como tentativa de eliminar esse mau cheiro de dentro do código. Agora mais especificamente no contexto de JSF, vejamos o exemplo do código a seguir:

<h:selectOneMenu required=”true” label=”Origem Recurso”
value=”#{linhaCreditoBean.idcidade}”>

<s:selectItems var=”cidade”
value=”#{linhaCreditoBean.cidades}”
noSelectionLabel=”Selecione” itemValue=”#{cidade.id}”
label=”#{cidade.siglacidade}” />

</h:selectOneMenu>

A maneira mais simples de se implementar o gerenciador desta página é com um atributo List de Cidade, e o método getCidade() com a consulta no banco. Bem claro e simples. Acontece que no decorrer do ciclo de vida do JSF os métodos get/sets são chamados várias vezes, dependendo do estado que o seu bean estiver atuando. O resultado é consultas indevidas e sobrecarga na aplicação.

Uma maneira simples de se resolver é criando um método somente para popular a lista. Além, é preciso avisar ao JSF que esse método deverá ser executado antes dos demais. Isso pode ser feito com a annotation @PostConstruct do JSF, ou a annotation @Create do JBoss Seam. Algo assim:

@Create
public void carregarCidades() {
cidades = dao.recuperarCidades();
}

Veja que é importante criar métodos com esse comportamento, pois no decorrer do ciclo de vida do JSF os métodos get/sets são chamados indiscriminadamente, dependendo do estado que o seu bean estiver atuando, o que gera consultas indevidas no projeto.

<h:selectOneMenu required=”true” label=”Origem Recurso”
value=”#{linhaCreditoBean.idcidade}” id=”cidade”>

<s:selectItems var=”cidade”
value=”#{linhaCreditoBean.cidades}”
noSelectionLabel=”Selecione” itemValue=”#{cidade.id}”
label=”#{cidade.siglacidade}” />

</h:selectOneMenu>

Caminhos para seguir na computação

No ínicio desse mês fui convidado para dar uma palestrar pra um turma de calouros do CESUPA. O foco era dar uma idéia inicial sobre o curso (Bacharelado em Sistema de Informação) e algumas dicas do eles deveriam encontrar, e o que poderiam esperar nos próximos anos de graduação. Acabei focando mais no mercado de trabalho (acadêmico e empresarial), e nas diversas oportunidades que estão disponíveis pra quem quiser (e tiver muita disposição) trabalhar na área de TI.

Pra quem quiser conferir a apresentação, segue os slides.

A síndrome beta

Voltando para o mundo corporativo, vivencio novamente aquilo que eu já havia, em partes, esquecido. Produto sendo entregue com baixa qualidade, prazos não realísticos, processos burocráticos que mais atrasam do que aceleram o time. Essa avalanche de maus cuidados acaba  em quem está no final da cadeia alimentar: os desenvolvedores.

A vivência na academia me mostrou muitas coisas, dentre as quais: Não importa qual o trabalho que você pretende desenvolver, se ele não estiver bem (leia-se *muito* bem) fundamentado, avaliado e testado, você não terá impacto com ele. Nesse caso o usuário (algum  avaliador do seu projeto) será critico o bastante para mencionar que a sua abordagem não está plenamente segura. Métodos, métricas e algoritmos são construídos tão somente com esse propósito, e grande parte do tempo para elaboração destes trabalhos está na avaliação destas medidas de resultados.

Voltando para o meio empresarial, acontece o que eu  chamo de síndrome beta. Algo que está longe de estar pronto, mas é passado para o cliente sob o status de beta , e caso algum problema aconteça, este estaria previamente justificado. Irônico, não?  Quem por volta e meia passa no blog, percebe o quanto eu bato na tecla na questão do teste de software. Muitos simplesmente dizem que tanto estudo é desnecessário. Concordo também que a aplicação de métricas de software é custoso e exige bastante esforço. Mas se abster é jogar a responsabilidade para aqueles que tem o único compromisso de utilizar, e não avaliar o que foi feito.

Parte desse problema é ideológico. Explico. Empresas e gerentes tratam desenvolvimento de software como um processo de fábrica,  inibindo a capacidade de criação e investigação, tão valiosas em um meio que respira dinamismo e inovação. Aplicando esse modelo, espera-se encurtar prazos, aumentando o hall de cliente.

Mas com o curto tempo,  como pensar em testes ou inovação?  O processo deveria ser tratado como uma tarefa artesanal, e não mecânica.

Categorias:Desenvolvimento

Ferramentas para teste de software em Python – Parte 1

Não querendo ser pretensioso demais, esse post vai tentar abordar algumas das ferramentas que podem ser utilizadas no teste de software específicos para linguagem Python, visto que esse é um cenário muito extenso e diversas abordagem podem ser utilizadas. Mas primeiramente, um grande questão: O que deve ser considerado no teste do software? Antes de responder, permita-me voltar um pouco com a história.

Quando se fala em testar, diversas variáveis podem ser consideradas: o custo do teste; o tipo do teste; a cobertura alcançada no código; a capacidade do teste revelar algum defeito, dentre várias outras. Responder a questão anterior está diretamente relacionado com a escolha de alguma destas, ou de outras métricas. E para cada característica, um tipo ferramenta pode ser utilizada. Por essa profundidade, inicia agora uma série de posts relacionados ao tema. Para começar, vamos falar do básico sobre o teste em Python.

Nota: Se você nunca criou testes, nem escreveu uma linha em Python, não se preocupe. Apesar de ser um assunto bastante abrangente, ele é de fácil compeensão.

Motivação

O teste ajuda a definir e restringir o problema em questão. Com ele você de garantir que o software que está sendo entregue ao cliente funciona como foi especificado, com uma maior garantia que no meio da noite não terá ninguém te ligando dizendo que ocorreu uma falha inesperada. Princípios como do Test Driven Development encorajam a escrita do teste antes da escrita do código de negócios. Mas o teste pode ser escrito em várias fases do processo de desenvolvimento. O importante é que ele deve ser escrito.

O primeiro passo é aplicar o teste de unidade. Entende-se por unidade a menor parte testável do programa. Em linguagens Orientadas a Objeto, este pode ser considerado tanto como a classe, quanto o método. Jamais um atributo, pois não existe um comportamento. Python é uma linguagem que pode ser utilizada no paradigma OO, e é também conhecida por ‘vir com as pilhas’ (componentes prontos para uso), logo no teste de unidade não é diferente. O unittest foi o primeiro framework desenvolvido para o teste de unidade, e  ainda é o mais conhecido e utilizado. Este é uma releitura do famoso JUnit, utilizado em programas Java. Para sua aplicação, alguns conceitos precisam ser introduzidos.

  • Dado de teste: É a menor unidade do teste. Verifica dados da especificação para um particular conjunto de entrada.
  • Suite de teste: É uma coleção de dados de teste.

O unittest fornece um rico grupo de ferramentas para construção e execução dos testes. Veremos que é possível satisfazer, com poucas linhas, as principais necessidades do teste de unidade. Para isso, considere o arquivo exemplo1.py, representado pela próxima figura:

O código praticamente fala por sí próprio. Na primeira linha é definido um método reverse aceitando lista como parâmetro. Na segunda linha, a lista é invertida, e em seguida, é retornada. O dado de teste para este código é apresendo a seguir.

Apesar do teste escrito ser bastante simples, ele apresenta as principais características necessárias de um dado de teste. Na primeira linha é feito um import para o unittest. Posteriormente, é criada a classe ReverseTests. O nome Test é necessário, pois informa ao compilador que este é um arquivo de teste. A classe ainda herda de unittest.TestCase. Isso é necessário, pois um dado de teste necessáriamente deve estender essa classe. A linha 5 faz um import específico para o método criado anteriormente, e a linha 6 representa o ponto crucial do teste, chamado assertEqual(). Este método verifica o resultado experado (primeiro parâmetro) com o resultado que é obtido (segundo parâmetro), realizando essa comparação. O último bloco apresenta uma maneira simples para rodar o teste. O método unnittest.main() fornece uma interface em linha de comando para o script. Quando o teste acima é executado, uma saida similar a esta é obtida:

--------------------------------------------------------
Ran 1 tests in 0.000s
OK

Nesse momento, você conseguiu executar o seu primeiro teste. E ele foi bem sucedido. Agora, mude o valor passado no método assertEqual e veja qual será a saida apresentada. Além do assertEquals, outros métodos são de importância: setUp() e tearDown().

O método setUp()é utilizado para preparar variáveis e/ou objeto que vão ser usadas nos métodos de teste. Este método é chamado imediatamente antes de todos os outros métodos de teste. Qualquer exceção lancada por esse método é considerado um erro, ao invez de uma falha no teste.

No caso do método tearDown(), o método é chamado após todos os métodos de teste serem executados. Esse método só vai ser chamando se o método setUp() for executado também. Com a inclusão destes métodos, o nosso arquivo de teste refatorado se tornou o seguinte:

O código acima ficou muito simples e claro, e ainda conseguiu atender todas as nossas necessidades. Estes foram os passos básicos para o teste de unidade ser atendido. No próximo episódio, os caminhos para tornar sua documentação testável. Não perca!

Categorias:Teste de Software