Os quase trinta

January 26th, 2008 § 7 comments § permalink

I’m thirty-three for a moment
Still the man, but you see, I’m a they
A kid on the way, babe
A family on my mind

100 Years — Five for Fighting

Em menos do que cinco meses eu completo trinta anos. A mudança para os trinta é geralmente a que mais aterroriza o coração humano, porque assinala o momento em que aquela juventude inocente ficou irremediavelmente para trás e que a meia idade não está muito longe.

Eu acho que parte do terror é contemplar os anos para trás e perceber que muitas vezes não se fez metade do que o sonhado ou o buscado, e que esses anos, que deveriam ter sido os melhores e mais produtivos, os mais fortes e mais puros, passaram quase que desapercebidos, perdidos em uma tentativa de se concentrar demais em vários caminhos ou jogados em uma obsessão única que levou somente a uma perspectiva medíocre do futuro.

Dizem que raramente um matemática produz alguma coisa depois do seus vinte nove anos. Preocupações ou o fim daquele pulso juvenil estupendo alteram alguma coisa e raras vezes na história da matemática alguém produziu alguma coisa significativa além disse. Eu não sei se é verdade, mas eu tenho minhas dúvidas. Talvez seja mais um reflexo daqueles que brilharam rápido demais e deixaram sua marca mais forte do que aqueles que trouxeram suas contribuições pequenas mas significativas em outros anos.

Trinta anos é um tempo enorme de aprendizado. Os últimos cinco anos o foram ainda mais. Parece que as mais de duas décadas anteriores a esses anos foram uma enorme preparação para agüentar a dificuldade desses cinco e agora, no meio de uma das maiores transformações da minha vida, eu me sinto na posição perfeita.

Trinta é um excelente número. E quer eu viva mais cinqüenta, mais trinta, mais cinco ou mais dois, eu sempre serei grato por esses trinta. They were beautiful.

Conceitos de Programação: Lazy Evaluation

January 25th, 2008 § 11 comments § permalink

Inspirado por alguns pedidos aqui no blog, estou começando uma nova série sobre conceitos de programação. Alguns desses conceitos são úteis como técnicas para melhorar a forma como você resolve problemas em seus programas e outros são úteis como forma de entender o que acontece em determinadas situações quando você está programando de modo a aproveitar melhor as características das linguagens em questão.

Para começar, vou experimentar com alguns assuntos que me parecem mais interessantes e postar algo sobre os mesmos a cada sexta-feira. Se houver interesse, mantenho o formato. E é claro, estou sempre aberto a quaisquer sugestões de assuntos.

Lazy Evaluation

O primeiro tema que vamos tratar aqui é o de lazy evaluation. Também conhecida como delayed evaluation essa é uma técnica útil para evitar a necessidade de realmente computar um resultado até que o mesmo seja necessário. Isso significa, é claro, que se por algum motivo o resultado não for necessário, o mesmo também não será calculado.

Dois dos efeitos colaterais mais interessantes do uso dessa técnica são a possibilidade de definir estruturas de dados infinitas (como a lista de todos os números primos por exemplo) e definir estruturas de controle sem a necessidade de funções primitivas da própria linguagem. Se feito de maneira correta, o uso de lazy evaluation é capaz de aumentar consideravelmente a performance de um programa.

Curto-circuito

Em linguagens imperativas, principalmente as que não são dinâmicas, um dos usos mais familiares de lazy evaluation acontece em expressões lógicas. Por exemplo:

rating = (playCount > 10) ? (playCount * 2) : (playCount / 2)

No exemplo acima, dependendo do valor que a variável playCount possuir, somente um dos blocos de código será executado. O outro, compilado ou não, será simplesmente ignorado, embora faça parte da mesma expressão.

Esse é um exemplo bem simples de lazy evaluation mas ilustra a técnica. Esse, inclusive, é um dos poucos casos em que mesmo linguagens que usam execução estrita de maneira geral (call-by-reference e call-by-value) utilizam esse comportamento para otimizar a execução.

Estruturas de controle

Uma função que eu via muito em código ASP era justamente uma forma de criar o operador ternário acima. Aliás, para quem não está familiarizado com esse operador, ele é apenas uma açúcar sintático para a estrutura condicional if. O exemplo usando anteriormente é o mesmo que:

if (playCount > 10)
  rating = playCount * 2;
else
  rating = playCount / 2
end

Em ASP, para emular esse efeito de simplificação, programadores geralmente usavam algo assim:

Function IIf(Expression, TrueValue, FalseValue)
  If Expression Then
    IIf = TrueValue
  Else
    IIf = FalseValue
  End If
End Function

O grande problema desse função é que todos seus parâmetros, por causa da natureza do VBScript, são computados antes da execução da função. Se construirmos um exemplo equivalente ao primeiro, teríamos algo assim:

Rating = IIf(PlayCount > 10, PlayCount * 2, PlayCount / 2)

Ineficientemente, todos os valores acima são computados antes de srem passados adiantw mesmo que somente um deles seja retornado. Em uma linguagem que usasse lazy evaluation, o usual seria substituir as expressões por uma promessa de execução e só computar o valor quando a mesma fosse necessária. Em uma linguagem assim, a função IIf seria exatamente equivalente à estrutura condicional if.

Listas infinitas

Um exemplo muito usado para explicar o assunto, quase que um exemplo canônico, é o cálculo dos números de Fibonacci em uma linguagem lazy como Haskell.

Para comparar, veja a implementação recursiva abaixo em Ruby:

def fib(n)
  return 1 if n <= 1
  return fib(n - 1) + fib(n - 2)
end

Essa é uma implementação ineficiente, é claro, mas serve para comparar com a implementação similar em Haskell:

fib 0 = 0
fib 1 = 1
fib n = fib(n - 1) + fib(n - 2)

Essa é uma implementação que segue a definição matemática da função mas que também é bem ineficiente. Essa implementação recursiva geralmente falha por volta do trigésimo quinto item por causa da quantidade de chamadas feitas.

Em Ruby, isso geralmente é resolvido com uma versão iterativa. Em Haskell, podemos resolver da seguinte forma:

fib n = fibs !! n
  where
    fibs = 0 : 1 : zipWith (+) fibs (tail fibs)

Antes de explicar a expressão, é necessário explicar o que zipWith faz. Essencialmente, zipWith pega duas listas e aplica a função às mesmas, elemento por elemento, resultando em uma única lista final. Por exemplo:

*Main> zipWith (*) [1, 2] [3, 4]
[3, 8]

O uso de (*) tem a ver com outro conceito interessante chamado currying que veremos em um artigo futuro.

Essencialmente, então, o que a definição de fib está dizendo é:

  1. Para o argumento n, fib de n é o elemento n de uma lista chamada fibs. O operador !! é o equivalente Haskell do indexador [] em outras linguagens.

  2. A lista fibs é definida como a concatenação de 0, 1 e do resultado da concatenação de si mesma com sua cauda com a aplicaçâo de (+). Essa última parte pode soar estranha, mas é exatamente isso o que está acontecendo. Essencialmente, o que você tem aqui é uma lista infinita. Digamos que você queira calcular então o quinto termo da série de Fibonacci. Nesse caso, você teria a seguinte execução:

0 : 1 : zipWith (+) (0 : 1 : ...) (1 : ...)
0 : 1 : (0 + 1) : zipWith (+) (1 : 1 : ...) (1 : ...)
0 : 1 : (0 + 1) : (1 + 1) : zipWith (+) (1 : 2 : ...) (2 : ...)
0 : 1 : (0 + 1) : (1 + 1) : (1 + 2) : zipWith (+) (2 : 3 : ...) (3 : ...)

O retorno final seria três, que é o quinto item da lista. Se você está curioso, a própria função zipWith pode ser definida como:

zipWith f (x:xs) (y:ys) = f x y : zipWith f xs ys
zipWith _ _ _ = []

Em outras palavras, zipWith de uma lista cujo primeiro elemento é x e cujo restante é xs e de uma lista cujo primeiro elemento é y e cujo restante é ys para uma função f é f de x e y concatenado a zipWith de xs e ys sobre f. A segunda linha diz que em qualquer outro caso, o retorno é uma lista vazia. A definição recursiva pode ser vista facilmente na chamada em fibs.

