Archive for the 'Programação' Category

Nunca use o método Date.getYear() do Javascript

Post movido para: http://blog.guilhermegarnier.com/2010/01/29/nunca-use-o-metodo-date-getyear-do-javascript/

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:

Classes abstratas em Ruby?

Post movido para: http://blog.guilhermegarnier.com/2009/12/04/classes-abstratas-em-ruby/

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

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.

Problema com múltiplos joins em Criteria

Post movido para: http://blog.guilhermegarnier.com/2009/11/12/problema-com-multiplos-joins-em-criteria/

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.

Desenvolvedores e plataformas poliglotas

Post movido para: http://blog.guilhermegarnier.com/2009/09/11/desenvolvedores-e-plataformas-poliglotas/

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.

Livros técnicos traduzidos nunca mais

Post movido para: http://blog.guilhermegarnier.com/2009/07/16/livros-tecnicos-traduzidos-nunca-mais/

Há alguns meses atrás, eu estava interessado no livro Effective Java, segunda edição. A princípio, eu pretendia comprar na Amazon, mas decidi pesquisar antes. Pela internet, não achei o livro mais barato em nenhum lugar, mas acabei encontrando em uma livraria perto do trabalho por um precinho camarada. Só tinha um problema: era a edição traduzida em português.

Inicialmente nem pensei em comprar a edição traduzida, pois acho que livros técnicos devem ser mantidos na língua original. Algumas pessoas que discordam disto argumentam que nem todos dominam o inglês, mas, sinceramente, se você tem dificuldades com inglês e quer estudar informática, procure um curso de inglês urgente! Por mais que você procure ler somente livros em português, em algum momento vai precisar consultar alguma documentação, referência ou fórum de discussão em inglês. Além disso, acho que nas traduções, por melhores que sejam, acaba-se perdendo um pouco do original (como num filme dublado, em que algumas piadas em inglês perdem completamente o sentido quando traduzidas), aumentando a possibilidade de erros e a dificuldade de compreensão do assunto. Num livro de programação então nem se fala, pois é muito comum utilizarmos muitos termos em inglês que não têm tradução para português – ou até tem, mas o original se popularizou tanto que é usado como se fosse uma palavra do nosso vocabulário.

Na época em que fiz essa pesquisa, o livro estava mais caro na Amazon do que hoje, e ainda tinha que incluir o frete. Aquela edição traduzida sairia por menos da metade. Além disso, eu não teria que esperar a entrega, era só dar um pulo na livraria e comprar. Decidi dar uma folheada no livro, só pra ver se tinha algum erro gritante de tradução, como trechos de código traduzidos – sim, eu já vi livros com aberrações como “calculaMédia”, com acento mesmo. Como não encontrei nada de mais, acabei me deixando levar pela tentação de economizar uns trocados e comprando o livro traduzido.

Quando comecei a ler, achei a tradução muito boa. Nos primeiros capítulos, o único termo que machucou os ouvidos foi “encaixotamento automático” em vez de autoboxing – por mais que esteja correto, esse é um daqueles termos que não se costuma traduzir. Além disso, os trechos de código foram mantidos originais, e abaixo de cada um há a tradução de cada linha de comentário. Achei um pouco desnecessário, porém interessante.

Ao chegar no capítulo 4, estranhamente os comentários nos códigos passaram a ser substituídos pelos traduzidos. Isso continua até o final do livro. Aparentemente a tradução foi feita por pessoas diferentes, e faltou uma revisão mais rigorosa no final. Porém, não é nada que atrapalhe. Mais adiante, vi uma citação a uma referência bibliográfica e resolvi verificar qual era o nome do livro referenciado. Descobri que o livro não tinha bibliografia! Obviamente isso é uma exclusividade da edição em português. Mais uma falha de revisão, e esta é mais grave.

Quando comecei a ler o capítulo 5, que fala sobre generics, achei o trecho abaixo bem estranho:

Antes da versão 1.5, essa teria sido uma declaração de coleção exemplar:

/**
* Minha coleção de selos. Contém apenas instâncias de Stamp.
*/
private final stamps = …;

Não está faltando definir o tipo de stamps? Tudo bem, eu não devo ter entendido direito. Sigo a leitura e, um pouco mais à frente aparece o seguinte:

Com os genéricos, você substituiria o comentário por uma declaração de tipo aperfeiçoada para a coleção que passaria ao compilador as informações que anteriormente ficariam ocultas no comentário:

private final stamps = …;

Ué, mudou alguma coisa? Não é exatamente igual ao código anterior? Resolvi pegar o livro original em inglês emprestado com um amigo, e vejo que nele aparecem os seguintes trechos:

Before release 1.5, this would have been an exemplary collection declaration:

// Now a raw collection type – don´t do this!

