Mês: agosto 2010

Primeiro contato com o Struts2

Thiago Burgos Programação, Tudo , ,

Essa última semana tive o prazer de conhecer 2 frameworks web que até então não conhecia (mas tinha vontade de conhecer, só faltava a oportunidade). O primeiro deles, que estou conhecendo e trabalhando é o Struts2. Ok, Ok, ok, eu sei que estou conhecendo com alguns anos de atraso 😛 Mas antes tarde do que nunca não é?

Bom, conceitualmente o Struts é um framework MVC, onde a implementação desse padrão é feita com a utilização de 5 componentes: Actions, Interceptors, Value Stack, Result Types and Views. A imagem abaixo mostra mais detalhadamente onde cada componente se encaixa dentro do MVC no struts 2.

O Componente Action é um dos componentes centrais do struts. O fluxo mais comum é ter um JSP chamando alguma Action, que irá processar a requisição e responder alguma string de acordo com o processamento. Essa string respondida pela action deverá passar pelo filtro do famoso STRUTS.XML 😛

Bom, esse “arquivinho” basicamente contem um mapeamento xml de todas as actions, possíveis respostas (strings) e para cada possível resposta um link a ser seguido (como uma outra action por exemplo,  ou um link para qualquer outra coisa). Como você já deve estar percebendo esse arquivo com o tempo e crescimento do projeto tende a ser gigantesco, e ao meu ver manter xml é uma coisa terrível 😛 (por conta disso quando falei de injeção de dependência e spring eu exemplifiquei tudo com annotation para evitar declaração de beans no applicationcontext.xml). Esse arquivo é para mim um dos grandes complicadores do struts e também proporciona diversos erros de Typo,além de exigir uma atenção monstra na sua edição, pois qualquer caractere errado pode lhe ferrar.

Aqui vai um pedacinho de um struts.xml para você terem idéia do que estou falando.

<action name="HelloWorld" class="tutorial.HelloWorld">
      <result name="irParaHelloWorld">/HelloWorld.jsp</result>
      <result name="irParaSiteGoogle">http://www.google.com</result>
      ...
      <result name="acessarOutraAction">Outra!MetodoDesejado</result>
</action>

Lembrando que a linha 5 (que está com highlight) diz que se o retorno da action chamada por “acessarOutraAction” então será chamada a classe de nome OutraAction.java e o método chamado MetodoDesejado. Todas as vezes que uma action é chamada segue-se esse padrão.

Bom, essa foi uma geral do struts, e como eu tinha comentado eu também tive a oportunidade de conhecer o framework wicket então o próximo post será sobre ele, e tentarei fazer algumas comparações com o struts.

Injeção de Dependência e Spring

Thiago Burgos Programação, Tudo , , , , ,

Quem nunca ouviu falar em injeção de dependência? Ou inversão de controle? Pois bem, Inversão de Controle (IoC – Inversion of control) é uma estrategia para inverter quem está no comando de realizar determinadas operações. Quando se fala em inversão de controle, geralmente também se fala no princípio de Hollywood, que prega o seguinte “Don’t call us, we’ll call you” que signfica que a responsabilidade de chamar (ou instanciar/inicializar) alguma coisa não é (mais) sua, e sim de outro alguém.

Não precisa nem falar mas existem diversos tipos de inversão de controle, mas vamos no ater a um tipo específico que é bem conhecido, a Injeção de Dependência. A responsabilidade de instanciar/inicializar uma determinada dependência, não mais pertence a classe que a usa, mas sim a esse outro alguém que comentamos acima (no caso do java pode ser o Spring, e no casos de linguagens mais novas como ruby já existe um controle nativo de injeção).

Spring possui um container de inversão de controle, que tem um Application Context, que é uma espécie de repositório aonde o spring inicializa e guarda cada entidade que você sinalizar que o spring deve controlar (chamados de components ou beans). Uma vez explicitado quais entidades o spring deve controlar, ele já consegue gerenciar e injetar essas dependências em todas as outras entidades que as utilizam (e você explicitou)

Para iniciar, um grande facilitador do Spring são as injeções de dependência via Annotations. Tanto para você configurar quais classes vão ser controladas pelo spring ( @Component ), quanto para você configurar aonde o spring deve injetar as dependências ( @Autowired ). Antes dessas annotations, cada component e cada injeção tinham que ser configuradasem em um arquivo chamado (applicationcontext.xml), só que com essas anotações, basta colocar uma configuração no applicationContext.xml configurando o spring para scanear os pacotes do projeto procurando pelas classes anotadas com essas annotations que comentei anteriormente.

<context:annotation-config/>
<context:component-scan base-package="com.bytesdontbyte"/>
Aqui segue um exemplo de uma classe que estará dentro do applicationContext, pois está anotada com a annotation @Component.
@Component
public class MovieFinder {
    private MovieFinder movieFinder;
    private Movie findMovie(String name) { ... }
}

Neste próximo trecho fictício de código abaixo, o componente declarado acima (MovieFinder) é usado sem ser inicializado, mas como o atributo está anotado com @Autowired,
então o próprio spring injetar a uma instância dessa entidade na classe.

@Component
public class MovieOperations {
    @Autowired
    private MovieFinder movieFinder;