Note que a lista sempre é expressa como uma lista sem término, ou seja, infinita. Para retornar um valor específico, basta pegar o elemento em questão. O cálculo necessário é feito somente até aquele ponto e não mais. O resto da lista continua sendo expresso internamente por uma representação que permite obter o próximo valor sem mais do que uma simples continuação do processamento. A função é bem eficiente e não sofre das penalidades recursivas da versão original.

A beleza da função acima, entretanto, não está em evitar recursão explícita (esse é outro conceito que exploraremos futuramente) ou usar uma lista infinita. Antes, está no fato de que o cálculo, além de somente ser executado quanto necessário, não é repetido. Ou seja, seu eu pegar o décimo primeiro elemento e depois pegar o quinto, a lista não é recalculada. E quando eu precisar do vigésimo elemento, só serão necessárias mais nove passagens na lista. O cálculo todo acontece sob demanda.

Um outro exemplo interessante disso é o cálculo do Crivo de Eratóstenes em Haskell:

primes = sieve [2..]
  where
    sieve (p:xs) = p : sieve [x | x <- xs, x `mod` p > 0]

Essencialmente, a função tira todos múltiplos de dois de uma lista infinita de números naturais maiores ou iguais a dois, depois tira todos múltiplos de três, depois todos de cinco, e assim por diante, com cada novo primo descoberto.

Ao contrário da função fib, essa é extremamente ineficiente, o que mostra que o uso de lazy evaluation não é uma panacéia e que também depende de bons algoritmos.

O que isso tudo significa

Em linguagens com suporte direto a lazy evaluation, o uso da mesma pode facilitar a implementação e aumentar muito a performance de um programa.

Em linguagens que não suportam lazy evaluation, uma simulação da técnica pode ser bem útil para gerar resultados com maior performance. É um troca, na verdade, já que geralmente isso envolve um consumo maior de memória, mas pode ser bem útil se o cálculo é tão intensivo que exige uma forma melhor de ser tratado.

Uma forma de fazer algo parecido em Ruby é usando a classe Fiber, disponível a partir da versão 1.9. Você teria algo assim:

require "fiber"
  
fib = Fiber.new do 
  x, y = 0, 1
  loop do 
    Fiber.yield y
    x, y = y, x + y
  end
end

Essa computação é infinita, já que não há uma condição de saída, e você pode obter valores chamando o método resume na classe retornada:

20.times { puts fib.resume }

O problema com a chamada acima é que se eu quisesse recalcular uma número de Fibonacci qualquer, eu teria que criar uma nova Fiber. Isso pode ser resolvido com algo um pouco mais complexo:

require "fiber"

class LazyList
  
  def initialize(&block)
    @memo = []
    @fiber = Fiber.new(&block)
  end
  
  def [](value)
    @memo << @fiber.resume while @memo.size <= value
    @memo[value]
  end
  
end

def fib(n)
  (class << self; self; end).instance_eval do
    ((@global_lazy_dict ||= {})[:fib] ||= LazyList.new {
      x, y = 0, 1
      loop do 
        Fiber.yield y
        x, y = y, x + y
      end      
    })[n]
  end
end

[12, 10, 17].each { |i| puts fib(i) }

O código acima usa uma forma bem básica de memoização para manter a lista em memória mas a idéia é essa. Se você rodar o código, verá que a lista somente é calculada até onde necessário e que valores anteriores são retornados do cache.

Uma aplicação interessante desse tipo de técnica seria executar cálculos pesados em uma thread separada e retornar somente o necessário para a exibição. Se está fosse feita em páginas, por exemplo, você poderia requisitar somente os valores daquela página enquanto os das demais páginas estão sendo calculados. Para quem, inclusive, quer experimentar com isso em Ruby, há justamente uma biblioteca chamada lazy.rb para auxiliar. Veja o método future.

Conclusão

Espero que isso tenha ajudado a entender um pouco o que é lazy evaluation. Qualquer dúvida posterior, coloque nos comentários aqui. Da mesma forma, sugestões e críticas são bem-vindas. Na próxima sexta-feira, continuaremos com mais um artigo.

Vivendo em código

January 24th, 2008 § 6 comments § permalink

God said, “Cancel Program GENESIS.” The universe ceased to exist.

Arthur C. Clarke

