Este é um artigo que li em inglês e achei que seria bacana traduzir, hoje trabalho com uma equipe focada em .net e queria compartilhar os relatos do autor com o pessoal lá.
Espero que sirva de inspiração ou pelo menos para atiçar a curiosidade no assunto.

imagem por todorov40

Você é um programador .NET pleno.

Você já desenvolveu muitas aplicações com ASP.NET.

Você já gastou muito tempo, muitas noites sem dormir tentando descobrir detalhes avançados, como fazer a modelo orientado a eventos do ASP.NET trabalhar do jeito que você gosta.

Você já é experiente em padrões como “Presentation Model” ou “Model View Presenter” para adequar sua aplicação e deixá-la mais fácil de se testar fazer manutenções.

Você acha que Ruby on Rails é apenas mais uma dessas tecnologias de modinha e você não deve gastar seu tempo com isto, pelo menos até que o mercado comece a respeitá-la ou exigi-la quem sabe.

Bem vindo ao meu mundo.

Se você continua lendo este artigo até aqui já merece o meu respeito, porque você deve estar curioso o suficiente para saber como eu, após um mês desenvolvendo em Ruby on Rails, mesmo sendo um programdor experinte em .NET, posso dizer que muitas aplicações que fiz anteriormente, poderiam ter sido feitas em bem menos tempo e código, caso eu tivesse conhecido o Ruby on Rails antes.

Para ser justo, continuo gostando muito do .NET, afinal ele me ofereceu um ambiente no qual eu sempre pude entregar valor de negócio aos meus clientes. No entanto, eu sempre gosto de me lembrar que há várias maneiras e tecnologias para se resolver um mesmo problema, alguns melhores que outros. Sendo fiel a apenas uma tecnologia, eu acabo sendo obrigado, mesmo que inconscientemente a tomar decisões tendenciosas, fator que acaba prejudicando minha capacidade de agregar valor ao negócio.
Por exemplo, conhecendo uma linguagem de script dinâmica como o Ruby me faz pensar que eu posso escrever automações simples de batch/shell em bem menos tempo, se comparado com uma linguagem compilada.

Então, por quê não?
Descrevo abaixo algumas coisas que descobri e me trouxeram um novo paradigma como um programador .NET aprendendo Ruby, espero que se goste.

Não compile
Em Ruby, não existe o conceito de compilação, tudo roda em tempo de execução. Alguns podem dizer que a compilação é uma segurança para seu código, mas você deveria dar uma olhada em como o desenvolvimento orientado a testes, integração contínua, testes unitários (testes que não tocam em banco de dados ou web services) e injeção de dependência podem lhe ajudar a produzir código de qualidade e permitem boa flexibilidade para alterá-lo com confiança.

De repente compilar o seu código podem não ser tão útil assim.

Melhore o comportamento das suas classes dinamicamente – sem um Decorator
Usar o padrão de projetos Decorator é uma maneira de se fazer isto em linguagem tipada (outra maneira pode ser o Método de Template). Porém em Ruby, há muitas outras maneiras de melhorar uma classe dinamicamente e com facilidade, apenas pelo fato de que a linguagem suporta isto, sem ter que complicar a estrutura de seus projetos. Considere “module mixins”, “class_eval”, instance_eval, etc. É possível definir programáticamente métodos em uma classe em tempo de execução. Geração de código em uma linguagem tipada pode ser em caminho para conseguir isto, mas só de saber que existem outras opções já o tornam um solucionador de problemas melhor.

Diminua suas linhas de código em 10˜20% apenas por retirar todas as declarações de tipo e de interface
Ruby é uma linguagem dinamicamente tipada. Você não precisa declarar o tipo de uma variável antes de usá-la ou fazer seus parâmetros de método propriamente tipados. Isto significa que o seu código fica mais enxuto em detrimento a maior dificuldade de debugar e procurar por erros, certo? Nem tanto, se você acreditar em testes unitários e bons conceitos de orientação a objeto. Se as suas classes forem curtas e coesas, e seus métodos por sua vez forem curtos, bem intencionados e cobertos por testes, então debugar e encontrar erros será “mamão com açucar”.

Ajax sem dor
Ruby on Rails tem suporte embutido ao script.aculo.us, uma biblioteca Ajax com toneladas de efeitos para fazer sua aplicação mais “user-friendly” (você também pode usar jQuery). Em muitos casos, ter requisições web em Ajax no server side em Rails é equivalente a colocar uma tag de controle em suas páginas e escrever um método no code-behind, simples assim.

Com Rails, você não precisa de um O/R Mapper
Aplicando algumas conversões de nomes enquanto cria seu banco de dados, tabelas, colunas e objetos do modelo, você pode esquecer o castigo que é implementar um O/R Mapper, Ruby on Rails faz isto por você. Nos casos mais simples, tudo o que você precisa fazer é adicionar um campo em sua view, insistir para colocar um campo de texto no seu html e adicionar a coluna onde você quer que o valor seja guardado na tabela, depois é só assistir o texto inserido usuário popular a recém criada coluna no banco. De verdade, isto é tudo.

Usar scripts em Ruby para desenvolver/implantar/publicar é melhor que usar NAnt
A ferramenta padrão para isto em Ruby on Rails é o Rake. O Rake usa Ruby, isto significa que você usa Ruby em seus scripts para várias necessidades de desenvolvimento e implantação. Como linguagem, o Ruby é muito melhor quando se trata de manipulação de strings, criação de arquivos e diretórios, incluindo o suporte superior a expressões regulares. Pense em quantas vezes, em seus scripts de batch ou NAnt, você fez coisas como: para cada arquivo com a extensão .sql no diretório “a”, copie do servidor A para o servidor B e então execute um por um. Se você odeia as limitações de scripts batch ou não gosta das coisas no formato xml do NAnt, há grandes chances de você gostar do Rake.

Sem dor, sem ganho
Sim, existem alguns obstáculos que tive de atravessar para aprender Ruby.
Primeiro, eu tive que lidar com as emoções para aceitar o fato de que incialmente iria levar mais tempo encontrar uma nova solução em Ruby do que eu levaria com uma tecnologia com a qual eu já estava acostumado. Esta é uma experiência muito dolorosa, mas depois de um tempo, você começa a perceber que consegue desenvolver diversas maneiras de resolver diferentes problemas, é aí que começa a ficar divertido.
Segundo, apenas ler sobre Ruby e Rails apenas me dispersa. Usar o que você aprende na prática, ajuda a fixar o que foi aprendido. Lembre-se use o que você aprende ou estará perdendo tempo investido em ler sobre isto.

Sobre o autor original
Stephen Chu é desenvolvedor de software, consultor da ThoughtWorks. Ele é um experiente desenvolvedor .NET e recentemente foi capturado pelo Ruby on Rails. Você pode ler mais em seu blog: http://www.stephenchu.com.

Considerações:
O artigo original pode ser encontrado aqui: http://www.infoq.com/articles/Netter-on-Rails.
Esta é uma tradução livre, pode conter erros que com o tempo vou revisando, se você encontrar alguma inconsistência entre os textos, por favor me avise.