Se você fizer um programa em C que precise trabalhar com inteiros muito grandes vai usar long long int, que é um inteiro do tamanho de um double (você pode ver aqui na wikipedia). O resultado disso pode ser devastador e pode ser que valha a pena fazer tudo direto em double. É claro que se você optar por usar somente double terá que tomar cuidado com algumas operações matemáticas porque vão existir casas decimais.

Mas é exatamente disso que os testes de usabilidade tratam, e no final das contas, temos mais é que testar isso tudo mesmo! Eu acho que quanto mais fácil se tornou desenvolver os sistemas, mais preguiçosos ficamos. Explico. Fácil de desenvolver porque hoje temos ferramentas de geração de código (que não existiam até bem pouco tempo) baseadas em padrões de projeto (que não estavam documentados até bem pouco tempo) que nos permitem simplesmente esquecer que certas partes precisam ser feitas. Muitas vezes tudo que precisamos fazer é introduzir pequenos detalhes específicos no código gerado, mas na maioria dos casos nem isso! Ficamos preguiçosos porque os sistemas cresceram, são agora corporativos, é muito menor a demanda de pequenas empresas por seus próprios softwares, com isso o analista que sai da faculdade demora a ter, se é que vai ter, contato direto com o cliente. Os analistas passam a ter um ponto focal centralizado a quem se reportam e acho que isso mascara a responsabilidade levando a uma negligência involuntária.

Antes que eu receba vários ataques de analistas raivosos, não estou aqui falando que todo analista de sistemas (e neste caso estou considerando a dualidade analista/programador) sejam negligentes. Embora eu já tenha trabalhado com muitos que eram realmente negligentes, estou falando aqui de uma negligência involuntária, é mais uma coisa de não fazer porque a percepção é de que o software é para uso próprio e poderemos conversar com o usuário e explicar.

Mesmo que o software seja para uso da própria empresa deve ser desenvolvido com todo o cuidado. Você pode ler mais sobre as minhas impressões sobre análise em:

• Como se faz análise
• Antes de resolver, defina o problema
• Artesanato de Software

Mas agora de volta aos testes de usabilidade. Um problema que temos com os sistemas corporativos é que são muito difíceis de testar pelo alto grau de dependência entre as partes, dessa forma, os testes unitários são quase testes de integração. Uma alternativa é fazer os testes unitários das camadas mais básicas de forma a garantir que estas estão funcionando de forma que os testes das camadas superiores possam se basear nessas camadas, mas se fizermos isso quebramos a possibilidade de paralelizar nossa equipe já que não haverão módulos básicos suficientes para todos. O que acaba ocorrendo é que as pessoas codificam antes de criar seus testes (acredite o Test Driven Development funciona!) e acabam por nunca mais fazer os testes.

Além disso os sistemas corporativos têm uma tendência forte a serem baseados em arquitetura Web ou SOA precisando estar instalados em um servidor de aplicação para executar, o problema disso é que a fórmula:

(a implantação do sistema em um servidor + iniciar o servidor de aplicação) * (obter referências aos componentes a serem testados + executar os testes)

Não é facilmente incluída nos scripts de testes unitários. O que estou pensando em adotar é um esquema de testes semiautomatizado, ou seja, a parte de iniciar o servidor e implantar a aplicação é feita manualmente, a parte de obter referências e executar testes é feita com JUnit.  Até existe um framework JSFUnit, mas infelizmente ele tem uns problemas com o ICEfaces, eu até achei o ponto onde é o problema (depois de baixar o código fonte do JSFUnit e do ICEFaces dos repositórios e gastar umas 4 horas nisso direto), mas precisa de uma modificação no código que ainda não tive tempo de implementar e testar. Embora esta seja uma parte importante, ainda assim não testaria todo o sistema, porque não resolveria a parte dos EJBs e depois de testar com EJBUnit (e mais alguns vários) chegamos a conclusão que não existe um suporte efetivo para essa camada.

