Parte do trabalho de um arquiteto de software consiste em empregar da melhor forma possível técnicas e boas práticas para construir uma aplicação levando em consideração variáveis como:

- tecnologias disponíveis;
- interesses de negócio;
- durabilidade da aplicação;
- custo;
- expectativa do usuário;
- skill da equipe técnica;
- entre outras.

Trocando em miúdos, uma decisão errada impacta significativamente na consonância entre essas variáveis. Vamos pegar como exemplo um problema conhecido por quem desenvolve software chamado alto acoplamento.

(Aqui em abro um grande parêntesis. O termo acoplamento às vezes é confundido com coesão, contudo são dois conceitos diferentes. Uma classe pode ser coesa e altamente acoplada com outras classes, como também pode acontecer de ser desacoplada de outras classes e possuir baixa coesão. Coesão está relacionado ao Princípio da Responsabilidade Única (PRU), ou seja, se uma classe possui mais do que um motivo para ser alterada, possivelmente ela está fazendo mais do que devia. Já o acoplamento refere-se ao quanto que uma classe depende de outra classe, assim sendo, o ideal seria termos sempre alta coesão e baixo acoplamento.)

Dentre as técnicas mais utilizadas para resolver o problema do alto acoplamento a injeção de  dependência (DI, dependency injection) ressurgiu com grande destaque, em parte graças a crescente prática de testes unitários e desenvolvimento baseado em testes (TDD). Martin Fowler certamente foi um dos grandes responsáveis pela popularização do termo injeção de dependência, considerado-o um tipo de IoC (Inversion of Control). Apesar de não ser nova, diversas bibliotecas de DI, conhecidas como lightweight container, facilitam a utilização desta técnica que, somada ao motivos do seu reaparecimento citados no início desse parágrafo, destacam-na com uma das “modas do momento”.

Um bom arquiteto, na minha opinião, deve tomar suas decisões levando em consideração as variáveis citadas no primeiro parágrafo, elencando uma série de questões pertinentes, e com base nelas procurando as respostas mais sensatas para a sua realidade. Pensando no tema injeção de dependência:

• A aplicação de DI pode representar um risco elevado levando em consideração o skill da equipe?
• A empresa tem como cultura a prática de testes (TDD ou qualquer outra técnica)?
• Se a aplicação não tem previsão de vida longa vale a pena aplicar DI?

E o caminho inverso também deve ser ponderado:

• Eu consigo aumentar o skill da minha equipe aplicando uma nova técnica?
• Eu consigo mostrar os benefícios de praticarmos TDD já que DI nos propicia isso mais facilmente?
• Eu consigo comprovar que os custos com manutenção serão menores se empregarmos melhores técnicas agora, ainda que isso onere um pouco mais o projeto?

Respondidas as questões, imbuído de tranqüilidade e principalmente harmonizando as variáveis em jogo o arquiteto pode partir para a tomada de decisão com mais assertividade. Deste modo, retomando a frase “o ideal seria termos sempre alta coesão e baixo acoplamento”, cabe ao arquiteto entender o quanto desse objetivo deve ser alcançado com o uso de DI.

Lembrem que a acepção da palavra “ideal” não deixa dúvidas:

ideal
adj.
1. Que só existe na idéia.
2. Que reúne toda a perfeição imaginável.
3. Conjunto imaginário de perfeições que não podem ter realização completa.

Arquitetura, Reverberando enterprise library, injeção de dependência, ioc

O título do meu post anterior foi um pequeno gracejo com o intuito de provocar alguma reflexão sobre a participação das pessoas em blogs de tecnologia da informação. Fora a única avaliação do post (de 1 ponto ), nenhum outro tipo de comentário foi realizado, até porque os comentários estavam bloqueados no post, propositalmente.

Vejo aqui no Brasil pouca participação nos blogs de tecnologia comparado com outros países (sempre encontro algum post de autor de blog reclamando da falta de participação), e quando digo participação refiro-me aos comentários. Seja para acrescentar alguma informação que faltou no post, discorrer sobre algum ponto forte ou fraco, dividir alguma experiência, ou até mesmo para sugerir outros assuntos um comentário é um meio rápido de disseminar conhecimento e informação, e infelizmente esse recurso é pouco utilizado (claro, essa é a minha opinião).

