Posts

Showing posts from January, 2009

Refactoring como meio e Design como Fim

Image
Ainda é muito comum discussões sobre refactoring . Mas sinceramente acredito que boa parte delas perderam o ponto a muito tempo. Refactoring como o próprio Fowler disse é uma técnica sistemática para reestruturar código sem mudar o seu comportamento. Sempre que escolhemos uma abordagem de design como por exemplo: DBC , TDD , RDD , DDD, etc.. estamos levando a solução através modelos consolidados. Esses modelos tem prós e contras e dependendo da situação um vai ser melhor do que o outro. Eu partircularmente gosto muito do modelo do RDD . Mas como chegamos a um modelo solido e eficaz? O design não nasce pronto, deve ser feito de forma incremental utilizando refactoring por exemplo, mas o refactoring não deveria mudar a semantica, logo precisamos de algo mais que refactoring, nesse caso estamos falando de design incremental. Como fazer um bom Design? Para fazer um bom design é necessário conhecimento do dominio! Sem conhecimento do dominio é impossível fazer um design robusto e sustentáv

Como reduzir o peso da gerencia de projetos utilizando o Tracker

Mesmo que você não esteja utilizando XP ou até mesmo Agile , você pode reduzir boa parte da carga de trabalho de gerenciamento de projetos! Um gerente de projetos normalmente tem que ficar atualizando uma seria de artefatos que são utilizados para acompanhar tanto o status do projeto como riscos, requisitos e entre outras coisas. O XP determina uma role que ele chama de Tracker . Essa pessoa normalmente faz a atualização de gráficos, de riscos, do próprio backlog se você utiliza Scrum por exemplo. O XP determina que essa pessoa seria o Tracker de todo o projeto. Eu vejo uma aplicação mais nobre para esse papel, se você desenvolve de maneira iterativa com iterações de 1-4 semanas você pode fazer um roteamento de Tracker. O Tracker não precisa ser a mesma pessoa sempre, o ideal é que esse papel seja um papel rotativo, assim todos ficam mais ciente do que está acontecendo no projeto e um bom peso é removido do gerente. Sem falar que com a rotatividade todos da equipe irão participar das

Swing Fácil com Groovy: Como criar seus próprios componentes

Não tenho dúvidas que o desenvolvimento de aplicações desktop com Java tem seu problemas. Não digo apenas pela estrutura de composite do Swing, ou de classes gigantes com muitas responsabilidades como o JFrame. Mas mesmo com todos esses problemas vejo o desenvolvimento de aplicações Swing para Java ainda com viabilidade. Hoje é dia é comodismo desenvolver aplicações para Web. O que acontece é que nem todos os sistemas ou nem todas as funcionalidades dos sistemas podem ser feitas na web, por que? Complexidade do desenvolvimento com JavaScript Consumo de memória do cliente(Browser) Complexidade de tecnologias Ajax VS problemas de uso de Arquiteturas Commet. Falta de bons IDEs e Debuggers para JavaScript Pouca performance na execução de JS devido a sua arvore DOM. Tempo de desenvolvimento e custo de manutenção Quando desenvolvemos com Swing puro por mais nojento que possa ser ainda assim nos livramos de muitos problemas. Vejam que eu não sou contra o desenvolvimento para web, m

Backup fácil no Ubuntu com Groovy e Groosh

Image
Em um projeto de desenvolvimento de software é comum usar boas práticas de gerência de configuração e ambiente. Essas práticas são na maioria traduzidas em processos de ferramentas. Ferramentas são utilizadas para diversos propósitos como controlar a versão do código ou controlar os buils do projeto ou controlar e gerenciar o bugs e issues do projeto. Normalmente por questões de custo e performance essas ferramentas ficam em um ambiente Linux. Logo não basta apenas ter um bom conjunto de ferramentas que auxiliam no desenvolvimento mas é necessário ter bons scripts de backup também. Utilizando o Bugzilla por exemplo como ferramenta de BugTracking você possuirá uma base de bugs e ocorrências sobre eles. Você não vai querer perder esses dados pois eles são muito úteis para tratar e controlar a evolução doa software mas também para o trabalho de métricas de um profissional de Qualidade de software. Bom já que não queremos perder essas informações precisamos fazer backup. Mas qual a

O Papel do Arquiteto de Software

