No final do século 20, a disputa entre os dois browsers mais populares da época, Netscape e Internet Explorer, ficou conhecida como guerra dos browsers. Nos últimos anos, após um período negro de domínio do IE, outros browsers começaram a crescer e recuperar o espaço que era ocupado pelo falecido Netscape.

Mais recentemente, desde o ano passado, os browsers mais modernos começaram a dar suporte ao HTML 5 – o Firefox, por exemplo, suporta desde a versão 3.5. Entre diversas novidades, o recurso mais popular do HTML 5 é a tag video, que permite a execução de vídeos sem o uso de plugins. A imensa maioria dos sites de vídeo usam Flash, que é uma tecnologia proprietária, e não é suportada em plataformas como o iPhone/iPod Touch. Porém, juntamente com esta nova tag surgiu uma polêmica.

No mês passado, o Youtube – seguido posteriormente por outros sites de vídeos – anunciou que começaria a oferecer vídeos em HTML 5, porém usando o codec H.264. Apesar de suportar HTML 5, o Firefox não tem suporte a este codec, pelo fato de ele ser proprietário, e exigir o pagamento de licenças caríssimas. O Firefox suporta somente o codec OGG Theora, que é open source. Esta atitude do Youtube criou uma grande polêmica: por que eles deixariam de usar uma tecnologia proprietária (Flash) para adotar outra igualmente proprietária (H.264)? O uso de HTML 5 deixa a impressão de que o Youtube partiu para tecnologias abertas, mas isto não ocorreu, devido ao codec escolhido.

Enquanto isso, o Safari (incluindo aí o iPhone) suporta o codec H.264, mas não suporta Theora; o Google Chrome suporta ambos os formatos; o Opera começará a suportar vídeos com codec Theora a partir da versão 10.50; e o IE 8 nem suporta HTML 5, criando um cenário totalmente heterogêneo. Um dos problemas desta divisão é que começamos a nos distanciar da padronização – que é o objetivo principal do W3C – e criar um ambiente onde cada browser suporta diferentes formatos de vídeo, retornando à época da guerra dos browsers, onde dificilmente uma página era igualmente visualizada no IE e no Netscape. Outro problema é que, como o Firefox não consegue exibir os vídeos em HTML 5 do Youtube, muita gente diz erradamente que o Firefox não suporta HTML 5, quando na verdade é um problema de codec.

A solução para os desenvolvedores é oferecer seus vídeos em mais de um formato, multiplicando, desta forma, o espaço necessário e o trabalho de codificação dos vídeos. O Video For Everybody ajuda a resolver este problema, oferecendo um trecho de código HTML que deixa a cargo do browser a escolha da opção mais adequada – se o browser suportar HTML 5 e Theora, este vídeo será exibido; se suportar HTML 5 e H.264, usará este formato; caso contrário, usará o plugin de Flash ou QuickTime, caso estejam instalados. Em último caso, exibe uma imagem do vídeo com um link para download. Esta solução exige o armazenamento do vídeo em dois formatos, mas parece uma boa solução diante de tantas variantes.

Referências:

• Dive Into HTML5 – Video on the Web – What Works on the Web
• The Dark Side of HTML 5 Video

Até a década de 1990, era muito comum escrevermos datas com apenas 2 dígitos representando o ano (ex: 1996 -> 96). Como todos já sabem, esta prática levou ao famoso bug do milênio, pois, desta forma, o ano 2000 tornava-se 0 (ou 100, dependendo do caso), gerando uma série de problemas, especialmente em códigos que calculavam um período entre duas datas. Felizmente, hoje em dia não temos mais esta preocupação. Ou temos?

Outro dia fui testar um sistema em diversos browsers, e ao realizar o teste no Opera, verifiquei que o componente inputCalendar do Tomahawk abria no ano de 3910. Testei no Firefox, Google Chrome e Internet Explorer 6, 7 e 8, e todos eles funcionavam corretamente. Resolvi olhar o código fonte do componente, e descobri que ele verificava o ano atual usando o método getYear da classe Date. Este método é fonte de diversos problemas e gambiarras em códigos Javascript que manipulam datas. O motivo é que diferentes browsers interpretam o método de maneiras diferentes. De acordo com a especificação ECMA-262, a função getYear deveria retornar o ano atual menos 1900. Nas versões mais recentes, o Firefox e o Google Chrome seguem esta especificação, retornando 110 para o ano de 2010. Já o Opera e o IE retornam 2010, contrariando a especificação e gerando os problemas já conhecidos. É muito comum encontrarmos códigos que verificam qual é o browser (com comentários condicionais ou verificações por Javascript) e, quando não for o IE, somando 1900 ao valor retornado pelo getYear. Esta verdadeira gambiarra não resolve completamente, pois, como já citado, o Opera se comporta da mesma forma que o IE.

