Archive for July, 2005

O SOA Nosso de Cada Dia

Tuesday, July 5th, 2005

Você ouve, ouve, ouve… mas cadê o SOA de verdade?

Assim como os componentes que nos prometeram que iam abundar as prateleiras, o tal do SOA parece não sair do papel, primeiro dos PDFs de teses acadêmicas, agora do papel brilhante e caro das revistas “top de linha”.

Mas, assim como a componentização, só parece que não está acontecendo. Olhe em volta.

O problema dos componentes e todo o hype formado ao redor deles foi que os componentes tomaram outra forma. Componentes de lógica de negócio são raros, mas qualquer outra coisa pode ser comprada ou obtida de terceiros (ninguém que eu tenha lido falava em como o software livre iria influenciar o mercado de componentes), de geradores de relatórios até clientes HTTP, raramente se precisa escrever algum componente de baixo nível hoje em dia, basta procurar um pronto.

E o SOA? Você já reparou que estamos vivendo na onda das APIs?

E muitas outras, estãos são apenas as dos sites que eu uso constantemente.

Perceba um padrão: são sites. Eles têm uma interface (no caso do flickr uma interface digna de respeito), e teoricamente seu serviço deveria incluir o uso desta. Uhm…deveria?

O que estes sites “vendem” não é a interface. O que o Google Search oferece não é uma caixinha de texto, é uma pesquisa na internet! O maps fotos por satélite e mapas interativos, o flickr organização de fotos por tags… etc.

Isso já atinge o desenvolvedor diretamente em como é importante separar interface de negócio. Interfaces mudam e a tendência hoje é ter algo como o del.icio.us, uma interface web bem fraquinha, mas uma senhora API que pode ser extendida em por browsers, aplicativos desktop e outros sites.

Esqueça a era do VB (ou Delphi se você, como acredito que sim, mora no Brasil ou Rússia). Com o advento dos computadores baratos com monitores coloridos, interface amigável virou lei, a lógica era o de menos (ok, geralmente é o bom e velho “coloca-no-banco-lista-tira-do-banco”). Hojeelinhas bonitinhas são facilmente construídas em segundos com editores gráficos, a lógica de negócios e a integração destas é o que importa.

Essas APIs são baseadas em protocolos leves sobre HTTP, que apesar de bem problemático para aplicações de verdade continua sendo padrão na Internet. Por enquanto, são serviços únicos mas logo em breve você poderá solicitar uma pesquisa assim:

  1. Envia ao Yahoo! e Google um pedido de numero de resutlados para pesquisar “frango da malasia”
  2. Yahoo! informa que achou 482 resultados, Google 379.
  3. Você cancela a pesquisa no Google e pede os resultados do Yahoo!
  4. O Yahoo! debita o referente a consulta (seja dinheiro, seja númerod e consultas/dia) e retorna os resultados num formato XML

Sua aplicação final (o que 99% dos programadores vai fazer nas empresas) vai ser uma telinha chamando serviços disponíveis na rede da empresa e emr edes externas. Hoje você já pode fazer isso.

Bom, eu sou técnico, mas vamos tentar dar uns palpites no ramo dos negócios.

Todos os citados acima são serviços gratuitos ou possuem versões gratuitas. Imaginar um modelo de negócios viável para serviços não é difícil, se baseie em coisas do mundo real. Quando você compra um ticket do metrô, você não compra nada além do serviço de transporte.

Venda tickets para sua aplicação.

Homo Burocraticus

Monday, July 4th, 2005

Esse texto desconexo é um desabafo.

É impressionante como conceitos enganam. O Homo Burocraticus prevalece nas empresas do mundo todo, e raramente alguém percebe que tem algo errado. Será que é evolução?

Você já o viu, certamente. Talvez na baia ao lado, talvez na sua baia. Esta espécie está sempre atrás do mais novo relatório XYZ, sempre querendo saber por que o documento ASD-00321.8 não está marcado para revisão.

Today's Dilbert Comic

As pessoas criaram processos para tentar fazer profissionais de todos os níveis trablharem bem. A idéia é simples: force os programadores medíocres a seguirem um conjunto de processos pré-definidos e burocráticos e eles não terão chance de fazer besteira. Os bons profissionais, como dizem, serão bons em qualquer processo.

Este ambiente criou espaço para uma raça enfadonha que se esconde atrás do processo. Você tem que acreditar no processo, o processo é tudo, é ele quem produz software, não as pessoas.

Reconhecer um ambiente assim é simples, basta ver quando um projeto possui como marco documentação. Note: documentação é importante o suficiente para perder tempo escrevendo-a, mas quando se dá às especificações o mesmo valor que funcionalidade implementada ou qualidade, nós ou estamos construindo um prédio ou estamos em maus lençóis.

Neste lugar, as reuniões são com as mesmas reclamações: “Não pude implementar ABC porque a especificação ainda está em revisão”, “Err.. eu não sabia que não dava pra fazer o módulo B daquele jeito, vou ter que mudar a especificação e isso vai alterar outras coisas”… no fim das contas, sua especificação fica defasada e não serve para nada. Ok, depois você conserta, só que “depois” nunca chega, quando chegar a hora de fazer isso ou já tem projeto novo ou as pessoas deixam o time.

