Rafael Fidelis

I write about programming and random things

Ruby Não é Somente Rails, Carai!

| Comments

Tempo médio de leitura: 10 minutos

Keep calm
Créditos da imagem: Keepcalm-o-matic

Ok, minha vontade era de deixar o título desse post como “Porque o Rails não é a melhor opção para a nova versão da web”, mas pra evitar click bait acho mais justo deixar como tá mesmo. Mesmo porque, a ideia desse post não é discredibilizar o Rails, e sim chamar a atenção para outros frameworks do mundo Ruby.
Nesse post eu quero focar em algo muito sério do meu ponto de vista:

Porque raios todo mundo acha que só existe vida no mundo Ruby se for com o Rails?

Na realidade, isso é algo que me irrita bastante! Temos uma linguagem linda, robusta, humana, incrível e muito madura nesse estágio, mas tudo que se ouve falar quando se fala de Ruby é somente de Rails, Rails, Rails…

Quando se fala de Ruby essa é a imagem que todos tem, que se você programa Ruby, é porque somente desenvolve com Rails. Ok, isso pode ser verdade para muitos desenvolvedores, talvez a grande maioria, mas não para todos, é onde eu e muitos outros programadores se encontram: Existe vida além do Rails sim!

Como já dito, esse post não foca em te tentar convencer em largar o Rails, e sim em apresentar as alternativas existentes para desenvolvimento web, e também te mostrar que sim, estão utilizando Ruby para outras finalidades além de aplicações web.

Eu adoro programar em Ruby, acho a sintaxe e as características da linguagem muito interessantes, e se você é programador Ruby provavelmente sente um apreço muito grande pela linguagem, porque esse foi o objetivo do Matz ao desenvolver essa linguagem, ele queria fazer os desenvolvedores felizes enquanto escreviam seus programas, e eu tenho certeza absoluta que conseguiu, Ruby é muito prazerosa!



Você vai aprender mais ainda sobre Ruby

Com isso tudo, porque você vai deixar de conhecer todo o ecossistema que a linguagem de proporcionar para ficar vidrado e aceitar SOMENTE UM modo de desenvolver aplicações web com Rails?

Para você como desenvolvedor, sair do padrão e abrir caminho para a evolução, para outras possibilidades, para outras arquiteturas e padrões de desenvolvimento de software é algo muito valioso, você pode ser melhor do que é hoje, você deve ser melhor do que é hoje se quiser continuar evoluindo e ser relevante na sua profissão, e te digo algo: ficar só no básico do dia a do Rails não vai te fazer um desenvolvedor melhor, talvez até te faça um desenvolvedor pior, já que o Rails faz tudo de forma tão automagicamente que você não precisa realmente aprender como as coisas funcionam.

Eu tenho algumas perguntas pra você que está usando Rails a anos, ou meses:

- O que você entende do Rack?
- Quais outras ORM além do ActiveRecord você conhece?
- Você entende os problemas de connection pooling do Active Record?
- Você entende como uma aplicação Rails realmente funciona?
- Você sabe como disparar um email em plain ruby? Ou só sabe utilizar o ActionMailer?
- Você seria capaz de fazer deploy de uma aplicação off Rails, isto é um app Rack nesse exato momento?
- Você já leu o código do Rails alguma vez? Sabe como funciona o life cycle de um request HTTP dentro do Rails?
- Você sabe lidar bem com require de arquivos em seus programas Ruby ou depende do const_missing que o Rails utiliza para também fazer require dos arquivos automagicamente?

Eu gostaria que você responde essas perguntas pra você mesmo, e pensasse um pouco sobre isso… Provavelmente algumas das respostas são meio misteriosas pra você, e se isso realmente acontece, você deve parar um pouco e pensar porque não sabe exatamente a resposta.

Não é como se eu não gostasse do Rails - até mesmo já fiz uma singela contribuição para o Railtes, que é o core do Rails - , pra mim ele trouxe uma evolução muito grande pra todo o ecossistema de desenvolvimento web, certamente foi uma das grandes e mais importantes ferramentas da web 2.0, e pra mim tá ali junto com o jQuery no hall dos projetos mais revolucionários de todos os tempos, eu realmente sou muito grato ao Rails e a todo conhecimento que ele trouxe para TODO o mercado de desenvolvimento de software, principalmente a revolução que o mesmo causou no desenvolvimento de aplicações web, o Rails foi do caraleo nesse sentido, se hoje temos uma linguagem Ruby mais madura, mais robusta, mais segura e mais performática você pode ter muita certeza que foi graças ao Rails, todos sabemos que a ascensão do Ruby só veio realmente pelo Rails.