Quando falamos de um projeto desenvolvimento de software que se utilize Java como linguagem de programação é comum ouvir de alguém que você precisa de um arquiteto de software. Na verdade esta necessidade não é única de projeto Java, independente da tecnologia de implementação dependendo da magnitudede seu projeto você vai precisar tanto de um arquitetocomo você precisaria de um analista ou gerente de projetos. Diferente do que muitos pensam arquitetura não significa escolher frameworks, a arquitetura de software vai muito além do que meramente decidir se no projeto vão utilizar Spring ou Hibernate, Struts ou JSF. Mas qual o papel do Arquiteto de Software? Em poucas palavras é dar suporte e participar de todas as decisões técnicas significativas em termos de design e implementação. Em outros termos estamos falando de riscos, a arquitetura serve para mitigar os principais riscos técnicos de um projeto, veja que eu disse os principais ao invés de todos. Se você trabalha com riscos no s

Apresentações no SlideShare

Criei uma conta no slideshare e coloquei algumas apresentações lá . A partir de hoje vou começar a colocar as apresentações lá. De facto com o Slideshare é mais fácil para visualizar, baixar e compartilhar apresentações. Uma grande vantagem é que ele disponibiliza um objeto para você colocar em seu website ou blog. Coloquei algumas postagens como o novo recurso, vocês podem conferir clicando nos links a baixo: http://diego-pacheco.blogspot.com/2008/12/apresentao-sobre-jboss-drools.html http://diego-pacheco.blogspot.com/2008/03/palestra-aopaspectj-154.html http://diego-pacheco.blogspot.com/2007/08/palestra-de-spring-framework-20.html

Não Existe Separação entre Requisitos e Desenvolvimento

Image
Acho que uma das primeiras coisas que todos aprendemos ou deveríamos ter aprendido na faculdade ou em uma curso técnico (sou do antigo PD) ou até mesmo trabalhando é que o modelo em Cascata é ruim. De facto não é um modelo ruim por natureza, só que para o desenvolvimento de software não funciona! Muitos sabem disso ou pior pensam que sabem, provavelmente qualquer pessoa que você falhe vai concordar com você sobre isto, porem na prática na hora de executar as coisas , o que eu vejo por ai é muito projeto em Cascata até mesmo projetos que se dizem ágeis . É o velho desenho do balanço. Mas a grande questão que esse desenho nos trás é a seguinte palavra: Requisitos . Também não é nenhuma novidade que cada real gasto em requisitos pode ser 60% mais caro em produção. Muitos falam que sabem disso mas na prática eu vejo justamente o contrário. Um sintoma de que as coisas não estão indo bem, sinal de confusão :) é separar as disciplinas em fases ou momentos. Não existe um momento de análise o

Estimando com Scrum

Image
É possível ter um certo nível de predicatibilidade utilizando Scrum . Podemos realizar estimativas de valor com o método. Isso pode ser atingido mesmo com uma certa rotatividade de recursos humanos da equipe. O único requisito é que as iterações tenham o tamanho fixo. Falando de iterações com tamanho fixo isso é variável de projeto a projeto, empresa a empresa. O Recomendável é que isso fique de 1 a 4 semanas, pelo Scrum. Falando de RUP ou EVO por exemplo podemos ter iterações maiores, mas iterações mais curtas já se provaram mais produtivas. A grande questão a se balancear é o overhead de se fazer a retrospectiva do Scrum e abrir a nova Sprint pois esses processos comem tempo! Mas uma vez você escolhendo o tamanho de sua iteração ou como o Scrum chama: Sprint, você deve utilizar esse padrão sempre. Agora podemos estimar, o Scrum recomenda que utilizemos a sua medida abstrata que são os pontos, muitas pessoas utilizam isso em conjunto com User Stories ou até mesmo features. Eu parti

WebService REST fácil com Groovy e Jersey

Como já disse o Jim Webber o WSDL deve morrer! Não tenho dúvidas de que em termos de produtividade e simplicidade utilizar WS-REST é a melhor solução do que utilizar WS-* . Em 2007 já tinham surgido soluções em Java para implementação de WS-REST como o RESTLet . Hoje após a criação da JSR-311 , que dita como criar um WebService REST em Java existem já alguns frameworks que podemos utilizar além do RESTLet como o Jersey . O Jersey é um framework Java que implementa a JSR-311 além de ser a implementação de referência para essa JSR. Com ele podemos escrever WebServices REST de maneira fácil e rápida utilizando um conjunto de anotações. Você pode publicar um WS-REST utilizando qualquer container como o Glassfish, JBoss, Oracle IAS, ou até mesmo o Tomcat. Mas existe um pequeno servidor chamado de Grizzly . Esse servidor é escrito em Java e prove acesso via HTTP e de forma parcial a API de servlets, mas isso é mais do que suficiente para a escrite e disponibilização de um WS-REST. Vou