InfoQ

InfoQ

Notícias

Meus Favoritos

Faça oLogin ou Cadastre-se para ativar o recurso de favoritos por tempo ilimitado.

O conteúdo foi adicionado aos favoritos!

Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.

O que a significará a padronização para o Ruby

Postado por Mirko Stocker , traduzido por Herbertt Bamonde em 12 Mar 2010

Seções
Desenvolvimento,
Arquitetura e Design
Tópicos
Runtimes ,
Ruby ,
Especificações
Tags
Rubinius ,
MagLev ,
RubySpec ,
Ruby 1.9

Na RubyKigi 2008, o inventor do Ruby Matz anunciou planos para padronizar o Ruby com a intenção de "melhorar a compatibilidade entre as diferentes implementações do Ruby [...] e facilitar a entrada do Ruby nos sistemas do governo Japônes". A primeira proposta para a padronização será feita para o Comitê Japônes de Padrões Industriais e depois para a ISO, visando se tornar um padrão internacional. Por enquanto, um primeiro rascunho (em torno de 300 páginas) e o anúncio oficial estão disponíveis. Outra alternativa que está em desenvolvimento é uma wiki para disponibilizar a padronização em formato HTML.

Outra maneira muito diferente de unir as implementações Ruby é o projeto RubySpec (mais notícias relacionadas ao RubySpec você encontar na InfoQ), uma comunidade que direciona seus esforços para construir uma especificação executável. RubySpec é descendente do projeto Rubinius:

O projeto RubySpec pretende escrever uma especificação executável completa para linguagem de programação Ruby que é compátivel com a sintaxe do RSpec. [..] As especificações, geralmente servem para dois propósitos: 1) para guiar o desenvolvimento, e 2) como um mecanismo de verificação.

A InfoQ conversou com o pai do RubySpec, Brian Ford para descobrir o que ele pensa sobre a padronização e o que isso significa para o RubySpec.

Eu penso que o esforço na padronização ISO é muito importante tanto para linguagem como para a comunidade Ruby, que inclui os programadores Ruby, pessoas que usam software escrito em Ruby e o crescente número de empresas que utilizam softwares escritos em Ruby.
O documento de padronização e o RubySpec são complementários na minha visão. O documento coloca em primeiro plano a descrição do Ruby com as devidas formalidades. O documento prevê, essencialmente, uma definição do Ruby.
O RubySpec, ao contrário, coloca em primeiro plano o código que demonstra o comportamento do Ruby. No entanto, o RubySpec também enfatiza o Ruby o descrevendo como um elemento essencial da especificação de execução e esse é o motivo de usar uma sintaxe compátivel com a do RSpec.
O RubySpec também tenta capturar o comportamento da união de todas as implementações Ruby. Isso permite ao documento de especificações garantir a execução das diferentes implementações. Por exemplo, nem todas as plataformas usadas para implementar Ruby suportam todas as features. Então a especificação vêm justamente dizer qual a implementação possui aquela feature.
Isto ilustra uma importante diferença entre o documento de padronização ISO e o RubySpec. O documento ISO pode simplesmente afirmar que um aspecto particular da linguagem é " definido pela implementação" e não fornecem nenhum tipo de guia. Infelizmente, a implementação dessa norma pode ser difícil, como vimos com a confusão causada por vários fabricantes de navegadores ao tentar implementar CSS. O RubySpec tenta reduzir a quantidade de comportametos Ruby não especificados para a menor possível.
Uma vez que o documento de Padronização ISO amadurece, vamos acrescentar algum tipo de marcação ao RubySpec para permitir uma implementação executar todas as especificações definidas pelo "Padrão ISO". Isso permitiria uma implementação alegar que eles estão de acordo o que foi especificado no documento ISO. Eu não sei ainda como as especificações serão aceitas por um órgão (talvez governamental) e como será verificado o cumprimento das mesmas.

A rascunho inicial é baseado no Ruby 1.8.7, mas a versão 1.9.2 também já está em vista. Nós perguntamos ao Yuki Sonoda, gestor da release Ruby 1.9, quais são os planos para essa versão 1.9 em relação a padronização:

O rascunho do padrão JIS/ISO foi projetado de forma que o Ruby 1.9 esteja em confirmidade com ele . O rascunho foi afrouxado propositalmente. Isso permite aos interpretadores Ruby uma mínima restrição para ser  um "Ruby". Até a versão 1.8.7 era necessário especificações mais rigorosas como o RubySpec para manter a compatibilidade entre as implementações.

A partir de outras implementações do Ruby, Monty Williams da Gemstone, a empresa por trás do MagLev, comentou o que ele pensa sobre a padronização:

Nós certamente aplaudimos os esforços para chegar a um padrão Ruby. Em alto nível, um padrão aprovado deve ajudar  a aumentar a adoção do Ruby em certos setores. Esperamos estar habilitados a assegurar que o MagLev esteja em conformidade com os padrões uma vez que forem definidos.

InfoQ: Os padrões podem ser vantajosos para o desenvolvimento do Maglev?

Grande parte do trabalho de implementação do MagLev precedeu os padrões. Neste ponto,  o que nos ajudaria mais seria um teste de compatibilidade o qual certificaria as conformidades dos padrões, similar ao JCK. O projeto RubySpec é um ótimo passo para alcançar este objetivo. Contudo, os padrões podem ser de grande ajuda para os futuros implementadores a descobrir detalhes do Ruby.

O que vocês leitores acham: será mais fácil introduzir Ruby em suas empresas se existir um padrão ISO por trás?

Conteúdo Educacional

Formando equipes de alto desempenho, parte 1: Início e fases de evolução

Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.

Business Model Canvas, passo a passo

O Business Model Canvas é uma ferramenta estratégica para a construção visual de novos produtos ou serviços. Conheça cada um dos seus elementos e como preencher o Canvas, passo a passo.

Google Apps Script, Parte 2: Google Docs, triggers e envio de emails

Nessa segunda e última parte de uma série sobre o Google Apps Script, conheça como funciona o envio de emails, a conversão de documentos e como criar menus e triggers.

Serviços de cloud computing PaaS: um guia para desenvolvedores Java

Este artigo avalia seis dos mais importantes fornecedores de serviços de cloud computing PaaS para desenvolvedores Java, analisando critérios como desempenho, escalabilidade e tecnologias suportadas.

Canvas de Modelo de Negócios: uma contribuição para o sucesso de Startups

O Canvas de Modelo de Negócios é um novo modo de comunicar e suportar a validação iterativa, incremental e empírica de modelos de negócio de startups e novos produtos substituindo o plano de negócios.

Entrevista com Rebecca Parsons Parte 2: Agile Distribuído, Arquitetura vs. Design e SOA

Nesta segunda e última parte de uma entrevista exclusiva para InfoQ Brasil, Rebecca Parsons, CTO da ThoughtWorks, fala sobre o Agile Distribuído e técnicas para definição de arquiteturas.

Entrevista com Rebecca Parsons Parte 1: Agile nas Empresas e Arquitetura Evolucionária

Nessa primeira parte de uma entrevista com a CTO da ThoughtWorks, veja recomendações sobre formas de construir e arquitetar sistemas para obter o máximo de flexibilidade e responsividade a mudanças.

Agile das equipes à organização: o papel do gerente, estratégias e dicas para a adoção

Os gerentes de projetos podem assumir o papel crítico de liderar a introdução do Agile. Vejas conceitos, dicas e técnicas para apoiar esse processo de mudanças.