Porque o HTML 5 é relevante, e o que você deveria saber

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.

Integração do Internet Explorer 9 com Windows 7

Se você está vendo este artigo, então sabe que a Microsoft lançou o beta do Internet Explorer 9 na última semana, e sabe que ele tem funcionalidades interessantes para o Windows 7: fixar site na barra de tarefas, listas de tarefas do site e até ícones para sobreposição.

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

E a Apple estava certa: os pads são a resposta definitiva

Não que isso seja uma grande novidade para os fãs de Jornada nas Estrelas. Acontece que, como reportado por Jesús Diaz lá do Gizmodo, os notebooks estão morrendo.

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.

Crie tipos on-the-fly com Tipos Anônimos

O .NET Framework é cheio de features que, passadas desapercebidas, nunca fariam falta. Uma delas é a capacidade de criar objetos com propriedades sem a necessidade de declarar uma classe.

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"

Reduza o código para implementar propriedades

Convenhamos. Eu sou preguiçoso. E para um preguiçoso, quanto menos trabalho, melhor.

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.

Use Tipos Implícitos e deixe o óbvio de lado

Você já deve saber que eu tenho problemas com a natureza burocrática da tipagem em .NET. Tipos são ótimos e tudo o mais, mas quando eu começo a escrever mais código de casting do que de negócio, algo não está certo. Por isso, acho válida qualquer tentativa de reduzir o nível de burocracia na hora de escrever o código.

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);

Corrigindo a classe dos outros com Extension Methods

Quem já programou acesso a banco de dados na mão em .NET, sabe que mexer naquelas classes do ADO.NET é mais feio que processo na Justiça. É uma salada mista de Commands, Connections, DataReaders, DataAdapters, e outros bichos. O ADO.NET é uma biblioteca de baixo nível, bem estruturada, e por causa disso, um pé-no-saco de se programar.

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.

Classes especializadas com Generics

Vamos colocar isso em pratos limpos: o framework .NET é fortemente tipado, e isso às vezes é uma maldição.

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.

Nullables em C# e artimanhas com nulidades

Minha tia uma vez pediu para em criar uma classe Pessoa em um sistema de cadastro de clientes. Depois de um pequeno bate papo, cheguei com essa infalível classe em C#:

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?

Futura – 3

Meses se passaram até que a espessa camada de poeira e cinzas se assentasse da atmosfera. Anos até que os primeiros grupos de humanos pudessem se encontrar. No primeiro senso, 23 anos após o choque, contabilizava cerca de 500 milhões de humanos, muito pouco, em relação aos nove bilhões de 2035. O planeta estava destruído e a sociedade, dizimada. Poucas cidades sobreviveram ao cometa e estas, logo foram escolhidas para serem as cidades capitais da Nova Terra. Em 2055 foi eleito em Tântris, continente Pacífico, o Conselho Superior de Nova Terra, com suas principais metas: 1- reunir os povos do mundo devastado e 2- conseguir meios de evitar que a raça desaparecesse.