Welcome to MSDN Blogs Sign in | Join | Help

Arquitetura Prática

Existe um tipo de programador que denominamos na Microsoft como “Programador Prático”. Como o nome diz, ele não está interessado em grandes complexidades ou na tecnologia pela tecnologia. Ele valoriza a simplicidade e a praticidade. Ele ama poder desenvolver rapidamente algo de útil para a sua empresa.

Creio que de certa forma nós arquitetos deveríamos tê-los mais em mente. Nossos conjuntos de classes, bibliotecas e frameworks deveriam ser simples o suficiente para suportá-los. Talvez adicionando linguagens visuais (DSL’s), às vezes promovendo componentes simples para drag-and-drop.

Me pergunto também se não deveriam existir também mais “Arquitetos Práticos”. Utilizando mais a infra-estrutura e produtos de prateleira (ou COTS – Commercial of-the-shelf) e visando resultados rápidos com bom retorno de investimentos.

Entendo a tentação de projetarmos nós mesmo a nossa infra-estrutura – estudamos para isto temos muito prazer e realização nisto. Mas compreendo também que o mercado não comporta o investimento de um framework por projeto ou por empresa. Como na arquitetura civil, existem os casos das construções padronizadas e aquelas em que a arte da arquitetura pode ser plenamente exercitada.

Não sei quanto à experiência de vocês, mas tenho encontrado mais arquitetos com ânsias de artista do que profissionais objetivos e alinhados com a praticidade.

Eis um desafio para a nossa classe: ganhar a maturidade para saber quando ser um ou outro. Ou melhor: como ser os dois!

Posted by Otavio Pecego Coelho | 3 Comments
Filed under: ,

Capacidades e Framework Arquitetural

Quais são as capacidades necessárias para a arquitetura dos sistemas que comumente encontramos na atualidade? Dê uma olhada na figura abaixo...

image

Nela você vê a proposta do Simon Guest, diretor do time de Estratégia de Arquitetura da Microsoft. Para ele as principais capacidades são:

  • Fundamento computação: isto é, onde e como roda nosso software? Virtualizado ou não? Hospedado internamente ou em um fornecedor? Hardware dedicado ou compartilhado?
  • Infra-estrutura: Como é tratada a identidade e autorização? Como são implementadas as mensagens? O armazenamento é estruturado, relacional ou tradicional/baseado em arquivos? O workflow é baseado em eventos ou necessita alto volume/taxa de transferência?
  • Serviços de Aplicativo: uma lista de capacidades que uma aplicação pode exigir, como colaboração, monetização, composição, regras de negócio, BI, Workflow, formatos e protocolos para a exposição de API’s e formato de entrega para a Web.
  • Serviços no Cliente: uso ou não de RIA no browser? Apresentação e comunicação com o dispositivo móvel usando que tecnologia? Idem com o PC e dispositivos incorporados (embedded).

Com esta estruturação, podemos agora compor as capacidades para obter estilos de aplicações.

Exemplos:

Um Wiki costuma ter uma apresentação em HTML e usa fortemente as capacidades de colaboração e armazenamento tradicional. Se for hospedado de modo compartilhado em um fornecedor teríamos a configuração abaixo:

image

Um provedor SaaS, baseado em web, com serviços para clientes off-line poderia ter a seguinte configuração:

image

Infelizmente não achei esta apresentação para passar o link a vocês (se conseguir tomar coragem, tento reproduzi-la eu mesmo nos WebCasts de arquitetura).

Mas o importante aqui é o estilo: pense você também em capacidades antes de montar seu framework para a sua empresa, produto ou família de produtos. Esta é uma forma estruturante de pensar que, creio eu, contribui com melhor reuso e separação lógica entre camadas.

Não se esqueça que pode contar com Stored Procedures

Um caso real: em 98 estava numa sessão de JAD (Joint Application Development) ajudando a definir a tecnologia de um projeto que seria orientado a objetos quando chegamos à questão relatórios. Perguntei ao grupo se iriam usar um gerador de relatórios e ... silêncio. Todos olharam para mim e para o consultor que seguiria com eles na modelagem e construção do sistema. Num salto, o consultor afirmou: "faremos nossos relatórios usando OO".