A solução ideal para este problema é substituir o método getYear por getFullYear. Este método retorna o ano completo, com 4 dígitos, em todos os browsers, eliminando qualquer necessidade de verificação de browser. Esta recomendação, inclusive, faz parte da especificação ECMA-262, na página 242:

The getFullYear method is preferred for nearly all purposes, because it avoids the “year 2000 problem.”

Após corrigir este bug do Tomahawk, abri uma issue no Jira do projeto, anexando um patch para corrigir o problema.

Outras Referências:

• Javascript getYear fix
• getYear. No, not that year!

Ontem meu Gmail começou a apresentar um problema estranho. Quando eu clicava nas tags, nas pastas de spam ou lixeira, ou tentava fazer uma pesquisa, nada acontecia. Porém, na caixa de entrada tudo funcionava perfeitamente.

Inicialmente pensei que o problema fosse do Firefox, já que ontem atualizei para a versão 3.5.7. Antes de tentar fazer um downgrade, resolvi pesquisar por este problema e encontrei uma referência no forum do Remember The Milk. O problema estava relacionado ao add-on Remember The Milk for Gmail. O Google, de vez em quando, atualiza a versão Gmail, sem qualquer aviso, e a última atualização provocou alguma incompatibilidade nessa extensão. Como a atualização do Gmail é feita inicialmente para um grupo de usuários e só posteriormente replicada para todos, pode ser que muitos usuários não estejam passando por este problema.

O pior é que, como a compatibilidade depende da versão do Gmail, o Firefox não tem como descobrir se a extensão será compatível ou não. A melhor maneira de descobrir se a versão atual é suportada é consultando a página de status do add-on. Para verificar qual é a versão do seu Gmail, clique em Settings e depois na opção Tasks (que só aparece se a extensão estiver instalada e habilitada).

A solução provisória é desabilitar esta extensão até que ela seja atualizada para suportar a última versão do Gmail. O problema só ocorre na extensão de Firefox, o gadget do Remember The Milk, que fica na barra lateral do Gmail, continua funcionando normalmente.

Como eu estava há algum tempo sem mexer com Ruby, resolvi fazer o ótimo curso online gratuito Core Ruby, do Satish Talim (também conhecido como Indian Guru) para relembrar algumas coisas. Ao chegar no tópico Ruby Overriding Methods, há um item sobre classes abstratas, que diz o seguinte:

Abstract class

In Ruby, we can define an abstract class that invokes certain undefined “abstract” methods, which are left for subclasses to define. For example:

# This class is abstract; it doesn't define hello or name
# No special syntax is required: any class that invokes methods
# that are intended for a subclass to implement is abstract
class AbstractKlass
  def welcome
    puts "#{hello} #{name}"
  end
end

# A concrete class
class ConcreteKlass < AbstractKlass
  def hello; "Hello"; end
  def name; "Ruby students"; end
end

ConcreteKlass.new.welcome # Displays "Hello Ruby students"

Assim que li esse código, fiquei com uma pulga atrás da orelha. Ele mostra como um exemplo de classe abstrata uma classe que faz referência a métodos não definidos, explicando que seria necessário criar uma classe concreta estendendo esta classe e implementando os métodos necessários.

Eu sempre pensei que classes abstratas fossem classes que não poderiam ser instanciadas, o que não é o caso do exemplo. É perfeitamente possível criar objetos da classe AbstractKlass. Só ocorrerá uma exceção se o método welcome do objeto criado for executado:

irb(main):006:0> obj = AbstractKlass.new
=> #<AbstractKlass:0x37d490>
irb(main):007:0> obj.class
=> AbstractKlass
irb(main):008:0> obj.welcome
NameError: undefined local variable or method `hello' for #<AbstractKlass:0x37d490>
        from (irb):9

Resolvi levantar esta questão no forum do curso, e recebi uma resposta de um dos participantes dizendo que em Ruby o conceito de classes abstratas seria diferente daquele que apresentei acima. De acordo com a definição da Wikipedia: “An abstract class, or abstract base class (ABC), is a class that cannot be instantiated”.

Pesquisando sobre o assunto, encontrei referências apresentando algumas sugestões de como implementar classes abstratas em Ruby de diferentes maneiras (herança, módulos e até um gem):

• How to implement an abstract class in ruby?
• Abstract Classes, For Ruby: Abstraction

Uma das possibilidades mostradas nos links acima seria desta forma:

class AbstractClass
  class AbstractClassInstiationError < RuntimeError
  end

  def initialize
    raise AbstractClassInstiationError, "Cannot instantiate this class directly"
  end
end

class ConcreteClass < AbstractClass
  def initialize
  end
end

Isso teoricamente resolveria o problema:

irb(main):043:0> obj1 = AbstractClass.new
AbstractClass::AbstractClassInstiationError: Cannot instantiate this class directly
        from (irb):36:in `initialize'
        from (irb):44