A idéia de que o Universo é uma máquina virtual ou uma simulação é um conceito antigo. E mesmo fora da ciência e tecnologia, culturas muitas vezes apresentaram o existência material como um sonho de um deus.

O próprio Cristianismo–e aqui eu me coloco com um cristão–lida introspectivamente com a questão de como o Universo está em relação a Deus, já que somente aquele existia anteriormente e se houve alguma limitação por parte da divindade ao criá-lo.

Mais recentemente, com o surgimento de condições favoráveis a este tipo de exploração, as pessoas começaram a questionar a possibilidade de simular toda uma realidade mecanicamente. Isso é bem natural, é claro, considerando as perguntas básicas sobre a existência.

Um artigo recente que me chamou a atenção foi The Physical World as a Virtual Reality. O artigo é o resultado da pesquisa de um físico sobre esse mesmo assunto, explorando as implicações de uma possível simulação para o Universo dentro do conceito da física como a conhecemos.

A leitura é fascinante e, embora nenhuma conclusão ou tentativa de criar algo matematicamente consistente seja tentada, a exploração é bem ampla. É claro que se fosse realmente possível provar que o Universo é uma simulação, as implicações seriam estonteantes–o que me lembra, é claro, as tentativas dos personagens de Simulacron-3 / The 13th Floor de escapar de seu plano para simplesmente encontrar outro acima dele.

O que seria realmente interessante, em um contexto de realidade virtual, seria a possibilidade de hackear o Universo, modificando ou introduzindo novas leis. Pode-se imaginar uma série infinita de Universos, cada um com suas próprias simulações e enormes experimentos sendo conduzidos nos mesmos. Esse é, não sem surpresa, parte do tema do livro e filme citados acima.

E é claro que o assunto pede a questão: se estamos numa simulação, qual forma tomaria uma tela azul?

O ano de viver em perigo

January 24th, 2008 § 8 comments § permalink

Depois de pensar um pouco e fazer algumas comparações pouco científicas, decidi que esse ano vou me dedicar a aprender Lisp de maneira decente. Lisp é uma linguagem que sempre foi do meu agrado e cheguei a dedicar um pouco mais de tempo a ela na forma de Emacs Lisp. E, como o Luiz me lembrou, se eu quero aprender uma linguagem funcional e ao mesmo tempo experimentar mais a fundo com meta-programação, Lisp é a linguagem ideal.

Io me deixou bastante tentado. Quando mais eu lia sobre essa minúscula linguagem, mais interessante me parecia. Só perdeu para o Lisp porque eu realmente quero pode falar com mais consistência sobre uma linguagem que já admiro há muito. Haskell é outra que sempre me atraiu bastante, mas eu vou poder experimentar com bastante coisa similar trabalhando com Lisp.

Uma outra vantagem enorme de Lisp é que meu editor favorito, o Emacs, possui um tremendo suporte para a mesma na forma do Slime, o Superior Lisp Interaction Mode for Emacs. Além de suportar basicamente todas implementações Lisp em uso atualmente, o Slime é o melhor REPL com o qual experimentei.

Alias, o SLIME é quase um IDE psíquico, capaz de adivinhar o que você está querendo enquanto você escreve. Além das funções normais de edição, compilação e execução, a parte de documentação e de ajuda à definição é muito boa. Eu gosto especialmente da parte de fuzzy completion que permite que você digite parte de um comando qualquer e ele sugira as escolhas prováveis.

Meu ambiente, resumido, é o seguinte:

  • Emacs (Carbon Emacs)
  • SBCL e CLISP, que são minhas implementações favoritas
  • Slime, é claro
  • Hyperspec instalado localmente e integrado ao Slime

E como material de apoio:

Agora é só meter a mão na massa. UCW é um dos próximos passos.

Eu preciso…

January 23rd, 2008 § 12 comments § permalink

