Posts

Showing posts from March, 2009

Atualizando o Twitter com Groovy

Alguns dizem que o Twitter vai substituir o blogging eu particularmente acredito que uma coisa não substitui a outra. Até por que a idéia do twitter é atualização simples e freqüente e o blogging é maior volume de informação com menos freqüência. O Twitter é extremamente útil para passar pequenas informações ou dicas, como por exemplo links de artigos, atualizações de software entre tantas outras coisas. Vou mostrar como é fácil atualizar o seu twitter com um script groovy . O Twitter tem uma API REST para acesso as suas informações. Vamos utilizar essa API para atualizar o seu twitter através de um script. Você poderia fazer mais coisas, pois a api permite diversas operação em cima da sua conta no Twitter. Para tal feito vou utilizar um modulo extra do Groovy que é o HttpBuilder , como o nome já diz é um builder que tem capacidade de trabalhar com requisições http através dos métodos POST e GET utilizando JSON ou XML. package com.blogspot.diegopacheco.httpbuildergroovytw

As Diferenças do OpenUp para o RUP

Image
A proveitando a Dúvida de um leitor vim neste post para falar das diferenças do RUP e do OpenUP . Vou focar nos pontos que considero mais importantes destes grandes métodos de desenvolvimento de software. Vamos aos pontos em comum. Ambos são métodos para desenvolvimento de software, o foco desses métodos é a fase de projeto, ou seja, até o momento de colocar o software em produção depois disso é outra história e já não é não é o foco desses métodos. Se você procura um método de desenvolvimento de software baseado em RUP mas está mais preocupado com a pós-construção, manutenção e desativação do mesmo recomendo que você confira o EUP do Scott Ambler . RUP não é cascata! Do contrário de que muitos pensam RUP é um método de desenvolvimento de software iterativo e incremental . O OpenUP também não é um método em cascata. Apesar de muitas vezes ambos serem usados de maneira errada. A proveito para dizer nesse post que RUP/OpenUP tem defeitos sim! E não são dois tipos de bala de prata que r

De força ao Usuário com o Drools parte 3

Nos posts anteriores falei sobre o Drools e como ele poderia ser uma boa solução de BRMS. Agora vou mostrar outra forma de expor uma regra de negocio do seu sistema. A idéia agora é expor as regras com a linguagem do usuário. Isso possibilita que usuário com menor conhecimento de tecnologias consigam modificar o comportamento do sistema de uma maneira segura e eficiente. Recomendo que você leia os dois posts anteriores para uma melhor compreensão deste post: De força ao Usuário com o Drools parte 2 De força ao Usuário com o Drools parte 1 Utilizarei boa parte do código do exemplo anterior. A DSL pode ser internacionalizada para outros idiomas, isso seria útil se o seu sistema roda em diversos países e você tem pequenas variações nas regras de pais a pais. Mas o que é um DSL? D omain S pecific L uanguage são linguagens para domínios bem específicos. Você pode estar pensando que nunca usou isso ou nunca vai usar, se esse for seu caso você não esta ligando o nome a pessoa. E

De força ao Usuário com o Drools parte 2

No post anterior fiz uma contextualização sobre parametrização em sistemas e sobre BRMS. Agora mostrar através de um exemplo simples como o Drools poderia ser utilizado para parametrizações em um sistema. O meu exemplo vai ser simples. A arquitetura esta longe de ser a mais adequada, mas ela é funcional e serve para mostrar como usar o Drools em conjunto com o Spring Framework . Nesse exemplo criei um pequeno modelo de objeto. A idéia principal é mostrar como as regras de negocio são parametrizadas através de uma planilha MS Excel e como isso é processado através de um service que fica no Contexto do Spring. Aqui temos uma aplicação de locação de carros, imagine que o valor do aluguel varia muito, dependendo do humor do locador e da cor e do modelo do carro, então provavelmente você teria que atender a diversas solicitações de mudança para isso. Vamos colocar essas regras de tarifa em uma planilha MS Excel. Não se atenha a baixa complexidade da regra pois meu goal aqui é mostrar

De força ao Usuário com o Drools parte 1