irb(main):044:0> obj1.class
=> NilClass
irb(main):045:0> obj2 = ConcreteClass.new
=> #<ConcreteClass:0x309f9f>
irb(main):046:0> obj2.class
=> ConcreteClass

Porém, há um detalhe importantíssimo: em Ruby todas as classes são abertas, ou seja, sempre será possível reimplementar métodos ou adicionar módulos que alteram o comportamento da classe, tornando impossível proibir completamente a instanciação e, consequentemente, a implementação de classes abstratas (pelo menos de acordo com o conceito apresentado aqui).

A linguagem Ruby possui alguns conceitos diferentes dos utilizados em outras linguagens, em função de algumas de suas características, como classes abertas e meta programação. Isso nos força a pensar em maneiras diferentes de implementar soluções para os mesmos problemas, o que é muito bom.

Para concluir, segue um trecho do livro “Programming Ruby” que foi apresentado na discussão sobre este assunto no forum do curso:

The issue of types is actually somewhat deeper than an ongoing debate between strong typing advocates and the hippie-freak dynamic typing crowd. The real issue is the question, what is a type in the first place?

If you’ve been coding in conventional typed languages, you’ve probably been taught that the type of an object is its class—all objects are instances of some class, and that class is the object’s type. The class defines the operations (methods) that the object can support, along with the state (instance variables) on which those methods operate.

In Ruby, the class is never (OK, almost never) the type. Instead, the type of an object is defined more by what that object can do. In Ruby, we call this duck typing. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck.

O Criteria é uma API do Hibernate que facilita muito quando precisamos montar uma query complexa com filtros opcionais. Adicionar restrições ou criar joins com esta API é muito mais simples de gerenciar do que concatenando Strings, como faríamos ao trabalhar com SQL puro.

Apesar das vantagens, o Criteria também tem alguns problemas. O último que encontrei foi ao tentar fazer 2 joins entre as mesmas 2 tabelas. No meu caso, eu tinha no banco as tabelas projeto e historico. A segunda tabela é populada através de uma trigger no banco: sempre que o status do projeto muda, a tabela historico registra o status anterior do projeto com data/hora da mudança. Eu precisava fazer uma query que buscasse um projeto com status “iniciado” num determinado período de datas e com status “finalizado” em outro período. Inicialmente, pensei simplesmente em criar 2 joins entre as tabelas, cada um com um alias diferente e filtrando pelas datas específicas:

Criteria criteria = getSession().createCriteria(Projeto.class);

// Primeiro join
criteria.createCriteria("historicoList", "historicoIniciado", Criteria.LEFT_JOIN)
        .add(Restrictions.eq("historicoIniciado.status", Status.INICIADO.value()))
        .add(Restrictions.ge("historicoIniciado.data", dataIniciadoDe))
        .add(Restrictions.le("historicoIniciado.data", dataIniciadoAte));

// Segundo join
criteria.createCriteria("historicoList", "historicoFinalizado", Criteria.LEFT_JOIN)
        .add(Restrictions.eq("historicoFinalizado.status", Status.FINALIZADO.value()))
        .add(Restrictions.ge("historicoFinalizado.data", dataFinalizadoDe))
        .add(Restrictions.le("historicoFinalizado.data", dataFinalizadoAte));

O código acima, apesar de semelhante ao que eu já havia criado para adicionar outros filtros à query de projetos, fazendo joins com outras tabelas, não funcionava. Tentei retirar um dos joins com a tabela historico e funcionou. Ou seja, o problema estava na criação do segundo join com as mesmas tabelas, mesmo utilizando aliases diferentes. Ao pesquisar este problema, descobri que não é um bug. Na verdade, o Criteria não suporta múltiplos joins para a mesma associação.

Sendo assim, a solução que encontrei para este problema foi criar uma subquery para a tabela historico, utilizando um DetachedCriteria:

DetachedCriteria historicoCriteria = DetachedCriteria.forClass(Historico.class, "historicoIniciado")
        .setProjection(Projections.distinct(Projections.property("projeto")))
        .add(Restrictions.eq("historicoIniciado.status", Status.INICIADO.value()));
        .add(Restrictions.ge("historicoIniciado.data", dataIniciadoDe));
        .add(Restrictions.le("historicoIniciado.data", dataIniciadoAte));
criteria.add(Subqueries.propertyIn("id", historicoCriteria));

Desta forma, apenas um dos joins precisa ser substituído por uma subquery. O outro join pode ser mantido sem problemas.

No último dia 14 aconteceu o Dev in Rio (veja vídeos e fotos do evento). Organizado pelo Guilherme Chapiewski e pelo Henrique Bastos, o evento foi um grande sucesso.

Na abertura do evento, Guilherme e Henrique informaram que o evento seria totalmente voltado para os desenvolvedores, destacando a importância de se integrar e reunir as pessoas para troca de experiências. Eles também ressaltaram a importância de se integrar comunidades de diferentes tecnologias, reforçando também a tendência dos desenvolvedores poliglotas.

A primeira palestra foi de Ryan Ozimek, sobre o CMS Joomla. Ryan, que não é desenvolvedor, falou sobre a história deste projeto, destacando a importância da participação da comunidade para o crescimento do Joomla.

Na palestra seguinte, Nico Steppat e Guilherme Silveira, da Caelum, falaram sobre Java como plataforma, e não como linguagem, destacando o suporte a várias linguagens, permitindo que possamos escolher a linguagem mais adequada a cada situação sem perder as vantagens oferecidas pela plataforma.

Após o almoço, Fábio Akita trouxe uma geral sobre o ecossistema Ruby on Rails. Na minha opinião, esta foi a melhor palestra do evento, pois ele soube resumir em pouco tempo uma quantidade enorme de conteúdo. Primeiramente, ele trouxe um histórico da linguagem Ruby, e, através de uma “meta-apresentação”, mostrou um pouco da linguagem e suas principais características, como meta-programação, por exemplo. Depois, falou sobre Rails, destacando algumas de suas principais características e os mais famosos mitos, como “Rails não escala” (link para a apresentação).

Em seguida, Jacob Kaplan-Moss, um dos criadores do Django, falou sobre este framework Python, sua história, evolução e principais características (link para a apresentação).

Na última palestra, Jeff Patton falou sobre metodologias ágeis, mas focando na criação de produtos e interação com o cliente, e não no desenvolvimento em si. Ele trouxe como exemplo o desenvolvimento de um produto real, as dificuldades encontradas e as soluções utilizadas.

Finalmente, foi feita uma espécie de mesa redonda com a maioria dos palestrantes e alguns convidados, como Marcos Tapajós, Sylvestre Mergulhão e Daniel Cukier, entre outros. Vinicius Teles fez o papel de mediador entre os participantes e o público.

Em paralelo às palestras, ocorreram coding dojos de Ruby, Python e Java. Destaque também para a tradução simultânea das palestras (tanto inglês-português quanto português-inglês), serviço que foi bastante elogiado por aqueles que o utilizaram. Também foram sorteados vários brindes no final, como ingressos para o Rails Summit.

No final, o balanço do evento foi extremamente positivo, pois conseguiu reunir muita gente, incluindo figuras bastante importantes e conhecidas no desenvolvimento de software. Os organizadores estão de parabéns, pois tudo correu sem qualquer problema aparente, todas as palestras foram muito pontuais e de excelente qualidade. Agora, só resta esperar pelo Dev in Rio 2010! Vale a pena conferir também os posts do Guilherme e do Henrique sobre o evento.

Há alguns anos atrás, era muito comum encontrarmos desenvolvedores que conheciam somente uma linguagem, e por isso intitulavam-se “desenvolvedor Java”, “desenvolvedor Delphi”, “desenvolvedor ASP”, ou qualquer outra linguagem. Eram pessoas que conheciam uma, e somente uma, linguagem de programação, e a defendiam com unhas e dentes em qualquer discussão nos fóruns, frequentemente gerando flame wars.