Eu preciso de:

  • Tirar férias. Quatro anos sem sair de Belo Horizonte exceto a trabalho não dá. Preciso de uma viagem longa e para longe. Algo do tipo subir a costa brasileira de carro. Mas acho que vou ter que me contentar com algo mais simples. Vida de empresa é dureza. Se eu não gostasse tanto da liberdade, eu juro que ia trabalhar fichado.

  • Correr. Antes que os músculos atrofiem. Com os 30 chegando em pouco mais de quatro meses, seu eu não começar agora não vai mais. É claro que, do jeito que eu estou agora, correr significa passar um mês andando levemente, mais um mês andando devagar, mais um mês trotando. Bem, eu para pegar a idéia.

  • Dormir regularmente. Por mais que eu goste da idéia de não dormir, eu preciso parar com a variação na hora de ir para a cama. Do jeito que as coisas estão indo, em breve eu vou parar de separar o dia e a noite. Aliás, a hora que eu vou dormir é tão variável que estou usando a mesma como meu gerador de números randômicos. São só dois números por dia, mas já é útil para alguma coisa.

Só algumas coisinhas básicas mesmo.

DataPortability Workgroup e Microsoft

January 23rd, 2008 § 2 comments § permalink

Em mais uma surpresa relacionada ao DataPortability Workgroup, o Read/Write Web está reportando que agora foi a vez da Microsoft se juntar ao grupo. Nada formal ainda, mas um anúncio deve sair logo.

A adesão da Microsoft é a última em uma cadeia de pesos pesados que incluiu Google e Facebook inicialmente, seguiu com SixApart, LinkedIn e Flickr, e finalizando com um interesse geral no assunto.

Como o pessoal do Read/Write Web aponta, não dá para deixar de ficar curioso com o que a Microsoft pretende com sua entrada na iniciativa, considerando que a empresa é sinônimo de lock-in e práticas anti-competitivas.

Há também o fato que o OpenID é uma parte essencial do esforço de portabilidade, uma aceitação real por parte da Microsoft implicaria em pelo menos um suporte paralelo ao mesmo em sua estrutura Passport. Transformar cada idetidade Passport em uma identidade equivalente OpenID seria algo extremamente vantajoso para a conscientização e suporte geral de uma enorme fatia da população Web.

De qualquer forma, o momento em favor da adoção de padrões portáveis abertos está aumentando e mesmo que a Microsoft esteja se juntando ao barco somente para não perder o PR agregado, isso não implica que benefícios colaterais virão desse suporte. É claro que sempre há a possibilidade de que ela introduza algum “padrão” incompatível–o que não seria grande surpresa, inclusive–mas esperamos que a presença dos outros pesos da indústria tenha um fator mitigador em qualquer tentativa da empresa de gerar alguma vantagem para si subvertendo os esforços atuais.

Django People

January 22nd, 2008 § 0 comments § permalink

Simon Willison acaba de lançar um site para identificar desenvolvedores trabalhando como Django. Apropriadamente chamado de Django People, o site permite que você cadastre uma mini-biografia e uma série de outras informações pessoais que outros desenvolvedores logados podem acessar.

É bem similar ao Working with Rails mas com o foco em localização para juntar pessoas interessadas que estejam próximas. Boa iniciativa.

Blink

January 22nd, 2008 § 0 comments § permalink

Há alguns dias, terminei de ler Blink, o segundo livro de Malcolm Gladwell. Como em The Tipping Point, Gladwell explora explicações contra-intuitivas para um fênomeno com fortes conotações sociais ou psicológicas.

O tema de Blink é algo que Gladwell chama de thin-slicing, que é a habilidade de encontrar padrões e explicações para determinadas situações baseadas em um feedback mínimo. Em outras palavras, o que convencionalmente chamamos de intuição.

Embora Blink seja um bom livro–Gladwell é um excelente expositor–eu não gostei tanto do mesmo como do anterior. Em The Tipping Point, Gladwell estabelece um framework conceitual para a tese que está expondo e trabalha a mesma através de considerações teóricas e exemplos levantados em sua pesquisa. Em Blink, entretanto, o foco acaba ficando quase que somente nos exemplos e o livro perde com isso. Se os exemplos fosse removidos, o livro provavelmente perderia dois terços do seu conteúdo.

O propósito do livro, nas palavras de Gladwell, é triplo: primeiro, mostrar que a intuição é algo que funciona e que podemos confiar na mesma; segundo, identificar onde a intuição falha; e, terceiro, mostrar que é possível treinar a intituição.

