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?

Um novo paradigma em desenvolvimento Web

January 18th, 2008 § 8 comments § permalink

Ruminando nos últimos dias sobre o futuro do desenvolvimento em especial, pensando sobre o que eu andei escrevendo sobre testes e linguagens específicas de domínio, e principalmente sobre as coisas que tem chamado a minha atenção nos últimos tempos no campo, eu fiquei surpreso ao perceber que por mais que estejamos falando em novos paradigmas, nenhuma aplicação ou framework está explorando os conceitos mais novos de maneira significativa.

O histórico do área é abismal, é claro. Já estamos beirando os quarenta anos desde que alguma mudança significativa de paradigma aconteceu, e quase vinte anos desde que práticas mais estruturas se tornaram a base do que fazemos hoje. Apesar disso, a indústria permanece estagnada no campo minado que orientação a objetos, bancos relacionais, e design bottom-up representam.

Pensando em desenvolvimento Web, por exemplo, por mais inovadores que Rails e Django sejam, os dois possuem duas características que os tornam completamente inúteis a longo prazo.

A primeira característica é a fragmentação conceitual. Na tentativa de tornar o desenvolvimento “indolor”, esses dois frameworks e seus descendentes diluem o domínio da aplicação em uma série de pequenos pedaços que, embora representem uma forma mais gerenciável de desenvolvimento, também tende a criar uma desconexão entre o código e aquilo que ele deve representar.

A segunda característica é a fixação em soluções constritas. O uso de REST pelo Rails é um bom exemplo disso. Embora REST seja um conceito interessante e mesmo necessário para uma classe de aplicações, a implementação do Rails é limitada, dependente de truques, e sofre da mesma fragmentação citada acima.

De fato, muito do que a maioria dos frameworks modernos estão fazendo é pretender que a complexidade não existe ou que ela pode ser gerenciada com o uso de métodos pequenos e testes.

Desenvolvimento guiado por testes, ao contrário do que se prega atualmente, não é uma bala de prata. Antes, é mais uma prática que está sendo transformada através de uma falta de compreensão em uma panacéia–como algo, inclusive, que pode guiar o design de sua aplicação até o ponto em que não é necessário fazer uma análise apropriada do domínio do problema. A quantidade enorme de exemplos mostrando como testar algo que, por definição, já está testado é insana. Eu sou tão culpado quando o próximo programador ao fazer isso em minha própria documentação.

E por mais que eu defenda Seaside, por sua aplicação inovadora de conceitos antigos e por sua recusa em se ater às soluções supostamente provadas, o fato é que, a exemplo dos outros frameworks, Seaside também não é uma solução que parte de premissas radicalmente diferentes das que a indústria tem oferecido nos últimos anos.

Algo que está me dando esperança de que as coisas podem mudar logo é o interesse em programação orientada a linguagens. Se isso se transformar em uma característica dominante das linguagens que estão crescendo hoje, podemos experimentar uma renovação conceitual nos próximos anos.

Talvez o que precisamos é de uma forma de gerar especificações executáveis que seja realmente uma forma de criar aplicações e não uma maneira inferior de modelar o comportamento esperado de uma aplicação. Isso é algo para se pensar.

Talvez aqui esteja uma meta para esse ano: tentar descobrir uma forma de combinar as peças que estão soltas, peças geradas nos últimos vinte anos que parecem estar a uma pequena distância de uma revolução. Alguém de habilita?

O efeito ASP

January 16th, 2008 § 13 comments § permalink

Muito do meu desenvolvimento diário, para minha infelicidade, ainda é feito em aplicações legadas em ASP e PHP. Desnecessário dizer, não é um trabalho muito agradável mesmo quando a aplicação foi construída com um cuidado maior do que simplesmente gerar arquivos e mais arquivos em uma tentativa de trazer ordem ao caos.

Aplicações ASP são capazes de infligir terror ao mais corajoso desenvolvedor Web. A mistura de lógica e apresentação vem sendo usada há vários anos para exemplificar o que há de pior da área e não sem razão. Atualmente, para falar a verdade, é muito raro que eu aceite um contrato de manutenção ASP se a aplicação não atende certas práticas que eu estabeleci como referência. O trabalho simplesmente não vale a pena, por melhor que seja o pagamento.