/**
* My stamp collection. Contains only Stamp instances.
*/
private final Collection stamps = … ;

e

With generics, you replace the comment with an improved type declaration for the collection that tells the compiler the information that was previously hidden in the comment:

// Parameterized collection type – typesafe
private final Collection <Stamp> stamps = … ;

Os destaques em negrito são do livro original. Aparentemente, tudo o que estava em negrito foi omitido na tradução! E, se estava em negrito, é porque é exatamente o trecho mais importante do código! Posteriormente, descobri que isso acontece em todo o capítulo 5. Do 6 em diante os códigos voltam ao normal e não encontrei mais nenhuma bizarrice, exceto a tradução de “thread” para “segmento”.

Outro erro que se repetiu bastante no livro são as referências a números de páginas (ex: “veja a página 147″). Em todas as situações em que isso ocorre, o número da página que é referenciado é o do livro original, tornando a referência inútil na edição traduzida.

A conclusão que tirei dessa situação: livro técnico traduzido nunca mais! Os trocados que resolvi economizar com o livro acabaram saindo muito caros. Vale muito mais a pena investir um pouco mais no livro original – e num curso de inglês, caso você precise – para não ter dor de cabeça com livros mal traduzidos.

Instant Rails, o ambiente Rails de bolso

Post movido para: http://blog.guilhermegarnier.com/2009/06/18/instant-rails-o-ambiente-rails-de-bolso/

Com a proliferação dos pen drives com alguns GB de capacidade e a preços acessíveis, aplicativos que rodam sem necessitar de instalação tornaram-se igualmente populares. Estes aplicativos “portáteis”, mais conhecidos como Portable Apps, podem ser executados diretamente do pen drive, geralmente com todas as funções dos equivalentes instaláveis. Eles são mais comuns em ambiente Windows (o site mais conhecido é o PortableApps, mas existem outros, como o The Portable Freeware Collection), porém também existem Portable Apps para Mac OS X. Até onde eu sei, não existem Portable Apps para Linux, porém, é possível executar os Portable Apps de Windows via Wine.

Como não poderia deixar de ser, existem também muitos ambientes de desenvolvimento portáteis. Talvez o mais conhecido seja o XAMPP, que inclui um servidor Apache com MySQL, PHP e Perl, entre outras ferramentas. Basta descompactar e executar.

Para Ruby on Rails, também existe um ambiente portátil. É o Instant Rails, infelizmente disponível somente para Windows. A exemplo do XAMPP, basta descompactar um arquivo zip para se ter um ambiente Rails totalmente funcional, com Mongrel, Apache e MySQL. É possível, inclusive, instalar RubyGems e plugins Rails normalmente, como num ambiente Rails comum. O pacote inclui ainda o SQLite, PHP, phpMyAdmin, o editor SciTE e o typo, sobre o qual já escrevi aqui no blog.

A principal desvantagem do Instant Rails é que ele está bastante desatualizado – a versão atual, 2.0, é de dezembro de 2007, e inclui as seguintes versões:

  • Ruby 1.8.6
  • Rails 2.0.2
  • Mongrel 1.1.2
  • RubyGems 1.0.1
  • Rake 0.8.1
  • Apache 1.3.33
  • MySQL 5.0.27
  • SQLite 3.5.4
  • PHP 4.3.10
  • SciTE 1.72
  • phpMyAdmin 2.10.0.2

Segundo o wiki do projeto, há uma petição solicitando o upgrade para a versão 1.9.1 do Ruby.

UPDATE: Só agora vi que o Urubatan escreveu sobre o mesmo assunto no blog dele. Só que ele citou o Ruby on Rails Portable, um projeto muito semelhante ao InstantRails, porém um pouco mais atualizado: a versão do Rails atualmente é 2.1.0 (a do Ruby é 1.8.6).

Outro projeto semelhante que encontrei, mas ainda não testei, é o Flash Rails.

Tutoriais de JSF

Post movido para: http://blog.guilhermegarnier.com/2009/05/25/tutoriais-de-jsf/

Uma das maiores dificuldades para se aprender JSF é seu aparentemente complexo ciclo de vida, composto por 6 fases. Ao debugar uma aplicação JSF, percebe-se que alguns métodos dos Managed Beans são executados várias vezes, uma em cada fase, o que não é muito intuitivo, principalmente quando se está acostumado com outros frameworks web que utilizam abordagens bem diferentes.

Para facilitar a compreensão do ciclo de vida do JSF, recomendo o tutorial The JSF application lifecycle, da IBM. Ele explica cada fase, e apresenta um exemplo bem simples de uma aplicação usando JSF. Este tutorial é a segunda parte da série “JSF for nonbelievers”. As demais partes também são bem interessantes:


@guilhermgarnier

Estatísticas

  • 56,502 hits
Linux Counter

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.