No último dia 15, a Microsoft lançou para download a primeira versão beta do Internet Explorer 9. O IE foi o último grande navegador a dar algum tipo de suporte ao vindouro padrão HTML 5.

Sejamos sinceros, ninguém acreditava muito na Microsoft. Para muitos usuários conscientes de tecnologia, Internet Explorer deixou de ser sinônimo de navegador há muito tempo. Alguns preferem o poder de customização do Firefox, ou a velocidade bruta do Chrome, ou as soluções inovadoras do Opera. E há os que não trocam o Safari por nada.

O que a Microsoft poderia dar em troca? Conformação com os padrões seria o mínimo. Aceleração de renderização por hardware? Quem precisa disso? Oras, ninguém quer jogar Crysis no navegador. As propostas inovadoras da Microsoft para a nova geração do IE pareciam piada.

Mas ninguém está rindo agora.

De todas as novidades do IE, você deveria prestar atenção em duas:

• Aceleração por hardware
• Realce no site/aplicação web

Algumas semanas antes do lançamento do Internet Explorer, a Mozilla Foundation anunciou que o iria lançar uma versão do Firefox 4 com aceleração por hardware, e a Google, para não ficar para trás, incluiu o recurso no Chrome 7. Isso é uma clara forma de correr atrás da concorrência.

Mas ao invés de uma briga boba por contagem de feature bullets, a aceleração de composição, vídeo e texto por hardware é um avanço real. De repente, o trabalho gráfico pesado não depende de plugins (como o Flash, que há várias versões faz aceleração de vídeo por hardware). E, de repente, o navegador abre caminhos para novas aplicações ainda não pensadas. Se você ainda não experimentou, acesse o tanque de peixes com uma das versões beta do Firefox 4, Chrome 7 ou IE 9. E depois compare com seu navegador atual.

Junto com isso, o novo IE dá um salto em foco no site que não era visto desde a entrada do Chrome ao mundo. A superfície de controle do navegador é a menor entre todos (mesmo até do antigo campeão, Chrome), e o site/aplicação web simplesmente salta na tela.

Isso sem falar na polêmica integração com o Windows 7. Já falei sobre isso nesse blog, e achei a funcionalidade fabulosa. Na combinação IE9+Win7, o site é elevado a categoria de aplicação, com direito a seus próprio atalho pinado na barra de tarefas, e detalhes como botões na miniatura e ícones de overlay. Claro, vai ser para 5% de toda a população de usuários do IE, mas algo nessas funcionalidades nos faz pensar em algumas tendências…

A barreira entre desktop e web

Por mais que a Microsoft quisesse, a web não se fundiu com o desktop. A Microsoft tem uma vida difícil porque, ao mesmo tempo que não pode deixar muito espaço para concorrentes na web como o Google, ela precisa vender Windows como se fosse a solução definitiva para o universo.

A Google por sua vez, surgiu da web. Sua especialidade são aplicações baseadas na Internet. E com todo seu crescimento, era uma questão de tempo até que ela começasse a interferir no desktop. Quando o Chrome foi lançado, todos nós sabíamos: cansada de esperar o segmento, a Google decidiu fazer sua própria plataforma, para suas próprias aplicações.

Mas quando ela anunciou o Chrome OS, muitos acreditaram isso era demais. Um sistema operacional totalmente plugado? Sites como aplicações? E meus arquivos locais? E se eu não conseguir conexão?

Calma. A Google não está dizendo que a partir de amanhã, você não terá mais a necessidade um computador para, por exemplo, computação gráfica. Mas a roda da evolução está girando. O movimento que a Google ajudou a acelerar, e a Microsoft confirmou com o lançamento do IE9, está acontecendo.

E o alicerce de tudo isso é o HTML 5.

O HTML 5 vai mudar o que você conhece de aplicações web

Em 2004, a W3C promoveu um workshop para que as diversas entidades relacionadas à Internet pudessem dar voz as suas idéias para o futuro de aplicações web. Os participantes ficaram divididos entre aqueles que acreditavam que as aplicações web deveriam seguir o caminho do XML (XML, XHTML, SVG, XSL, XSLT) e aqueles que apoiavam todo o trabalho já construído em cima do HTML e CSS.

No final do workshop, a seguinte pergunta foi feita aos participantes:

A W3C deveria desenvolver uma nova versão do HTML e CSS para implementar os requisitos de Aplicações Web (…)?

8 votaram Sim. 14 votaram Não.

Findando o workshop, as pessoas que apoiavam o HTML – em especial Apple, Mozilla e Opera – fundaram o Web Hypertext Applications Technology Working Group, o WHATWG. Eles começaram a trabalhar nas várias propostas que iriam se tornar o HTML 5.

Devido à grande atenção que o grupo ganhou, em 2006, a própria W3C se uniu ao WHATWG, incorporando os trabalhos como documentos do consórcio. E em 2009, a W3C encerrou os trabalhos no XHTML 2, morto antes de nascer. Isso quer dizer que o HTML 5 é real, e vai estar nas mesas nos computadores de todos cedo ou tarde.

O que faz o HTML 5 especial para quem desenvolve aplicações web?

Formulários renovados

Os novos tipos de campos de formulários produzem muito mais contexto para os navegadores. Quem já usou um iPhone, sabe que em certas aplicações web, quando você põe foco em um campo de e-mail, o teclado virtual muda para um modo especializado para e-mail. Isso não é magia; é o campo do tipo email funcionado.

O formulário agora tem muito mais suporte a validação. Você pode definir um campo como requerido; em campos numéricos, pode especificar a faixa de valores permitida. Pode até especificar uma expressão regular como validador.

Isso sem falar em autofoco sem script.

Armazenamento local

Sim, é verdade. Por muito tempo, ficamos limitados a soluções erradas como cookies, ou plugins como Flash e Gears para armazenar informação local no cliente. Não mais. O HTML 5 prevê que os navegadores terão, por padrão, uma forma de armazenamento de informação local.

A priori, apenas armazenamento do tipo chave-valor são aceitas. Todos os navegadores atuais já possuem essa funcionalidade (mesmo o IE8), disponibilizando pelo menos 5 MB para cada aplicação. Com o tempo, é possível que o padrão IndexedDB seja incorporado, dando uma solução estruturada de armazenamento.

Aplicações web offline

Isso não é paradoxo. Isso é real e possível hoje. Trata-se apenas do uso inventivo do cache do navegador.

Aplicações offline trabalham em duas frentes. Nas suas páginas, você precisa indicar uma lista de arquivos que precisam ser cacheados caso o usuário queira usar sua aplicação de forma desconectada. E na sua lógica de página, você tem acesso a uma API que permite que você saiba se o usuário está offline, quando esse status muda, se o usuário deseja ou não trabalhar offline, etc.

Aliado com o armazenamento local, é possível criar aplicações web bem poderosas. E que desafiam um pouco mais o que é web e o que é desktop.

CSS 3

Tecnicamente não é parte do HTML 5, mas está sendo empurrado junto nessa nova onda de aplicações web.

CSS 3 prevê interfaces bem mais interativas e aprazíveis. Munido apenas de CSS, é possível definir animações, transições e transformações em 2D. Sites com animação, sem Flash.

Alguns exemplos aqui.

Canvas

Mais um adendo ao HTML 5 que elimina a nossa necessidade de plugins como Flash. Trata-se de uma área de desenho livre para HTML. Uma aplicação consegue desenhar formas e construir animações. O primeiro grande destaque ao canvas foi uma aplicação bem simples baseada no twitter, mas bem cool.

Com todo esse foco no desenho e gráficos, não é de se espantar que Mozilla, Microsoft e Google estão atrás de aceleração por hardware.

O que falta

Em uma única palavra, ferramentas. Hoje temos boas ferramentas para edição de HTML e CSS, mas não há nada bom para desenvolver em JavaScript. Eu não estou falando em programação reativa, como Notepad+Firebug. Eu estou falando em auto-complementação de código. Em descoberta de contexto. O Visual Studio 2010 chega perto disso, mas se enrola às vezes.

De qualquer forma, em HTML/CSS/JavaScript estamos bem servidos. O que ainda estamos bem defasados é em ferramentas para desenho/animação. Enquanto não houver uma ferramenta boa para animação e criação em canvas e CSS 3, os desenvolvedores e designers preferirão usar plugins como o Flash.

Quem fornecerá essas ferramentas? A Adobe pode muito bem fornecê-las, já que é conceitualmente a melhor no design para web. Além disso, ela falou que ia fazer isso. Mas com as recentes dúvidas em relação ao WPF dentro da Microsoft, não se surpreenda se o Visual Studio 11 ou o Expression Studio 5 vier como a melhor ferramenta de desenvolvimento para aplicações HTML5.

O futuro está mais próximo do que você imagina

Algumas coisas nos fazem pensar:

• A empresa top-of-mind da Internet fez sucesso fazendo aplicações web
• A mesma Google cria um sistema operacional somente com aplicações web
• Os produtores de navegador de Internet se unem para criar um padrão de aplicações web
• A Google cria o Gears, plugin para desconectar aplicações web. O recurso vira um padrão HTML.
• O iPhone é um dos primeiros a transformar aplicações web em itens de primeira instância, permitindo criar links lado a lado a aplicações nativas
• O Internet Explorer adiciona aceleração de hardware na renderização (e todo mundo segue atrás)

No dia seguinte ao lançamento do IE9, a Google veio a público dizer que o Chrome 7 ficaria 60 vezes mais rápido. Além disso, incluiria suporte a 3D com CSS e WebGL. Isso permitiria a aplicações extremamente demandantes, como jogos 3D, rodar no navegador. Mesmo que eles não cheguem nesse número, entende o caminho para onde a coisa está andando?

Outra história. Lá no início de setembro, o ex-gerente do projeto Silverlight postou:

