Posts Tagged ‘TDD’

Palestra: Guerrilla SOA – Falando em Java 2009

maio 25, 2009

Guerrilla SOA

palestra de Dr. Jim Webber da ThoughtWorks

Foi uma palestra muito bacana, abordando de forma direta e engraçada um assunto que normalmente traz mais perguntas do que respostas.

Muitas vezes ele encontra muitos sistemas complexos e nestes casos eles utilizam middlewares. Mas ele vai mostrar uma outra opção que utiliza:

  • Agile: pode ser usado em aplicacoes grandes.
  • Web:  Não da forma que conhecemos.

Podemos trazer agile e web juntos

No começo da computação

No começo da computação era comum e normal ter “silos” de aplicações.  Algumas pessoas inteligentes, presenciando esse panorama, enxergaram a possibilidade de dividir e comunicar estes silos de aplicação. Estes caras fizeram muito “encanamento” para juntar estas aplicações.  E isto funcionava, porque de alguma forma os silos estavam ligados entre si. Não era bonito mas funcionava.

Através dos anos, com o desenvolvimento da computação, a competição surgiu e os especialistas de integração se tornaram muito fortes. Eles exercerciam muita influência e se tornaram muito grandes no mercado.

Eles absorveram muita coisa: BPM, Regras de negócio, adapters, GUI tools, segurança, transformations, confiabilidade…. Com isso, mais silos foram integrados e, mesmo assim, não se tornaram muito melhores.

Neste cenário, SOA veio ao resgate destes problemas. Veio para aumentar o nível de abstração, para pensarmos em nosso sistema com uma mente voltada ao negócio. Mas não é para ser implementado da forma que os livros pregam, não focam em processos de negócio, mas em uma visão de TI.

ESB poderia ser uma boa opção, mas ele é ingovernável, porque para ser efetivo todos os sistemas da empresa deveriam estar funcionando no mesmo bus. E se tivéssemos este bus, estaríamos replicando o problema que atualmente temos com os DBAs.  Além disso, esta solução não escala.

Pensando em agilidade

Ninguém pode negar a beleza do modelo tradicional. É mais confortável, parece que podemos prever tudo. Mas, sabendo que não podemos prever tudo, aprendemos ao longo do projeto. Por isso muitos projetos waterfall falharam.

Foi abordada a criação do manifesto ágil, e que os valores ágeis são bem diferentes do tradicional. E que para eles funcionarem tivemos que aprender sobre BDD, restrospectiva, TDD, review e outras técnicas. Aprendemos também a crescer de forma incremental. E temos que fazer isto para desenvolvimento de sistemas complexos e não só para uma única aplicação.

A WEB

A web quebrou regras. Não foi só uma plataforma de publicação, mas de coordenação de tarefas. Quando navegamos em um site como o Amazon, vamos tela a tela… sendo guiados no processo de compras.

A web é protocol-centric, fazendo com que não seja necessário nenhum middleware. É uma rede “burra”, mas que é uma boa idéia.

A rede telefônica é boa em comprar e prover serviços de voz. Quando tentamos utilizar para serviços de dados, chegamos a um limite. A internet é a rede mais burra possível, ela roteia os pacotes independente do que esteja sendo executado.

Tem uma arquitetura que permite o surgimento de inovação, sem que haja previsão do quão grande isso será.

SOA Tradicional

Formada por pessoas de gabinete e programadores no front.

A guerrilha SOA propõe a idéia de quebrar em diversos pequenos passos, como parte de um grande programa de mudança. Devemos dividir os serviços de acordo com os serviços de negócio, deixando com que os responsaveis do negócio definam e sejam responsáveis  por ele.

Devemos priorizar e entregar incrementalmente os serviços, assim damos valor ao trabalho daqueles que estão no gabinete e os que estão no front.

Web e Serviços

A web é um middleware. Ele gastou muito tempo trabalhando em soluções de middleware. E só depois percebeu que a web já fazia quase tudo. E além disso, a Web já está em todos os lugares.

Além disso, a web é incremental, porque podemos fazer deploy de coisas novas sem quebrar o que já existe. Fazendo com que o risco de usar a web seja muito baixo.