Um pouco dessa dificuldade vem do fato que os frameworks *Unit são ferramentas independentes, se a Oracle/Sun adotassem o *Unit como padrão da implementação do Java isso seria incrível para os desenvolvedores, isto porque toda vez que saísse uma nova versão da plataforma e suas especificações já teríamos uma ferramenta de testes para usar.

Estou realmente achando que essa coisa de testes unitários semiautomáticos pode dar certo para a camada EJB.

Uma outra alternativa mais radical (e que na verdade eu gosto muito) é fazer o sistema todo isolado de tecnologias específicas tal como EJB, ou seja, as regras de negócio ficam em classes puramente Java, também conhecidos como POJO – Plain Old Java Objects – algo que em português seria (livremente) traduzido para Bom e Velho Objeto Java. Isto funciona porque os POJOs podem ser facilmente testados com JUnit básico, e se você usar o EJB apenas para envolver os POJOs então você garante que as regras de negócio estão sendo testadas o que já é um grande alívio. Mas porque então não tem muita gente fazendo isso?

Para separar as regras de negócio você terá mais uma camada, mais um nível de indireção e consequentemente mais classes para gerenciar. Acredito que esta seja a maior barreira para se adotar essa prática, mas eu vou criar um sistema de testes (digo sistema, porque para testar esse tipo de coisa não adianta criar uma classezinha de teste) para avaliar o impacto de se criar essa camada extra.

Outro fator é que muitas vezes as regras de negócio têm dependências de dados que precisam ser supridas, se você conseguir prever todas as necessidades de acesso a banco de dados por exemplo e executar isso antes de chamar o método fica mais fácil de tratar, mas as vezes precisamos fazer uma busca em banco no meio de um processamento de regra de negócio. Aí começa o dilema, porque se você usa JPA com EJB, então terá uma dependência do servidor de aplicação para resolver isso e quebramos a automatização do teste de novo. É claro que você pode usar Mock Objects, uma técnica de fornecer objetos que fingem ser os que realmente precisamos para efeitos de teste, mas ainda assim você terá uma proliferação de classes muito grande.

Assim que eu tiver resultados vou colocar aqui.

Resolvi então baixar um programa de benchmark, mas só achei um bem velho (que usa como referência o Pentium 90, ou seja, muito velho) chamado nbench. Tentei rodar o programa, mas na versão 32 bits do linux não funcionou legal, só que como o autor explica esse não é um benchmark para máquinas multi-core, resolvi que vou adaptar (mas devagar né?) o programa (que já está pronto) para uma versão paralela a fim de testar máquinas multi-core.

De qualquer forma não serviu para o que eu queria, então resolvi fazer o mais básico possível, um simples programa de multiplicação de matrizes, baseado em pthreads usando memória compartilhada e rodar ele nas 3 máquinas a fim de chegar a alguma conclusão. Aí sim fez diferença! Para começar já abusei do gcc colocando os parâmetros -O3 e -march=amdfam10, que segundo o guia de referência da própria AMD são opções de otimização agressivas, com essas opções os resultados foram impressionantes! Depois eu coloco os números, mas o Phenom ficou 4x mais rápido que o Turion.

Agora quando utilizo a máquina virtual Lua com paralelismo, o programa no Phenom fica 2x mais lento que no Turion, ainda não consegui desvendar o mistério, acredito que tem a ver com erros de cache, troca de contexto e com a impossibilidade de aplicar as mesmas otimizações, o que me incomoda é que eu esperava pelo menos que ficasse igual, mas não pior.

De volta a prancheta.

Usando, BOINC, a mesma plataforma do projeto SETI@home (dedicado a procurar por vida extra terrestre), o projeto MilkyWay@home está aproveitando a colaboração de usuários do mundo todo para calcular de forma distribuída para mapear a forma de nossa galáxia. Atualmente essa plataforma superou, em poder de computação o segundo supercomputador mais rápido do mundo (atualmente claro, porque essa lista sempre muda, nota mental: “eu quero um supercomputador”) atingindo um petaflop (peta = 1.000 giga = 1.000.000 mega = 1.000.000.000 kilo = 1.000.000.000.000 operações de ponto flutante por segundo.)