OBS: E também vale agradecer o trabalho do core team do Rails que é formado por uma galera muito zica, como Tenderlove, Yehuda Katz, José Valim, Santiago Pastorino, Rafael França, e tantos outros.

Muitas empresas fodas pra caraleo conseguiram conquistar seu espaço graças ao Rails, graças a velocidade de desenvolvimento que ele proporcionou para que seus produtos pudessem ser lançados o mais rápido possível, e também por permitir a evolução dos meses durante os anos seguintes, alguns exemplos são: Airbnb, Shopify, Twitter, Hulu, entre tantas outras.

Muitas dessas empresas inclusive foram responsáveis por evoluir a comunidade e o ecossistema do mundo Ruby, foram anos incríveis até aqui, eu sou muito grato ao Rails por sua influência e sua importância, esse framework foi revolucionário, porém para mim tá na hora do Rails sair um pouco de cena e dar espaço para os seus pupilos, que são mais específicos e menos mágicos.



O modelo de desenvolvimento de software para web evoluiu muito!

Mas beleza, se você está trabalhando com tecnologia já deve ter entendido que o cenário mudou muito nos últimos anos, muito mesmo, e o modelo de desenvolvimento de software também mudou muito.
Você pode até ser um fã absurdo do Ruby on Rails, nesse sentido não existe nenhum problema, mas eu espero que você também esteja olhando além disso, porra, você é um desenvolvedor de softwares ou uma pessoa totalmente acomodada? Se você pensa que o Rails pode resolver todos os seus problemas, eu sinto muito, ele não pode! E isso vai ser verdade para praticamente qualquer ferramenta existente, não existe bala de prata.

Certo, chegamos nesse ponto do post aonde você talvez já esteja irritado com minhas perguntas e minha petulância em insistir que você como programador Ruby deveria estar olhando um pouco além do Rails, certo certo, porque você não vai buscar uma água, tomar um café e pensar um pouco sobre isso? Prometo que te espero aqui.

(alguns minutos depois…)

E aí, viu só? Esperei pacientemente pela sua reflexão, a partir desse momento vamos falar um pouco do mundo Ruby off Rails, isso vai te empolgar, tenho certeza.

Antes de começar a abordar esse assunto, Gostaria de contar um pouco sobre minha história com Ruby e porque me sinto frustrado em geralmente conhecer programadores Rails, e não programadores Ruby.

RPGMaker VX Splash Screen
Créditos da imagem: Wikipedia

Como a maioria dos jovens, eu curtia muito jogar videogames, mas diferente da grande maioria, eu queria construir meus jogos, e não somente jogar os que existiam disponíveis. Eu era muito fã de Cavaleiros do Zodíacos quando era moleque, e uma vez comprei um CD da Digerati que tinha um jogo independente do CDZ, eu pirei quando joguei!!!!!
Os diálogos eram em português, a jogabilidade era massa embora fosse bem simples. E aí, eu descobri que o jogo foi desenvolvido numa ferramenta chamada RPG Maker, fui pesquisar sobre e descobri que eu também podia fazer meus jogos usando essa ferramenta, caraleo, pra mim foi como conquistar o mundo, foi uma satisfação muito grande ter esse poder. Lá por 2006 eu ficava brincando de fazer meus joguinhos com um amigo utilizando o RPG Maker 2k3 (ainda lembro de a gente trocando disquetes com as atualizações, e olha que eu nem sou tão velho assim).

Beleza, nessa época eu tinha uns 12 anos e devidos as circunstâncias da vida, tive que me mudar de cidade e também de realidade, nessa altura já não tinha mais acesso a um computador. Depois de anos, quando eu tinha mais ou menos 17 anos, consegui ter acesso a um computador novamente, e meio que instantaneamente eu baixei uma nova versão do RPG Maker, o grande diferencial dessa versão era incrível: Era possível escrever scripts para modificar todo o sistema do jogo, desde os menus, até a jogabilidade, era possível fazer qualquer coisa para oferecer uma experiência única para seus jogos, tudo isso graças ao RGSS: Ruby Game Scripting System, basicamente era uma biblioteca construída com Ruby para permitir a customização de componentes internos do jogo.