Perguntei ao grupo se conheciam o impacto desta decisão... silêncio.

Eu tinha duas preocupações: produtividade e desempenho.

Comecei então com meu exemplo costumeiro. Um relatório para listar Bancos, Agências e Contas.

No modelo OO, construímos um loop sobre a lista de bancos, dentro dela outro loop sobre as agências para, num loop final, alcançar as contas. Se não houver um bom mapeamento entre o relacional e objetos, isto costuma provocar um número enorme de selects (1 para os n bancos, n para as m agências e m para as contas = 1*n*m).

Em contraste, usando o poder do join, no relacional, seria possível trazer os dados e uma única querie.

Depois das explicações, voltei ao grupo. Vocês não preferem um gerador de relatórios?

Olhos no consultor. Logo ele nos dá seu ponto de vista: “sou matemático e entendo que temos que uniformizar o modelo de programação para um único modelo: o OO”.

Brincando, respondi: “além de engenheiro sou carioca” (risos – eu estava em São Paulo. Somos famosos aqui pelo jeitinho ou, pior, a malandragem). “Se tiver que misturar meu paradigma para tornar a engenharia e o custo viáveis, não duvido muito.”

Fomos à votação e o modelo OO ganhou. Não usaram um gerador de relatórios.

Ouvi anos depois que o projeto não foi bem. Não sei se por causa dos relatórios, mas desconfio que pela mudança cultural e excesso de idealismo.

Conto isto tudo para poder dar um conselho: é muito bom poder contar com queries Linq que trazem em um único select Banco, Agência e Conta. Mas não se esqueçam que, quando estiverem usando um ORM, o algoritmo tenderá a um ninho de loops sobre a coleção de objetos em memória – o que também é ruim. Neste caso, operações relacionais mais complexas podem ser necessárias. Lembre-se: não tenha medo de usar stored procedures, se necessário.

Entity Framework e ORM's em geral

Estudando e procurando referências sobre o Entity Framework (EF) é fácil encontrar boas discussões sobre seu uso e arquitetura. Nestes momentos, aproveito sempre para generalizar estas discussões para um contexto maior - a classe de produtos ORM’s em geral - uma vez que a crítica é sempre uma comparação com um modelo ideal de ORM. Mas será que existe um?

Uma crítica que li refere-se ao EF não ser uma camada ORM independente e multi-plataforma para ser utilizado por todos os softwares da empresa – o objeto de desejo de um Enterprise Architect. Lembro-me que já existia em 98 produtos nesta categoria de ORM – com cachê de objetos para serem compartilhados por múltiplas aplicações (ver figura abaixo). Na época eu trabalhava numa empresa de ERP e meu medo era um simples VBScript vindo de uma planilha atualizando meu banco de dados sem que o cachê do ORM soubesse. Bem, com certeza, o EF não se coloca nesta categoria. Ele é simplesmente uma tecnologia de acesso a dados através de objetos.

ORM

Outra discussão interessante: devemos fazer um DAO acima do EF? A pergunta tem sentido se considerarmos que novas tecnologias de acesso a dados devem chegar num futuro ainda próximo e que esta talvez nos obrigue a mudar de tecnologia de acesso a dados ou de ORM dos nossos futuros legados. A contrapartida é que este excesso de camadas e sobre-engenharia, além de ter um custo alto para o desempenho, talvez tenha um custo de implementação maior do que o simples refactoring futuro da aplicação. Sinto um cheiro de excesso aqui. Mas já existem até livros sobre este assunto usando o EF, como o Pro Linq Object Relational Mapping.

Por fim, existe a crítica de que o EF não é Persistence Ignorant (PI). Isto é, o EF não permite (ao que parece, ainda, já que existe a promessa de torná-lo PI numa versão futura) que o programador crie uma classe comum e a mapeie contra o banco de dados. No EF, ele deve seguir as regras, herdando de classes e interfaces por exigência do Framework. Por que isto é ruim? Além de contribuir com a PI, ORM’s com esta qualidade facilitam o teste das regras de negócio antes que os dados existam em um repositório, o que é essencial quando usamos o TDD (Test Driven Design). O lado bom costuma ser o desempenho e alta integração com frameworks existentes – como a integração com o Linq e interfaces de bind do .Net Framework.