O middleware, neste cenário, é opcional. A web pode ser o seu ESB. Se precisar escalar, coloque um servidor proxy para sua aplicação. A Web é projetada para crescer.

As vantagens da tecnologias Web-Centric em comparação da abordagem tradicional:

  • evolutionary design (ao contrario do BDUF)
  • entrega constante (grandes projetos)
  • Mais barato (caro)
  • Incremental (arriscado)
  • Escala da internet (escala da empresa)
  • Tem em todos os lugares (especializada)
  • integração por produto, entregando valor para o produto

Blog:  http://jim.webber.name

Alexandre Gomes, da Sea, fez uma palestra sobre este assunto no lançamento do InfoQ Brasil.

Perguntas que foram feitas

Se SOA é ruim, porque falamos dela tanto?

– Muita gente faz dinheiro com ela.

– Queremos que SOA funcione.

Como usar HTTP para nossos serviços?

– Fornecer os serviços no lado do servidor.

– Implementar melhor máquina de estados no lado do cliente, aprendendo novas técnicas ou reaprendendo técnicas tradicionais.

Quando eu utilizaria SOA dentro de uma empresa?

– Nas mesmas situações que você utilizaria lits distribuídos hoje. usar distribuído por default, REST.

– No ano passado estava trabalhando para uma empresa no Canadá e perceberam que podiam cachear uma boa parte do catálogo utilizando REST. Desde então, ele usa como REST por default. Só não utilizaria em situações onde o tempo de latência deve ser inferior a 1 segundo. neste caso, ele pagaria por isso.

E a TV Digital?

Ele acha que está convergindo com a web, será um aliado natural da Web.

É preciso treinar!

fevereiro 3, 2009

Depois que o Michael Phelps aprendeu a nadar, quanto tempo você acha que ele treinou? E depois que você aprendeu a programar, se você aprendeu algum dia, quanto tempo você treinou? E quando digo treino, é programar sem ter algo para entregar ou corrigir, somente com objetivo de exercitar o conhecimento.

A maioria dos programadores não treina, só programa quando é para “valer”.

Eu estava em um curso de verão no IME e fui apresentado a uma técnica de treino de programação chamada Dojo. Basicamente, esta técnica consiste em reunir pessoas para aprender sobre um determinado assunto. O grupo trabalha em torno de um problema e vai aprendendo junto. A idéia é ter um ambiente onde a pessoa se sinta à vontade para tentar e errar.

As reuniões podem se alternar entre dois formatos:

  • Kata: alguém resolve o desafio em casa e apresenta na reunião “ao vivo”, começando do zero.
  • Randori: o problema é resolvido “ao vivo” pelos participantes, usando TDD e Programação Pareada.

Eu não vou listar tudo aqui sobre o Dojo, ao invés disto, leia o post do Danilo Sato sobre o assunto. Leia, porque lá já fala tudo!

Lá no curso fizemos o Dojo de um projeto bem simples, mas o mais importante foi a troca de informações entre pessoas que conheciam muito, pouco ou nada sobre o assunto. Ao fim da sessão, todos pareciam satisfeitos com o que foi feito, mas fizeram algumas observações:

  • Como fazer se temos pessoas em diferentes níveis? O grupo segue o ritmo dos mais “lentos”, que não conhecem tanto. Desta forma, os mais experientes passam e exercitam o seu conhecimento.
  • Mas se o grupo for muito lento, como vai aprender? A idéia é que as pessoas em grupo aprendam mais rápido do que se estivessem sozinhas. E alguém que manja muito de um assunto, pode ser inexperiente em outro, por isso que a idéia é trocar idéias.

Na próxima segunda eu devo ir no Dojo lá no IME. Qualquer um está convidado, é só querer aprender sobre programação! Vai lá !

Onde:

IME – Instituto de Matemática e Estatística

Rua do Matão, 1010 – Bloco A – Sala 256 – Cidade Universitária

Quando: Todas as segundas-feiras, das 20:00 às 22:00

Saiba mais: visite a página do grupo no Google groups ou o Blog deles.