Eu demorei um pouco a realmente me interessar por programação no RPGMaker, mas quando eu decidi aprender minha vida mudou para sempre, não porque eu conseguia fazer jogos mais elaborados, mas sim porque eu fui apresentado a um mundo que eu não fazia ideia que existia, caraleo, noites e noites de empolgação lendo tutoriais de Ruby(why the lucky stiff <3) até que um dia consegui autonomia suficiente pra começar a desenvolver meus próprios scripts e compartilhar com toda comunidade maker, eu desenvolvi uma caralhada de scripts Ruby para o RPGMaker, e isso me fez ganhar prêmios como “Scripter do ano” pela finada ReinoRPG.com, além disso comecei a desenvolver vários scripts para meu fã game de Harvest Moon- aqui um vídeo com a demonstração - e ele foi eleito o “Projeto do mês” pelos membros do SantuárioRPGMaker) - uma respeitadas comunidades de RPGMaker do Brasil naquela época - eu senti firmeza.

Com isso dito, passei uns 2 anos programando RGSS e então eu decidi que era hora de evoluir meu nível em Ruby e aprender a programar para web, e como sempre, tudo que eu pesquisava sobre a linguagem naquela época me remetia ao tão famigerado Ruby on Rails, mas por algum motivo eu não queria realmente utilizar o Ruby on Rails, mas eu não manjava NADA de programação web, então o Rails foi o caminho mais curto para eu aprender o básico de desenvolvimento web.

Comecei desenvolvendo pequenos projetos pessoais, e foi do caraleo! Comecei a aprender princípios como REST, entender o basico do basico do HTTP, o básico sobre banco de dados, etc.

Porém durante esse tempo eu me encantei de forma mística por um micro framework chamado Sinatra, e instantaneamente comecei a desenvolver tudo que era possível nesse micro framework, e de certa forma ele me trazia MUITO Mais satisfação que o Rails, e eu comecei a me perguntar porque de me sentir assim.

“Porque eu me sinto muito mais feliz programando com o Sinatra do que com Rails?”

Rails vs Sinatra.
Créditos da imagem: AirPair

Então a resposta ficou clara pra mim: Eu sou movido a desafios, e o Rails sempre me deu tudo de mão beijada, de uma maneira que eu realmente não conseguia entender o que acontecia, já que o Rails é totalmente implícito no seu jeito de funcionar.Já Sinatra me forçava e estimulava a aprender melhor como as coisas REALMENTE funcionavam, eu errava muito, mas isso me impulsionava muito também, comecei a aprender como o Rails funcionava por baixo dos panos - graças ao Rack - e isso me trouxe uma necessidade de entender melhor como funcionavam várias coisas que o Rails não me permitia realmente entender, por exemplo como uma requisição é processada desde o momento que ela saia do computador do usuário, até o momento que ela era processada pelo web server, retransmitida para o app server, processada pelo rack, enviada para a aplicação, retransmitida para o web server novamente e então para o cliente.

Comecei a confiar muito no Sinatra, sofri um cado tentando aplicar o jeito Rails no Sinatra, e também fui percebendo que muitas coisas não faziam sentido! Porém a única referência que eu tinha era o Rails, e um pouco de PHP que eu já havia brincado no passado.
Então eu decidi me dedicar a aprender outras linguagens e frameworks, para poder entender como eles funcionavam e se poderiam existir soluções melhores que o Rails e o Sinatra, nesse meio tempo tive contato com o maravilhoso micro framework Slim do PHP, também fiz coisas com o Express e Ace do Node, usei o CakePHP que é muito inspirado no Rails, conheci e dei uma fuçada no Laravel.
Isso me fez entender que o Rails fazia muita mágica por mim, e que eu não gostava daquele modelo implícito de resolver as coisas, eu sou mais fã de uma das filosofias do The Zen of Python:

Explícito é melhor que implícito.

E minha imagem do Rails foi cada vez ficando mais duvidosa, depois quando decidi voltar pro mundo Rails e aprender novamente, já que agora me sentia muito mais seguro pois eu entendia melhor o que o Rails tava fazendo sem me deixar realmente saber.