Tenho cada vez mais pensado e utilizado o EF como um mero acesso a dados. Faço queries Linq nas regras de negócio e trabalho com um ou mais ObjectContext (uma espécie de DataSet que armazena os objetos retornados pelas queries) por thread/transação. Crio diferentes edmx para cada visão ou agrupamento de tabelas segundo o domínio de negócio e uso o System.Transaction para garantir as propriedades ACID nas transações que usam mais de um ObjectContext. Simples, com desempenho aceitável e de alta produtividade. O que de fato espero de um ORM.

Aumente seu Vocabulário

Linguagens Orientadas a Objetos foram tema da minha tese na universidade em 92, mas confesso uma grande atração pelas linguagens funcionais.

Esta semana realizei um desejo antigo: reservei um tempo para leitura de livros sobre ML e F#. Aqui vão alguns comentários:

  • Não tenho problemas com o uso de recursividade – para mim, algoritmos recursivos costumam ser mais limpos. Meu problema maior com eles é o possível estouro da pilha. Bem, pelo menos em F# isto diminui um pouco: funções recursivas onde o último comando é a chamada à recursão reusam a pilha atual para a próxima chamada. Assim o estouro da pilha é evitado. O difícil, às vezes, è transformar nossos algoritmos para só fazerem a chamada nesta última linha (o livro Expert F# dá boas dicas);
  • Alguns mecanismos lingüísticos são simplesmente maravilhosos. Refiro-me a quatro deles em especial:
    • pattern matching: que permite definir tratamentos diferentes de acordo com o padrão (formato e tipos de dados) de uma estrutura de dados;
    • pipes: tornam linear o tratamento em seqüências e outras coleções;
    • inferência de tipos: sempre fui fã de tipos devido ao benefício do erro em tempo de compilação, mas entendo que tipos são restrições que dão trabalho, o que, por sua vez, justifica o sucesso de Python e Ruby, entre outras. Bem, com a inferência de tipos (bem mais poderosa do que a que vemos no C# atual), unimos o melhor dos dois mundos;
  • O livro Expert F# me convenceu que a composição de funções e o uso de interfaces com delegação podem ser mais poderosos do que a herança. O livro tem também excelentes exemplos de código.

Ao final das leituras, sinto que ganhei novos estilos para especificar e escrever código.

Sugestão: aumente você também o seu vocabulário.

Quanto a mim, vou continuar meus exercícios seguindo o velho provérbio chinês: Eu ouço e eu esqueço. Eu vejo e eu me lembro. Eu faço e eu entendo.

Desempenho com Economia

Projetar para desempenho custa caro e é bom economizar energia – gaste apenas quando precisar.

Tenho um caso de sucesso para contar. Em 84, no meu segundo emprego (acreditem, só fiquei 4 meses no meu primeiro emprego - não agüentei o marasmo e pedi demissão), fui designado para implementar o protocolo X.25. Aceitei a tarefa e exigi que fosse implementado em C.

Bem, naquele tempo esta empresa desenvolvia em linguagem de montagem (assembly) e o pessoal achou que ia ter baixíssimo desempenho. Como já tinha desenvolvido um protótipo na universidade, sabia que um X.25 seria grande e, com isto, convenci que em C seria menos custoso.

Grupo montado (éramos 3) implementamos o nível 3 do protocolo e fomos testá-lo. Resultado? No máximo 200bps quando precisávamos de 19200bps!

Lembro-me até hoje de quanto tive que ouvir por causa daquele mau desempenho...

Seguro do que estava fazendo, pedi mais um tempo para fazer otimizações. Colocamos um analisador (profiller) para analisar o comportamento do código e constatamos que 90% do tempo o código estava tratando da interrupção para transmissão e recepção de bytes do hardware. Com isto, focamos apenas neste código reimplementando-o em assembly a partir do código original em C.

Quatro dias de otimizações e fomos para o laboratório testar. Resultado? 21000bps!

Hoje, vejo arquitetos muito preocupados com o desempenho de suas aplicações implementando over-enginnering antes da hora. Isto costuma levar a sistemas complexos, de alto custo para fazer e manter.

Meu conselho: realize provas de conceito testando primeiro as arquiteturas mais simples e pare quando o sistema mostrar que consegue, na média, um desempenho aceitável. Daí em diante gaste tempo e dinheiro apenas com as funções mais críticas. Seu bolso e suas noites vão agradecer.

Posted by Otavio Pecego Coelho | 3 Comments
Filed under:

Fim dos Frameworks caseiros?

A solução simples de três dores de uma arquitetura em 3 camadas mostradas em apenas 2 artigos!

Primeiro artigo: Customize Data Display with Data Binding and WPF do Josh Smith.

Segundo artigo: The Entity Framework In Layered Architectures do John Papa.

Binding de dados e validação de um data entry sempre foi um trabalho relativamente árduo. O artigo do Josh Smith mostra como WPF/Silverlight 2.0 simplificam esta tarefa. Se a separação entre apresentação e código já era um atrativo para o uso de XAML, talvez este exemplo de binding seja o suficiente para que passemos a usar este framework de Interface com o Usuário.

Já o artigo do John Papa mostra como é simples mapear os dados com o Entity Framework – o que antes fazíamos com uma camada de dados nossa – e como usar o WCF para conectar a camada de negócio com a de apresentação. O exemplo é simples e honesto: a camada de apresentação usa um presenter que, por sua vez, chama a camada de negócio para realizar queries e o CRUD. Além disto, ele mostra que o ObjectContext pode (e deve, creio eu) ser criado/destruído à cada transação, simulando o comportamento de de um DataSet. Questões como concorrência e tratamento de erros também são discutidas no artigo.

Se eu tivesse que recomendar alguma leitura para mostrar o quão simples está se tornando programar contra Banco de Dados, eis os dois artigos que eu sugeriria. Afinal, estes são 3 dos problemas que costumeiramente me levaram a criar bibliotecas e frameworks. Sonhava com o dia em que não seriam mais necessários frameworks caseiros. Talvez tenha chegado a hora....

A Cozinha da Composição

Boas novas. Acaba de sair o Composite Application Guidance para WPF. Além de exemplos e código fonte que mostram como compor uma interface gráfica, ele contém também uma referência interessante aos patterns utilizados em http://msdn.microsoft.com/en-us/library/cc707841.aspx. Vale uma olhada.

Composição é umas das técnicas mais importantes da computação e tem ganhado novas armas nestas últimas décadas. Começamos com a composição de estruturas de dados e de funções (funções chamando funções) e hoje chegamos à composição de objetos, componentes, classes genéricas, módulos, etc.

Nos 90, meu sonho era instanciar meu site com comandos como new Site<Session<SQLSession>, Security<Https, Token>, ProcessModel<OutProcess>>. Hoje podemos fazer isto de forma elegante e dinâmica usando frameworks para injeção de dependência como o Unity Application Block.

A composição de funções é uma que por vezes é esquecida, mas que vale a pena ser revisitada. Um exemplo: esta semana estava precisando calcular um produto do quadrado dos valores de um array e logo me lembrei do Linq. Não sou expert em Linq e consegui realizar o produto com dois loops invisíveis. Veja o código:

            double [] l = { 1, 2, 3 };

            IEnumerable<double>  ld = from o in l select o*o;

            double result = ld.Aggregate<double>((x,y)=>x*y);

Insatisfeito com o duplo loop, parti para implementar uma função que recebe como argumentos o tipo da agregação e a operação para cada elemento do array. Aqui está a função:

public class math

{

    public delegate double f(double x);

    public delegate double oper(double x, double y);

 

    static public double fromto(   IEnumerable<double> l,

oper aggregate_op, f func )

    {

            double result = func(l.First<double>());

            foreach (double d in l.Skip<double>(1))

            {

                result = aggregate_op(result, func(d));

            }

            return result;

    }

}

Veja como ficou simples utilizá-la:

            double [] l = { 1, 2, 3 };

            result = math.fromto(l, (x,y)=>x*y, y=>y*y );

Meu ponto: composição é como o molho de um bom design. Usado com simplicidade e elegância pode dar valor renovado ao seu prato principal.

Competição e Tecnologia

A competição no mundo da tecnologia da computação é grande e nem sempre bem compreendida. Em conversas, por vezes me perguntam por que o interesse em comprar a Yahoo? por que HP comprou EDS? por que o Software Aberto é tão importante para a IBM? etc.

Pra compreender melhor este universo, criei um gráfico com duas dimensões: a da complexidade de serviços, e outra que divide a competição entre hardware e software.

Empresas que vivem da complexidade costumam ter exércitos de consultores e, por vezes, tratam do hardware e software como adendos. A IBM, por exemplo, como eu entendo, é hoje uma empresa de serviços complexos que busca aumentar seu faturamento com a venda de hardware e software. Outras, como a Accenture, focam em serviços e criam parcerias com outros fabricantes para compor soluções mais abrangentes.

A Microsoft e o Software Aberto visam o espaço onde serviços são realizados principalmente através de software e plataformas. O serviço feito por profissionais é o adicional, o periférico, que torna viável a implantação do software e costuma ser realizado por terceiros. Neste universo, o hardware é comoditizado para que o software faça a diferença.

Empresas como SAP e Oracle também visam o mercado de software, mas de softwares complexos, que exigem muito serviço para parametrização. Por isto vivem no topo do gráfico.

Podemos plotar no gráfico empresas como HP, que vendem hardware com serviços acoplados, e a Apple que associa hardware e software para criar um universo de dispositivos.

Por fim, empresas como Google , Yahoo e Salesforce, por sua vez, habitam o espaço mais à direita, uma vez que namoram o SaaS. Não há quase venda de serviço, e a forma de pagamento pode ser por propaganda ou por mensalidade.

Se somarmos ao gráfico a área representando o espaço que a empresa ocupa hoje no mercado, ele ficaria algo parecido ao gráfico abaixo (Esta não é uma análise precisa, alguns tamanhos não devem estar corretos. É apenas um rascunho do como eu compreendo a competição hoje).

image

Deste gráfico tendo a inferir coisas interessantes como:

  • Todos visam crescer seu espaço atacando o espaço dos outros. Não há conforto neste universo;
  • Por estar perto da Microsoft, o Software Aberto parece funcionar ora como um batalhão de frente para a IBM, ora como um colchão para evitar a entrada de software MS dentro das corporações;
  • O universo do SaaS é muito atraente devido a vários fatores:

- é ainda relativamente desabitado;

- provê um baixíssimo custo final ao usuário - o que é importante para quem quer habitar à direita do gráfico (mesmo para empresas como a Apple que criam o iTunes que inicia como um complemento ao iPod e pode um dia tornar-se seu maior produto);

- parece estar livre dos avanços do Software Aberto;

  • Empresas com pouca interseção podem estabelecer fortes parcerias ou mesmo se juntar para uma maior sinergia. Isto explica EDS e HP juntas;

Não sou expert em competição nem acompanho ostensivamente os números e movimentações do mercado. O importante aqui é apenas o exercício do raciocínio que torna mais inteligível as mudanças que acontecem no mercado.

Você já fez este exercício para o universo da sua empresa?

Posted by Otavio Pecego Coelho | 2 Comments
Filed under:

Comments Enabled

Sempre tive inveja de outros blogs cheios de comentários enquanto o meu... silêncio. Hoje tenho cerca de 50 mil visitantes mês e todos eles em... silêncio.

Mas o Ramon Durães me salvou indicando que meu template simplesmente não deixava ninguém dar sign in.

Descoberto o bug. Comments Enabled !

Obrigado, Ramon.

Dores Constantes

Nestes últimos anos visitei muitos fabricantes de software tentando ajudá-los com revisões informais da arquitetura. Tenho agora uma lista de erros mais comuns que encontrei e que atrapalham o desempenho na produção:

  • Excesso de comunicação entre camadas;
  • Excesso de dados passando entre camadas (ex.: ViewState);
  • Excesso de dados em variáveis de sessão (onde o mais comum é trazer para a memória todo o resultado de uma query, mesmo que de milhões de linhas, para então fazer a paginação a fim de apresentar em um grid);
  • Locks, muitos locks no banco de dados. Os principais motivos costumam ser:
    • Erros em queries;
    • Falta de uso de hints, quando adequados, como o de ReadOnly;
    • Iniciar e prender cedo demais os recursos, ou liberá-los tarde demais;
  • Excesso de loops com queries, ao invés de fazer uma única query mais complexa (sei que é um tipo de excesso de comunicação entre camadas, mas vale a pena sublinhar);
  • Excesso de passagem de parâmetros por valor. Exemplo: passar por valor um string xml para métodos que extraem certos valores de tags, como conta corrente ou outro;
  • Falta de análise do custo dos algoritmos utilizados;
  • Design ruim do modelo do Banco de Dados (falta de índices, e erros graves no modelo de entidades e relacionamentos);

Para estas dores, sempre recomendo a leitura do livro do Patterns&Practices: Improving .NET Application Performance and Scalability. Mesmo antigo, ainda funciona.

Por outro lado, do lado da governança, eu tenho encontrado muita preocupação com processos de controle e pouco com o de melhoria da produção. É espantoso ver empresas com CMMI alto que não têm como costume hábitos simples e baratos como revisão de código e design, fazer um capacity planning, build e teste diário, teste de stress e análise de risco. Pior: muitas não investem na automação da burocracia destes processos, tornando-os muito caros. Parecem preferir o gasto maior ao longo do tempo do que um investimento inicial alto mais de retorno certo.

Deixei a universidade em 92 e neste tempo pouco se falava sobre estes temas. Minha impressão é que a dor continua.

PS.: Para quem quiser saber mais o como comparar o Retorno de Investimento de um CMMI contra um mero processo de revisão, recomendo o site do David Rico.

Swarm Intelligence e Comunidades

Falei de darwinismo outro dia e me lembrei do sentimento que tive quando entrei na Microsoft em 99. Nesta época existia uma disputa no grupo de produtos entre qual equipe teria o repositório de dados: o time do Exchange, o grupo do SQL ou outro que não me lembro mais. Parecia que haveria uma unificação e, daí, a competição.

Vendo este e outros casos, cheguei a uma conclusão: a Microsoft usa um modelo darwinista, altamente competitivo (interna e externamente), com o benefício da diversidade, e este benefício deveria ser maior que os eventuais malefícios decorrentes da redundância.

Tempos depois descobri outro tipo de algoritmo, de certa forma semelhante aos algoritmos genéticos: os algoritmos de enxames baseados no conceito de swarm intelligence. Imagine uma superfície em 3 dimensões e o problema de achar um pico. Neste tipo de algoritmo, jogamos pontos aleatórios na superfície, damos a eles uma direção também aleatória, e fazemos um pequeno movimento. Neste momento, cada ponto, como abelhas, avalia seu novo estado e também consulta o estado de seus vizinhos. Se algum de seus vizinhos está em melhor posição, ele copia algum de seus valores (como a direção) e o usa para a próxima iteração. Caso não haja vizinho em melhor condição, ele joga os dados para mudar seu estado e continua. Você pode encontrar uma descrição mais completa no livro Swarm Intelligence.

Ainda não utilizei este algoritmo, mas dizem que, com o tempo, são formados diferentes enxames de pontos que caminham em direção aos vários picos da superfície. A chance de um deles chegar ao topo máximo é grande.

Outro fato importante: a velocidade com que encontramos o maior pico costuma ser mais rápida do que a que conseguimos com algoritmos genéticos.

Ao compreender este algoritmo mudei de idéia: a Microsoft, como a toda comunidade (a de tecnologia inclusive), parece ser um grande enxame, onde cada designer ou programador faz seu movimento olhando também para o lado para ver o que está acontecendo ao redor; checar o que funciona ou não, e reavaliar seu próprio comportamento ou design. Este não parece ser uma exclusividade da Microsoft. Outras empresas e mesmo a comunidade Open Source parece seguir estes princípios, entendo eu.

Para mim, isto só reforça a importância das comunidades, troca de idéias e respeito às diferenças. Daí a pergunta:

- E você, já participa de alguma?

Posted by Otavio Pecego Coelho | 0 Comments
Filed under:

Duas dicas rápidas

A primeira: nosso grupo de arquitetos está aumentando e procuramos um arquiteto com bom conhecimento de ALM e desenvolvimento de soluções. Se você estiver interessado, por favor, envie e-mail para mim (otavioc@microsoft.com)

A segunda é um passo-a-passo completo para um exemplo simples de uso do DSL no Visual Studio: o QuizLanguage. Ele foi escrito pelo André Furtado, que já ganhou ImagineCup e hoje trabalha no grupo do Windows. Vale a pena uma olhada em http://www.linhadecodigo.com.br/Artigo.aspx?id=1456.

Boa semana.

Posted by Otavio Pecego Coelho | 0 Comments
Filed under: ,

Goto Algoritmos Genéticos

De tempos em tempos tenho uma recaída e me assusto com o grau de experimentações que são feitas na nossa área.

Templates em C++ é um bom exemplo. É poderoso, mas não é elegante. Difícil de depurar, ele parece não ter tido nenhum modelo de tipos, formal ou não, para auxiliá-lo.

Outro exemplo: AspectJ. Da primeira vez que eu vi AspectJ fiquei assustado. De imediato me veio à lembrança do comando “come from”. Muito antigamente, numa revista chamada Datamation, o autor (Lawrence Clark) escreveu um artigo piorando ainda mais o famoso “goto” tão criticado pelo Dijkstra. Parecia impossível piorar um “goto”, mas ele conseguiu. AspectJ recolocou o comando “come from” no centro da linguagem, fazendo disto a sua virtude. Uma vez me mandaram um link para um artigo de um autor que teve a mesma impressão que a minha... pena que perdi L

Há alguns anos venho seguindo alguns experimentos mais radicais: algoritmos genéticos. São algoritmos baseados no processo de gerar um conjunto de soluções aleatórias, escolher um subconjunto com as “melhores” soluções e, a partir desta geração, criar outra através de operações que misturam partes das soluções maternas (crossover) ou que modificam alguns de seu dados para gerar outros. Darwinismo puro. Ao final de algumas (ou várias) gerações, chegamos a um resultado ótimo ou sub-ótimo. É impressionante como traz bons resultados.

Vi esta semana no channel 9 que este será o algoritmo usado para escolher salas e tracks da conferência chamada PDC que vai acontecer em outubro nos EUA. Daí as lembranças para este blog e uma recomendação final: para quem não conhece os algoritmos genéticos, sugiro a leitura do livro “How to solve it: Modern Heuritics”. É um livro simples de ler e muito interessante.

Alguma coisa fora da nova ordem mundial

Participei nesta terça do julgamento para a categoria Projeto de Software para o ImagineCup. Para minha surpresa, foram oito soluções exemplares de Software + Serviços (S+S).

Celulares tirando fotos, enviando mensagens ou gravando voz para enviar denúncias de desmatamento ou pedidos de coleta de lixo.

Controle de energia à distância, seja a energia da sua casa ou a do seu computador, controlado através do browser ou celular.

Aparelhos novos, com GPS, foto, medidor de temperatura e acidez. Seu uso? Bem, um professor entra no seu Word e cria com ajuda do seu ribbon um trabalho (ou jogo) para seus alunos coletarem dados na rua. Do editor ele clica um botão e lá está o trabalho no site para que os alunos possam dar início à sua coleta e trabalho.

As soluções fluíam com naturalidade orquestrando as atividades entre dispositivos e rede. Mash-ups, conceitos de Web 2.0, tudo presente e apresentado de forma consistente e simples.

Enquanto isto, neste sábado, num jornal da televisão a reportagem avisava que “a memória e o processamento estará todo na rede” ao mesmo tempo em que mostrava processadores menores e mais possantes e interfaces com o usuário novas.

Algo estranho: tanto poder de computação e necessidade de interação nas mãos e os datacenters são anunciados como o centro de tudo...

Será que precisamos de uma noção de centro? O datacenter não é apenas mais uma peça nesta rede que une pessoas e dispositivos?

À tempo: a solução vencedora era também um primor no design da interface gráfica, mostrando toda a força do RIA (Rich Internet Application) e de uma boa workstation.

Posted by Otavio Pecego Coelho | 0 Comments
Filed under: ,
More Posts Next page »
 
Page view tracker