Um exemplo positivo com relação aos comentários em blog é a famosa série de posts do Rob Conery, chamada MVC-Storefront, onde além dos posts e vídeos produzidos pelo autor uma participação efetiva dos leitores através de comentários enriqueceram muito o conteúdo do blog. Óbvio, sempre existe aqueles comentários do tipo “Poxa, que legal, parabéns!”, mas no geral o conteúdo ganha um dinamismo providencial com as opiniões.

Acredito que o problema da pouca participação não seja exclusivo dos blogs, percebo que nos grupos de discussão isso também ocorre, com os chamados membros “read only”, pessoas que acompanham as thread como leitores somente.

Enfim, deixo aqui um novo post, com o bom formato Web 2.0, com o mecanismo de comentário habilitado, como de costume. Muito provavelmente não haverá nenhum comentário, ficaria positivamente surpreso se houvesse… Quem sabe, talvez o leitor que avaliou com 1 ponto o outro post possa dar alguma opinião agora, com os comentários habilitados?

Seria melhor imaginar que nada pudesse ser acrescentado? Hummm, acho que não.

Reverberando comunidade

O que vocês acham?

Reverberando comunidade

Sinceramente, não consegui formar uma opinião completa sobre isso:

http://msdn.microsoft.com/pt-br/beginner/bb308754.aspx

http://msdn.microsoft.com/en-us/devlabs/cc950524.aspx

Acho que estou ficando velho… e rápido demais.

Reverberando devlabs

Sempre achei fascinante a engenhosidade das Rube Goldberg Machines, a idéia de realizar operações extremamente simples através de uma engenharia complexa de eventos e ações é fabulosa (como entretenimento, claro). Pra quem não sabia, Rube Goldberg Machines foram originalmente criadas por Reuben Garret Lucius Goldberg numa série de cartoons que ficaram conhecidos internacionalmente. Hoje em dia existem até campeonatos incríveis de inventores que produzem esses aparatos, uma rápida busca no YouTube dá uma boa dimensão da coisa.

Abaixo coloquei um exemplo de uma máquina que tira creme dental do tubo. Repare que uma das ações consiste em fazer um pássaro mover um pino que sustenta um peso sobre o creme dental. Fantástico! Fala sério?

O fato é que, apesar de pitorescas, temos como certo que essas máquinas absurdas nunca seriam construídas na vida real, correto? Bem, infelizmente no desenvolvimento de software não é raro encontrarmos códigos ou soluções técnicas no melhor estilo Rube Goldberg. E a ocorrência deste tipo de problema se estende para analistas de sistema, arquitetos, e por aí vai.

Um desenvolvedor consciente deve desconfiar quando uma atividade simples requer uma grande cadeia de eventos e mecanismos para funcionar, e sempre se questionar se não existe um caminho mais curto e conciso para executar essa tarefa. Soluções muito rebuscadas só servem para dificultar a manutenção e o entendimento do código, ou seja, perda de esforço e investimento.

Se você fizer um retrospecto e chegar a conclusão que participou da construção de “Rube Goldberg Softwares” (com todo respeito aos geniais cartoons de Goldberg), sugiro que estude o quanto antes Design Patterns, técnicas de refactoring, boas práticas das tecnologias e metodologias que utiliza e convença os demais profissionais envolvidos a adotarem a mesma postura. Pode acreditar que vale a pena!

Um pássaro tirando um pino que sustenta um peso… Magnífico! :)

Reverberando boas práticas

No grupo de discussão .Net Architects foi colocado colocado pelo Giovanni Bassi um tópico muito interessante intitulado “Programadores de produção negativa”, onde contribui com o texto abaixo. Convido todos a participarem com suas opiniões aqui e no site do grupo.

No final de 2007 assumi a liderança do time de desenvolvimento da empresa onde trabalho, na ocasião a equipe era muito heterogênea no conhecimento técnico e haviam algumas discrepâncias de Skill x Valor/Hora/Produtividade. A solução só veio com a aplicação de uma prova prática, onde os conhecimentos do candidato eram avaliados numa aplicação real. O tempo que levei para conseguir fechar uma contratação praticamente quadruplicou, contudo, todas as atividades realizadas pelos desenvolvedores que entraram nunca precisaram ser refeitas, a equipe (20 profissionais entre desenvolvedores e analistas de teste) ficou equalizada afinal. Durante a seleção fiquei impressionado com a quantidade de currículos “perfeitos” que chegavam em minhas mãos de pretensos programadores sênior que após a prova se mostravam extremamente ineficazes.