Image
Quem já não ouviu falar mal da TI? Provavelmente você já trabalhou em um empresa em que os outros setores não olham a TI com bons olhos. Talvez por que ali podem estar os salários mal altos da organização, salvo a alta diretoria. Mas o problema não é nem o valor que um profissional de TI chega a receber mas sim o que ele faz para merecer o mesmo. Não venho neste post para falar de gestão de competências para isto deixo com meu amigo Cássio Dias. Mas vi falar em o que poderíamos fazer para dar mais poder ao usuário. Uma das primeiras ações já deve estar bem clara em sua cabeça não? Desenvolvimento iterativo incremental utilizando práticas e métodos. Mas só isso (Não que seja pouco ou fácil) não será o suficiente. Parametrização? A Luz no fim do Túnel? Talvez. Todos querem um sistema parametrizável. Mas toda parametrizarão tem um custo e parametrizar todo o sistema não é viável e muito menos efetivo, por que tem coisas que mudam tão pouco que o retorno não pagaria o esforço, ainda mais

Mudanças no Blog

Fiz mais algumas mudanças no blog neste sábado. Adicionei um novo widget com as 20 últimas postagens na 1ª coluna da esquerda. Além disso fiz uma conta para mim no Twitter e no Yahoo Pipes . Por sinal o Yahoo Pipes é muito legal. Ele é um editor para construção de mashups . Construir meu primeiro pipe fazendo com que ele lesse meu feed do Twitter e remove-se o nome do meu usuário nas postagens, então ele me devolve o pipe via rss, ai foi só consumi-lo em uma gadget do Blogger. Adicionei uma imagem ao cabeçalho do blog, acredito que ele seja auto explicativa, ainda mais se tratando de Java :). Criei também um gadget com meus outros profiles, como linked in, bloglines, e slideshare. Removi a gadget do slideshare por que alem de pesada me dava muita dor de cabeça para ajustar o layout com as outras gadgets. Os comentários agora aparecem em um post-it antes do título do post. Isso foi o que deu mais trabalho para fazer, fazer com que o número de posts aparece-se bem no meio do post-it nã

10 Motivos para Você Usar Maven

Image
Qual desenvolvedor Java que já não fez um script ant ? Ant é uma poderosa solução escrita em Java para automação de build. Eu já usei muito Ant, não tenho nada contra a solução, mas em um projeto você precisa muitos mais do que build. Os scripts ant tem o seu valor, na verdade todo bom script seja ele em ant, bash, groovy ou no que for tem seu lugar ao sol. Não acho perda de tempo escrever esses scripts, mas acho absurdo ter que reescrever a mesma coisa várias vezes. Na prática é isso que acontecia. Quando se inicia um projeto Java se tem um setup muito pesado e que as vezes demora bastante. Por que tem que se criar toda uma infra-estrutura de diretórios, tem que se configurar o framework A,B,C e D para funcionar com o X,Y e Z, bom quem já fez isso sabe a novela que é. Um desenvolvedor novo? Caos No mínimo 2 dias configurando e instalando coisas na máquina do desenvolvedor. Para variar você esquece de algo e começa a dar problemas de ambiente, assim a brincadeira vai até que as cosias

Não esqueça das políticas

Image
Relembrando o post sobre o Banquinho . Que por sinal ainda acho que é uma visão a se ter sobre uma solução completa extremamente viável e simples. Hoje eu adicionaria outros pilares ao banquinho, seria como se fossem as cores secundarias, todas derivadas do bom e velho RGB , por isso não vou fazer mudança no banquinho. Mas vou falar de um pé sub-colateral, falando da rosa dos ventos agora.O ponto em comum entre ferramentas e processos, que estou chamado aqui de políticas. Acredito que esse seja o melhor nome, até por que esse termo é comum em gerência de configurações. Políticas? Hummmm.... Não. Não é esse tipo de política que você deve estar pensando. Falo de políticas de uso quanto a ferramentas, aqui ferramentas e processos se misturam, não falo apenas de workflow de trabalho, mas em formas de uso. Uso de Ferramentas Ferramentas servem diversos propósitos, os que considero mais importantes são: Diminuir o peso do processo Facilitar o trabalho das pessoas Automatizar tarefas repet

Agile Cartoon

Agile Tu Si Foo View more presentations from dmetallica .

Não acredito no Agile 2.0