Ao invés de medir a qualidade pelo número de páginas ou abrangência de sua documentação, foque na única documentação que sempre está atualizada: o código. As linguagens de programação de hoje possuem um nível tão alto que já são auto-documentáveis.

Para manter seu código legível o uficiente para servir de documentação crie testes, pratique Domain Driven Design e refatore sempre.

Crie Testes
Programar orientado a testes é uma técnica muito boa, isso já foi dito em muitos lugares e não vou justificar novamente aqui.

Mas criar um teste unitário é utilizar um componente. Fazendo isso, você exercita a interface pública deste e diz quis as condições de erro e de acerto. Uma pessoa nova no projeto que lê o teste já sabe como a classe funciona e quando ela quebra do ponto de vista do usuário.

Pratique Domain Driven Design
Neste contexto, DDD é programar para o domínio. Quando você usa esta técnica, seu software (sua camada de negócios quase sempre) reflete o conhecimento do domínio do seu usário, você modela os conceitos do problema de uma maneira clara no software.

Ao invés de simplesmente criar estruturas de dados e algoritmos, você implementa conceitos e através deles cria um entendimento muito maior sobre o que seu sistema faz para seus usuários, você e para quem for ler seu programa.

Refatore
Refatorando seu código você em primeiro lugar exercita ele na sua cabeça. Para pessoas como eu que simplesmente não conseguem lembrar coisas, isso é inestimável.

Depois, você aumenta a qualidade do código. Quem ler seu código em seguida vai ter muito mais clareza do que quem leu aquela primeira versão, feita com um prazo curto e pressão de gerentes e usuários.

São medidas simples e aplicáveis em qualquer lugar, não é rpeciso que se tenha um processo XP, A, B ou Z.

Se você está preso num lugar onde especificações detalhadas são a ordem da casa, tente criar documentos mais abstratos (aposto que ninguém vai reparar). Não detalhe processos, documente apenas a interface externa do seu componente (que provavelmente outra pessoa vai precisar usar) e descreva em poucas palavras(ou diagramas) o funcionamento interno, utilize o encapsulamento aqui, faça a especificação ser uma interface do seu componente.

Tente colocar uma referência aos testes unitários como parte da documentação, apenas diga onde podem ser encontrados e, talvez (depende do ambiente) como executá-los. Se você está especificando para outro implementar, este pode se guiar pelos testes para entender o que você quis dizer.

Mantenha o documento aberto junto com o código (se sua memória RAM deixar, claro, do contrário imprima uma cópia e use caneta e marcador de texto), e quando for mudar algo drástico, mude o documento na hora. Como você escreveu de maneira abstrata, mudanças na implementação (que são mais comuns do que na interface, queira o bom Zahl) não devem alterar muito o documento.

Não crie documentação que pode ser gerada automaticamnete, como diagramas de classe. Não crie documentação só por criar, se não precisa usar, não crie.

Se você é gerente de projeto, por favor aprenda a medir o andamento do seu projeto de software através de métricas reais. Não sei se você reparou, mas PDF e documento Word não compila, não roda e não dá funcionalidade. O número de diagramas num documento é proporcional ao trabalho que dá atualizar tudo depois e, acredite, tudo vai precisar ser atualizado depois.

Note que eu não estou dizendo para você não especificar ou documentar, estou dizendo para você não gastar esforço em coisas que não trarão valor.

É impressionante….

Monday, July 4th, 2005

Como o orkut só funciona decentemente entre 6 e 9 horas da manhã GMT -3…

JSP Virou Coisa de Gente Grande

Saturday, July 2nd, 2005

Há um bom tempo eu não criava interfaces HTML.

Minhas últimas experiências com HTML, JSP e JSTL foram horríveis, e eu esperava não ter que usar isso tão cedo. Das útlimas vezes havia usado o Velocity para tentar fugir desta coisa horrível.

Eu gosto do Velocity não só por ser mais simples mas porque ele não te induz a colocar lógica em páginas, como scriptlets fazem. Como muitos parecem não saber:

Você não deveria, em hipótese alguma, usar JSP, Velocity, Freemarker ou qualquer outra coisa do gênero para qualquer outro fim que não seja gerar HTML dinâmicamente. A única finalidade destas tecnologias é criar HTML, não fazer processamento.

No meu último projeto, tive que criar uma simples interface web para a gerência de alguns parâmetros do sistema (que utiliza HTTP para sua atividade principal, mas troca mensagens em XML, não HTML) e como não tive muita escolha, resolvi usar as ferramentas padrão J2EE (como sempre, haviam sugerido Struts para uma aplicação CRUD com meia dúzia de páginas e servlets).

Me surpreenndi. Sério.

Claro que como estou sempre em fórums, eventos, palestras já conhecia JSTL, mas eu não sabia que ia efetivamente me dar prazer em usar. Apesar de eu não precisar de muitos recursos, a aplicação ficou bem limpinha e fácil de manter. Para aproveitar e aprender mais, resolvi fazer a interface tableless.

Eu ainda odeio fazer interface web, mas posso dizer que (como, aliás, já disseram no GUJ outro dia) pode-se usar JSP sem perder os poucos cabelos que restam no pobre programador.