É fato que todos somos responsáveis por esse cenário, pois se deixamos de dispensar um mau desenvolvedor estamos reforçando a idéia de que o mercado comporta esse tipo de profissional. Empresas que contratam alocação de consultorias muitas vezes ajudam a piorar este quadro, uma vez que não utilizam de critérios muito rígidos para selecionar um candidato, imaginam que podem a qualquer momento “estalar” o dedo e substituir o mau desenvolvedor por outro. A falta de algum tipo de categorização profissional, apesar de concordar que não seja a única saída, não dá parâmetros para os contratantes discernirem sobre a justiça no valor/hora pago a um desenvolvedor.

No excelente artigo “A necessidade de se compilar o conhecimento arquitetural” Miha Kralj fala sobre  a profissionalização do arquiteto de software, e creio que muito ainda precise ser feito para desenvolvedores. Acho de extrema valia este tipo de debate, pois devemos lutar para que este estigma acabe o quanto antes.

O que você acha a respeito?

Reverberando ti

É uma pena que o transporte público de São Paulo seja tão caótico, pois não há nada como poder refletir descompromissadamente sobre qualquer assunto durante o percurso para o trabalho. Recentemente adquiri o direito de utilizar ônibus - é... meu carro foi furtado - e me vi obrigado a vivenciar o "melhor" que o trânsito pode oferecer (ok, eu tinha seguro e no momento atual nunca conseguiria vender tão bem o carro, e ele já tinha passado da hora de ser trocado mesmo, então isso nem chega a ser uma reclamação legítima).

O fato é que tenho refletido nas últimas semanas sobre a quantidade de novidades que tivemos esse ano, e entre uma parada e outra um estalo me veio na cabeça:

- É isso, 2009 será o ano onde o paradigma realmente pode ser quebrado em sua totalidade!

Explico-me. Há muito tempo que temos (quando digo "temos" refiro-me aos profissionais de TI) a certeza de que a Web possui um potencial inexplorado, mesmo com sua absurda evolução, uma sensação de subutilização sempre permeou meus pensamentos. Se olharmos a estratégia da Microsoft com bastante atenção podemos observar vários movimentos interessantes. Destaco a seguir o que pude observar para chegar a conclusão da quebra de paradigma, dividida em três frentes.

Para usuários em geral

A Microsoft vem paulatinamente estimulando os usuários a utilizarem os serviços "Live", o novo formato do Windows Live traz novidades bem interessantes, concentrou alguns serviços e criou um conceito mais consistente de rede social. É possível organizar no seu perfil todas as suas preferências de livros, DVD's, filmes, além de compartilhar arquivos pelo SkyDrive que foi um dos serviços agrupados dentro do Windows Live - até o momento o total é de 25GB para armazenamento no SkyDrive, aliás, que nome sugestivo, não? ;) Existe um espaço para publicar as suas "informações sociais" com seus interesses e pessoas de relacionamento. O Windows Live oferece diversas ferramentas gratuitas para mensagens instantâneas, email, fotos, filmes, navegação na Web e blogs.

Talvez a mais importante novidade para end-users em 2009 é o possível lançamento do Microsoft Office para Web. Pensem comigo, o Office já teve todo o seu conceito de usabilidade alterado drasticamente na versão 2007, aliás, um conceito totalmente portável para Web. O padrão de documentos Open XML é simplesmente perfeito para uso na Internet: facilmente integrável com outros sistemas, é um padrão aberto e permite interoperabilidade.

Para profissionais de TI

Os desenvolvedores, através do Live Services, dispõem de diversas tecnologias e ferramentas para criação de aplicações ricas para a Internet. Escrevei um post sobre o Silverlight Streaming, onde mostrei o Deep Zoom Composer. No meu post sobre Photosynth, que faz parte do Live Labs, é possível ver o potencial desta tecnologia e imaginar diversas aplicações para a web, principalmente em usabilidade (mais um desafio para arquitetos da informação).

O Live Services SDK disponibiliza, atualmente, as seguintes opções:

• Live Framework SDK
• Live Services User Data APIs
• Microsoft Virtual Earth SDK
• Live Search API
• Live Services Communications and Messaging APIs
• Windows Live ID SDK
• Microsoft Advertising APIs
• Silverlight Streaming SDK
• Windows Live Agents SDK
• Windows Live Admin Center SDK
• Windows Live Tools for Visual Studio Controls
• Windows Live Spaces SDK
• Windows Live Client Extensibility APIs

Coloquei no SkyDrive para download o diagrama do Live Framework SDK:

O diagrama ao lado mostra a plataforma do Live Services. Escrevei recentemente um post sobre o Live Mesh que, mesmo na versão beta, oferece uma ferramenta para sincronizar informações entre diversos dispositivos (incluindo Mac) bem interessante. Ainda no Live Services você encontra a Mashups Library, uma biblioteca para construção de mashups, combinando dados e conteúdo de diversas aplicações em uma só.

O SQL Services foi o primeiro produto que me chamou atenção, pois acredito que terá uma aceitação muito rápida aqui no Brasil, ele disponibiliza um conjunto de capabilities do SQL Server baseados em nuvens. Alguns dos destaques do SQL Data Services:

• Interface baseada em padrões, como SOAP e REST
• Modelo flexível de dados, sem necessidade de esquema
• Modelo de Serviço - pague de acordo com seu crescimento
• SLAs de negócios
• Geo-replicção e consistência transacional de dados

O SQL Services SDK disponibiliza as ferramentas necessárias para desenvolvimento.

Seguindo a linha de ferramentas baseadas em nuvem o .Net Services disponibiliza funcionalidades para as seguintes áreas:

• Service Bus
• Access Control Service
• Workflow Service

Além do SDK para .NET ainda é possível obter os SDK's para Java e Ruby. Wow! As ferramentas para o Visual Studio permitem a simulação do ambiente hosteado localmente.

Para as empresas

Finalmente, o Windows Azure consolida a grandiosa estratégia da Microsoft, disponibilizando plataformas como serviço na Internet, as famosas "nuvens". Escrevei um pequeno post sobre Azure, indicando um caminho para iniciar os estudos desta nova plataforma.

A minha grande dúvida é se os preços de contratação do Azure serão realmente atrativos, por isso acredito que o SQL Services será o serviço de aceitação mais imediata, até mesmo pela quebra de paradigma que esta plataforma requer. O desenho a seguir ilustra o Azure com todos os seus componentes atuais:

 
Fonte: http://www.microsoft.com/azure/howdoesitwork.mspx

Acredito que a absorção destes conceitos levará um certo tempo, por isso as comunidades de TI serão muito importantes em 2009 na disseminação e, principalmente, para amadurecer o conhecimento. Tratarei em posts futuros as tecnologias abordas aqui, e espero contribuir com minha visão sobre essa iminente realidade. Convido todos a participarem comigo desta jornada (ou poderia dizer, oportunamente, desta viagem?).

Viva o trânsito!

Arquitetura, Azure, Reverberando windows live, silverlight, live services, sql services, .net services, azure

Essa semana o Giovanni Bassi deixou um post muito interessante em seu blog intitulado "O longo prazo e a arquitetura de software", dele foi derivado um tópico no grupo de discussão do .Net Architects onde contribui hoje com o texto a seguir.

Na maioria das situações TI é "catalisadora" no processo, ou seja, você possui um interesse, diversas tecnologias envolvidas e um resultado final para ser produzido. Deste processo TI é o meio capaz de transformar os agentes envolvidos em prol do resultado esperado. É muito frustrante para a equipe técnica saber que uma solução será desenvolvida com baixa qualidade ou, utilizando analogamente os termos do Giovanni, foi mal feita.

O que podemos fazer para sofrermos menos nessas situações é separar a nossa expectativa (que tende a alcançar o software perfeito) da verdadeira realidade de quem "compra" a solução com todos os demais agentes influenciadores ao redor. Muitas vezes um aparente mal resultado pode ter sido o melhor resultado cabível, isso se afastarmos-nos do contexto de desenvolvimento e olharmos muito de cima, bem macro mesmo.

Entendido os pontos acima, chegamos à questão de continuidade e longo prazo, que não nos exime de praticarmos o melhor possível (e cabível) na construção de software. O que acho difícil é alterar o senso comum e o que é comumente aceito, infelizmente somos estigmatizados com diversos rótulos irreais, contudo não fazemos nada para modifica-los, assim tornamos-nos nossos próprios algozes. Muitas vezes acho que o grande empecilho da nossa área é a absurda evolução tecnológica, pois nos impede de solidificar um conhecimento e amadurece-lo para que façamos com qualidade, já que "temos" sempre que correr atrás de uma tecnologia emergente. Como pensar em longo prazo se não conseguimos sequer focar no que estamos fazendo? Perdemos o referencial, invariavelmente.

Reverberando arquitetura, padrões, .net architects