Com esses quase 10 anos de *agile* algumas coisas mudaram. Antes o Agile era o ator coadjuvante e agora é o Ator principal da cena de desenvolvimento mundial. Esse fato vem sendo chamado de pós-agilismo . De facto o movimento ágil trouxe inovação ao desenvolvimento de software, mas essa inovação vem diminuindo cada vez mais. Tanto é que cada vez mais se vê a tentativa de Rebranding de Agile com Lean . Mas eu não estou criticando Lean neste ponto, acredito que ali existe muito valor e boas práticas que podem ser aplicadas a uma organização, mas o ponto é que Lean != Agile. Lean veio muito antes de Agile e não existe nenhuma linha histórica que mostra e evolução de um ao outro. Agile 2.0 ? Sim esse pode ser um dos efeitos do pós-agilismo. Agile 2.0 seria a nova versão do Agile, entrariam aqui coisas que ficaram faltando na versão 1.0. Na nova versão(2.0) existem tentativas de se aplicar coisas como: O ambiente Corporativo e manutenção de projetos. Qual é o marco para o Inicio do Agi

Desenvolvedor de Luvas e Arquiteto de Frameworks?

Image
Não sou adepto da política que trata o desenvolvedor como um desprovido de inteligência! Muitas vezes vejo que se criam arquiteturas e soluções para proteger os desenvolvedores dos frameworks ou sistemas. Isso é diferente de prover uma arquitetura adequada que diminui a complexidade do desenvolvimento, alguns chama isso de parede, outros chamas de uma grande desperdício de dinheiro. A Solução é evitar a arquitetura? No way! A arquitetura é sobre riscos e diminuir a complexidade do desenvolvimento. Isso significa que temos que pegar as maiores pedras no arquitetura, mas isso não elimina o trabalho do desenvolvedor. Tanto é que o arquiteto se envolve nos pontos mais importantes de Design e isso é diferente de se envolver em todos os pontos. Não se engane com os arquitetos de Frameworks! Já vi direto isso no mercado, muita gente acha que o arquiteto é o cara que mexe com frameworks. Acha que é o cara que decide se vai usar o JSF ou GWT, se vai usar Hibernate ou JPA. Arquitetura de softw

O papel do ESB em uma solução SOA

Image
Usar um ESB virou moda nos últimos meses. Não digo que a tecnologia não seja adequada, mas usar um ESB não significa necessariamente ter SOA. Se você esta interessado em saber o que SOA é ou não é você pode ler este post . Meu objetivo aqui é passar a minha visão sobre ESB e de como e quando ele pode ser usado em uma solução SOA e em soluções que não são SOA. Bus ? Isso mesmo, se formos pela tradução literal significa serviço de ônibus corporativo. A idéia é bem simples o bus leva e traz dados para você, logo você não precisa estar se preocupando com certos detalhes. Imagine que os passageiros são os dados e a cada parada do bus é um sistema que está sendo acessado com por um protocolo diferente. O conceito de bus não é novo na aérea, se olharmos para placas mãe já tínhamos esse conceito lá, ele foi apenas adaptado para integração de sistemas. Na prática usar um ESB nos trás mais abstração do que usar JMS por exemplo. Pois o bus esta em um nível superior, provendo bem mais abstraçõe

Não são Riscos, são seus olhos

Image
Todos os projetos de desenvolvimento de software tem riscos. Não interessa tamanho, domínio, experiência da equipe ou recursos, os riscos estão ai, sempre estiveram e sempre vão estar. Alguns acreditam que gerenciar riscos é gerenciar projetos eu discordo dessa opinião, pois deixa as coisas de uma maneira muito simplista e de facto não é. Não estou falando de rabiscos quando falo de riscos. Estou falando de perigos, ameças e tudo aqui lo que pode prejudicar o sucesso do seu projeto. Então vamos associar a palavra riscos com a palavra perigo ou se você preferir: danger ! Um exemplo de Risco Mas cuidado! Essa é boa não? Bom você não pode ficar entrar em paranóia, mas também não pode seguir o seu projeto sem pensar em como mitigar riscos. Alguém sabe o problema dessa figura? Ela é extrema, claro que é uma sátira. Não existe a menor possibilidade de você estar lidando com todos os riscos do projeto é simplesmente impossível ! De forma divertida é isso que a figura a cima mostra. Mas voc