Rails e [Tecnologia/Técnica X]

October 31st, 2006 § 6 comments

No Seminário Ruby on Rails, durante algumas palestras foram levantados alguns questionamentos sobre o modo Rails de fazer certas coisas e como esse modo pode ser comparado com outras linguagens. Felizmente, as discussões foram bem civilizadas e estão rendendo bons comentários até o momento. Quando das questões, não houve muito tempo para responder algumas delas e como eu fiquei pensando no assunto na viagem de volta, resolvi colocar algumas dessas considerações aqui.

Antes de começar, vale a pena dizer que não é possível comparar plenamente uma tecnologia como o Rails, que tem pouco mais de dois anos de vida com outras que já estão passando pela linha de dez ou doze anos. O ecossistema do Rails, por maior que seja, ainda é muito menor e menos desenvolvido. É claro que ele está crescendo, mas algumas comparações simplesmente não se aplicam.

Uma das coisas que eu vi que é que “convenção ao invés de configuração” é algo que muitos desenvolvedores demoram a colocar na cabeça–principalmente para usuários de linguagens estaticamente tipadas, que dependem de muita configuração. Olhando de fora do Rails, pode parecer às vezes, com foi citado no seminário em alguns momentos, que o Rails é procedural. Nada mais longe da verdade. O que acontece é que essas convenções do Rails colocam tantas peças em lugares automáticas que um desenvolvedor iniciante ou de outra linguagem poderia pensar que o Rails é como uma dessas bibliotecas onde você simplesmente preenche as linhas em branco. Mas, nesse caso, basta um pouco de experiência para entender que a convenção jamais se opõe à flexibilidade.

Dito isso, é possível esclarecer algumas perguntas feitas.

Uma delas foi em relação a regras de negócio, mais especificamente, onde eles se localizam no Rails. A resposta mais simples seria que quaisquer regras de negócio ficam no modelo de dados. A verdade é que isso depende de quais regras estamos falando. Regras relacionadas ao modelo ficam realmente no modelo. Validações, agrupamentos, esses tipos de regras são facilmente expressas por meio dos métodos já presentes do Rails (validações, chamadas interceptadas, entre outras). Mas, caso o desenvolvedor precise, ele pode usar classes fora da hierarquia padrão do Rails para expressar quaisquer regras necessárias, usando qualquer estratégia que deseje.

O fato é que o Rails não possui, propositadamente, qualquer meta-framework para expressar regras de negócio. Cabe ao desenvolvedor escolher a melhor maneira para descrevê-las. Com a flexibilidade do Ruby, a tendência atual é a utilização de linguagens de domínio extremamente especializadas para isso. Em resumo, o Ruby permite um poder de expressão tão grande em termos de linguagem que qualquer -framework especializado seria redundante. Se a linguagem é limitada, e exige que o desenvolvedor “roube” cada vez que precisa de algo mais avançado, o resultado é o surgimento de bibliotecas que violam a linguagem em favor dos desenvolvedores. No Ruby, isso não acontece e o desenvolvedor é livre para criar suas próprias linguagens de domínio. Tanto é assim, que plugins em Rails tendem a ser bem simples e específicos. Aliás, um exemplo dessa flexibilidade e simplicidade pode ser visto em um plugins que ajuda a criar máquinas de estado finito em puro Ruby.

Esse tipo de coisa é comum ao Ruby e acessível a qualquer desenvolvedor, que não fica dependente de bibliotecas pesadas e complexas para resolver problemas comuns.

Uma outra pergunta feita foi em relação ao Rails e AOP. Muito do que eu disse acima se aplica a esse tema também. Particularmente, eu acredito que o Rails nunca precisará de uma solução equivalente ao AOP porque o Ruby é uma linguagem que suporta AOP indiretamente por padrão.

Um exemplo citado foi o uso do Glassbox para fazer depuração e profiling de aplicações Java. Com stack traces do tipo que o Java gera, não é difícil ver a necessidade de uma aplicação que faça as coisas pelo desenvolvedor. A facilidade de expressão e reflexão que o Ruby dão ao desenvolvedor significam menos problemas, menos erros e mais entendimento do que o código faz. O Glassbox usa AOP, com compilação dinâmica, para capturar o estado da aplicação e identificar problemas. Uma aplicação assim provavelmente seria muito mais fácil de se escrever em Ruby por causa da natureza dinâmica da linguagem, sem necessidade de compilação ou interceptação indireta. O Ruby possui mecanismos naturais para isso, usados por qualquer aplicação. Ou seja, AOP acaba sendo uma prática natural e não algo a ser colocado sobre a linguagem.

É claro que pode-se dizer que AOP é mais do que isso. Mas esse argumento é enganoso. AOP existe para suprir uma falha em linguagens fechadas demais para permitir construções nativas que fornecem o equivalente. Isso é resultado do paradox Blub, descrito por Paul Graham. Mesmo o C# prova isso, apesar de sua natureza mais estática.