Comecei a trabalhar em projetos legados desenvolvidos com Ruby on Rails, JESUS amado, eu tinha chegado a trabalhar com PHP - que é uma linguagem que eu também gosto bastante - e a maioria dos projetos que eu tinha a oportunidade de trabalhar estavam horrivelmente arquitetados, e enfim, quando comecei a entrar em projetos Rails a minha experiência foi bem parecida com a que eu tive quando via aqueles amontoados de códigos PHP: Uma puta decepção.

Cerca de 70% projetos Rails que eu trabalhei eram um grande de um amontoado de gems - daquele tipo gem install minha-regra-de-negócio - e totalmente cagados do ponto de vista de arquitetura, e isso porque o Rails convenciona uma padrão de arquitetura, ele é até bem organizadinho desse ponto de vista. Mas por N motivos muitos desenvolvedores decidem não seguir nenhum padrão de código e arquitetura, principalmente os programadores iniciantes que geralmente tem um primeiro contato com o Rails, e o framework torna tão fácil o processo de desenvolvimento que muitas pessoas não buscam conhecer como as coisas funcionam, e como deveriam realmente funcionar e saem escrevendo código como dá para lançarem os produtos e sites que se comprometeram a entregar.
A cagada é que isso tem um puta custo em questões de débitos técnicos no futuro. Já vi empresas quase terem que fechar as portas ou gastar uma puta grana e refazer o produto por não conseguirem escalar suas aplicações Rails que foram feitas de qualquer jeito por um programador qualquer, e depois de meses começaram a cobrar essas dívidas, aqueles rails g scaffold - ou então nas inumeras dependencias que começam a quebrar - não são suficientes para manter o crescimento de uma empresa e de um negócio, embora o Rails seja realmente fantástico, ele também vende a ideia de ser capaz de desenvolver software extremamente rápido - quem não lembra daquele vídeo do blog em 15 minutos? - bom vocês devem conhecer o ditado: ”a pressa é inimiga da perfeição

E cedo ou tarde, geralmente essas imperfeições durante o desenvolvimento guiado a “vamos que vamos” - famoso go horse - aparecem, eu não sei da sua experiência, mas eu acredito que você deve ter trabalhado em algumas aplicações Rails muito cagadas, porque essa filosofia de depender de inúmeras gems e escrever o código do jeito que era convencionado pelo Rails, isso gerou e ainda gera problemas para muitas empresas com seus sistemas legados.

OK, não sei se você concorda ou não com tudo que eu disse até aqui, mas espero que consiga entender, já que tudo exposto até agora é pra te ajudar a pensar diferente.

Para finalizar essa seção, fique com esse twitte pra pensar um pouco:

Twitt



Precisamos de novos jeitos de pensar para solucionar novos problemas

Lembra quando eu disse que tudo é mudou e mudou nos últimos anos? Na época do BOOOM do Rails - lá por 2006-2007 - não existia iPhone, não existia Android, não existiam tablets, não existiam dispositivos como Internet of Things, hoje você acessa uma aplicação pelo browser, pelo celular, pelo videogame, pelo Kindle e até mesmo pela sua geladeira! A evolução chegou como deveria de ser, e com isso a forma como desenvolvemos softwares também mudou, hoje não existe somente o browser, é necessário oferecer uma experiência para qualquer dispositivo que esteja conectado a Internet! Com isso, deixamos de desenvolver aplicações monolíticas, isto é, aplicações que acoplam toda a regra de negócio e também a camada de apresentação em uma única instância, isto é, uma única aplicação. O mercado sentiu a necessidade de mudar, aonde seria necessário oferecer serviços que pudessem ser acessados por diferentes aplicações: pelo browser, por aplicativos em smartphones, pelos consoles de videogames(ex: Netflix, Spotify, Steam, Google)

A partir desse momento, aplicações web começaram a ser desenvolvidas em duas camadas: server e client, onde o server é o repositório central com toda regra de negócio e os clients são aplicações que se integram com o servidor para enviar e receber dados, de forma universalizada e sem a necessidade de compartilhar a regra de negócio entre vários clientes, em outras palavras foi quando aconteceu a ascensão das web APIs.



Certo, e o que isso tem a ver com esse post?

Bom, estávamos falando do mundo onde o Rails não é a única opção para desenvolvimento web com Ruby, né?