Nos últimos anos, é claro, eu tenho tentado me dedicar mais e evangelizar, sempre que possível, novos modelos e frameworks de desenvolvimento. Nem sempre a empresa aceita mudar para algo que ela considera esotérico e fora da realidade do mercado, mas algumas vezes a vontade de reduzir o time-to-market vence o medo e algo de interessante acontece.

Estamos hoje há mais de três anos do início da evolução do desenvolvimento Web que frameworks como Rails e Django começaram e acho que estamos começando a ver os reais efeitos que o desenvolvimento nestes novos paradigmas está tendo. O uso de MVC está se tornando uma constante e mesmo a questão de desenvolvimento guiado por testes está se firmando como algo mais comum em locais onde usualmente se via um processo menos elaborado.

Nos últimos tempos eu tenho recebido alguns propostas para completar ou manter aplicações Rails já existentes e estou surpreso com a baixa qualidade do que estou vendo. De fato, no que tange a falta de cuidado com o código e a mistura de lógica e apresentação, eu só não compararia o nível dessas aplicações ao que usualmente vejo com ASP porque pelo menos a parte de convenção versus configuração segura os abusos mais berrantes.

Eu ainda não tenho dados suficientes para dizer a mesma coisa de Django, mas é possível notar um pouco disso nas aplicações e projetos espalhados pela Web que pouco cuidam em promover técnicas como TDD ou mesmo um reuso mais efetivo de código. E quanto promovem, o que se vê são usos pouco significativos dessas técnicas como a eterna persistência em testar o funcionamento de camadas ORM. Isso é válido também para quase todos outros framework Web, independentemente de linguagem e estruturação.

Parte do motivo desse uso incorreto é explicada pela soma de dois fatores distintos: o fato de que poucos programadores são realmente capazes de entender o que OOP significa e o fato de que Rails, Django e todos esses outros frameworks promovem uma versão mais light, por assim dizer, de OOP que efetivamente isola muitos programadores de um desenho mais efetivo do domínio do problema.

Eu fico pensando no mercado daqui a cinco anos, quando o mesmo estiver inundado de aplicações nesses novos frameworks. Provavelmente, não haverá diferença nenhuma em termos de manutenção para o que vemos hoje. Aplicações realmente bem feitas permanecerão confinadas a um pequeno conjunto dentro da indústria. Um efeito ASP em ação.

A revolução ainda espera e Frederick Brooks continua mais válido do que nunca. Rails e Django podem ser indolores no começo, mas eu tenho pena dos programadores que terão que manter o que está sendo criado hoje.

Mais empresas se juntam ao DataPortability Workgroup

January 10th, 2008 § 0 comments § permalink

Dois dias atrás, Google e Facebook chacoalharam o mercado ao anunciarem a sua decisão de se juntarem ao DataPortability Workgroup. Com o mesmo entusiasmo do dia–e em um tom de quase descrença–o Read/Write Web está reportando que mais três grandes players estão assumindo representação na iniciativa: Flickr, SixApart e LinkedIn. E excelente representação, por sinal: as pessoas envolvidas não são meros funcionários mas indivíduos com histórico de atuação nas áreas de interesse do grupo.

É óbvio que a influência dos dois gigantes está se espalhando e eu não duvido que várias outras empresas anunciarão participações similares nos próximos dias e meses. O que começou como algo basicamente formado por pessoas preocupadas com os rumos da indústria pode se tornar uma força dominante na implementação de padrões de portabilidade durante os próximos anos.

O mais importante na história toda é que todos os padrões apoiados pelo grupo são abertos e, juntos, representam uma enorme tendência contra o tipo de atitude disseminada pela Microsoft ao tentar cooptar produtos naturalmente livres em implementações proprietárias. Considerando que aplicações Web hoje são primordiais, padrões abertos e flexíveis obviamente tornam iniciativas fechadas consideravelmente mais difíceis.

O ano promete. Com o OpenID ganhando espaço e com anúncios quase que diários de possíveis implementações em larga escala, os próximos meses podem acabar se tornando marcos na história da Internet.

Facebook e Google apoiando o DataPortability Workgroup

January 8th, 2008 § 0 comments § permalink