Esse tipo de desenvolvedor ainda existe, mas é cada vez menos comum, e isto é muito positivo. O livro The Pragmatic Programmer recomenda que aprendamos uma linguagem nova por ano, e, com isso, muitos daqueles desenvolvedores Java ou C# estão aprendendo Ruby, Python ou Erlang. Mesmo que não tenhamos pretensão de trabalhar com estas linguagens, pelo menos a curto ou médio prazo, cada linguagem tem suas particularidades, ajudando a quebrar paradigmas. Quando conhecemos somente uma linguagem, temos uma grande tendência a resolver os problemas sempre da mesma forma, conforme aprendemos e como é feito tradicionalmente com aquela linguagem. Desta forma, a tendência é a estagnação, pois não procuramos outras maneiras de resolver os problemas. A partir do momento em que começamos a estudar outras linguagens, abrimos nossa cabeça e começamos a “pensar fora da caixa”, e percebemos que existem muitas outras maneiras de resolver aquele mesmo problema, muitas delas mais simples e adequadas à situação. Surgem os desenvolvedores poliglotas.

Na época dos desenvolvedores monoglotas (sim, essa palavra existe!) era muito comum vermos discussões do tipo: “que linguagem é melhor, X ou Y?”. A melhor resposta é: depende! Depende da situação, do projeto, da experiência da equipe… Para cada situação, uma linguagem pode ser mais adequada que outra, o que traz uma grande vantagem para os poliglotas, pois, para se tomar esta decisão, é necessário conhecer as linguagens disponíveis. Ao mesmo tempo, se ninguém na equipe tiver experiência com determinada linguagem, seria um grande risco utilizá-la no projeto. É como uma caixa de ferramentas: se eu tiver somente um martelo na minha caixa, como farei para apertar um parafuso? É importante termos o maior número possível de ferramentas disponíveis, e conhecimento sobre cada uma delas, para que possamos escolher a mais adequada em cada situação.

Acompanhando esse comportamento, há atualmente uma forte tendência a plataformas poliglotas, o que também é muito positivo. As plataformas existentes já estão bastante maduras, têm algoritmos eficientes para gerenciamento de memória e Garbage Collection, por exemplo, e são bem conhecidas. Encontram-se nesta categoria as plataformas Java e .NET, que estão continuamente aumentando o número de linguagens suportadas – veja a lista de linguagens suportadas pela JVM e pelo .NET. Com isso, a escolha da linguagem para cada projeto fica muito mais fácil, permitindo, inclusive, projetos poliglotas. Se você trabalha com Java e decide utilizar Ruby no seu projeto, por exemplo, basta adicionar o jar do JRuby.

A conclusão que podemos tirar disso é que um desenvolvedor nunca deve estagnar. Procure sempre estudar e aprender novas coisas, mesmo que não seja nada relacionado com o que você está trabalhando atualmente, pois, mesmo que não venha a trabalhar, isso ajuda a quebrar paradigmas e permite que você se torne um melhor desenvolvedor.

Muitos já devem estar sabendo, mas acho que não custa nada ajudar a divulgar: no dia 14 de setembro ocorrerá aqui no Rio de Janeiro um evento imperdível: o Dev in Rio. Organizado pelo Guilherme Chapiewski e pelo Henrique Bastos, o evento terá palestras sobre Rails, Django, Java, Open Source e metodologias ágeis, contando, inclusive, com palestrantes internacionais. A inscrição custa apenas R$ 65,00, e, pelo sucesso que está fazendo, acho que as vagas vão acabar logo!

Para quem estiver sem grana, vale a pena tentar ganhar ingressos pelo RubyInside ou pela revista TI digital.

Mais informações sobre o Dev in Rio no site e no twitter. Parabéns aos organizadores pela iniciativa!

Há muito tempo eu uso o Google Reader como leitor de feeds. A principal vantagem sobre as demais alternativas para desktop é o fato de não necessitar de instalação, podendo ser acessado diretamente pelo browser.

Outro dia, tentei cadastrar o feed do Twitter no Google Reader, e recebi a seguinte mensagem: “Sorry, an unexpected condition has occurred which is preventing Google Reader from fulfilling the request”. Tentei acessar o feed diretamente no Firefox, e, após solicitação de login e senha, os feeds apareceram normalmente. Após uma rápida pesquisa, descobri que o Google Reader não suporta feeds autenticados, o que é o caso do Twitter.

Uma das alternativas a este problema seria utilizar um leitor de feeds que suporta autenticação, como a extensão NewsFox para Firefox ou algum outro. Porém, para poder continuar utilizando o Google Reader, uma solução é o FreeMyFeed, um serviço que funciona como uma espécie de proxy para feeds autenticados: você informa a URL, o login e a senha do feed que exige autenticação, e ele gera um novo endereço de feed que permite acesso direto, inclusive pelo Google Reader.