Exatamente agora há uma guerra entre HTML 5 e Silverlight dentro da Microsoft. Oh e WPF está morto… digo… já estava, mas agora… funeral.

Logo após, o site I-Programmer postou um artigo bem interessante sobre como o WPF é tratado dentro da Microsoft. Em suma, a única equipe que usa WPF na Microsoft é a equipe que a criou, o time das ferramentas de desenvolvimento. De fato, mesmo depois de 5 anos de existência, o único grande software que usa WPF é o próprio Visual Studio.

Voltando ao ex-gerente do Silverlight, ele ainda acrescentou:

HTML 5 é o substituto do WPF… o time do IE quer estender o HTML5 colocando APIs do Windows via JS

Isso semanas antes de a gente descobrir sobre Jump Lists e ícones de overlay no IE9. Alguém duvida que a Microsoft pensa em incluir extensões para outras APIs do Windows, como IO e DirectX?

O que você, desenvolvedor, vai fazer sobre isso?

Imagino se você agora esteja em fase de negação. Eu estive. “Aplicações no navegador?” “Nunca substituirei meu Word!” “Não tem como {insira sua aplicação improvável aqui} rodar no navegador!”

O que eu posso dizer a você é: se livre de preconceitos. Seja tabula rasa e crie novos conceitos.

Outra história. Até 2004, geoprocessamento era tratado como uma coisa para poucos. Se você quisesse um mapa, você comprava em uma livraria, ou procurava por uma imagem na Internet. GPS era coisa de firmas especializadas como Garmin e Magellan. Internet e geomática eram coisas tão ligadas quanto aviões e submarinos. As empresas grandes do ramo se esforçavam para que tudo continuasse assim. “É impossível criar uma mapa sem o datum adequado”. “Transformações geográficas devem ser exatas”. “Precisão”. “Burocracia”.

Então, em 2004, a Google comprou uma empresa chamada Keyhole e lançou ao mundo o Google Earth. Imediatamente, da noite para o dia, todas as pessoas do mundo aprenderam tudo o que precisavam saber sobre imagens de satélite, geolocalização, rotas, GPS. Tudo impreciso, sem formalização. Mas não importava: qualquer um podia ver o lugar que morava, como eram as grandes pirâmides ou como é a sensação de estar no alto do Everest.

Isso simplesmente criou um novo nicho de mercado. Google Maps, Fourquare, Facebook, Latitude, Twitter, e muitíssimas outras aplicações fazem uso de geolocalização. GPS em um smartphone não fazia sentido em 2003; hoje é recurso obrigatório. Geolocalização faz parte do HTML 5.

E como estão as empresas sisudas de geomática e GPS hoje? Ainda correndo atrás do prejuízo. Tentando proteger sua propriedade intelectual, não arriscaram abrir a mente para novas idéias. Não viram o potencial das aplicações de Internet. E deixaram de ser o protagonista da revolução da geolocalização.

Não seja assim. Está sendo construído um padrão para aplicações de Internet. Nunca antes 5 produtoras de navegadores sentaram na mesa para discutir. O padrão não é perfeito. Não resolve tudo. Haverão discrepâncias. Mas é certamente a melhor plataforma para construir aplicações web feita até hoje. Aproveite, encontre um nicho, crie idéias, explore. E não tenha preconceitos.

Se você é desenvolvedor web, então esse post é para você. Saiba como fazer as coisas divertidas que o Internet Explorer pode fazer.

A primeira coisa que você precisa aprender é que essas funcionalidades estão disponíveis apenas para Internet Explorer 9. Por isso, se você tentar executar algum código dessas funcionalidades em outro navegador, um belo erro de script vai acontecer.

Há quem faça detecção de browser via script. Nesse caso, não é necessário (e é contra-producente, não faça). O que você precisa fazer é detecção de funcionalidade. Para checar se o site suporta as funcionalidades, cheque por msIsSiteMode.

try {
    if (window.external.msIsSiteMode()) {
        // suportado, tudo certo no deserto
    } else {
        // IE9, mas SiteMode não suportado
    }
} catch(ex) {
    // Outro navegador, não suportado
}

Dito isso, vamos às funcionalidades.

Fixar aplicação na barra de tarefas ou menu Iniciar

Qualquer site pode ser fixado na barra de tarefas ou menu Iniciar, seja ele preparado para o IE ou não. Fixar é tão fácil quanto arrastar a aba do navegador para a barra de tarefas. Você ainda pode usa o botão Ferramentas (Alt+X) para fixar no menu Iniciar.

Quando você fixa o site, várias coisas acontecem:

• O site fica fixado como se fosse um programa

• Quando aberto, o IE mostra o ícone do site na extrema esquerda
• Os botões de voltar e avançar mudam de cor

Para configurar o ícone do site, continua o bom e velho link shortcut icon.

<link rel="shortcut icon" type="image/x-icon"
    href="/themes/gizmodo3/favicon.ico" />

A cor dos botões, por padrão, é baseada na cor predominante do ícone do site. Web designers provavelmente irão querer fazer tweaks no ícone do site para melhorar a aparência da aplicação. Mas é possível alterar a cor padrão usando uma meta tag:

<meta name="msapplication-navbutton-color" content="red"/>

Também é possível alterar a URL que é aberta quando o usuário clica no link da barra de tarefas:

<meta name="msapplication-starturl"
    content="http://example.com/start.html"/>

E além disso, é possível customizar o tamanho da janela que é aberta:

<meta name="msapplication-window" content="width=800;height=600"/>

Jump lists

Jump lists, ou lista de tarefas, podem ser criadas no ícone com uso de scripting. As listas de tarefas são úteis para criar atalhos para partes do site, como no site do Paul Turrott:

Ou para relembrar atividades recém feitas no site, como neste exemplo usando o Twiter:

Existem dois tipos de jump lists: as tarefas de aplicação e as listas dinâmicas.

Tarefas de aplicação

As tarefas de aplicação estão ligadas à categoria Tarefas do menu de aplicação. Elas tendem a ser estáticas e são relacionadas às atividades que seu usuário usa o site.

Pelo caráter estático das tarefas, elas são mais facilmente declaradas como meta tags no site. Dessa forma:

<META name="msapplication-task"
    content="name=Task 1;action-uri=http://host/Page1.html;icon-uri=http://host/icon1.ico"/>
<META name="msapplication-task"
    content="name=Task 2;action-uri=http://microsoft.com/Page2.html;icon-uri=http://host/icon2.ico"/>

Cada meta msapplication-task admite três parâmetros:

• name: o nome da tarefa
• action: a URL que é aberta ao clicar na tarefa
• icon-uri: o endereço do ícone da tarefa.

As tarefas podem ser atualizadas. Sempre que o usuário abre a aplicação via ícone fixado, as tarefas são atualizadas pelas meta tags encontradas no momento.

Ah, e metas podem ser criadas sem medo de compatibilidade. Navegadores que não entendem msapplication-task simplesmente a ignoram.

Listas dinâmicas

Você pode criar sua própria categoria e lista de links. Isso é feito com um pouco de JavaScript. Existem várias etapas para criar uma categoria:

• Crie a categoria: primeiramente, use msSiteModeCreateJumpList para criar uma categoria com um nome. Você precisa criar pelo menos uma categoria antes de começar a criar itens para ela.

window.external.msSiteModeCreateJumplist('List1');

• Adicione itens: Adicione itens à categoria com msSiteModeAddJumpListItem. Note que nesse momento, os itens são adicionados apenas em memória e não aparecem no link.

window.external.msSiteModeAddJumpListItem(
    'Item 1', 'http://host/Item1.html', 'http://host/images/item1.ico');
window.external.msSiteModeAddJumpListItem(
    'Item 2', 'http://host/Item2.html', 'http://host/images/item2.ico');
window.external.msSiteModeAddJumpListItem(
    'Item 3', 'Item3.html', 'images/item3.ico');

Cada item requer um nome, uma URL de ação, e um ícone de aparência.

• Mostre a lista: usando a função msSiteModeShowJumpList, a categoria do link é atualizada com a lista em memória.

window.external.msSiteModeShowJumplist();

Note o seguinte:

• Um site pode criar apenas uma categoria customizada, portanto escolha bem o nome
• Quando atualizada, a categoria não perde todos os itens; os itens em memória são adicionadas aos itens já existentes.
• A atualização não duplica itens iguais: os itens referenciados são movidos para o topo da lista
• A categoria suporta somente 20 itens; depois disso os itens mais antigos são removidos
• É possível limpar a lista imediatamente chamando msSiteModeClearJumpList
• Sites podem receber notificações quando o usuário manualmente remove um item da Jump List com o evento mssitemodejumplistitemremoved

document.addEventListener(
    'mssitemodejumplistitemremoved', handler, false);

Ícones de Sobreposição

Enquanto o site está aberto, você pode sobrepor o ícone de aplicação na barra de tarefas com seus próprios ícones.

Para definir um ícone de sobreposição, basta chamar msSiteModeSetIconOverlay.

window.external.msSiteModeSetIconOverlay(
    'http://host/images/search.ico', 'Searching');

O primeiro parâmetro é o endereço do ícone. O segundo parâmetro é opcional e muda a tooltip do ícone da aplicação.

Similarmente, para remover o ícone de sobreposição, basta chamar msSiteModeClearIconOverlay.

Botões no preview miniatura

O site pode também adicionar aqueles pequenos botões em cima do preview em miniatura da janela.

Os botões são criados por janela, primeiramente em memória. Use o método msSiteModeAddThumbBarButton para adicionar um botão:

btn1 = window.external.msSiteModeAddThumbBarButton(
    'http://host/images/button1.ico', 'button 1');
btn2 = window.external.msSiteModeAddThumbBarButton(
    'http://host/images/button2.ico', 'button 2');