Nesse sentido, o Rails não conseguiu realmente acompanhar essa evolução do mercado, isto é, o Rails sempre foi convencionado a aplicações monolíticas, e isso é verdade até hoje!(Estamos em 2017, carai).

Outras opções começaram a ganhar mais credibilidade, exemplos são sinatra e o grape, que é um framework totalmente orientado a desenvolvimento de APIs, que atualmente estão muito estáveis e rodando em produção em muitas empresas. O Grape por exemplo já é utilizado em inumeras APIs nesse mundão a fora, alguns exempos são GitLab, ScreenHero que foi comprado pelo Slack.

Se você acha que outros frameworks não são tão maduros quanto o Rails ou não conseguem fazer seu negocio valer, bom, veja o caso do [Artsy.net] que também utiliza o Grape na sua API pública:

Artsy.net

Artsy is a new way to discover art you’ll love, featuring work from leading galleries, museums, and private collections around the world.

Artsy.net

Eu particularmente venho utilizando o Grape a pelo menos 2 anos e já coloquei pelo menos uns 5 produtos em produção que estão rodando Grape muito de boas, tranquilo. Já com o Sinatra é ainda mais popular e já está sendo utilizado em milhares de empresas em todo canto do planeta, nessa página você pode ver algumas empresas que estão usando, entre elas: Travis.ci, Linkedin, Github, Heroku, BBC…

E até mesmo aplicações rack only já foram deployadas milhões de vezes, quer ver um exemplo? O dashboard web do Sidekiq é uma aplicação puramente Rack(um objeto que só precisa responder para o metodo call, basicamente) sem depender de nenhum micro framework, somente PORO(Plain Old Ruby Objects).

Nós Rubistas somos responsáveis por criar a proxíma versão e continuar elevando a reputação da nossa comunidade, e eu acredito que temos potencial e competência para evoluir todos esses novos pupilos do Rails, precisamos olhar mais para o Sinatra, mais para o Grape, mais para o Hanami, mais para o Sequel.



Onde o Rails ainda cai como uma luva

Eu acredito piamente que o Rails ainda pode ser uma solução muito válida para muitos problemas, eu ainda quero continuar utilizando o Rails, mas somente em aplicações onde ele realmente faça sentido, eu hoje utilizaria o Rails para prototipar aplicações, criar MVPs apra testar uma ideia, e mesmo em Hackatons aonde o tempo é limitado e não quero perder tempo fazendo setup de uma aplicação comum. Um uso de caso que acho bem interessante para utilização de aplicações Ruby é um desses exemplos de aplicações para melhorar as nossas cidades que necessitam de desenvolvimento rápido para testar uma ideia e não necessariamente precisam escalar no mesmo nível de uma aplicação comercial.
Hoje na maioria dos casos uma aplicação necessita ser desenvolvida como API, e não venha me dizer que o modo --api-only do Rails resolve isso, você já deu uma olhada no generator? Ele somente remove alguns middlewares do Rack e dá uma enxugada no ActionController para evitar todo o código relacionado a interações com o browser(cookies, sessions, etc), mas você ainda está totalmente preso no jeito Rails de programar, que é totalmente implícito.



Eu devo parar de utilizar o Rails?

Veja bem, muita calma nessa hora. Isso é você que vai decidir, você pode simplesmente ler esse post e continuar sua vida, no final das contas como dito aqui: quando você não se permite que a evolução e inovação entre na sua vida, é você que sai perdendo, é você que vai se manter no mesmo padrão sempre, limitado, então a decisão fica por sua conta. Porém, eu espero que você realmente pare para pensar um pouco, você já deve ter entendido que o Rails foi uma opção foda pra caraleo durante muitos anos, e que no mundo em 2017 existem TANTAS opções mais relevantes que o Rails(em várias linguagens de programação).
Observe que eu nem citei o fator performance, mesmo porque eu nem sempre acho que esse deve ser o fator principal ao decidir escolher uma tecnologia, na realidade o Rails está sempre bem abaixo da maioria dos frameworks nesse sentido, mas isso geralmente é “aceitável” para alguns produtos pela performance oferecida durante o tempo de desenvolvimento, bom, aqui vai caber você olhar para o que você está desenvolvendo e determinar se realmente vale a pena.



Como eu posso começar a desenvolver minhas aplicações off Rails?