O blog Read/Write Web está reportando–com um considerável entusiasmo–que tanto o Google quanto o Facebook se juntaram ao DataPortability Workgroup. Eu não encontrei a notícia no site do próprio Workgroup mas vindo do Read/Write Web é algo com uma boa probabilidade de estar correto. É curioso, inclusive, ver isso logo depois da controvérsia em relação à remoção da conta de Robert Scoble por parte do Facebook (1, 2).

Esse grupo, que eu já mencionei aqui antes, está trabalhando em iniciativas para permitir o reuso e transferência de dados transparentemente de site para site. Há uma enorme quantidade de desafios tecnológicos para vencer até que isso seja algo natural na Web e a presença das duas maiores companhias sociais da atualidade é algo que vai dar um novo grau de legitimidade ao projeto–especialmente considerando as pessoas que que representaram cada uma das companhias.

Com um dos documentos gerados pelo grupo (ainda bem na fase inicial) mostra, um dos objetivos primários é reutilizar tecnologia e formatos existentes e procurar integrar ao máximo antes de procurar novas alternativas tecnológicas para o que não estiver funcionando. Essa é uma boa estratégia porque representa maior facilidade na adoção.

Com a entrada do Google e Facebook, o eventual surgimento de uma API generalizada por representar uma transformação em basicamente todas as aplicações que estão surgindo e se popularizando no momento, sem contar a eventual integração de dados ao longo de empresas e seus clientes. É uma visão grandiosa e, claro, efetivamente centrada na capacidade de gerenciar as questões de privacidade por trás da movimentação dos dados.

Mas, como o artigo do Read/Write Web diz, pode representar também mágica para o desenvolvimento da Web. É o que esperamos.

Facebook versus Scoble: o outro lado do moeda

January 4th, 2008 § 0 comments § permalink

Parece que metade da Web, esse que lhes escreve incluído, falou cedo demais ontem. Embora o Facebook realmente esteja se tornando um local onde alguns dos problemas mais sérios da Web estão sendo verificados em situações de uso real, a história com o Scoble tinha um lado completamente diferente.

Pelas últimas notícias, o que Scoble realmente andava fazendo era testar uma ferramenta da Plaxo, competidora do Facebook, que serve para migrar dados de uma rede para outra. Como certos dados não são acessíveis pela API do Facebook, a ferramenta da Plaxo usa scraping para obter os mesmos. E como em última instância isso é indistingüível de um ataque para obter informações que seriam depois usadas para spam, um banimento automático aconteceu.

O resultado final é que o Facebook estava mais certo do que o Scoble na história. O bom de tudo isso é que uma nova discussão comecou em torno do que constitui seus dados e o que constitui os dados de outras pessoas no que tange ao grafo social. Essa é uma discussão que já estava acontecendo entre os interessados mas que se expandiu agora para uma maior fatia da população tecnológica. O Facebook, pelo visto, vai continuar sendo o campo de provas da Web quais sejam os resultados.

RIA em 2008

January 4th, 2008 § Comments Off on RIA em 2008 § permalink

Tim Bray começou sua lista de previsões para 2008 dizendo que esse é o ano decisivo para aplicações RIA em contraposição a aplicações Ajax: ou aplicações RIA se transformam em uma tecnologia usada comumente, ou se tornarão secundárias, usadas por alguns mas largamente ignoradas pela maioria dos desenvolvedores Web.

Um ponto interessante que ele faz em seus comentários é que ele tende a associar a “riqueza” em aplicações Web não com interface–segundo ele, somente desenvolvedores pensam nisso–mas com as capacidades interativas e de conteúdo da aplicação. Eu concordo, mantendo minha opinião de que Flex e Silverlight (e outras tecnologias similares) tem um papel diferente em prover níveis de interface mais adequados a uma classe bem específica de aplicações.

Obviamente, isso não é o que a Microsoft e Adobe querem para os desenvolvedores: a primeira com toda a sua necessidade patológica de controlar o campo, e a segunda com sua duplicidade em relação ao código aberto. Eu não estou preocupado. Eu acho muito difícil que aplicações públicas, com necessidade de interação e acessibilidade maiores, serão convertidas para essas duas tecnologias. Um dos principais problemas com interfaces novas é que, por mais perfeitas que sejam, jamais conseguem acompanhar precisamente o sistema operacional hospedeiro e o preço dessa dissonância cognitiva é o fato de que aplicações JavaScript com uma base mais próxima do navegador se tornam um opção mais interessante.