btn1 = window.external.msSiteModeAddThumbBarButton(
    'http://host/images/button3.ico', 'button 3');

O valor de retorno é um identificador do botão na barra de botões.

Para detectar se o usuário clicou em um botão, escute o evento msthumbnailclick:

document.addEventListener('msthumbnailclick', handler1, false);
…
function handler1 (btn) {
         alert ("addeventlist:thumbnail btn id" + btn.buttonID);
}

O botão pode ser identificado com a propriedade buttonID do objeto de evento. Ele vai ser um dos identificadores retornados por msSiteModeAddThumbBarButton.

E depois de definidos, você pode mostrar a barra de botões com msSiteModeShowThumbBar.

O código completo de inicialização da barra é algo assim:

var btn1, btn2;

function init()
{
    document.addEventListener('msthumbnailclick', processSelection, false);
    
    btn1 = window.external.msSiteModeAddThumbBarButton('Images/play.ico', 'Play');
    btn2 = window.external.msSiteModeAddThumbBarButton('Images/stop.ico', 'Stop');
    
    window.external.msSiteModeShowThumbBar();
}

function processSelection(btn)
{
   if (btn.buttonID == btn1) 
   {
       // Play video
   }
   else if (btn.buttonID == btn2) 
   {
       // Stop video
   }
} 

Modificando os botões

Depois que a barra de botões foi mostrada, você pode habilitar/desabilitar, ocultar/mostrar, e mudar o ícone do botão.

Para desabilitar e ocultar, você pode chamar o msSiteModeUpdateThumbBarButton.

window.external.msSiteModeUpdateThumbBarButton(btn1, false, true);
window.external.msSiteModeUpdateThumbBarButton(btn2, true, true);
window.external.msSiteModeUpdateThumbBarButton(btn3, true, false);

O primeiro parâmetro é o identificador do botão, o segundo parâmetro indica se o botão está habilitado (verdadeiro/falso), e o terceiro indica se o botão está visível.

Para modificar o ícone do botão, você primeiro precisa declarar estilos de botão. Declare estilos usando msSiteModeAddButtonStyle, passando o identificador do botão, um endereço de ícone e a tooltip do botão.

style1 = window.external.msSiteModeAddButtonStyle(btn1,
    'http://example.com/img/down.ico', 'Button depressed');
style2 = window.external.msSiteModeAddButtonStyle(btn1,
    'http://example.com/img/up.ico', 'Button released');

Um botão pode ter vários estilos.

Alterne os estilos de botão usando msSiteModeShowButtonStyle, passando como parâmetros o identificador do botão e o identificador do estilo.

window.external.msSiteModeShowButtonStyle(btn1, style1);

Chamando atenção do usuário

É possível fazer o ícone da aplicação piscar chamando msSiteModeActivate:

window.external.msSiteModeActivate();

Tamanho dos ícones

Os sites fixados usam ícones em vários lugares. É recomendado que os arquivos de ícones tenham as seguintes resoluções: 16×16, 24×24, 32×32, 64×64.

Na configuração padrão, os ícones usados são:

• Ícone da barra de tarefas: 32×32
• Ícone de Jump List: 16×16
• Ícone de botão de preview em miniatura: 16×16
• Ícone no canto esquerdo superior no navegador: 24×24
• Ícone de sobreposição: 16×16

Conclusão

Espero que tenha achado interessante as novas ferramentas do Internet Explorer. Elas fazem com que o limite entre desktop e a web fique um pouquinho mais nublado. No mais, inclui ferramentas interessantes para power-users.

Lembre-se que o IE9 ainda está em beta, e alguma coisa pode sempre mudar. Fique de olho na documentação em progresso, e no blog do time do IE.

As informações aqui contidas foram retiradas em parte do tutorial na documentação do IE.

A notícia é que a venda dos notebooks vem sofrendo uma queda do crescimento, principalmente após Janeiro deste ano, quando o iPad foi anunciado. Hype ou não, a queda nas vendas estava prevista pelo menos desde 2009, quando o WSJ reportou que era hora de deixar os laptops para trás.

Vou te contar uma história. Minha sobrinha vai assumir um cargo de gerência em uma multinacional em Portugal. Como parte das atribuições, ela precisa estar sempre em movimento. E como parte dos benefícios, ela vai receber um Blackberry. O aparelho vai ser necessário para receber emails e gerenciar sua agenda, que poderá ser controlada pela empresa.

Isso está acontecendo em todo lugar. Email, agenda e Internet, antes possível apenas com o uso de um notebook, agora podem ser acessados via um aparelho de 15 centímetros e tamanho. E com vantagens: mais leve, mais ágil, mais eficiente.

Mas minha sobrinha vai receber também um laptop. Esse vai servir para criar relatórios e acessar as aplicações da empresa – web ou desktop.

É nesse nicho que os pads podem se mostrar um melhor form-factor. É no lugar de notebooks de baixo desempenho e netbooks que o formato pad pode se destacar. Não por acaso, a venda de netbooks vem caindo desde 2009.

Afinal, por que os netbooks existem?

Sempre houve uma necessidade (pelo menos é isso o que o mercado acredita) de transformar o computador pessoal em algo mais móvel. Existe a necessidade para profissionais on-the-go de:

• Ler emails
• Ler noticias
• Marcar, ver compromissos
• Criar relatórios, artigos
• Usar aplicativos da empresa

Para o usuário comum, é interessante uma forma mais simples de:

• Navegar na internet
• Ver emails
• Comunicação instantânea (IM, Skype)
• Criar documentos (na escola, pelo menos)
• Ver fotos
• Assistir vídeos
• Ouvir música
• Jogar!

Smartphones e palmtops (descansem em paz) são interessantes, mas não podem fazer tudo isso. Notebooks podem, mas são algo como overkill: são pesados, grandes, e desnecessariamente potentes, drenando mais bateria que o ideal. Netbooks eram a escolha óbvia então. Não fogem do seguro look and feel de um notebook, mas são mais adaptados para agilidade e eficiência.

Então, Steve Jobs assistiu muitos episódios de Jornada, e resolveu que a Apple podia adiantar o futuro. E todo mundo seguiu atrás.

O alvorecer do futuro

Um parênteses antes de continuar. Quando eu menciono pad, eu estou me referindo ao formato, ou seja, um aparelho leve, com uma tela gigante sensível ao toque para computação pessoal – e não especificamente o iPad, o aparelho da Apple.

O pad é o substituto perfeito para o netbook e notebooks. Eles possuem telas maiores que smartphones, permitindo uma usabilidade bem mais avançada que a pequena tela do telefone. E são bem superiores em facilidade de uso do que um netbook. Quando uma avó de 99 anos pode usar um computador como uma geek, você sabe que acertou na usabilidade.

O que sabemos é que o mouse é um mal necessário. Não há precisão como o mouse, mas ele requer uma superfície. Isso sozinho já reduz versatilidade de um aparelho móvel. Touchpads de notebooks são ok, mas requer uma técnica maior ainda. Com telas sensíveis a toque, não há metáfora, não há abstração: você literalmente toca o que você quer tocar. Não há nada mais óbvio que isso, e minha mãe pode usar um computador (não é ela ali em cima).

O que ainda falta

Há quem diga que os pads na atual concepção ainda não são o aparelho final que vai substituir tudo. Ainda falta alguns pequenos detalhes para a dominação mundial. Mas se já não estamos lá, estamos muito perto.

Teclado e suporte

Essa é uma grande questão. Há os proponentes do teclado físico, e há quem diga que isso não é necessário.

A verdade é que a resposta táctil na digitação é uma mão na roda, principalmente para aqueles com visão comprometida. Por outro lado, um teclado no aparelho ocupa espaço útil (que deveria ser tela).

Outro problema crônico dos pads é justamente a falta de suporte – no sentido de apoio mesmo. Segurar um iPad no braço e digitar não é para os fracos. Sentar em uma posição ereta em uma mesa e digitar num pad não é confortável.

A saída é incorporar no aparelho um teclado e uma forma de suporte. A Dell está no caminho certo, mas desde que isso não comprometa o peso e tamanho. Ou usar acessórios. Um acessório matador seria aquele que oferecesse suporte, teclado, proteção e leveza para o pad. E eles já existem.

Documentos

Convenhamos, todos nós estamos ligados ao Microsoft Office. Mesmo que eu não queira usá-lo. A necessidade de ler e criar documentos .doc vai ser uma presença por uma bom tempo.

Os pads precisam lidar com isso. E podem fazer isso de duas formas: ou os pads precisam incorporar um editor desse formato localmente, ou os documentos precisam deixar o computador e ir para a web.

Office no Windows é impraticável. Porque o Windows no pad é impraticável (veja mais daqui a pouco). O OpenOffice é OK, mas ainda precisamos vê-lo em uma distribuição Linux decente que não precise de grande processamento. As melhores soluções atualmente são do iPad, mesmo porque foram pioneiras. O aplicativo Pages possui algum suporte a arquivos .doc, e você sempre pode contar com o Documents-to-go.

A alternativa é mover os documentos para a nuvem e usar aplicações web. O Google Docs já está aí há algum tempo e é o primeiro nome que vem à cabeça. A Microsoft conta com o Office Live Workspace para concorrer na área. Temos o Sharepoint para as empresas que querem controlar o conteúdo, e até um cliente de Sharepoint para iPad.

De qualquer forma, as soluções para arquivos de escritório estão aí.

Sistema operacional

Quem duvida ainda que um pad precisa ter um sistema operacional compatível com o formato? O iOS da Apple foi uma grande sacada, e os desenvolvedores podem se beneficiar de uma mesma API para seus programas. É, de longe, o sistema operacional mais bem preparado para o formato. O Android ainda não está otimizado para pads, mas nada que não se corrija em uma ou duas versões. Nada se fala de grande no mundo dos Linuxes. Enquanto que a Microsoft…