Particulamente, eu acredito que nenhum dos três objetivos foram cumpridos completamente. Embora eu concorde com a conclusão primária de Gladwell, que intuição é nada mais do que reconhecimento de padrões, e somente possível se derivada de uma ampla experiência, isso não é fazer muito mais do que declarar o óbvio. Nesse ponto, o mérito do livro está mais em resumir o que existe hoje sobre o assunto do que estabelecer novas fundações. Em relação à pesquisa de por que a intuição falha, muito do que Gladwell escreve chega a ser parcialmente contraditório com o que ele fala da primeira parte. E o terceiro sub-objetivo do livro é resumido em um capítulo minúsculo e sem muito fundamento.

Talvez parte disso seja o quase aspecto místico que Gladwell confere à intuição. Em um dado momento ele diz que é algo que nunca entenderemos e que temos que respeitar porque funciona mesmo assim. Isso é um besteira completa. Outro ponto que eu achei muito fraco foi comparar as falhas na intuição com um autismo temporário. Gladwell pega um tipo de autismo e converte isso em um exemplo de falha de intuição de uma maneira que achei pouco válida.

Apesar disso, o livro vale a leitura por alguns insights bem interessantes sobre o problema. Por exemplo, Gladwell fala bastante sobre a questão de aproveitar a velocidade da intuição em certas situações como uma forma de ganhar um avanço em relação ao entendimento de um certo problema para somente depois analisar mais profundamente. Essse é um guia útil para ajudar na resolução de problemas espinhosos e algo que podemos treinar para fazer bem. Um outro exemplo interessante é a discussão sobre a introdução na New Coke como forma de combater o crescimento da Pepsi, Gladwell nota acertamente que o contexto em que intuição funciona tem uma correlação profunda com a validade do mesmo em situações onde há informação estendida–em outras palavras, a situação para a intuição deve ser equivalente à necessária para uma análise mais profunda.

Em última instância, a lição de Blink, que eu considero válida e que torna a leitura do livro interessante, é que expertise combinada com uma confiança em uma parcela de nosso inconsciente pode ser uma ferramenta poderosa na solução de problemas e na criação de vantagens competitivas nos campos em que trabalhamos. Isso é algo que deveria ser óbvio mas que vai contra certas premissas psicológicas estabelecidas e vale a pena pensar um pouco mais sobre o assunto à luz dos exemplos mostrados por Gladwell.

IE8 e Compatibilidade

January 22nd, 2008 § 8 comments § permalink

Com o IE8 vindo por aí, com um renderizador completamente novo, é óbvio que uma das maiores preocupações dos desenvolvedores é o quanto essas mudanças vão ajudar–ou atrapalhar–a criação de novos sites e aplicativos e como fica a questão de compatibilidade para trás.

Ontem à noite, o Chris Wilson, um dos responsáveis pela nova versão do IE, publicou um longo texto sobre explicando como esses problemas serão tratados. Em resumo, o uso dos mais novos recursos de renderização agora será sujeito à escolha do usuário. Essa é a nova proposta da Microsoft, feita com o apoio do WaSP.

Antes de explicar como isso será feito, vale a pena lembrar do que aconteceu quando o IE6 foi introduzido. Naquela época, a Microsoft escolheu o mecanismo de troca de DOCTYPE para decidir entre dois modos de renderização: um modo que procurava emular as versões anteriores (quirks mode) e um modo que procurava seguir ao máximos os padrões (standards mode).

Isso funcionou bem por um tempo, mas há uma falha fundamental no processo: ele depende de uma atualização constante no suporte a padrões. Como o comportamento do IE6 só for atualizado cinco anos depois com a chegada do IE7, o resultado óbvio é que o standards mode do IE6 se tornou efetivamente o quirks mode do novo mecanismo de renderização. O resultado é que uma nova atualização trará os mesmos problemas de compatibilidade das versões anteriores e agora não há um forma lógica de separar que páginas devem renderizar de um ou outro jeito sem uma confusão generalizada. Ironicamente, essa situação é um resultado do próprio sucesso que os proponentes de padrões tiveram com suas campanhas.