Um outro ponto mencionado por Tim Bray é que atualmente quase qualquer aplicação é uma aplicação Web–mesmo que apenas em uma pequena parcela de sua funcionalidade. Combine isso com o surgimento de interfaces duais para modos online/offline e já estamos em um caminho inteiramente diferente.

Ao contrário de Bray, eu vou me arriscar a uma previsão mais definitiva e dizer que RIA, no que tange a Flex e Silverlight, continuará como uma opção secundária e que nenhuma aplicação de grande porte e significativamente popular surgirá em 2008 usando qualquer das duas–isso não implica que o mesmo não venha a ser usado em sites transientes dependendo de mídia; o critério aqui é o uso em aplicações. Também acredito que veremos notícias de Flex ou Silverlight sendo usados internamente em alguma grande empresa.

O resto do ano, porém, será ainda melhor para Ajax.

Facebook: o campo de provas da Web

January 3rd, 2008 § 2 comments § permalink

Pela segunda vez em pouco mais do que dois meses, o Facebook se vê com uma situação nas mãos que é, essencialmente, impossível de controlar. Considerando o tamanho, a influência e o tipo de usuários do Facebook, isso é excelente para o futuro das aplicações Web em geral.

Da primeira vez, foi a controvérsia sobre o Facebook Beacon, a aplicação de anúncios dentro do Facebook que usava informações obtidas em outros sites participantes e o próprio grafo social do usuário para maximizar a contextualização dos anúncios. O problema era que um usuário não podia optar por não usar o produto e informações privadas acabam sendo passadas para amigos relacionados ao perfil do usuário. O resultado foi uma tempestade de protestos que acabou levando a mudanças significativas no modo como o produto funciona.

A controvérsia de hoje é a remoção da conta de Robert Scoble por violar os Termos de Uso site. Scoble estava usando um script para recolher informações do seu perfil já que o Facebook não permite qualquer forma de exportação de dados e foi banido por isso. A controvérsia já começou sobre o assunto e no momento há uma tempestade em formação no Techmeme. Scoble é um power-user do Facebook e um A-lister cuja opinião conta muito para os usuários mais avançados que, em última instância, foram determinantes durante o problema do Facebook Beacon.

O que eu acho interessante e significativo sobre a situação é que o Facebook está se provando um excelente local para testar o que os usuários permitirão ou não em termos de seus dados e privacidade na Web. O Facebook já gerou uma resposta forte dos outros envolvidos na forma do Open Social por causa da sua atitude de jardim murado. Com o cancelamento da conta do Scoble, o Facebook acabou providenciando o maior argumento possível para a portabilidade de dados sem que os críticos precisassem de fazer qualquer esforço.

Embora seja fácil entender porque o Facebook deseja prender seus usuários, esse tipo de padrão está com os dias mais do que contados e é bem possível que o banimento do Scoble seja o evento que forçará o Facebook a admitir isso. Uma boa possibilidade é que eles mesmos criem um padrão de portabilidade que possa ser incorporado ao Open Social, revertendo o enorme problema de relações públicas que tem em mãos no momento.

Esse tipo de prova público do que os usuários vão tolerar é fundamental para o surgimento de novas políticas de trabalhar com dados de terceiros e serve também como um bom aviso para quem está colocando as suas fichas em serviços fechados que não permitem uma remoção de dados rápida mesmo depois de restrições válidas às contas em questão. Ainda é cedo para ver o impacto completo do problema atual nesse tipo de política, é claro, mas os próximos dias e meses serão interessantes.

Pão de Cast #8

December 24th, 2007 § 0 comments § permalink

Para alegrar o seu Natal está no ar o Pão de Cast #8 – Edição “Jingle Bells é a mãe”. Entre os assuntos falados estão o lançamento do SimpleDB, da Amazon; o fato de que o IE8 agora está passando no Acid2 e o que os lançamentos atuais da Microsoft mais a idéia do IE8 podem significar para o mercado dos navegadores; mais discussões sobre o código livre e comentários gerais sobre os eventos da semana que passou.

Com sempre, estamos abertos a sugestões e comentários e temos agora uma nova forma de contribuição. Se você quer contribuir com o Pão de Cast, nos envie seus comentários e perguntas através de arquivos MP3 ou OGG e os colocaremos no ar durante a gravação.

Where Am I?

You are currently browsing the Web category at Superfície Reflexiva.