A Heroku lançou uma ferramenta chamada Pliny que eles criaram para o desenvolvimento de suas APIs públicas e internas em Ruby, a stack desse projeto basicamente inclui:

Sinatra
Sequel
PostgreSQL
Rake

Porém eu tenho utilizado a seguinte stack nos meus projetos:

Grape & Sinatra (Micro/API frameworks)
PostgreSQL (Banco de dados)
Capistrano (Deploy)
Dotenv (Configuração)
Sequel (ORM)
Active Model Serializers (Serialização de objetos)
NiftyServices (Services objects)
Rake (tasks)
Rspec (testes)
Shotgun (auto reload)

E de forma geral isso tá sendo mais que o suficiente, posso observar minhas aplicações usando muito menos memória do que uma aplicação inteira do Rails, e além do mais um puta ganho de performance e um ótimo pique - basicamente equivalente ao modo Rails - na velocidade de desenvolvimento.



Outros projetos além do Rails

A comunidade Ruby desenvolveu excelente projetos, entre eles os mais conhecidos são:

Rack - A modular Ruby webserver interface
Sinatra - Micro Framework
Grape - REST API Framework
Hanami - The web, with simplicity Sequel - The database Toolkit for Ruby
Homebrew - The missing OXS package manager
Play - Your company DJ
Sonic-Pi - The Live Coding Music Synth for Everyone
Jekyll - static site generator in Ruby
Octopress - an obsessively designed framework for Jekyll blogging
Ruby Warrior - Game written in Ruby for learning Ruby and artificial intelligence.
Puppet - Server automation framework and application
Metasploit - World’s most used penetration testing software
Logstash - transport and process your logs, events, or other data
Sass - CSS Preprocessor
RubyMotion - Mobile app development toolchain
Streamio FFMPEG - Simple yet powerful ruby ffmpeg wrapper
Vagrant - Tool for building and distributing development environments
Event Machine - fast, simple event-processing library for Ruby programs
Capistrano - Remote multi-server automation too
Chef - A systems integration framework
Gusu - 2D game development library for Ruby and C++



Conclusão

Nesse post busquei falar um pouco sobre a história do Rails e sobre como ele foi responsável por uma grande evolução na web e também para o desenvolvimento do Ruby, e também tentei oferecer soluções e formas de pensar em outras alternativas além do que já é o tradicional.
Eu gostaria de ver a nossa comunidade realmente formada por mais programadores Ruby e não somente programadores Rails, e acredito que esse é o melhor momento para isso acontecer, algumas coisas devem ser deixadas para trás e devemos buscar a inovação e evolução através de todo conhecimento adquirido, e aplicar esse conhecimento através das novas ferramentas mais específicas e mais escaláveis.
Eu acredito que o Rails ainda continua sendo relevante, grandes empresas ainda irão manter o Rails como seu framework principal, porém acredito que o tempo irá contar melhor como as coisas vão acontecer, acredito que seja natural as coisas irem migrando aos poucos para outras tecnologias que oferecem maior estabilidade, mais performance e menor custo e produtividade compatível com a que o Rails oferece, tá na hora de a comunidade Ruby off Rails aparecer mais e continuar construindo ferramentas incríveis!

OBS: Minha intenção não é mesmo criar flamewar, se você veio aqui pra isso pode até tentar, mas não vai rolar. Agora se por outro lado você tiver afim de discutir de forma sadia, vamos que vamos!



Referências

Alguns posts que acho que vale a pena a leitura para qualquer Rubista, cada um deles apresenta argumentos bem válidos e acredito que podem ajudar a abrir a cabeça de quem ler, seja para apontar os problemas do Rails, ou então para glorificar as vitórias até aqui.

The Ruby Community the next version by Adam Hawkins

The Ruby Community and Reputation by Fabio Akita

Ruby Reputation by Alan Bradburne

The Rails Culture and The Rails way

Moving on from Rails by Adam Hawkins

Ruby Current Status in Railshurts

My time with Rails is up

8 Things I Learned during 8 years of Ruby and Rails

Why I wouldnot use Rails for a new Company by Jared Friedman founder of Scribd

Rails has won the Elephant in the Room by Fabio Akita

Rails perfomance and the root of all evil

Let Asset Pipeline Die

My experiencies off Rails

Quando utilizar Ruby on Rails

Parse.com blog: How we moved our API from Ruby to Go and saved our sanity

Comments