A Microsoft ainda insiste em usar o Windows em pads. De certa forma, faz sentido. Afinal, se estamos falando sobre substituir os notebooks por pads, também estamos falando que aquele sistema legado da empresa que foi feito para o notebook com Windows também vai rodar no pad.

Mas sabemos que o Windows puro simplesmente não vai funcionar no pad. Mesmo que hajam skins maravilhosas para melhorar a interface da Área de Trabalho, os sistemas feitos para Windows podem não trabalhar perfeitamente. Os menus não são dedáveis. Os botões são muito pequenos. A tela não rola quando o teclado virtual fica em cima de um campo de formulário. Sem falar no desempenho do Windows, que requer quantidade massiva de processamento, e bateria.

Bem, a Microsoft lançou nesse último mês o Windows Phone 7, e as ferramentas de desenvolvimento para o sistema operacional de telefone. Steve Balmer já chegou a dizer que não há plano nenhum em colocar o WP7 nos pads, e pelo que eu andei lendo, ele realmente não foi feito para isso. Mas há quem diga que ainda é possível. Para o desenvolvedor, isso seria bom. Se não pudermos ficar com o Windows, pelo menos teríamos uma única API em dois formatos para nos preocupar – que por acaso é quase a mesma coisa que estava por aí faz alguns anos.

E ainda temos o WebOS e o ChromeOS. Nenhum deles deu a graça em pads ainda, mas o WebOS sempre foi bem aclamado pelo seu multitarefa. A HP disse que tem pads com WebOS saindo em 2011, então só precisamos aguardar.  As idéias de multitasking do WebOS foram parar no Chrome OS, que usa quase as mesmas metáforas: aplicações ocupam a tela inteira e são facilmente alternáveis. O problema do ChromeOS é que ele roda exclusivamente aplicações web, e isso pode ser um problema para os que requerem que as aplicações fiquem armazenadas localmente.

A morte do notebook (como é hoje)

Agora considere as características:

• Portátil
• Leve
• Consumo eficiente
• Conectado
• Fácil de usar

Parece um netbook, certo? Mas são as características de um pad. Além disso, conte que:

• Aplicações promovem a eficiência
• É realmente usável. Acelere sua produtividade com interfaces de toque
• Você pode esquecer o teclado quando não precisa dele, ou pode usá-lo se precisar de longos trabalhos de digitação.

Não é à toa que os netbooks estão morrendo. E levam junto os notebooks de baixo desempenho.

No entanto, não é acreditável que os notebooks irão morrer por completo. O pad é, essencialmente, um aparelho leve. Isso, hoje, implica em baixo desempenho. Algumas aplicações ainda irão requerer o processamento de um bom notebook:

• Designers gráficos
• Edição de vídeo
• Desenvolvimento de aplicações
• Jogos de alto desempenho

Portanto, é provável que, a médio prazo, o mercado de computação móvel esteja segmentado em smartphones, pads, e notebooks de alto desempenho. Isso significa morte aos notebooks de baixo desempenho.

Claro que nada impede que, no futuro, um pad seja tão potente que eu possa fazer edição de vídeo nele, ou chegar em casa, encaixá-lo num dock, e usar mouse, teclado e uma tela de 30 polegadas para jogar um pouco. Estamos quase lá, sim senhor.

Note que eu não estou falando de Tipos Implícitos – Tipos Implícitos, ou var, permitem que você não se preocupe com o tipo de variável.

Não, eu não estou falando de var. Estou falando disso:

var pessoa = new
{
    Nome = "João",
    Idade = 23
};

Console.WriteLine(pessoa.Nome);
// Imprime "João"

Viu o que eu fiz ali? Eu criei um objeto do nada! Quão fantástico é isso, hein? “Olhe mãe, sem definição de classe”.

Bem, se você não está animado até agora, não posso fazer mais nada. Porque a feature acaba aí. Usando essa sintaxe de new, você pode criar um novo objeto simplesmente declarando as propriedades e os valores das propriedades, assim, tudo de uma vez.

Não pense que isso é um objeto superdinâmico. Não há nada de JavaScript aí. Não é possível criar um objeto desse jeito e mais pra frente criar novas propriedades.

var pessoa = new
{
    Nome = "João",
    Idade = 23
};

// Isso é um erro
pessoa.Nascimento = DateTime.Today;

Internamente, o compilador literalmente cria uma nova classe com as propriedades que você declarou, inferiu os tipos das propriedades com o valores, criou um novo objeto com essa classe e atribuiu os valores nele. Ele só não te falou qual é o nome da classe. Ergo, Tipos Anônimos.

Quando usar

Bem Tipos Anônimos é um bom exemplo de feature que parece ser revolucionária, que dá vontade de usar toda hora, mas na verdade é bem difícil achar um caso em que você possa aplicar.

Use o seguinte pensamento para usar Tipos Anônimos:

• Eu preciso atribuir um valor a uma variável
• A variável vai ser usada no mesmo escopo da sua declaração e não vou passar a variável para métodos posteriores
• Os dados que a variável vai receber vêm de um tipo mais complexo, que eu não quero usar
• Mas eu também não quero declarar uma nova classe só para usar aqui
• Portanto, eu vou usar um Tipo Anônimo

Parece restritivo, não é? E é. Na prática, você vai usar tipos anônimos com LINQ, especificamente para a cláusula select.

var pessoas = from pessoa in Pessoas
                select new
                {
                    Nome = pessoa.Nome,
                    Idade = DateTime.Today.Year -
                    pessoa.Nascimento.Year
                };

Detalhes

Existem mais alguns detalhes sobre tipo anônimos:

• As propriedades do objeto são criadas read-only. Isso mesmo, você não pode alterar o valor depois do objeto criado
• As propriedades são sempre public
• Você só pode declarar propriedades. Não é possível criar métodos e eventos em um tipo anônimo
• O tipo é criado como herança de object. Portanto, não é possível tratá-lo como nenhuma outra classe ou interface.
• Se dois objetos são criados com as mesmas propriedades na mesma ordem, o compilador gera apenas uma classe anônima para os dois objetos
• Você não pode passar um objeto de classe anônima para um método
• Você não pode passar um objeto de classe anônima como retorno de um método
• Você pode fazer as duas coisas anteriores se tratar o objeto como object. Mas então, fora do método você vai precisar fazer um casting de object para… o que mesmo?
• Equals() e GetHashCode() já vem implementados. Duas instâncias de mesmo tipo anônimo são iguais se todas as propriedades são iguais.

Concluindo

Basicamente, você vai usar tipos anônimos quando você quer reduzir a complexidade de um objeto para usar em seguida somente para leitura. Em outras palavras:

• Em código de visualização de dados (código de views),
• Ou como passo intermediário em uma transformação de dados complexa.

De qualquer forma, tipos anônimos são uma boa para reduzir a complexidade de código e, se bem usada, pode gerar belos programas.

Tipos anônimos estão disponíveis a partir da versão 3.0 do .NET Framework.

Uma das features do .NET 3.0 é uma coisa chamada Propriedades Auto-Implementadas. Eu adoro o time de nomeação de features da Microsoft. De qualquer forma, essa coisinha permite reduzir drasticamente a quantidade de código necessário para escrever uma classe.

Vou mostrar o que eu quero dizer. Há milhares de anos atrás, em C#, nós costumávamos declarar propriedades dessa forma:

private int _idade;
public int Idade
{
    get
    {
        return _idade;
    }
    set
    {
        _idade = value;
    }
}

Está vendo todo esse código aí? Tudo isso para criar uma propriedade, Idade. Eu falo a você. Antigamente nós subíamos montanhas com pés descalços. Com vento contra.

Mas não mais. Com o C# 3.0, eu e você podemos escrever propriedades simples assim:

public int Idade { get; set; }

• Sem campos privados
• Com muito menos linhas de código
• Com acessadores get e set funcionando perfeitamente

Internamente, o compilador vai criar campos privados para armazenar os valores da propriedade. Você não vai ter acesso a esses campos. Não importa. Você pode usar a propriedade para setar valores.

Veja essa classe com 4 propriedades declaradas:

class Pessoa
{
    public string Nome { get; set; }
    public string Endereco { get; set; }
    public int Idade { get; set; }
    public DateTime Nascimento { get; set; }
}

Pessoa p = new Pessoa();
p.Nome = "Somalia";

Isso seria impossível de conceber. Uma classe com quatro propriedades e 7 linhas?

E quando você deve usar essa sintaxe? Sempre. Sempre. Não há nenhuma perda em termos de desempenho em runtime, e o código fica aproximadamente 1337% mais claro. Não use a sintaxe antiga, a menos que você tenha uma boa razão para usar.

Uma boa razão para usar a sintaxe antiga

Você vai querer usar a sintaxe antiga se a propriedade não for trivial como setar ou buscar valor. Se Idade da classe Pessoa for um campo calculado, talvez não seja possível usar essa sintaxe de propriedade auto-implementada:

class Pessoa
{
    public string Nome { get; set; }
    public string Endereco { get; set; }
        
    public DateTime Nascimento { get; set; }

    public int Idade
    {
        get { return DateTime.Today.Year - Nascimento.Year; }
    }
}

Restringindo modificação

Com a sintaxe mostrada, é possível perceber que tanto o get quanto o set são públicos. Em alguns casos você não vai querer esse comportamento. Na classe Pessoa, o Nome e a data de Nascimento não podem ser modificadas depois da criação do objeto.

Nesse caso, você pode usar a sintaxe do private set.

class Pessoa
{
    public Pessoa(string nome, DateTime nasc)
    {
        Nome = nome;
        Nascimento = nasc;
    }

    public string Nome { get; private set; }
    public DateTime Nascimento { get; private set; }