De qualquer forma, a situação precisa ser remediada agora e a solução encontrada foi criar um flag que indique a vontade do desenvolvedor em usar a mais nova implementação dos padrões disponíveis no navegador. A proposta da Microsoft é inclusiva e pode ser implementada por qualquer navegador interessado. Para resumir a história toda, o desenvolvedor que deseje o uso máximo dos padrões e correções, usará o seguinte tag em suas páginas:

<meta http-equiv="X-UA-Compatible" content="IE=8" />

Isso indica que a página deve ser renderizada com o mecanismo do IE6. A falta do tag indicará que ela deve ser renderizada em compatibilidade retroativa.

O tag também pode ser usado para especificar múltiplas versões de naveagdores:

<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;Opera=9" />

Qualquer navegador não indicado deverá usar a renderização padrão. Como isso força a página ficar presa dentro daquela versão específica, há uma palavra-chave que permite indicar a última versão seja qual ela for:

<meta http-equiv="X-UA-Compatible" content="IE=edge" />

O cabeçalho, sendo http-equiv, pode ser usado também como um header a ser enviado na requisição para acelerar o processamento da versão correta:

X-UA-Compatible: IE=8;FF=3

Obviamente, a proposta não caiu bem com proponentes estritos de padrões. Sam Ruby, em seu último texto, nota que já configurou seu site para sempre requisitar a versão superior para o IE.

Pessoalmente, minha primeira reação foi pensar que esse tipo de mudança introduz mais problemas do que soluções. Alguns minutos depois de ler o texto de Chris Wilson, dois novos texos do A List Apart apareceram em meu leitor de feeds e não fiquei surpreso ao ler que Eric Meyer, um dos mais antigos proponentes de padrões e alguém que trabalhou muito para fazê-los chegar ao ponto atual, teve a mesma reação. Em um longo texto para o site, ele explica seus motivos e dá uma explicação muito boa sobre o raciocínio por trás da solução encontrada. A explicação faz sentido em termos pragmáticos, mas deixa um gosto amargo na boca. O artigo é complementado por outro na mesma edição explicando em mais detalhes como tudo funciona.

Em última instância, a mudança demonstra um interesse por parte da Microsoft em lidar com problemas de compatibilidade e não fazer com que tudo pare de funcionar quando uma nova versão do IE sair. O fato de que somente o feedback do WaSP foi usado é um erro, na minha opinião, mas melhor do que simplesmente inventar algo e soltar na Web. Resta saber agora se os demais navegadores seguirão a estratégia.

Perguntas sobre novos paradigmas Web

January 22nd, 2008 § 3 comments § permalink

Continuando a pensar sobre a necessidade de um novo paradigma de desenvolvimento Web, algumas perguntas para me ajudar a formular o que eu mesmo quero:

  1. Considerando o relacionamento entre MVC e REST dentro do Rails, me parece que controllers são essecialmente uma cola supérflua. Seria possível eliminá-los com uma representação direta de recursos?

  2. Ainda pensando em recursos, Seaside é componentizado e entende que cada componente deve ser capaz de criar sua própria representação primária. Como lidar com múltiplas representações e combinações de representações nesse caso? Multi-dispatch aplicada a uma linguagem específica de representação pode ser algo interessante aqui.

  3. REST não é necessário para todas aplicações e forçar isso tende a quebrar o workflow natural. Rails e Django permitem uma quebra e preferem recursos; Seaside ignora recursos em troca de continuidade de requisição. Seria possível modelar ambos com uma linguagem transversal?

  4. De onde a requisição deve partir, principalmente considerando necessidades atuais como RIA, Ajax e Comet?

  5. Uma representação como máquina de estados seria interessante? Principalmente ao se considerar a pergunta anterior e se descartarmos a separação explícita de modelos, uma representação como estados pode ser algo mais interessante (e em tese, até compilável). Se os modelos fossem removidos em aplicações onde o domínio é mais individualizado, fazendo com que a aplicação seja uma seqüência de transformações, alguns problemas de mapeamento se tornam mais simples.

  6. Se REST for descartado, como Seaside faz, e se considerarmos que sessões são contínuas, quais as possibilidades que temos quanto a transformar toda a aplicação em uma linguagem única específica para a mesma?

Respostas? Mais perguntas?

Where am I?

You are currently viewing the archives for January, 2008 at Superfície Reflexiva.