    private boolean isMovieAvailable(){
      boolean result = false;
      if  (this.movieFinder.findMovie("lord of the rings") != null)
          result = true;
      return result;
   {
}

Espero que tenha sido proveitoso para aqueles que estão iniciando neste mundo de injeção de dependências/inversão de controle e etc 😉

Book Suggestion: eXtreme Programming Explained

Thiago Burgos Agilidade, Programação, Tudo ,

Ter o Scrum como forma de gerenciar e acompanhar o desenvolvimento de um software é muito legal. Existem diversos conceitos interessantes de sprints, scrum master, sprint review, retrospective, product owner, etc.  Porém essas coisas estão inseridas no âmbito do gerenciamento e acompanhamento, e quando partimos para o lado mais “código” da coisa precisamos ter práticas, técnicas e princípios que possibilitem o desenvolvimento de forma diferente do que vinha sendo feito a muitos e muitos anos atrás (e ainda continua).

É aí que entra o eXtreme Programming Explained. Esse livrinho de cento e poucas páginas contém informações preciosas a respeito de novas formas de desenvolver software, tendo como preocupação principal um cenário aonde tudo pode mudar, os requisitos podem mudar (embrace change). Nesse livro Kent Beck fala sobre as formas que foram encontradas por ele e alguns companheiros de desenvolver software para o mundo real (o mundo onde as coisas continuamente mudam).

Logo no começo do livro, ele fala que programação extrema não traz nada de novo, ele apenas utiliza coisas que já conhecíamos no mundo do software e leva a níveis mais extremos (daí o nome :P). Por exemplo, se testar unitariamente o código é bom, vamos levar ao extremo, e então testar o código todo e o tempo todo (Test Driven Development). Se fazer revisão de código é uma coisa boa, vamos levar ao extremo e fazer revisão o tempo todo (Pair Programming). Se fazer a integração das partes do sistema e compilar o sistema como um todo é bom para antecipar problemas de integração, então vamos levar também ao extremo e fazer integração o tempo todo (Continuous Integration). Se trabalhar no design da aplicação para ficar o mais coerente e aderente a realidade é bom, então não vamos ter medo de fazer o tempo todo também (Simple Design and Refactoring). Se todos fazem parte da equipe não existe isso de um módulo ou parte do sistema ser de fulaninho, onde só ele modifica, e outra parte é de cicraninho, onde só ele que é o fera nessa parte que pode modificar. Nada disso, o código é de todos (Collective Ownership). Tudo isso sustentado por releases pequenos (Feedback Constante), o já conhecido jogo de planejamento (Planning Game) e testes de aceitação por parte do cliente (Customer Tests).

Essa imagem abaixo mostra as áreas descritas no livro, vale a pena dar uma conferida que é material de primeira.

Scrum Boards fora da parede

Thiago Burgos Agilidade, Tudo , , , ,

Times Ágeis Distribuídos? Parece uma coisa meio paradoxal, uma vez que metodologias ágeis pregam o time junto, unido, um ao lado do outro, de forma a reduzir ruídos de comunicação e até de forma a minimizar uma documentação extensiva (uma vez que estão todos juntinhos e sincronizados).

Sou a favor dessa proximidade física do time e entendo os benefícios, no entanto não podemos virar as costas para o movimento home-office ou mesmo para times distribuídos. Diversas empresas, como IBM, já adotaram home-office, e isso faz parte do dia-a-dia do desenvolvimento de software. Não é preciso nem comentar a respeito do desenvolvimento open-source, onde é praticamente todo distribuído, e ainda assim temos diversos casos de aplicações seguras, de qualidade e que são utilizadas em larga escala,  que foram desenvolvidas de forma distribuída.

Hoje em dia (e já a um bom tempo) temos diversas ferramentas que possibilitam esse desenvolvimento distribuído. Temos ferramentas para comunicação (email, msn, skype, etc…) , ferramentas para controle de versão/compartilhamento de arquivos/desenvolvimento paralelo  (svn, git, cvs, etc…), temos ferramentas de controle de bugs (mantis, trac, jira, etc…), e com o advento do scrum, hoje em dia também já temos ferramentas de scrum board (aquele quadrinho na parede cheio de post-it) on-line, que podem ser acessados pela web.

Como agora eu vou precisar trabalhar num time que utiliza scrum, e vou estar distante do resto do time, comecei a dar uma olhada em algumas ferramentas free de scrum board para começar a testar alguma.

Fiz uma pesquisa básica no velho google e achei algumas opções, mas procurei filtrar as que fosse de graça 😛 As opções que eu selecionei são as seguintes: Project Cards (esse aqui é integrado no eclipse, então não é bom pra gerentes e o povo que não usa eclipse) , FireScrum (bem legal, feito em flex, conheço a turma que trabalhou nele, disponibiliza um dashboard como o da figura ao lado) e SeeNowDo que eu vou falar um pouco mais adiante.

Bom, dentre esses o que me chamou mais a atenção foi o SeeNowDo, pelo simples motivo que oferecia tudo aquilo que eu procurava, gratuito, e rápido de utilizar. Ele oferece o dashboard do scrum (como cores diferentes para post-its de categorias diferentes), permite gerenciar múltiplos projetos, cadastro de sprints/estórias/tasks de forma simples e intuitiva, disponibiliza também o burndown chart das tasks cadastradas, e permite a transição das tarefas entre as colunas do quadro(TO DO/DOING/DONE) via drag and drop.

Ah, só tem um probleminha, você tem que utilizar a base de dados deles, pois não é possível fazer um download e instalar no ambiente da sua empresa/projeto. Então se houver alguma questão de confidencialidade no seu projeto, não é muito legal armazenar todas as atividades do projeto numa base on-line.

É isso, vou continuar minha pesquisa e ver se encontro outras ferramentas legais para scrum boards.

PS. Vale lembrar que tirar os post-its da parede e colocar numa ferramenta dessas é uma atitude também Verde (ecologica).

Menos post-its = menos papel = menos árvores derrubadas.