    public string Endereco { get; set; }

    public int Idade
    {
        get { return DateTime.Today.Year - Nascimento.Year; }
    }
}

private set torna set privado (duh). Isso quer dizer que, dentro da sua classe, você pode alterar os valores das propriedades simplesmente acessando a elas. Fora da classe, a propriedade é read-only. Isso quer dizer também que, se você quer passar valores às propriedades na inicialização, você precisa criar um construtor apropriado.

Concluindo

Simples e direto. Propriedades Auto-Implementadas é uma dádiva digital. Use. Sempre. Você vai querer usar sempre, será sua primeira escolha, a não ser que você tenha um bom motivo para não usar.

Um desses recursos é o famoso Tipo Implícito, também conhecido como var:

var numbers = new[] {4,8,15,16,23,42};

Console.WriteLine(numbers.Length);

O recurso é bem básico e fácil de usar. Faça o seguinte:

1. Use a palavra chave var para definir o tipo de uma variável ao invés do tipo real;
2. Note que a variável se comporta como uma variável tipada, incluindo Intellisense;
3. Lucre.

Uma nota importante antes de prosseguir: var não é object. var não serve para deixar uma variável aceitar qualquer tipo. Ele indica ao compilador para ele decidir que tipo a variável, e o compilador faz isso na primeira inicialização dela. Assim, isso dará um erro:

var numbers = new[] {4,8,15,16,23,42};

numbers = 23;

Porque de início, numbers foi inicializado como int[] e na linha 3 o código tenta atribuir um int à variável. No can do. var não é object, var é um recurso para deixar o compilador atribuir o tipo por você. A natureza fria e burocrática da tipagem em .NET ainda corre por baixo.

Mas deixe-me mostra exemplos onde isso é realmente interessante:

• Você pode criar variáveis locais var para receber valores de um método, mas não se importar com a documentação do método para descobrir que tipo ele vai retornar

var pessoa = Buscar(42);

Console.WriteLine(pessoa.ToString());

• Você pode usar no inicializador de um for

for (var i = 0; i < 10; i++)
{
    Console.WriteLine(i);
}

• Você pode usar em um foreach

foreach (var p in Pessoas)
{
    Console.WriteLine(p.ToString());
}

• Você pode usar para definir uma variável no using

using (var comando = new OracleCommand("select * from pessoas"))
{
}

Ah, e eu já falei que você não perde nenhum recurso do Visual Studio, não é? Se você pousar o mouse sobre a variável, o Visual Studio te fala qual é o tipo real. Se você teclar Control+Espaço, ele te dá Intellisense correto:

Como tudo que é bom tem restrições, você não pode:

• Usar var como tipo de retorno de um método ou propriedade

• Usar var como tipo de parâmetro de um método

• Usar var em uma constante

Quando Usar

O uso de var reduz a burocracia da tipagem, mas pode levar a um código confuso se ele for usado ao extremo. Imagine um código onde tipos não são mais declarados, e todo desenvolvedor é obrigado a sair a caça das declarações para inferir o tipo da variável.

Não, muito obrigado. Mas talvez você queira usar var quando:

• Se referir a tipos anônimos (na verdade, você é obrigado)

var pessoa = new { Nome = "João", Idade = 23 };

• Se referir a expressões LINQ

var pessoas = from p in Pessoas 
              where p.Nome.Contains("Somalia") 
              select p.Nome;

• Se referir a tipos genéricos complexos

var table = new Dictionary<string, object>();

E talvez você prefira declarar o tipo quando as atribuições forem mais simples e diretas.

Parágrafo Bônus: Arrays Implícitos

Se você viu o primeiro código exemplo deste post, deve ter percebido uma forma de tipagem implícita com o array:

var numbers = new[] {4, 8, 15, 16, 23, 42};
// numbers é implicitamente tipado para int[]

Bem, numbers é tipado como int[] sem mesmo a criação do array indicar que é um int[]. A única coisa que aparece na criação do array é um tal de new[].

Bem new[] é a palavra chave para os arrays tipados implicitamente. Basicamente o compilador, quando encontra new[], checa os tipos dos itens do array declarados logo a seguir para definir o tipo do array.

Outros exemplos:

// string[]
var words = new[] { "hello", null, "world" }; 

// int[][]
var matrix = new[]
{  
    new[]{1,2,3,4},
    new[]{5,6,7,8}
};

Concluindo

var reduz a burocracia do código e pode dar uma aliviada naquele código extremamente declarativo. Se você seguir algumas boas práticas para evitar o superuso, seu código vai ficar mais legível. Use sempre que possível. Vale lembrar que o uso de var não acarreta em nenhuma perda de desempenho do código final.

Como quase todas as coisas boas do .NET, var está disponível a partir da versão 3.0.

Pois bem, minha última pendenga com ADO.NET foi com parâmetros de comando. Para quem não é versado no assunto, basicamente o ADO.NET é estruturado de forma que você possa enviar comandos SQL para um banco de dados (como SELECT, INSERT, CREATE TABLE, etc) ou fazer chamadas a stored procedures e functions.

Rege as leis dos bons costumes (e o medo do SQL Injection) que, sempre que for necessário enviar dados para um comando SQL (como o filtro de um SELECT), você precisa usar parâmetros de comando. Ou seja, ao invés de você fazer isso:

public List<Pessoa> ListarPessoas(string nome)
{
    string query = "SELECT * FROM PESSOAS A WHERE A.NOME LIKE '%" + nome + "%'";
    OracleCommand comando = new OracleCommand(query);

    // Continua..

É bem melhor para sua sanidade e emprego fazer isso:

public List<Pessoa> ListarPessoas(string nome)
{
    string query = "SELECT * FROM PESSOAS A WHERE A.NOME LIKE :nome";    
    OracleCommand comando = new OracleCommand(query);

    OracleParameter param = new OracleParameter("nome", nome);
    param.OracleType = OracleType.VarChar;
    comando.Parameters.Add(param);

Só que com essa pequena adição de segurança, você ganha também uma porção de linhas de código a mais no seu programa. Que você terá que escrever. Imagine um comando relativamente realístico cheio de parâmetros como este:

string query = "SELECT * FROM PESSOAS A WHERE " +
    "A.NOME LIKE :nome AND " +
    "A.IDADE > :idade AND " +
    "DATA_CADASTRO >= :data_inicial " +
    "DATA_CADASTRO <= :data_final ";

Consegue ter uma idéia de quantas linhas de código são necessárias para adicionar todos esses parâmetros? Quanto tempo vai ficar perdendo tempo com burocracia de código? Quão mais próximo de um colapso do túnel de carpo? Eu digo a você: a resposta é muito.

Nessas horas eu me pego filosofando: deve haver um modo mais fácil de fazer isso. Um modo de economizar trabalho burocrático. Um modo de escrever apenas o essencial, de se livrar da gordura. Diabo, um modo de consertar essas classes que não pensam na saúde dos seus clientes.

E por incrível que pareça, existe um modo. A solução se chama Extension Methods, e está no .NET Framework a partir da versão 3.0.

Extension Methods

A verdade é que os programadores do ADO.NET se esqueceram do trabalho diário dos seus clientes. Se eu tivesse o poder de alterar alguma coisa no ADO.NET, eu incluiria um método mágico a classe OracleCommand. Esse método mágico receberia três parâmetros: seu nome, seu tipo, e o valor a atribuir. Eu planejaria usar esse método dessa forma:

comando.AddInputParameter("nome", OracleType.VarChar, nome);

E quer saber? É exatamente isso que o Extension Methods faz por você.

Extension Methods permite que você adicione métodos em classes já existente e compiladas sem ter que:

1. Criar um tipo derivado
2. Recompilar
3. Modificar de qualquer modo a classe original

Mágica? Parece, mas os Extension Methods nada mais são que métodos static com parâmetros especiais. Para o código cliente – ou seja, a sua classe que usa a classe estendida – é como se o método pertencesse ao tipo original. Mas não se engane: os Extension Methods não modificam o tipo original de forma alguma, tampouco permite acessar membros privados. Mas são divertidos pra caramba.

OK, vamos à obra. Para criar um método de extensão você precisa de três coisas bem simples:

1. Criar uma classe static com um nome sugestivo, como OracleCommandExtension (viu o que eu fiz? Esperto eu, hein?);
2. Criar o método de extensão desejado como um método public e static nessa classe recém-criada;
3. O primeiro parâmetro desse método precisa ser da classe que você quer “estender”, e precisa ter o modificador this no parâmetro.

Sem mais delongas, veja como eu criei minha classe OracleCommandExtension:

static class OracleCommandExtension
{
    public static void AddInputParameter(this OracleCommand comm, 
        string name, OracleType type, object value)
    {
        OracleParameter par = new OracleParameter(name, value);
        par.OracleType = type;
        comm.Parameters.Add(par);
    }
}

Reveja os pontos: classe static, método public e static, primeiro parâmetro com this e do tipo que eu quero estender. Note então o que eu faço no método: exatamente o que eu faria no código cliente – criar o parâmetro, configurar o parâmetro, colocar o parâmetro na lista de parâmetros do comando. Ou seja, todo o código burocrático e chato vai pro método de extensão.

Como usar? Simples demais. Simplesmente acredite que esse método agora faz parte da classe estendida:

OracleCommand comando = new OracleCommand(query);
comando.AddInputParameter("nome", OracleType.VarChar, nome);

Divino, ham? Tirando o primeiro parâmetro declarado no método de extensão (que indica a classe estendida), os outros parâmetros são mantidos para o código cliente usar.

Parece que a classe acabou de ganhar um novo método, mas não foi bem isso que aconteceu. Internamente, o compilador do C# traduz isso que você escreveu para isso:

OracleCommand comando = new OracleCommand(query);
OracleCommandExtension.AddInputParameter(comando, "nome", OracleType.VarChar, nome);

Portanto, não ligue perguntando porque você não consegue acessar campos privados ou protegidos, ou não consegue reescrever métodos virtuais. Extension Methods não é subclassing; é uma forma de eliminar a gordura do código cliente. No Visual Studio, os métodos de extensão aparecem diferentes no Intellisense: com uma setinha azul junto ao ícone do método, e com os dizeres (extension):

Estendendo coleções

Uma maneira muito legal de usar Extension Methods é com coleções. Sabe aquelas operações que precisam ser feitas levando em consideração todos os itens da coleção? Como “transformar todas as strings da lista em maiúsculas” ou “somar todos os números da coleção”? Ao invés de fazer foreaches sempre que precisar fazer isso, simplesmente crie um Extension Method e se livre da gordura.

Veja um método que estende List<string> para transformar todas as strings da lista em maiúsculas:

static class ListStringExtension
{
    public static void ToUpper(this List<string> list)
    {
        for (int i = 0; i < list.Count; i++)
        {
            if (string.IsNullOrEmpty(list[i])) continue;
            list[i] = list[i].ToUpper();
        }
    }
}

class Program
{        
    static void Main(string[] args)
    {
        List<string> lista = new List<string>();
        lista.Add("uva");
        lista.Add("pera");
        lista.Add("maçã");

        lista.ToUpper();

        foreach (string fruta in lista)
        {
            Console.WriteLine(fruta);
        }
    }
}

O primeiro parâmetro pode ser uma interface também. Veja um método de extensão que estende todas as coleções de decimal.

static class NumberCollectionExtension
{
    public static decimal Sum(this ICollection<decimal> list)
    {
        decimal sum = 0;
        foreach (decimal d in list)
        {
            sum += d;
        }
        return sum;
    }
}

class Program
{        
    static void Main(string[] args)
    {
        decimal[] numbers = { 4, 8, 15, 16, 23, 42 };

        Console.WriteLine(numbers.Sum()); // 108
    }
}

Extension Methods combinam tanto com coleções, que acabou se tornando a base para o LINQ. Falaremos de LINQ nos próximos artigos.

Pra acabar

Alguns pontos importantes sobre Extension Methods:

• Extension Methods não é herança (não custa nada lembrar)
• Extension Methods permite eliminar código repetitivo – de maneira elegante!
• Extension Methods transforma classes chatas de usar em classes menos chatas de usar
• Você pode criar Extension Methods para qualquer tipo em .NET:
  • Classes
  • Interfaces
  • Structs
  • Enums
• Se você criar um Extension Method com o mesmo nome de um método que já existe na classe estendida, o método de extensão nunca será chamado
  • Por exemplo, criar um método de extensão Count para a classe List<T> não adianta nada: o Count que já existe lá é que será chamado. Sempre.
• Atenção às bibliotecas de extensão! Se você criar bibliotecas com métodos de extensão e quiser usar em outros projetos, lembre-se que o compilador não pode encontrar os métodos de extensão se não puder encontrar a classe de extensão. Portanto, faça isso:
  • Declare a classe de extensão como public
  • No seu projeto cliente, adicione referência à biblioteca onde está a classe de extensão
  • No código cliente, crie um using para o namespace onde está a classe de extensão

Extension Methods é provavelmente a coisa mais legal que inventaram depois de pão fatiado. Recomendo a todos que usem!

Veja bem, não quero começar aqui uma discussão religiosa sobre linguagens de programação. Eu vejo a coisa de uma forma bem pragmática. Toda a questão sobre tipagem forte ou fraca no fim se resume a onde você, programador, quer ver o erro: na compilação ou no software rodando.

O problema com o .NET fortemente tipado é pela quantidade de declarações, castings, conversões de tipo você precisa fazer para um simples programa com uma coleçãozinha. Estou falando do ArrayList:

ArrayList pessoas = new ArrayList();

// Dentro do ArrayList vai qualquer coisa
pessoas.Add(new Pessoa("Fabricio"));
pessoas.Add(new Pessoa("Somalia"));

// Para devolver, você precisa dizer o que quer
Pessoa somalia = (Pessoa) pessoas[1];
Console.WriteLine(somalia.Nome);

A “grande” vantagem do ArrayList é que, como ele é uma coleção de object, ele pode receber qualquer coisa como item. O ArrayList é uma mãe: o que você mandar pra ele, ele recebe. Mas toda essa vantagem é jogada fora quando você quer o objeto de volta: você precisa dizer o que quer (casting). E que uma entidade oniciente te ajude caso o objeto que você espera não seja o que você pensa que é.

Quero dizer, uma vez me falaram que com o ArrayList você podia jogar qualquer coisa dentro. Tipo, misturar os objetos mesmo. Assim, ó:

ArrayList bagunca = new ArrayList();

bagunca.Add("Eu não queria estar nesse ArrayList");
bagunca.Add(42);
bagunca.Add(new Pessoa("Almeida Soares"));

foreach (string item in bagunca) // Isso não vai dar certo
{
	Console.WriteLine(item);
}

Sério? Quem programa coleções desse jeito? Isso não é vantagem, é um problema! O código acima vai quebrar, e você só vai descobrir quando rodar o programa.

O fato é que seria perfeito se:

1. Com uma única classe de coleção, pudéssemos adicionar qualquer objeto
2. Não precisássemos fazer castings e converões na hora de usar a coleção
3. Seja impossível um usuário da classe fazer bagunça em uma coleção (misturando valores adicionados)

Bem, alguém ouviu essas preces, implementou no .NET Framework, e chamou de Generics.

A idéia de Generics é a gente poder escolher, na hora de criar o objeto de coleção, qual classe a coleção vai aceitar como item. Complexo? Um exemplo então. Eis a versão Generics do ArrayList, o List:

List<Pessoa> pessoas = new List<Pessoa>();

pessoas.Add(new Pessoa("Fabricio"));
pessoas.Add(new Pessoa("Somalia"));

pessoas.Add(42) // isso nao funciona
pessoas.Add("Uma string malandra") // isso também não

Veja bem a declaração do objeto List. Note bem uma classe Pessoa pairando dentro daquilo que parace uma tag de HTML.

Acontece que o List por si só é um concha vazia. Uma alma sem cara-metade. Um barco sem mar, um campo sem flor. O List, como todas as classes Generics, precisa de um argumento, um tipo declarado entre o < e o >, que é justamente a classe alma-gêmea do Generics.

Quando você cria um objeto Generics com um argumento – digamos, um List com argumento Pessoa – tudo muda. O objeto Generic deixa de ser uma casca vazia. No nosso exemplo, a List passa a aceitar apenas objetos Pessoa. Coisas como números, strings e Enderecos não entram. A ajuda do Intellisense no Visual Studio mostra isso:

Mais tarde, se você precisar criar uma coleção de números, basta informar o tipo int na declaração da coleçao:

List<int> numeros = List<int>();

numeros.Add(4);
numeros.Add(8);
numeros.Add(15);
numeros.Add(16);
numeros.Add(23);
numeros.Add(42);

numeros.Add("números malditos!"); // nao permitido

Como você já pode ou não estar pensando, para obter um valor da lista é muito simples: basta obtê-lo!:

List<Pessoa> pessoas = new List<Pessoa>();

pessoas.Add(new Pessoa("Fabricio"));
pessoas.Add(new Pessoa("Somalia"));

Pessoa somalia = pessoas[1]; // livre de castings!

Console.WriteLine(somalia.Nome);

Entende como isso é libertador? Sem conversões. Sem insegurança de tipagem. Com ajuda. É uma vida mais feliz.

Mas não é só isso. Generics também melhora o desempenho de sua aplicação!

É que quando você cria um objeto Generic e o associa a um argumento do tipo de valor, o compilador, quando vai fazer coisas de compilador, olha para o List<int> e diz: “Humm, então você quer uma classe especializada para inteiros”. Pois o compilador literalmente cria uma classe especializada para inteiros, onde as estruturas internas são variáveis para inteiros.

Se você criar então, digamos, um objeto List<char>, o compilador vai lá e cria uma classe especializada só para char. Isso quer dizer que os valores não são mais guardados dentro de variáveis object – eles são guardados em variáveis tipadas apropriadamente. Conversões internas não são mais feitas a torto e direito. Desempenho for free.

Então ganhamos:

1. Com uma única classe de coleção, podemos adicionar qualquer objeto – basta declarar o tipo da coleção na declaração da variável
2. Não precisamos fazer castings e conversões na hora de usar a coleção – e o Intellisense do Visual Studio ajuda na hora de usar a coleção
3. É impossível um usuário da classe fazer bagunça em uma coleção – a não ser, claro, se ele declarar um List<object>

Generics em classes, interfaces, métodos…

Generics no .NET não está presente só em classes de coleções. Claro, de longe, a maior utilidade dos Generics no Framework são para coleções. Eu só falei do List<T>, mas outras coleções notáveis são:

• Dictionary<TChave, TValor>: é a versão Generic no Hastable. Ou seja, uma Hashtable tipada. Você especifica não um, mas dois argumentos – um para o tipo da chave do Hashtable, um para o tipo do valor que será guardado. Vive inseparável da classe KeyValuePair<TChave, TValor>, que nada mais é que o objeto que o Dictionary<TChave, TValor> guarda.

Dictionary<string, Color>() cores = new Dictionary<string, Color>();

cores.Add("RED", Color.FromArgb(255, 0, 0));
cores.Add("BLU", Color.FromArgb(0, 255, 0));

foreach (KeyValuePair<string, Color> item in cores)
{
	Console.WriteLine(item.Key);
	Console.WriteLine(item.Value.IsKnownColor);
}

• Queue<T>: versão Generic do Queue. Fila tipada pronta para uso.

Queue<Pessoa> vacinacao = new Queue<Pessoa>();

vacinacao.Enqueue(new Pessoa("Fabricio"));
vacinacao.Enqueue(new Pessoa("Somalia"));

Pessoa p = vacinacao.Dequeue();

Console.WriteLine(p.Nome); // Fabricio

• Stack<T>: versão Generic do Stack. Pilha tipada pronta para uso.

Stack<Prato> pratosParaLavar = new Stack<Prato>();

pratosParaLavar.Push(new Prato("Porcelana"));
pratosParaLavar.Push(new Prato("Duralex";));

Prato p = pratosParaLavar.Pop();

Console.WriteLine(p.Tipo); // Duralex

Você pode encontrar Generics em interfaces também. Essas interfaces podem ser usadas como tipos de variáveis, ou para criar outras classes. Por exemplo, o List<T> possui um método chamado Sort. Como você pode imaginar, Sort ordena os itens da coleção. Tudo parece claro: se a lista é de inteiros, Sort os ordena em ordem crescente; se a lista é de strings, Sort as ordena em ordem alfabética. Mas e se a lista for de Pessoa? Ah, bem, então o método quebra gerando uma excessão.

A não ser que Pessoa implemente a interface IComparable<T>. Você sabe, quando você implementa uma interface, você precisa seguir o mestre. E o mestre IComparable<T> manda que você tenha um método chamado CompareTo(T).

Veja todos esses T soltos pelo ar. Isso é ótimo. Quer dizer que, bolas, você não precisa se preocupar com o tipo adjacente ao qual todas esses Ts estarão associados no futuro. Você só precisa entender: se Pessoa implementa IComparable<Pessoa>, quer dizer que a classe Pessoa possui um método CompareTo(Pessoa outra), que vai dar modos a Sort<Pessoa> da coleção List<Pessoa> de ordenar todos os itens. Troque todas as Pessoa por Prato, e a lógica é a mesma. Ou por Carro. Ou por Cantor.

class Pessoa : IComparable<Pessoa>
{
    public Pessoa(string nome)
    {
        Nome = nome;
    }

    public string Nome { get; set; }

    public int CompareTo(Pessoa other)
    {
        return Nome.CompareTo(other.Nome);
    }
}

class Program
{
    static void Main(string[] args)
    {
        List<Pessoa> pessoas = new List<Pessoa>();

        pessoas.Add(new Pessoa("João"));
        pessoas.Add(new Pessoa("Maria"));
        pessoas.Add(new Pessoa("José"));
        pessoas.Sort();

        // Mostra na ordem: João, José, Maria
        foreach (Pessoa p in pessoas)
        {
            Console.WriteLine(p.Nome);
        }
    }
}

E, sim, você pode encontrar métodos precisando de argumentos de tipo. Utilíssimo quando você quer criar um método que faz coisas genéricas que servem para qualquer coisa – e ainda assim conservar a beleza da tipagem.

Imagine, por exemplo, um método para trocar valores de variáveis. Um método como esse:

void Swap(ref object esquerda, ref object direita)
{
	object temp = esquerda;
	esquerda = direta;
	direita = temp;
}

Veja, esse método parece uma boa… mas não funciona. O que você acha que acontece se eu fizer isso:

int a = 1;
int b = 2;

Console.WriteLine("{0} - {1}", a, b); // 1 - 2

Swap(ref a, ref b); // uhh.. erro

Console.WriteLine("{0} - {1}", a, b);

Isso é erro na certa. Por que Swap precisa de referências de object, e ref a certamente não é uma. Ok, poderíamos usar objects na declaração dos números, mas daí é adeus a checagem de tipo: nada impede de um espírito de porco tentar fazer swap de uma string com um número… e por aí vai.

Generics nos oferece uma solução muitíssimo mais elegante:

void Swap<T>(ref T esquerda, ref T direita)
{
    T temp = esquerda;
    esquerda = direita;
    direita = temp;
}

Veja a elegância desse código. Ele faz o que deveria fazer: troca os valores de duas variáveis. O tipo das variáveis não importa – o usuário do método decide na hora. E o uso?

int a = 1;
int b = 2;

Console.WriteLine("{0} - {1}", a, b); // 1 - 2

Swap<int>(ref a, ref b); // agora sim

Console.WriteLine("{0} - {1}", a, b); // 2 - 1

E a sintaxe de brinde é a seguinte: você não precisa especificar o tipo na hora de usar o método. O compilador infere o tipo e compila pra você:

Swap(ref a, ref b); // superb

Ah sim, você não precisa criar uma classe Generics para usar métodos Generics. Você pode começar a fazer com métodos Generics com suas classes feinhas do jeito que elas estão. Exato, agora mesmo.

Resumão

• Com Generics, você nunca erra o tipo
• Com Generics, você não precisa implementar classes específicas para cada caso
• Com Generics, coleções não têm nem a possibilidade de virar bagunça
• Com Generics, você nunca terá que fazer casting ao obter objetos de coleção
• Com Generics, seus métodos ficam turbinados.
• Com Generics, você escreve menos código
• Com Generics, seu código fica mais rápido
• Com Generics, a natureza fortemente tipada do .NET fica menos irritante

Como quase todas as coisas legais no .NET Framework,  Generics está disponível para a gente a partir da versão 2.0.

class Pessoa
{
   public string Nome { get; set; }
   public int Idade { get; set; }
}

Consciência limpa, trabalho feito, fui mostrar a classe para minha tia. Qual não foi minha surpresa quando o seguinte diálogo se secedeu:

Minha tia: “E se eu não tiver uma idade para informar?”
Eu: “Como assim, toda pessoa tem uma idade!”
Minha tia: “Nem toda.”
Eu: “Exemplifique..”
Minha tia: “Tenho umas clientes que não gostam de informar a idade..”

Pois é. Minha classe infalível tinha a mancha de uma falha. Que fazer?

A saída foi usar os Nullables. Os Nullables estão presentes no .NET Framework desde a versão 2.0. Basicamente, eles permitem que variáveis do tipo de valor (em contraste com os tipo de referência) possam receber valores nulos.

Em C#, você declara uma variável Nullable colocando um ponto de interrogação (também conhecido como ?) depois do tipo, na declaração da variável. Assim:

int? numeroNullable;

numeroNullable = null;

Fantástico, ahm? Os Nullables são ótimos para valores que podem receber nulos, sem a necessidade de boxing. Em C#,  isso quer dizer que não é preciso tratar a variável como object só porque ela pode receber nulos.

Minha classe estava salva então:

class Pessoa
{
   public string Nome { get; set; }
   public int? Idade { get; set; }
}

Conversões ??

Por algum motivo sombrio, minha tia queria também que eu somasse a idade de todas as pessoas do sistema dela. A primeira idéia que me passou pela cabeça parecia correta, então implementei:

int soma = 0;
foreach (Pessoa p in pessoas)
{
    soma += p.Idade; // parece uma boa, mas não é
}

Quando implementei isso, o compilador simplesmente riu da minha cara. O problema é que, embora exista conversão implícita de um tipo de valor para seu Nullable correspondente, não existe conversão implícita de valor Nullable para seu tipo simples. Eu tive, e você terá, que usar o método GetValueOrDefault() se quiser obter o valor simples do Nullable.

int soma = 0;
foreach (Pessoa p in pessoas)
{
    soma += p.Idade.GetValueOrDefault(); // agora sim
}

E se  a variável Nullable for null? Nesse caso, o valor padrão do tipo é retornado. Para inteiros, o valor padrão é 0. Mas GetValueOrDefault() também pode receber um valor como parâmetro. Esse valor é retornado pelo método, caso o Nullable seja null:

int? nullable = null;
int valor = nullable.GetValueOrDefault(42); // valor agora é 42!
nullable = valor;
valor = nullable.GetValueOrDefault(23); // valor continua sendo 42

E como existem pessoas boas no mundo, alguém achou que criar um operador para esse método ia ser uma boa. Eu te digo mais, é uma ótima! Eis o operador ??:

int soma = 0;
foreach (Pessoa p in pessoas)
{
    //soma += p.Idade.GetValueOrDefault(); // nah, muito grande
    soma += p.Idade ?? 0; // ah, bem elegante!
}

Tem valor? Me dê o valor

Minha tia queria também que eu criasse um método para obter as pessoas com uma certa idade (determinado por um parâmetro). Só que ela queria aproveitar o método para trazer todas as pessoas caso ela não apresentasse uma idade. Dá pra usar Nullables na veia (veia, não véia):

List<Pessoa> TrazerPessoas(int? idade)
{
    // Algo vai acontecer aqui
}

Como pode ver, Nullables podem ser usados em declaração de parâmetros também. Para fazer o método funcionar, lembre-se que todo Nullable também possui duas propriedades: HasValue e Value. HasValue indica se há valor na variável (retornando true) ou se a variável é null (retornando false). Se houver valor, ele estará na propriedade Value. Mas lembre-se que chamar Value quando HasValue é false acaba em uma excessão.

List<Pessoa> TrazerPessoas(int? idade)
{
    List<Pessoa> pessoas = ObterPessoasDoRepositorio();
    if (!idade.HasValue)
    {
        return pessoas; // Não passou idade, retornar tudo
    }

    // Nesse ponto, idade possui valor. Filtrar
    List<Pessoa> filtradas = new List<Pessoa)();
    foreach (Pessoa p in pessoas)
    {
        if (p.Idade == idade.Value)
        {
            filtradas.Add(p);
        }
    }
    return filtradas;
}

bool?

Veja bem, você pode usar operadores lógicos (&&, ||, !) com variáveis bool Nullables. Só preste atenção na tabela verdade, porque null entra na jogada. Por exemplo, false || null é false, mas true || null é true. Confuso?

Use as regras para não se perder:

• O operador && só pode retornar true se ambas as partes for true
  • Se uma das partes for false, então a resposta é false não importando a outra parte
  • Para todas as outras opções, o resultado é null
• O operador || só pode retornar false se ambas as partes forem false
  • Se uma das partes for true, então a resposta é true não importando a outra parte
  • Para todas as outras opções, o resultado é null
• !null é null
  • !true é false, e !false é true mesmo.

Resumão

Pra acabar, um resumão de Nullables:

• Nullables representam variáveis de valor que podem receber null
• Você pode criar um Nullable com qualquer tipo de valor
  • tipos simples (números e char)
  • enums
  • structs
• Você não pode criar Nullables com variáveis de referência (não existe string?)
• Você declara um tipo Nullable com a sintaxe T?, onde T é o tipo simples de valor
• Você pode atribuir valores a Nullables como se fossem tipos simples (como em int? a = 10)
• Use GetValueOrDefault() para converter valores Nullables em tipos simples. Use ?? para converter valores Nullables em tipos simples (como em int a = nullable ?? 0)
• Use HasValue para saber se existe valor na variável
• Use Value para obter o valor simples do Nullable, mas só se HasValue for true
• A tabela verdade de bool? é confusa

As buscas por gente e as pesquisas no campo da geografia revelaram um planeta árido, com poucas condições de sobrevivência a curto prazo. O Conselho tomou talvez a mais importante decisão política de toda a história. Ao invés de desenvolver pesquisas para recuperar as áreas afetadas, o Conselho criou um programa de sobrevivência espacial e retomou o programa SETI – Busca por Inteligência Extra Terrestre.

Já possuíamos a tecnologia espacial antes do desastre. Possuíamos colônias na Lua, Marte e em duas de suas luas. Colônias não habitadas, mas ainda assim, com potencial para tal. Modifica-las ia ser relativamente barato, caro seria reconstruir a infra-estrutura para lançar objetos para o espaço. Enquanto isso o programa SETI, que havia desativado em 2028 por falta resultados, agora estava a todo vapor procurando com tecnologia avançadíssima todo o espectro de luz em busca de sinal de vida alienígena.

Duzentos anos são suficientes para os humanos se reerguerem. Em 2260, o meu povo comemorava o duocentenário da sobrevivência humana com a inauguração da segunda colônia habitada, em Io, lua de Marte. Três milhões de habitantes na Terra, alguns poucos milhares em Marte. A sociedade naquela época era pacífica. Graças a tecnologia, tinham sobrevivido à armadilha do acaso e podiam sonhar com o futuro. Não havia guerras entre povos, mas os recursos naturais iam se esvaindo. O planeta estava quente, efeito dos imensos desertos que cobriam mais de trinta por cento da superfície e o desaparecimento gradual de florestas e águas. Os homens se mantinham graças aos dispositivos óptico-eletrônicos de alto desempenho, como computadores que nunca precisavam ser recarregados, sistemas de refrigeração sem emissão de gases poluentes, geradores de energia de fontes retornáveis.

Quando os primeiros seres extra-terrestres fizeram contato com os humanos, poucos ainda vivam no planeta. A maior parte dos 15 bilhões de humanos vivia em luas de planetas vizinhos ou em estações orbitais, como essa em que estou agora. Eram, de certa forma, extraterrestres também. A data era 30 de décimo de 2846. A primeira raça alienígena a entrar em contato fora do setor de Alpha-Centauri, estrela que ficava a apenas 50 anos-luz do nosso Sol. Eram pacíficos, tinham tecnologia superior, no entanto, logo se descobriu que em nada o nível intelectual se superava ao nosso, entretanto, tinham uma capacidade superior para se adaptar. Tanto que, em cinqüenta anos, a maior parte dos habitantes da Terra era provinda do setor Centaurino.

Na virada do quarto milênio já contabilizávamos relações comerciais com mais de 30 raças alienígenas, que nos trouxeram tecnologia superior e cultura muito diversa que se poderia imaginar 20 décadas atrás. A tecnologia nos fez espalhar por mais de dois mil planetas, viver mais de 180 anos, sobreviver nas condições mais bizarras de ambiente, construir naves, cápsulas, armas. A convivência com esses povos nos trouxe sua cultura, religião, alimentação, e principalmente, um crescimento no modo de enxergar as coisas com os olhos dos outros. Os humanos eram muito mais conscientes de seu lugar no universo do que 500 anos antes.

Mas tinham o mesmo espírito de 5000 anos antes. Não precisarei descrever a participação da raça em vários combates setoriais, e até sua participação ativa na Terceira Guerra Intergaláctica. Guerra traz tecnologia. E a tecnologia era base do progresso humano. Graças à tecnologia o homem era o que era naquele tempo.

Não haveria homem sem a ajuda das máquinas, então o homem pensou se poderia haver máquina sem homem. Na verdade, essa idéia perdurava desde os primeiros autômatos de 1950, e o sonho de o homem criar uma máquina que não necessitasse mais dele era algo quase que inexplicável. Essa idéia era evidente desde os primeiros robôs de auxílio doméstico, os autômatos de entretenimento, os bichos de estimação simulados. Mas por mais que a tecnologia conseguisse reproduzir fielmente o comportamento de um gato, ou os sentimentos de mulogh, os humanos ainda esbarravam na limitação do fato de que essas coisas ainda precisavam ser criadas. Para o homem, a perfeição só iria ocorrer quando a máquina produzisse a própria máquina, através de decisões próprias, e não programadas.

Fizemos bons avanços nessa área. Em 3827, foi mostrado a público o Miracle II, que era capaz de se reprogramar por própria vontade. Na verdade ele ainda foi um computador fabricado pelo homem, mas as rotinas que usaram nele foram ínfimas, ele próprio ajudou em sua construção. O Miracle VII, que tornaria a ter o nome da incrível máquina de 80 anos atrás, tinha a principal característica de ser totalmente autônoma, podendo viajar através das redes interestelares e fazer quase todo tipo de atividade que um software poderia fazer, inclusive modificar seu hardware para chegar a uma solução do problema. Ainda havia uma limitação a esses engenhos. Eram construídos com alguma base de certeza do que poderiam fazer, e depois de prontos, não iam além. Ou seja, não eram capazes de criar, tampouco de fazer decisões próprias verdadeiras.

Em 3963, o universo, humano ou alienígena, já era bem conhecido. Teoricamente, toda a ciência física já havia sido inventada. Mas ainda não conseguíamos resolver uma questão: de onde viemos e para onde iremos. Não sabíamos como o universo criou-se a si mesmo, e se não se criou, não podíamos responder o que havia antes. Mas já havíamos estado em boa parte do universo conhecível, e se não, não era problema ir até um lugar totalmente inexplorado. Graças a tecnologia quântica-relativista, a idéia de quarta dimensão foi provada na prática e com isso as facilidades de locomoção desapareceram.

Foi nesse ano em que foi apresentado à comunidade humana o Miriad, o computador que seria o primeiro computador com a capacidade de tomar decisões próprias verdadeiras, ou seja, sem que precisasse ser programado para enfrentar a questão. A tecnologia em torno da construção do Miriad envolvia óptica, quântica, e muita engenhosidade. Segundo os engenheiros, a capacidade de processamento dele seria a de deus, se esse existisse. Dizia-se que o Miriad poderia tomar qualquer decisão sobre qualquer coisa, tanto que nem os próprios construtores sabiam realmente o que ele faria. E ao ser inicializado, o Miriad não fez nada.

Nenhuma resposta por cinco dias. O assunto foi motivo de pilhéria, mas a indústria se mostrou confiante e reafirmou várias vezes que aquilo era esperado. Ao final desses cinco dias, O monitor do computador central do Miriad em Tântris começou a mostrar um timer contando horas, minutos e segundos, regressivamente. Três dias depois, esse timer poderia ser visto em monitores, implantes cerebrais visuais, e qualquer tipo de aparelho óptico dos setores mais próximos. Um ano depois, ele poderia ser visto em qualquer lugar para onde um ser vivo olhasse. Até tentou-se desligar o computador, que parecia estar infectado com algum tipo de vírus que ele próprio tinha criado, mas mesmo após o shut-down do computador central, o timer permanecia ligado.

Logo que surgiu, verificou-se que o timer indicava quanto tempo restava para a passagem do ano 4000 terrestre. Por algum motivo inexplicável, o Miriad imprimiu esse timer em todo dispositivo visual do universo conhecido, e fez o carregamento de seu próprio sistema para as redes de informação, fazendo-se onipresente.

As ondas de boatos em torno ao significado da mensagem logo atiçaram a ira contra as máquinas, que, não raras, eram destruídas por grupos rebeldes, que provocou guerras e guerras ao longo dos anos. Somente em 3993, trinta anos depois do aparecimento, tivemos idéia da razão do contador regressivo. Nos primeiros anos pareceu como uma enorme formação estelar, como um imenso buraco negro. Só a três anos atrás, devido a pesquisas, descobrimos que não havia formação nenhuma, aliás, quase todo o universo não habitável não existia mais.

A conclusão foi fácil de se chegar. Até a virada do ano 4000 terrestre, graças ao processamento de decisões próprias do Miriad, todo o universo se dissolverá em cordas subatômicas, dando fim a este universo.

Esta mensagem eu colocarei numa cápsula de transporte que idealizei nesses últimos anos. De acordo com a teoria da esponja de universos, ela reaparecerá em algum lugar, algum tempo, e talvez servirá para que alguma civilização tome conhecimento do que fomos nós, e do perigo que isso pode representar. Vou desligar agora as máquinas do módulo orbital. Já não tenho contato com quase mais ninguém.

O que fica é uma questão inquietante: Deus criou o homem, que criou Deus, que destruiu o homem. Por quê?