Uma terceira dúvida foi sobre a extensibilidade interna do Rails, ou seja, a capacidade do mesmo de se adaptar a problemas mais complexos. Isso é comum em bibliotecas onde a convenção é muito forte. De experiência pessoal, eu posso dizer que o Rails não falha nesse quesito. Recentemente, tive que fazer um aplicação onde tabelas genéricas, com grande valor semântico, eram criadas pelos próprios usuários durante a execução do programa. Essas tabelas tinham que se comportar, em termos de mapeamento, de maneira exata às tabelas pré-existentes na aplicação. Além de não ter qualquer problema com a geração das tabelas, também não tive problema algum em gerar todo a estratégia MVC correspondente às mesmas em tempo de execução com completa persistência sem recorrer a nenhuma técnica especial além da declaração de umas poucas definições idiomáticas para me auxiliar.

É fácil imaginar o que aconteceria se eu estivesse usando uma linguagem estática em que as definições tivessem que ser feitas em tempo de compilação. Seria, claro, possível fazer o que eu fiz, mas não com a naturalidade de nem precisar criar funções extras na biblioteca. E esse é um problema simples. Em aplicações que eu estou desenvolvendo agora, eu tenho casos de linguagens que são customizadas pelo usuário, geração dinâmica de condições de execução e coisas similares. Com o Ruby, eu não preciso fazer qualquer esforço.

Essas são algumas das minhas considerações iniciais. Se eu me lembrar de mais alguma coisa, continuo em outra entrada.

Eu não vou falar sobre implantação, que causou algumas dúvidas, porque acho que é só pesquisar sobre o Capistrano para perceber que no Rails não poderia ser mais fácil.

Obviamente, dúvidas são sempre válidas quando uma nova tecnologia promete muito. E acho que o Rails responde muitas coisas de uma maneira bem simples e poderosa. O fato é que, independentemente do que o Rails representa para outras tecnologias, desenvolver com o mesmo é algo que dá a qualquer programador uma agilidade maior na codificação e de quebra, por causa do Ruby, muda o seu modo de pensar. Nada melhor do que isso para algo tão novo.

§ 6 Responses to Rails e [Tecnologia/Técnica X]"

  • Spiceee says:

    eu acho que a extensibilidade do rails para se adequar a problemas mais complexos tem mais a ver com metaprogramming, que resolveu o seu caso criando models on-demand do que com as tais rails engines, que inclusive tomaram grande parte de uma das palestras sem me convencer completamente da sua aplicação!

  • Ronaldo says:

    Eu também ainda não me convenci do uso do Rails Engines. Só o fato dos mesmos terem sido deliberadamente excluídos das releases oficiais e os testes de performance não muito convincentes já diz muito. Eu realmente gosto muito de meta-programação. Estou estudando dois frameworks assim para o Smalltalk e vendo o que pode ser interessante para o Rails (Mewa e Magritte). Vamos ver no que dá.

  • Rapaz, muito bom, todos os pontos são extremamente válidos e de se levar ao pé da letra. Parabéns !

  • Ronaldo says:

    Opa, obrigado :-) Sinta-se à vontade para comentar mais aqui :-)

  • Walter Cruz says:

    Assunto interessante esse.

    Na verdade, uma das coisas mais fascinantes que eu acho nessa história de programar na linguagem ‘alpha’, ‘beta’ e ‘gama’, é que um programa traduzido de ‘alpha’ pra ‘beta’ de uma forma ‘natural’ não será a mesma coisa se não usarmos características inerentes de ‘beta’.

    É interessantíssimo as particularidades das linguagens. Escrevi um texto, meio primário até sobre o assunto, em: http://devlog.waltercruz.com/questao_nomes .

    Uma coisa que eu reparei são os Aspectos. Andei lenro dobre isso (não programo Java, ainda) e me interessei. Segundo alguns artigos que li, alguns design patterns são mais transparentes se implementados usando aspectos, e linguagens como ruby ou python trazem idiomatismos que tornam design patterns algo ‘buil-in’ da linguagem.

    Mais do que se acostumar com uma nova sintaxe, uma nova biblioteca e uma nova linguagem, é preciso mudar a forma de pensar, e é aí que eu penso estar o pote de ouro no fim do arco íris (isso para aqueles que de fato GOSTAM de programar e de estar sempre expandindo horizontes).

  • Ronaldo says:

    Linguagens de programação são realmente fascinantes. É como você disse, tem que mudar o modo de pensar e cada sintaxe tem seu próprio modelo mental. Eu estou quebrando a cabeça com alguns aspectos do Haskell porque, mesmo entendendo o que uma linguagem puramente funcional é e sabendo como usar, tenho “vícios” imperativos, coisa de anos de programação. E o estranho é voltar para o imperativo e tentar o funcional. Mas isso é o que vale a pena… :-)

What's this?

You are currently reading Rails e [Tecnologia/Técnica X] at Superfície Reflexiva.

meta