Em paralelismo usamos essa conta de operações em ponto flutuante por segundo porque são as operações mais pesadas para um computador executar E são muito utilizadas em sistemas de computação científicos.

Na página do projeto BOINC podemos achar uma lista de projetos que usam essa plataforma variando de aplicações em astrologia, bioinformática até a jogos e aplicações matemáticas (eu já disse que eu quero um supercomputador?)

O interessante é que qualquer pessoa pode participar, basta instalar um programa em sua máquina que funciona de forma semelhante a um screensaver, ou seja, quando você deixa usa máquina parada (sim, quando você vai para o banho e deixa a máquina ligada baixando coisas) o programa entra em ação, recebe dados do servidor central e começa a usar o poder de processamento (calma, não vai atrapalhar seu download) para calcular alguma coisa útil para a humanidade.

Um projeto bem legal, mas que não consegui determinar se usa a plataforma BOINC é o folding@home, inclusive com uma versão para PS3 que pode ser baixada diretamente via PS3Network, e roda no PS3 como se fosse um jogo. Isso foi uma coisa que me interessou porque gostaria de disponibilizar minha plataforma de doutorado no PS3 dessa forma, mas quando entrei em contato com o pessoal de Stanford eles me disseram que foi um desenvolvimento em conjunto com a Sony, ou seja, eu não conseguiria fazer isso sozinho. Bom seria necessário um kit de desenvolvimento específico para o sistema do PS3 (GameOS) e é exatamente essa ferramenta que não está disponível, essa ferramenta permite compilar um programa para rodar no PS3 como se fosse um jogo, afinal jogos são programas de computador também

Eu nunca usei o produto, até porque nem tenho programas em COBOL, mas é uma alternativa interessante para quem precisa manter aqueles programas do legado e quer mais facilidades. Lembro que nos meus tempos de EDS havia um grande buzz em torno do conceito de Application Modernization (modernização de aplicações) foram inclusive considerados produtos que permitiam avalizar o fluxo de chamadas entre módulos de programas COBOL para poder identificar o que eram regras de negócio e o que precisava realmente ser abandonado.

O fato que ninguém quer assumir é que não dá para jogar fora programas com 30 anos de execução, que você SABE que funcionam pelo simples fato de estarem rodando há tanto tempo. Tentar reescrever muitas vezes é a receita para o desastre porque você terá que revalidar as novas aplicações e garantir que está tudo certo, mas não temos hoje nenhum método ou ferramenta de teste que garanta 100% de cobertura de testes, mesmo que tal ferramenta existisse, seria impossível garantir que todos os casos de teste foram pensados. Ao longo dos 30 anos de existência aqueles programas COBOL foram testados, corrigidos, modificados e isso é uma coisa que só com o tempo para garantir a estabilidade.

A própria IBM investiu em um caminho contraditório, disponibilizou para mainframe (plataforma Z/OS) o Websphere e o Java de forma que você pode dentro do seu programa COBOL (que funciona há 30 anos) fazer uma chamada para um novo componente EJB feito em Java, pode também encapsular seu módulo COBOL em um EJB e expor para o mundo via WebService. Aí você pensa “duvido! isso não funciona!” mas nesse caso eu posso dizer que funciona porque trabalhei em um projeto assim na EDS, aliás meu último projeto por lá. O único inconveniente (não sei como está agora) é que a própria IBM não tinha muita experiência nesse tipo de integração então algumas dúvidas ficavam muito perdidas. Uma das coisas que foi legal de descobrir futucando manuais,  experimentando e lendo código fonte de outras plataformas é que essa integração (do Enterprise COBOL 4.3 ou superior) com o Java é feita via JNI (Java Native Inteface) então quando você quer referenciar no COBOL uma classe Java precisa fazer isso usando “/” como separador de pacotes ao invés de “.” para ficar mais claro:

java/lang/String ao invés de java.lang.String

Mas fora isso funcionava bem direitinho.