Por Odracir Antunes Júnior

Creio que boa parte dos desenvolvedores sabe da importância dos testes automatizados como ferramenta indispensável no desenvolvimento de software. Mesmo assim, para deixar as coisas ainda mais claras, gostaria de compartilhar uma experiência que tive com meus amigos em um projeto recente.

Estavamos trabalhando em um projeto de produto genérico, que serviria para várias empresas. Conseguimos um primeiro cliente que, obviamente, solicitou várias adequações para que o produto pudesse se utilizado por ele. Algum tempo depois tínhamos mais dois clientes além daquele inicial. Um deles pretendia utilizar apenas um sub-conjunto do produto original, e outro precisava de mudanças que eram incompatíveis com os outros dois.

A gestão da configuração do projeto se tornava cada vez mais complexa. Precisávamos atuar em frentes diferentes, para atender às necessidades dos clientes. Tínhamos que implementar as novas funcionalidades, porém sem quebrar o que já existia. Pra variar, acabamos atrasando. E os novos prazos estavam ficando cada vez mais apertados. Algumas vezes nós chegamos à entregar versões preliminares para homologação, com bugs em funcionalidades que já tinham sido testadas e aprovadas em versões anteriores. Isto nos causava um grande desgaste perante o cliente, e era preciso garantir a qualidade do que estava sendo entregue.

Tínhamos uma equipe de testes que também estava sobrecarregada, pois quanto mais complexos se tornavam os produtos, maiores eram as dificuldades na simulação dos cenários diferentes para os testes. Foi definido um “Smoke Test“, com as funcionalidades essenciais do produto que eram comuns entre os clientes. No meio da correria, depois de um refactoring crítico na infraestrutura do projeto, eu tive que testar manualmente a aplicação. Fiquei 4 dias testando e mal passei de 40% da cobertura básica!

Passada aquela correria, começamos a automatizar o processo de “Smoke Test” tanto quanto possível. Já sabíamos que muitas outras correria ainda nos esperavem num futuro não muito distante!

Boa parte das aplicações desenvolvidas últimamente são aplicações WEB, e portanto também é fundamental poder fazer testes através do browser, como se fosse um usuário comum operando o sistema. Obviamente isto não exime o desenvolvedor de implementar os testes unitários. Os testes através da camada web devem ser um complemento aos testes mais básicos.

O Selenium é uma ferramenta de para testes de aplicações WEB, distribuído sob a “Apache License, Version 2.0“. Temos os seguintes produtos, e modos de uso do Selenium.

Selenium Core - (Modo direto)

Os testes são efetuados diretamente através do browser. As páginas de teste devem estar hospedadas no mesmo servidor que o programa/site a ser testado. Esta restrição/característica é função da segurança relativa à mesma origem requerida pelo javascript.

Vantagens:

• Suporte para todos os browsers

Desvantagens:

• É necessário a instalação remota no servidor.
• Possui algumas limitações para testes mais complexos.
• Pode ter um comportamento irregular quando se testam páginas com ajax, onde é necessário um controle maior do tempo, e/ou seqüencia de eventos. Este comportamento é altamente dependente do “engine” java script do browser. Dependendo do caso, às vezes pode apresentar falsos erros em função da priorização das atividades, já que tando “quem testa” quanto “quem é testado” estão sendo executados sob o mesmo “engine” java script, e comportamentos concorrentes podem não ser tão previsíveis assim …

Selenium IDE - (Modo indireto - Plugin no browser)

Os testes são efetuados através de um plugin instalado no FireFox. Este plugin é um ambiente integrado de desenvolvimento. Permite gravar a navegação do usuário, e depois repeti-la à titulo de teste. Também permite exportar os testes gravados em outros formatos. (Maiores explicações adiante…)

Vantagens:

• A instalação é local e simples.
• É muito fácil de usar.
• Permite gravar sessões de teste para uso posterior.
• Permite exportar as sessões de teste como arquivos fonte Java, C#, Perl, PHP, Python e Ruby, que podem ser usados pelo Selenium RC.
• Excelente para quem inicia o uso do Selenium.
• Não é preciso saber programar.

Desvantagens:

• Funciona como plugin apenas no FireFox.
• Possui algumas limitações para testes mais complexos.
• Pode apresentar o mesmo comportamento irregular relatado no item Selenuim Core. (colocar link local para #L1)

Selenium RC - (Modo indireto - Programa de teste + Proxy)

Os testes são efetuados através de um programa, que comanda o browser através de um proxy. Este programa pode ser escrito em Java, C#, Perl, PHP, Python e Ruby.

Vantagens:

• Permite o uso de verdadeiras linguagens de programação.
• Permite um controle muito mais apurado do tempo, seqüencia de eventos, etc. …
• É possível importar os testes gerados pelo Selenium IDE.
• Muito mais flexível e poderoso. Pode evoluir até para grandes suítes de testes, integração contínua, geração de relatórios . Como o programa está nas suas mãos você pode fazer o que quiser!

Desvantagens:

• A instalação e configuração do ambiente é um pouco mais trabalhosa.
• É necessário saber programar.
• Pode ser mais complicado escrever os testes à partir do “zero”.

Qual ferramenta/modo eu devo usar ?

Além das informações listadas aqui, gostaríamos de sugerir a seguinte abordagem híbrida:

• Instale o Selenium IDE e crie os seus testes básicos.
• Exporte esses testes como programas (java, por exemplo).
• Crie um projeto com as suítes de teste para uso com o jUnit.
• Faça um refactoring nas classes geradas pelo Selenium IDE, pois o código gerado tem muita redundância.
• Melhor ainda seria arrumar o código para ficar simples como uma mini “DSL” (Links #9 e #10), mais adequada para a sua aplicação, com chamadas de mais alto nível.

Depois de que automatizamos uma parte dos testes, aquilo que eu levei 4 dias era feito em apenas 20 minutos! Uma cobertura mais abrangente e confiável! A tranquilidade e a segurança que temos depois que os testes passam após um “refactoring”, ou mesmo antes de uma entrega do sistema para o cliente, é algo que não tem preço!

Moral da história: O tempo utilizado na elaboração de testes automatizados não é um tempo “gasto”. Na verdade é um tempo “investido”!

[Odracir Antunes Júnior é Analista de Sistemas com mais de 20 anos de experiência de desenvolvimento de sistemas em C, C++ e Java]

Acabou de sair do forno!

O formulário de cadastro de novas vagas do Job4Dev agora aceita o uso de markdown para formatação de texto. Para quem não sabe, markdown é um padrão de codificação simples de texto para geração de HTML. É muito usado por wikis e afins.

Exemplos de marcação markdown:

• *texto em itálico*
• **texto em negrito**
  

O parser do texto e geração do HTML ficou a cargo da lib Python Markdown.

Recebi  este link interessante do AppleInsider mostrando a evolução dos painéis de controle do Mac OS, desde a versão 3 (1986) até o novíssimo Leopard (10.5), que está para ser lançado. Para saudosistas, macmaníacos e interessados por interfaces gráficas e IHM.

Aproveitando o artigo do Raphael sobre o design de um produto ou de uma solução, quero falar aqui sobre o design de um dos aspectos de um produto de software, que é a interface homem máquina.

Se perguntarmos para 100 pessoas qual a principal característica da Apple por exemplo, muito provavelmente 98 dirão que é o design de seus produtos (os 2 outros dirão que é o preço absurdo..mas isto está mudando!). Tudo o que sai da empresa do Tio Jobs prima pela beleza, atenção nos detalhes e simplicidade de uso. Nada mais simples e clean do que um iPod shuffle, com seus 4 controles. Alguém me disse um dia que primeiro eles definem como o produto vai ser, depois eles pensam como fazer para que ele seja daquele jeito. Não duvido disso.

A Google é outra que merece destaque no quesito interfaces. Não pela beleza: as interfaces deles são muitas vezes feias. Mas eles inovaram no quesito simplicidade, usabilidade e interatividade, mostraram ao mundo um novo jeito de interagir com sites na internet. O melhor exemplo disso é a tela inicial do motor de busca, uma tela branca e um campo de texto (na verdade, o motivo inicial desta tela espartana foi a falta de conhecimento de HTML dos fundadores Brin e Page). E nada mais eficiente, rápido e leve do que a interface do GMail, ou do Google Maps. E basta ver a quantidade de ofertas de empregos para engenheiros de interação em Seattle ou New York.

E existem muitas outras empresas que claramente se preocupam com a qualidade da forma como os usuários irão interagir com seus produtos. Flickr, Adobe, 37 signals…

Ok, back to Brazil.

A minha experiência pessoal é de que interface é encarada como um mal necessário na maioria dos projetos. Sobretudo em projetos para empresas. Infelizmente ainda não tive a oportunidade de trabalhar em projetos para o grande público, ou pelo menos em projetos onde quem paga é efetivamente quem usa. Talvez seja diferente. Mas em projetos enterprise, é assim.

Em projetos web, o melhor que podemos ter é uma interface construída em photoshop e um web designer para dar um ar mais profissional para a coisa. Daí o cliente vê a interface (em geral photoshop), e usa todo o seu conhecimento (em geral inexistente) em interação para aprovar. Por fim pegam algum computeiro que esteja sem nada melhor pra fazer e mandam ele implementar a interface.

Eu posso contar nos dedos de uma mão o número de desenvolvedores que eu conheço que gostam de trabalhar com interfaces. Acho que não preciso discutir os problemas de pôr alguém pra fazer algo que não gosta, e que acha que é um mal necessário. Preciso?

Sem contar que a maioria das vezes, as interfaces se resumem a listagens gigantescas e formulários. Nada contra eles, muitas vezes resolvem. A questão é quando tratamos com quantidade gigantescas de dados (o que é bastante comum hoje em dia, tanto em sistemas empresariais quanto em sistemas para o grande público). Grandes chances de que muito rapidamente se perceba que a interface é pouco produtiva, lenta…

Não estou aqui advogando pela otimização precoce de um sistema. Estou advogando pelo estudo cuidadoso de projetos de interface e interação quando a questão da quantidade de dados/eficiência de uso é algo facilmente previsível e sobretudo crítico para o sucesso do projeto. Exemplos de interfaces que requerem um certo estudo? Que tal uma tela que tenha que sintetizar graficamente uma tabela de excel de 500 colunas por 3000 linhas, permitindo que decisões possam ser tomadas a partir de uma análise rápida do conjunto ou então que dados isolados sejam facilmente encontrados e manipulados em um mesmo ambiente? Ou então uma listagem com milhares de nomes acessada centenas de vezes por dia, onde seja imperativo encontrar um nome específico ou conjunto de nomes que atendam certas características de forma rápida?

Um bom projeto de interface requer uma equipe especializada nisso, que saiba lidar com aspectos teóricos (usabilidade, acessibilidade, modelos mentais, metáforas, affordance), com aspectos técnicos (Javascript, HTTP, programação backend eficiente), e com aspectos gráficos e de layout (cores, fontes, posicionamento de elementos). Requer gente que tenha interesse pelo assunto, e que se preocupe com detalhes. Requer estudos, protótipos, testes. Requer coerência com o resto do sistema, e com o tipo de usuário que deverá utilizar o sistema. Requer pensar um pouco out of the box: muitas vezes, as soluções padrão não resolvem o problema adequadamente.

Resumindo: requer dedicação e tempo. Não pensar nisso pode ser o barato que sai caro.

Sugiro, a quem tiver interesse em trabalhar com design de interfaces, dar uma lida no texto do Joel Spolsky sobre tema: User Interface Design for Programmers.

[http://userfriendly.org/cartoons/archives/07sep/xuf010710.gif]

PS: Esta charge, apesar de engraçada, vai contra a crença do autor de post de que Emacs é muuuuuuuuuito melhor do que Vi.

Estou iniciando o desenvolvimento de uma aplicação utilizando MyFaces. Esta escolha se deu porque gosto do esquema do Java Server Faces (JSF), e após ter trabalhado com a implementação JSF da Sun, resolvi dar uma chance ao MyFaces, pois parece ter algumas soluções interessantes para alguns problemas que enfrentei com o anterior. Em conjunto, estou utilizando diversas componentes providas pelo Tomahawk, que extendem as funcionalidades das componentes básicas do JSF, além de oferecer diversas outras componentes.

JSF é muito bom, mas não resolve todos os problemas. Um destes problemas é a questão de gerenciamento de layouts - em JSF, se você quiser que todas as páginas de sua aplicação obedeçam a um mesmo layout, você tem que replicá-lo em todas as suas páginas; imagine se depois você quiser mudar esse layout, o problema que não vai ser alterar todas as páginas. Para resolver este problema, integramos ao JSF o Tiles. Este é um framework inicialmente desenvolvido dentro do Struts, mas que agora foi separado deste, que simplifica o desenvolvimento de interfaces de aplicações web. Ele se baseia no padrão Composite View, permitindo que se definam fragmentos de página (menu, header, footer, etc …), que podem ser agrupados em um layout, que pode ser aplicado às suas páginas. O conceito é bastante interessante, e para quem quiser mais detalhes, sugiro que leia o tutorial do Tiles.

Vou aqui explicar como estou realizando esta integração. A primeira coisa que fiz foi definir a estrutura do meu layout, que é composto por:

• Header
• Menu
• Conteúdo

Basicamente, o header e o menu são sempre o mesmo. A única coisa que varia é o conteúdo a ser exibido. Com isto, defini uma página ( layout.jsp ) onde defini o posicionamento destas componentes de layout, e a utilizei em uma definition no arquivo de configuração do Tiles:

      <definition name="layout" template="/layout.jsp" >
             <put-attribute name="header" value="/header.jsp" />
             <put-attribute name="menu" value="/menu.jsp" />
             <put-attribute name="content" value="/blank.jsp" />
      </definition>

Note que para cada componente do layout há uma página associada. Estes valores podem ser alterados em tempo de execução, e irei utilizar esta funcionalidade para exibir diferentes conteúdos da minha aplicação (alterando a página a ser exibida pela componente content. Abaixo, mostro o código de layout.jsp, onde posiciono um elemento embaixo do outro:

      <tiles:importAttribute scope="request" />
      <f:subview id="header">
           <tiles:insertAttribute name="header" flush="false"/>
      </f:subview>
      <f:subview id="menu">
           <tiles:insertAttribute name="menu" flush="false"/>
      </f:subview>
      <f:subview id="content">
           <tiles:insertAttribute name="content" flush="false"/>
      </f:subview>

Um problema desta forma de integração que adotei é que, para cada página (conteúdo) que desejo exibir, preciso criar dois arquivos jsp: um para definir o conteúdo, e outro para inserir este conteúdo dentro do layout. Abaixo, um exemplo da página que insere o conteúdo dentro do layout. Note-se que isto é feito utilizando a definition que criamos anteriomente, e sobrescrevendo-se a propriedade content:

      <f:view>
          <tiles:insertDefinition name="layout" flush="false" >
             <tiles:putAttribute name="content" value="/pageContent.jsp" />
          </tiles:insertDefinition>
      </f:view>

Certamente esta não é a melhor solução, mas foi a primeira que veio à minha cabeça. No futuro, pretendo gastar um pouco de neurônios pensando em uma forma de gerar apenas um arquivo jsp por página a ser exibida.

Para configurar o Tiles para ser utilizado pelo JSF, basta você acrescentar o seguinte código em seu arquivo web.xml (além dos jar’s do Tiles):

    <servlet>
       <servlet-name>tiles</servlet-name>
       <servlet-class>org.apache.tiles.servlet.TilesServlet</servlet-class>
       <init-param>
          <param-name>org.apache.tiles.DEFINITIONS_CONFIG</param-name>
          <param-value>/WEB-INF/tiles-defs.xml</param-value>
       </init-param>
       <load-on-startup>2</load-on-startup>
    </servlet>

Nesta solução, o que eu gostaria de alcançar era:

• facilidade de gerenciamento de layout
• manter o controle de navegação do JSF
• facilidade de integração

Tirando o overhead de gerar um arquivo a mais por página gerada, acho que a solução é boa. E tem funcionado bem para os meus propósitos. Se você tiver alguma sugestão, dica, crítica, não esqueça de deixar seu comentário. Se preferir, podes entrar em contato pelo alexandre(at)log4dev.com.

Powered by ScribeFire.

Caros,

Em março eu escrevi este artigo aqui sobre o Reactable, um sintetizador pós-moderno (até que o moderno se torne antigo).

Foto: Martin Kaltenbrunner

Para quem quiser ver um destes em ação, a edição do FILE 2007 - Festival Internacional de Linguagem Eletrônica, no SESI de São Paulo - SP, de 14 de agosto a 9 de setembro, vai ter demonstração do uso deste sintetizador com os músicos da banda da contora Björk.

Nunca vi um de perto, mas acho que vale a pena conferir esta e outras atrações do FILE 2007!

Baixei hoje para a minha máquina a versão 1.0 do Internet Explorer Developer Toolbar. Parece ser bastante útil para depuração de interfaces em aplicações web. Pra ficar completo, em tempos de AJAX, falta um bom analisador de requisições assíncronas estilo FireBug.

Mais informações podem ser encontradas aqui.

Continuando a falar um pouco sobre vídeo-games e o impacto que eles causam na evolução da computação (meu primeiro post sobre este assunto você encontra aqui) eu vou falar um pouco do Wii, o vídeo-game de sétima geração da Nintendo.

Olhando por fora, o Wii parece bonito. Mas todos os vídeo-games de sétima geração investiram bastante na sua imagem externa. O melhor mesmo está naquilo que os olhos não vêem (pelo menos em um primeiro momento).

Por um lado tem os processadores do Wii. O processador central é um IBM Broadway, um processador basedo em PowerPC. Como eu disse no primeiro artigo desta série, não é à toa que todos os vídeo-games de sétima geração possuem processadores IBM: eles tiram proveito da robustez das tecnologias desenvolvidas nos últimos anos pela IBM para a família de processadores Power para o mercado de processadores de servidores, que exigem uma alta carga de trabalho. Além disso o Wii vem com um processador gráfico da ATI, o ATI Holywood. Isso por si só coloca este vídeo-game com capacidade de processamento para torná-lo um representante da nova geração de vídeo-games.

É claro que, apesar do aumento do poder de processamento em relaçao ao GameCube, o vídeo-game de sexta geração da Nintendo, este, digamos assim, não é o grande diferencial deste console. Em relação aos outros consoles de sétima geração, o XBox 360 da Microsoft e o PlayStation3 da Sony, o Wii nem é assim tão poderoso em relação à sua capacidade de processamento. Apesar de existirem muito poucas informações oficiais a respeito do IBM Broadway, certamente ele possui uma arquitetura bem mais simples que a dos processadores multi-core presentes no XBox 360 e no PlayStation 3.

O Wii também tem todas aquelas coisas que os vídeo-games de sétima geração trazem: suporte a Wi-fi, Bluetooth, USB, adaptadores para redes locais, leitura de mídias óticas, etc. Além disso, ele também é compatível com os jogos do GameCube e consegue se conectar por rede sem fio com o Nintendo DS, o atual console de mão da Nintendo. Mas tudo isso, apesar de muito legal, também não é o que faz do Wii único.

O grande diferencial do Wii, para mim, é a forma pela qual os usuários interagem com os jogos e outros eventuais programas rodando no console. O nome inicial do projeto do Wii era “Revolution e, apesar da mudança do nome no laçamento do console, a forma de interação com o Wii é realmente revolucionária.

A Nintendo desenvolveu um controle sem fio, o Wii Remote. Até ai nada demais. Só que este controle é dotado da capacidade de perceber a sua posição, a direção em que ele é apontado e a velocidade em que se movimento no espaço, ou seja, ele possui um acelerômetro dentro dele. Desta forma, o Wii permite que o usuário interaja com os programas na tela através do movimento e da direção do controle.

Isto torna possível, por exemplo, que uma pessoa jogando um jogo de tênis para o Wii não fique apenas apertando os botões para que o seu “hominho” no jogo vá de um lado para o outro da tela e aperte um outro botão para “acionar” a raquete do “hominho”. Agora é possível realmente jogar tênis, se posicionando na frente da tela e, com o Wii remote, fazendo o seu “hominho” ir para um lado ou outro da quadra quando você se movimenta com o controle na frente da tela e fazendo com que o “hominho” rebata a bola quando você fizer o movimento certo com sua raquete virtual, representada pelo Wii remote, na frente da tela. Imaginem quantas novas possibilidade não podem se abrir a partir desta forma revolucionária de interação com os computadores?

Além disso, o Wii remote é expansível, o que permite a conexão de outros controles ao controle principal. Por exemplo, existe uma extensão, chamada de Nunchuk, que é parecida com um manche de avião e possui os velhos botões direcionais dos controles de arcade. Ele também possui um acelerômetro e você pode usar um Nunchuk em uma mão e um Wii Remote em outra durante um jogo! Além disso você pode conectar controles de alguns vídeo-games anteriores ao Wii Remote e jogar seus jogos do GameCube com o mesmo controle, ou, em outras palavras, com a mesma interface que você estava acostumado.

Toda esta realidade adicional, obviamente, empolga os jogadores. Não é à toa que a Nintendo está fazendo recall dos Wii Remote para subsitutir a presilha que vem com o controle para segurá-la junto ao punho do jogador: a presilha não foi feita forte o suficiente para suportar a força que está sendo imprimida por alguns jogadores no controle e os Wii Remote estão literalmente voando das mãos em alguns casos!

Esta nova forma de interação está fazendo com que o Wii, anunciado no final do ano passado, perto do lançamento do PlayStation 3, da Sony, esteja sendo mais popular e mais vendido que seu rival em muitos lugares, mesmo sendo o PlayStation 3 o vídeo-game mais aguardado dos últimos anos.

Esta nova forma de interação também pode abrir novos caminhos para a computação e para a forma como interagimos com as máquinas hoje em dia. Pode inspirar muitos sistemas no futuro. Sejam eles jogos ou não.

Sempre gostei de vídeo-games. Alias, lá no começo de tudo, a maior parte do tempo que eu passava na frente do MSX lá de casa era pra jogar. E continuou assim com meu primeiro PC (um 386 DX 40 MHz!). Entre o MSX e o 386 eu também tive um Phantom System. Fantástico também (para a época)!

Mas, de uns tempos para cá, por causa do meu trabalho, acabei tendo que entrar em contato com esta área dos vídeo-games sob um outro ponto de vista que se tornou, para mim, tão fascinante como aquele que eu tinha quando eu era apenas um “viciado” por jogos eletrônicos.

Este outro ponto de vista me levou a perceber coisas que, até então, apesar de parecerem naturais, não pareciam ter ligações entre si. Por exemplo, todo mundo sabe que a computação eletrônica vem evoluindo de maneira frenética nos últimos 20 anos ou mais, para não dizer desde que foi inventada. Também é meio que consenso geral que a evolução da computação, dentre outras coisas, é dirigida por necessidade de maior poder de processamento, afinal não faria sentido se aumentar o poder de processamento se não existem problemas que requeiram tal poder ou se não somos capazes de criar problemas para requererem este poder de processamento (não dizem que a computação veio para resolver os problemas que ela mesmo criou?). E ai chegamos no ponto que eu queria chegar: dentre as aplicações usadas por um usuário doméstico, quais são aquelas que, em geral, precisam de maior poder de processamento?… Jogos! Seja porque tentam renderizar gráficos com cada vez mais detalhes, seja porque tentam implementar inteligências artificiais cada vez mais complexas ou seja porque tentam criar novas formas de iteratividade com o usuário, jogos requerem um grande poder de processamento.

O poder de processamento de consoles de vídeo-games sempre foi relativamente grande se comparado com o poder de processamento de PCs. É claro que esta não é um comparação totalmente justa porque os consoles de vídeo-games não podem ser estritamente descritos como computadores de propósito geral e, por causa disso, é claro que eles sempre ganham em performance na execução de jogos quando comparados com os PCs. Mas é certo também que depois do meio da década de 1990 os PCs melhoraram bastante sua performance na execução de jogos. E, mais do que isso, parece que estamos vendo nascer uma nova indústria de consoles de vídeo-games onde o console começa a se misturar com o PC e vice-versa.

A entrada da Sony no mercado de consoles vídeo-games no meio da década de 1990 e, depois, da Microsoft no início dos anos 2000 mudaram definitivamente o rumo do mercado de consoles de vídeo-games no mundo. As duas desbancaram os fabricantes tradicionais de consoles, dos quais só sobrevive ainda hoje a Nintendo. Além disso, a entrada de ambos neste mercado marcou o início da era dos consoles que não apenas rodam os jogos mas também são capazes de muitas outras coisas.

Dos consoles atuais (de sétima geração), pelo menos dois deles apostam no aumento do poder de processamento como meio de se emplacarem no mercado. O XBox 360 da Microsoft e o PlayStation3 da Sony possuem processadores multi-core agressivos. Eles atacam nas frentes que já citei anteriormente: gráficos cada vez mais perfeitos e jogos cada vez mais inteligentes. Além disso, toda esta capacidade de processamento está tornando possível a criação de ambientes mais reais, já que o poder de processamento extra torna possível um processamento mais fino da física do jogo. Os raios de sol nestes consoles refletem nos vidros, a gravidade existe de forma mais parecida com aquilo que vivenciamos no nosso dia-a-dia e a água ondula de verdade quando jogamos uma pedra num lago.

É claro que tudo isso é muito legal, mas estes consoles vão ainda mais longe. Na minha opinião, eles querem se tornar as verdadeiras centrais de entreternimento das casas. Com tanto poder de processamento, estes consoles são capazes de tocar música e vídeos, servir como ponto de interconexão de dispositivos em rede na casa, navegar na Internet, permitir a conexão de TVs digitais e muito mais. Ah, sim, antes que eu me esqueça, eles são capazes de rodar jogos também!

Estes consoles tentam também emplacar novas tecnologias de mídia como o Blue-Ray, da Sony, que é padrão no PlayStation3, e o HD-DVD, apoiado pela Microsoft, que não é padrão no XBox 360 mas que pode ser conectado ao console.

Correndo por fora neste mercado, temos o Wii, console de sétima geração da Nintendo. Ele não possui um processador tão poderoso quanto o dos outros consoles, mas ele aposta numa nova forma de interação com o usuário que tem tudo para ser matadora neste mercado. Se os outros saem ganhando quando eles tentam ser a central de entertenimento da casa, o Wii sai ganhando por ser o console com melhor interatividade. A nova forma de interação com o usuário criada pelo Wii não é só inovadora, mas ela também justifica o que já citamos antes: ela também necessitou que houvesse um salto no poder de processamento dos consoles da Nintendo entre a sexta e a sétima geração para suportar, dentre outras coisas, este novo paradigma de interatividade. Mais ainda, ela também leva à evolução da computação de uma forma geral já que propõe novas formas de interação com sistemas de computação, se levarmos em conta que ela pode ser usada para outros sistemas que não sejam jogos.

Eu prentendo, mais pra frente, analisar mais a fundo pelo menos dois destes novos consoles de vídeo-games pois eu julgo que eles trazem inovações que irão afetar de forma definitiva a computação em geral e não só no mercado de vídeo-games nos próximos anos. Mas de qualquer forma, queria compartilhar com vocês esta minha percepção de que os vídeo-games são um dos grandes responsáveis pela evolução da computação pessoal nos últimos 10 a 15 anos, eu diria.

É claro que eu acredito que o que já citei neste post serve de prova para a ligação entre os vídeo-games e a inovação na computação, mas querem um outro argumento sobre porque eu acho que o mercado de consoles de vídeo-games está cada vez mais ligado ao mercado de computadores pessoais e à evolução da computação de uma forma geral? Sabem quem é o fabricante dos processadores dos três vídeo-games de sétima geração existentes?… A IBM, uma especialista em fazer processadores para servidores corporativos de alta capacidade de processamento e uma das maiores inovadoras nesta área.

Seguindo a linha do post anterior, queria falar sobre uma outra forma de interatividade que, de certa forma, é parecida com a anterior por usar alguns conceitos semelhantes mas na prática se mostra totalmente inovadora e diferente.

O Reactable, definido pelos próprios autores como uma “multi-user electro-acoustic music instrument with a tabletop tangible user interface” pode ser visto como um sintetizador modular (se olharmos para ele como um instrumento musical) ou até mesmo como uma linguagem de programação de controle de fluxo (se olharmos ele como um representante fiel de sistemas de controle movidos a sinais elétricos que dão origem a muito daquilo que conhecemos de robótica e computação).

Vou postar aqui alguns vídeos que na minha opinião valem serem assistidos para entender completamente o conceito sendo explorado. O sistema é simples. Basicamente uma câmera posicionada abaixo de uma mesa que captura os objetos que são colocados em cima da mesa e os movimentos que são feitos nos objetos. O resto dos efeitos e controles é feito por luzes e por um sistema computacional de controle. Depois de mostrar os vídeos tento comentar alguma coisa em cima do que pode ser visto neles, mas, como vocês vão ver, nada melhor mesmo que os vídeos para explicar o Reactable.

Como se pode ver pelos vídeos, o Reactable é, antes de mais nada, um sintetizador musical, um instrumento musical. E desta forma, como se pode ver por uma simples busca na internet, já foi usado em algumas festas na Europra. Imagina um que um bom DJ não conseguiria fazer com uma interface destas? Além do show musical, certamente seria um show a parte as imagens da manipulação do Reactable.

Por outro lado, como também é possível ver pelos vídeos, o Reactable nada mais do que reproduz um sistema de controle, no qual você pode compor suas ondas geradoras, retroalimentações, filtros de freqüência e etc. de forma a montar um sistema de controle. E, neste sentido, ele não deixa de ser uma linguagem de programação. Só que com uma interface muito mais intuitiva e com uma capacidade de mostrar o resultado da atuação do sistema de uma forma que realmente dá para visualizar a resposta antes de, por exemplo, ter que implementar um sistema de controle com as mesmas características para controlar um braço mecânico de um robô de uma linha de montagem.

Olhando por outro lado, também consigo ver nele uma tremenda e inovadora ferramenta educacional. Há se meus professores de física, sistemas de controle e telecomunicações tivessem acesso e disposição para usar uma ferramenta dessas durante as aulas! Certamente os conteúdos que, em geral são complexos e difíceis de entender por envolverem o espaço de freqüências, convoluções e etc. poderiam ser muito melhor compreendidos pelos alunos em um tempo bem menor!

E, ainda assim, se esquecermos tudo isso e voltarmos ao tópico sobre o qual estávamos falando originalmente, o Reactable nos mostra, de forma contundente, uma nova forma de interação homem-máquina que dá maior poder de expressão e de visualização de resultados para as pessoas que estão interagindo com o computador. É claro que vocês podem estar pensando como uma coisa como o Reactable poderia se aplicar na vida de uma pessoa comum, que usa o computador para navegar na internet e ler e-mails. Neste sentido, talvez a utilidade do multi-touch screen seja mais fácil de se enxergar. Mas não podemos de forma alguma descartar coisas como o Reactable, já que conceitos como este podem tornar possível, por exemplo, a apresentação de um objeto físico real (que não seja um quadradinho de plástico com um símbolo desenhado como nos exemplos) a um computador. Vocês já imaginaram nas possibilidades que podem se abrir se um computador conseguir a efetivamente reconhecer objetos e/ou pessoas que são apresentados a eles?

Depois de um tempo meio sumido, estou finalmente de volta! Espero não ficar tanto tempo assim longe do blog novamente.

Para voltar, queria falar sobre um assunto sobre o qual já postei no nosso blog (ainda no endereço antigo, no ano passado) mas que voltou à minha cabeça recentemente. Vou recolocar o vídeo aqui para quem não viu ou não lembra.

[youtube=http://www.youtube.com/v/nfVnwdda9Pw]

Neste e nos próximos posts eu queria falar um pouco sobre as novas formas de interação com computadores que estão surgindo nos últimos tempos.

Quando postei este vídeo o ano passado, a única coisa que me vinha à cabeça na época era: “que massa!”. Como bom apreciador de tecnologia eu achei o vídeo o máximo e a tecnologia mostrada algo inovador e capaz de quebrar paradigmas!

No entanto, mais recentemente, por força do meu trabalho atual, venho também analisando outros aspectos relacionados à interatividade homem-máquina e me veio a cabeça que são coisas deste tipo que vão nos fazer sair do marasmo criado há mais de 20 anos quando a última grande inovação tecnologica na interação entre homens e computadores saiu do forno: o mouse.

É claro que depois disso muitas outras coisas foram inventadas, mas nada ainda é realmente tão efetivo como um teclado e um mouse. E acho que isso em breve poderá mudar.

Finalmente estamos vendo se tornarem realidade novas formas de interação com os computadores que dão gosto de ver e de usar. Comandos por voz (que funcionam de verdade) e coisas como este multi-touch screen realmente me fazem ver uma luz no fim do túnel. Mais pra frente tentarei falar um pouco de vídeo-games explorando alguns dos novos assuntos com os quais ando tendo contato ultimamente e não poderei deixar de falar também do novo controle do Wii, o novo vídeo-game da Nintendo. Ele simplesmente aposta em um conceito revolucionário de interatividade que vem se provando um sucesso de mercado. Mas poderemos falar mais sobre isto em um próximo post.

Por hora, só queria deixar aqui minha percepção que as coisas estão mudando (e desta vez parece que para melhor!).

Já era hora!

Em algumas horas, darei uma palestra na Semana de Computação da UNESP/Rio Claro sobre AJAX. Acho que vai ser uma experiência interessante. A quem puder se interessar pelo assunto, estou disponibilizando aqui os slides da palestra em PDF.

Palestra sobre AJAX

Outro dia, li este artigo do Joel que faz um review às avessas de um celular, e me lembrei de um problema de interfaces que eu presenciei recentemente.

Estava no Banco do Brasil, esperando na fila para usar a única máquina que emitia cheques da agência. Na minha frente, um senhora estava tentando fazer algo bem simples: imprimir um extrato. A sequência era mais ou menos essa:

Insere e retira o cartão do leitor
Selecione a opção desejada (são necessários uns 3 cliques até selecionar Extrato impresso)
Digite sua senha de 6 digitos
Digite seu código de 3 letras
Insira e retire seu cartão para confirmar

Neste momento, se tudo desse certo, o extrato seria impresso. Só que no caso dela, provavelmente o cartão estava bloqueado por algum motivo. O resultado era que a seguinte mensagem aparecia na tela: Cartão bloqueado, utilize Terminal BB. A senhora em questão olhava a mensagem estupefata e repetia a operação….istou durou uns 10 minutos, até ela desistir.

É interessante analisar um fato: a senhora esta numa agência do Banco do Brasil, também conhecida como BB, usando um Terminal. Dificilmente consigo achar uma definição melhor para isso do que Terminal BB. O seja, basicamente o sistema mandava ela utilizar um terminal do banco do brasil pra resolver a questão do cartão dela, coisa que ela já estava fazendo, e mesmo assim não deu certo.

Isto já aconteceu comigo ! E devo dizer que ainda não sei como o Terminal BB pode me ajudar, porque eu pesquisei várias opções e nenhuma delas era a boa. Quando bloqueei meu cartão, a única salvação foi ir até a minha agência de origem e desbloquear com o gerente. Daí, ia até o terminal bb pra emitir uma nova senha.

Demorei pra escrever a segunda parte desse pequeno tutorial, mas antes tarde do que nunca. No post anterior eu expliquei brevemente o funcionamento da captura de teclas em Javascript. Neste vou colocar uma receitinha de bolo.

Segue o código, compatível com IE e Firefox. Qualquer dúvida com os comentarios, entre em contato:

document.onkeyup=handleKeyboardAction;

function handleKeyboardAction(e){

   var code;

  // Obtém o evento. No caso do Firefox, este
  // evento é passado como argumento, e no caso do IE,
  // deve ser obtido através do objeto window.
   if (!e) var e = window.event; 

   // Detecta o target da tecla
   var targ;
   if (e.target) targ = e.target;
   else if (e.srcElement) targ = e.srcElement;

   // Este código previne um erro do navegador Safari:
  // Se o usuari clica num DIV com texto, os outros browsers
  // retornam o DIV como sendo o target. Safari retorna  o nó contendo
  // o texto (nodeType 3). Nesse caso, o target que nos interessa é o pai.
   if (targ.nodeType == 3) // defeat Safari bug
      targ = targ.parentNode;

  // Obtém o nome da TAG HTML do target do evento
   tag = targ.tagName.toUpperCase();

  // Verifica se o evento não esta sendo acionado em nenhum
  // campo como campo de texto e combobox.
  // Esta verificação é importante, pois o handler pode bloquear
  // o funcionamento adqueado desses campos (por exemplo, em vez de escrever
  // a letra no campo, executa uma função).
   if (tag == "INPUT")
      return;

   if (tag == "SELECT")
		return;

   // Detecta o codigo da tecla
   if (e.keyCode) code = e.keyCode;
   else if (e.which) code = e.which;

   var character = String.fromCharCode(code);

  // Executa o procedimento associado à uma letra.
   if(character == "R"){
   } 

       //Seta para cima
	if(code == 38) {
           ...
          return;
	} 

	//Seta para direita
	if(code == 39) {
            ...
            return;
	} 

	//Seta para esquerda
	if(code == 37) {
		return;
	}
}