[{"_1":2,"_427":-5,"_428":-5},"loaderData",{"_3":4,"_37":-5,"_38":39,"_346":347,"_425":-5,"_426":-5},"root",{"_5":-5,"_6":-5,"_7":8,"_22":-5,"_23":24,"_25":26,"_29":30,"_35":36},"user","shoppingCartId","shoppingCart",{"_9":10,"_11":12,"_13":14,"_15":16,"_17":18,"_19":20,"_21":14},"id","no-cart","count",0,"free",true,"updatedAt","2026-01-27T11:03:05.099Z","paymentGateway","STRIPE","cartItems",[],"loading","toast","locale","en","constants",{"_27":28},"paypalClientId","AX53Cwz8jR6rVVzzZiZNWWXl0dGagi-GZrjG-S3Ua14E5nrKMn7DxDQ730O4R8LusLPp49ALn6aRVaEy","publishers",{"_31":32,"_33":34},"companies",[],"universities",[],"needsLocaleCookieSync",false,"routes/_store+/_readers+/read_/route","routes/_store+/_readers+/read_.$slug/route",{"_40":41,"_66":67,"_312":313,"_344":36,"_345":-7},"book",{"_42":43,"_44":45,"_46":47,"_48":49,"_52":53,"_55":56,"_64":65},"title","Ruby Web Dev: The Other Way","slug","rwdtow","metaText","When Rails is not enough! An attempt to describe the way to build the Ruby web app with a real understanding of each component with relevant knowledge.","coverFeatured",{"_50":51},"url","https://d2sofvawe08yqg.cloudfront.net/rwdtow/s_featured?1620540848&1620540848","coverFeatured2x",{"_50":54},"https://d2sofvawe08yqg.cloudfront.net/rwdtow/s_featured2x?1620540848&1620540848","authors",[57],{"_9":58,"_59":60,"_5":61},"Z2lkOi8vbGVhbnB1Yi9TdG9yZTo6UHJvZHVjdEF1dGhvci8yODAwNQ","name","Yevhen Kuzminov",{"_62":63},"username","iJackUA","showReadLinkString","full","parts",[68],{"_42":43,"_69":70,"_71":12,"_72":73},"description","","fileCount","chapters",[74,99,103,116,120,139,159,163,167,171,175,179,183,187,212,216,220,224,228,232,248,252,256,281,288,292,296,300,304,308],{"_75":76,"_42":77,"_78":79,"_71":80,"_81":82,"_89":-5},"level",2,"Intro","path","#leanpub-auto-intro",1,"subsections",[83,90,93,96],{"_75":84,"_42":85,"_69":-5,"_78":86,"_71":80,"_87":-5,"_88":-5,"_89":-5},3,"Why not “Ruby On Rails” and not “The Right Way”?","#leanpub-auto-why-not-ruby-on-rails-and-not-the-right-way","quizType","sectionNum","youtubeId",{"_75":84,"_42":91,"_69":-5,"_78":92,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Damaged ecosystem","#leanpub-auto-damaged-ecosystem",{"_75":84,"_42":94,"_69":-5,"_78":95,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Manifesto","#leanpub-auto-manifesto",{"_75":84,"_42":97,"_69":-5,"_78":98,"_71":80,"_87":-5,"_88":-5,"_89":-5},"You can help here","#leanpub-auto-you-can-help-here",{"_75":76,"_42":100,"_78":101,"_71":80,"_81":102,"_89":-5},"My Dream Stack","#leanpub-auto-my-dream-stack",[],{"_75":76,"_42":104,"_78":105,"_71":80,"_81":106,"_89":-5},"Ground knowledge","#leanpub-auto-ground-knowledge",[107,110,113],{"_75":84,"_42":108,"_69":-5,"_78":109,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Web","#leanpub-auto-web",{"_75":84,"_42":111,"_69":-5,"_78":112,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Linux","#leanpub-auto-linux",{"_75":84,"_42":114,"_69":-5,"_78":115,"_71":80,"_87":-5,"_88":-5,"_89":-5},"IDE","#leanpub-auto-ide",{"_75":76,"_42":117,"_78":118,"_71":80,"_81":119,"_89":-5},"Gems","#leanpub-auto-gems",[],{"_75":76,"_42":121,"_78":122,"_71":80,"_81":123,"_89":-5},"Ruby on Rails","#leanpub-auto-ruby-on-rails",[124,127,130,133,136],{"_75":84,"_42":125,"_69":-5,"_78":126,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Confusing environments","#leanpub-auto-confusing-environments",{"_75":84,"_42":128,"_69":-5,"_78":129,"_71":80,"_87":-5,"_88":-5,"_89":-5},"You don’t need ActiveRecord for every kind of model","#leanpub-auto-you-dont-need-activerecord-for-every-kind-of-model",{"_75":84,"_42":131,"_69":-5,"_78":132,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Before filter/action","#leanpub-auto-before-filteraction",{"_75":84,"_42":134,"_69":-5,"_78":135,"_71":80,"_87":-5,"_88":-5,"_89":-5},"HTML helpers. Decorators.","#leanpub-auto-html-helpers-decorators",{"_75":84,"_42":137,"_69":-5,"_78":138,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Active Job and business logic","#leanpub-auto-active-job-and-business-logic",{"_75":76,"_42":140,"_78":141,"_71":80,"_81":142,"_89":-5},"Alternative frameworks","#leanpub-auto-alternative-frameworks",[143,146,150,153,156],{"_75":84,"_42":144,"_69":-5,"_78":145,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Full-featured","#leanpub-auto-full-featured",{"_75":147,"_42":148,"_69":-5,"_78":149,"_71":80,"_87":-5,"_88":-5,"_89":-5},4,"Hanami.rb","#leanpub-auto-hanamirbhttphanamirborg",{"_75":84,"_42":151,"_69":-5,"_78":152,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Specialized","#leanpub-auto-specialized",{"_75":147,"_42":154,"_69":-5,"_78":155,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Grape","#leanpub-auto-grapehttpwwwruby-grapeorg",{"_75":84,"_42":157,"_69":-5,"_78":158,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Mini","#leanpub-auto-mini",{"_75":76,"_42":160,"_78":161,"_71":80,"_81":162,"_89":-5},"Architecture","#leanpub-auto-architecture",[],{"_75":76,"_42":164,"_78":165,"_71":80,"_81":166,"_89":-5},"Dependency Injection and IoC containers","#leanpub-auto-dependency-injection-and-ioc-containers",[],{"_75":76,"_42":168,"_78":169,"_71":80,"_81":170,"_89":-5},"The magical world of Metaprogramming","#leanpub-auto-the-magical-world-of-metaprogramming",[],{"_75":76,"_42":172,"_78":173,"_71":80,"_81":174,"_89":-5},"Mixin/Module include - it is not composition","#leanpub-auto-mixinmodule-include---it-is-not-composition",[],{"_75":76,"_42":176,"_78":177,"_71":80,"_81":178,"_89":-5},"Document your code","#leanpub-auto-document-your-code",[],{"_75":76,"_42":180,"_78":181,"_71":80,"_81":182,"_89":-5},"SQL","#leanpub-auto-sql",[],{"_75":76,"_42":184,"_78":185,"_71":80,"_81":186,"_89":-5},"Debug","#leanpub-auto-debug",[],{"_75":76,"_42":188,"_78":189,"_71":80,"_81":190,"_89":-5},"Tests","#leanpub-auto-tests",[191,194,197,200,203,206,209],{"_75":84,"_42":192,"_69":-5,"_78":193,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Unit tests","#leanpub-auto-unit-tests",{"_75":84,"_42":195,"_69":-5,"_78":196,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Test Behavior, not Configuration","#leanpub-auto-test-behavior-not-configuration",{"_75":84,"_42":198,"_69":-5,"_78":199,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Integration tests","#leanpub-auto-integration-tests",{"_75":84,"_42":201,"_69":-5,"_78":202,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Test data: Fixtures vs Factories","#leanpub-auto-test-data-fixtures-vs-factories",{"_75":84,"_42":204,"_69":-5,"_78":205,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Stub external services call","#leanpub-auto-stub-external-services-call",{"_75":84,"_42":207,"_69":-5,"_78":208,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Speed-up test","#leanpub-auto-speed-up-test",{"_75":84,"_42":210,"_69":-5,"_78":211,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Learn Tests Design","#leanpub-auto-learn-tests-design",{"_75":76,"_42":213,"_78":214,"_71":80,"_81":215,"_89":-5},"Authentication & Authorization","#leanpub-auto-authentication--authorization",[],{"_75":76,"_42":217,"_78":218,"_71":80,"_81":219,"_89":-5},"Know your App Server!","#leanpub-auto-know-your-app-server",[],{"_75":76,"_42":221,"_78":222,"_71":80,"_81":223,"_89":-5},"Know your CLI!","#leanpub-auto-know-your-cli",[],{"_75":76,"_42":225,"_78":226,"_71":80,"_81":227,"_89":-5},"Admin","#leanpub-auto-admin",[],{"_75":76,"_42":229,"_78":230,"_71":80,"_81":231,"_89":-5},"Templates","#leanpub-auto-templates",[],{"_75":76,"_42":233,"_78":234,"_71":80,"_81":235,"_89":-5},"Cache","#leanpub-auto-cache",[236,239,242,245],{"_75":84,"_42":237,"_69":-5,"_78":238,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Static content","#leanpub-auto-static-content",{"_75":84,"_42":240,"_69":-5,"_78":241,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Dynamic content","#leanpub-auto-dynamic-content",{"_75":84,"_42":243,"_69":-5,"_78":244,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Nginx page microcache","#leanpub-auto-nginx-page-microcache",{"_75":84,"_42":246,"_69":-5,"_78":247,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Application level key-value cache","#leanpub-auto-application-level-key-value-cache",{"_75":76,"_42":249,"_78":250,"_71":80,"_81":251,"_89":-5},"Fulltext search","#leanpub-auto-fulltext-search",[],{"_75":76,"_42":253,"_78":254,"_71":80,"_81":255,"_89":-5},"Style guide and style checker","#leanpub-auto-style-guide-and-style-checker",[],{"_75":76,"_42":257,"_78":258,"_71":80,"_81":259,"_89":-5},"Frontend","#leanpub-auto-frontend",[260,263,266,269,272,275,278],{"_75":84,"_42":261,"_69":-5,"_78":262,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Sad but true story…","#leanpub-auto-sad-but-true-story",{"_75":84,"_42":264,"_69":-5,"_78":265,"_71":80,"_87":-5,"_88":-5,"_89":-5},"HTML / CSS","#leanpub-auto-html--css",{"_75":84,"_42":267,"_69":-5,"_78":268,"_71":80,"_87":-5,"_88":-5,"_89":-5},"JavaScript","#leanpub-auto-javascript",{"_75":147,"_42":270,"_69":-5,"_78":271,"_71":80,"_87":-5,"_88":-5,"_89":-5},"jQuery","#leanpub-auto-jquery",{"_75":147,"_42":273,"_69":-5,"_78":274,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Debug JavaScript","#leanpub-auto-debug-javascript",{"_75":147,"_42":276,"_69":-5,"_78":277,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Server-side rendered JS","#leanpub-auto-server-side-rendered-js",{"_75":147,"_42":279,"_69":-5,"_78":280,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Modern JavaScript","#leanpub-auto-modern-javascript",{"_75":76,"_42":282,"_78":283,"_71":80,"_81":284,"_89":-5},"Performance","#leanpub-auto-performance",[285],{"_75":84,"_42":286,"_69":-5,"_78":287,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Benchmarks","#leanpub-auto-benchmarks",{"_75":76,"_42":289,"_78":290,"_71":80,"_81":291,"_89":-5},"Deployment and Server","#leanpub-auto-deployment-and-server",[],{"_75":76,"_42":293,"_78":294,"_71":80,"_81":295,"_89":-5},"Web Application Security","#leanpub-auto-web-application-security",[],{"_75":76,"_42":297,"_78":298,"_71":80,"_81":299,"_89":-5},"Stay open-minded, stay hungry!","#leanpub-auto-stay-open-minded-stay-hungry",[],{"_75":76,"_42":301,"_78":302,"_71":80,"_81":303,"_89":-5},"Community","#leanpub-auto-community",[],{"_75":76,"_42":305,"_78":306,"_71":80,"_81":307,"_89":-5},"Follow great Ruby developers","#leanpub-auto-follow-great-ruby-developers",[],{"_75":76,"_42":309,"_78":310,"_71":80,"_81":311,"_89":-5},"Books","#leanpub-auto-books",[],"toc",[314,83,90,93,96,315,316,107,110,113,317,318,124,127,130,133,136,319,143,146,150,153,156,320,321,322,323,324,325,326,327,191,194,197,200,203,206,209,328,329,330,331,332,333,236,239,242,245,334,335,336,260,263,266,269,272,275,278,337,285,338,339,340,341,342,343],{"_75":76,"_42":77,"_69":-5,"_78":79,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":100,"_69":-5,"_78":101,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":104,"_69":-5,"_78":105,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":117,"_69":-5,"_78":118,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":121,"_69":-5,"_78":122,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":140,"_69":-5,"_78":141,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":160,"_69":-5,"_78":161,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":164,"_69":-5,"_78":165,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":168,"_69":-5,"_78":169,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":172,"_69":-5,"_78":173,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":176,"_69":-5,"_78":177,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":180,"_69":-5,"_78":181,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":184,"_69":-5,"_78":185,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":188,"_69":-5,"_78":189,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":213,"_69":-5,"_78":214,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":217,"_69":-5,"_78":218,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":221,"_69":-5,"_78":222,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":225,"_69":-5,"_78":226,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":229,"_69":-5,"_78":230,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":233,"_69":-5,"_78":234,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":249,"_69":-5,"_78":250,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":253,"_69":-5,"_78":254,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":257,"_69":-5,"_78":258,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":282,"_69":-5,"_78":283,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":289,"_69":-5,"_78":290,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":293,"_69":-5,"_78":294,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":297,"_69":-5,"_78":298,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":301,"_69":-5,"_78":302,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":305,"_69":-5,"_78":306,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":309,"_69":-5,"_78":310,"_71":80,"_87":-5,"_88":-5,"_89":-5},"isUnavailableOnline","unavailableMessage","routes/_store+/_readers+/read_.$slug.$chapterId/route",{"_42":43,"_348":349,"_40":350,"_422":418,"_423":424},"content","

Stay open-minded, stay hungry!

Learn other languages to get fresh ideas and orthogonal points of view. Try to learn languages with completely different paradigms, e.g. functional languages. It changes the way you look at object-oriented languages and approaches (and no, I am not saying that you need to abandon OOP).

",{"_351":352,"_42":43,"_46":47,"_44":45,"_64":65,"_353":354,"_421":349},"previewContent","

\n Intro\n
- \n Why not “Ruby On Rails” and not “The Right Way”?\n
- \n Damaged ecosystem\n
- \n Manifesto\n
- \n You can help here\n
\n
\n My Dream Stack\n
\n Ground knowledge\n
- \n Web\n
- \n Linux\n
- \n IDE\n
\n
\n Gems\n
\n Ruby on Rails\n
- \n Confusing environments\n
- \n You don’t need ActiveRecord for every kind of model\n
- \n Before filter/action\n
- \n HTML helpers. Decorators.\n
- \n Active Job and business logic\n
\n
\n Alternative frameworks\n
- \n Full-featured\n
  - \n Hanami.rb\n
  \n
- \n Specialized\n
  - \n Grape\n
  \n
- \n Mini\n
\n
\n Architecture\n
- \n \n
  - \n Trailblazer\n
  - \n ROM.rb (Ruby Object Mapper)\n
  - \n dry-rb\n
  - \n Rectify\n
  - \n Learn OOP design\n
  \n
\n
\n Dependency Injection and IoC containers\n
\n The magical world of Metaprogramming\n
\n Mixin/Module include - it is not composition\n
\n Document your code\n
\n SQL\n
\n Debug\n
\n Tests\n
- \n Unit tests\n
- \n Test Behavior, not Configuration\n
- \n Integration tests\n
- \n Test data: Fixtures vs Factories\n
- \n Stub external services call\n
- \n Speed-up test\n
- \n Learn Tests Design\n
\n
\n Authentication & Authorization\n
\n Know your App Server!\n
\n Know your CLI!\n
\n Admin\n
\n Templates\n
\n Cache\n
- \n Static content\n
- \n Dynamic content\n
- \n Nginx page microcache\n
- \n Application level key-value cache\n
\n
\n Fulltext search\n
\n Style guide and style checker\n
\n Frontend\n
- \n Sad but true story…\n
- \n HTML / CSS\n
- \n JavaScript\n
  - \n jQuery\n
  - \n Debug JavaScript\n
  - \n Server-side rendered JS\n
  - \n Modern JavaScript\n
  \n
\n
\n Performance\n
- \n Benchmarks\n
\n
\n Deployment and Server\n
- \n \n
  - \n VPS, Dedicated server\n
  - \n PaaS\n
  - \n CI\n
  - \n DevOps\n
  - \n Local development\n
  - \n Local tunnels. Exposing dev env in the Internet\n
  - \n Protect non-production servers with HTTP Auth\n
  \n
\n
\n Web Application Security\n
\n Stay open-minded, stay hungry!\n
\n Community\n
\n Follow great Ruby developers\n
\n Books\n

Intro

\n\n

This guide is born out of the question: “could you write a list of all the things that a good Ruby on Rails developer should know?” I decided to expand it to the whole of Ruby web development, and related “full stack” skills, but also limit it to the web, as it is not about Ruby in general.

\n\n

This guide contains sections dedicated to very important aspects of web development, explanation (if needed), and lists of tutorial links. The format and advice is inspired by “PHP The Right Way”.

\n\n

Sometimes I will suggest tools or gems (with comparison if possible), but these are merely suggestions to get you started. It is up to you, the reader, to decide whether you would like to use them or not.

\n\n

\n
Important notice: All suggestions in this guide are my personal opinion. They do not represent absolute truth or generally-accepted best practices. My goal is simply to make suggestions based on my experience.
\n\n
This guide is not a complete tutorial. Clear steps like installing Ruby (via rbenv or rvm), managing dependencies via Bundler, etc., are not described due to the wide coverage of these topics in other tutorials. If I do not mention a particular topic, that means I am not aware of any specific issues with it. If it works for you, then it’s fine.
\n

\n\n

Why not “Ruby On Rails” and not “The Right Way”?

\n\n

I am glad you are asking! :)

\n\n

It is no secret that most Ruby web developers are introduced to Ruby via Rails. This is a double-edged sword. It lowers the barrier to entry, but it also narrows the range of knowledge acquired by junior level developers. This guide contains a special Ruby on Rails section to cover Rails-specific things, and hopefully it will encourage you to look outside of Rails and the “Rails Way.” I can’t call the approach described here “The Right Way,” as it is just another way to look at Ruby web development.

\n\n

Damaged ecosystem

\n\n

The main issue, that forced me to start writing, is unconscious feeling, that something is not perfect with the Rails Way. Attempts to change the behavior or add more structure had no luck. When you introduce a new part into your Rails app - it results in a tension and even active resistance (of the codebase and teammates).

\n\n

The whole eco-system is deeply damaged by Rails in terms of code and mindset of developers. And yes there are no real competitors, only because of Rails is so huge in the room of Ruby, that it requires enormous forces to rise a competitor.

\n\n

It results in no pluralism of ideas, no real code reusability, as most gems are made solely for Rails (and it is the real pain to customize them). Exactly because of this “it is so hard to write Ruby web app without Rails”.

\n\n

This guide is an attempt to describe the way to build the web app with a real understanding of each component, with knowledge that is relevant in any web language and framework. To become a better web developer and demand for a better ecosystem!

\n\n

Manifesto

\n\n

prefer simple solutions
configuration over confusion
boilerplate over magic

\n\n

You can help here

\n\n

I am open to questions, suggestions, and critique based on the contents of this guide.

\n\n

You can participate by opening a discussion issue on GitHub or joining the Gitter chat.

\n\n

I am not a native English speaker, so the verbiage here may be far from perfect. Please contribute with your proofreading and typographical fixes via pull requests in GitHub.

\n\n

Share this guide if you consider it useful. Please use the #RWDTOW hashtag on social media.

\n\n\n

My Dream Stack

\n\n

Before I start with any detailed descriptions, let us have a brief look at the “ideal” Ruby web application stack that I am trying to achieve in my work. Not everything is available yet, but “viam supervadet vadens” â€“ a journey of a thousand miles begins with a single step.

\n\n

Linux based OS with RubyMine IDE
PostgreSQL DB and Redis cache
Hanami.rb framework, to have a full-featured framework with as little magic as possible
Trailblazer to organize business logic and reusable widgets, plus handle JSON API conversions
Dependency injection in Ruby code
Minitest and Capybara for testing, with clear OOP approaches instead of a DSL
Vue.js + ES6/WebPack for rich JavaScript pages
Docker for local development and production deployment

\n\n\n

Ground knowledge

\n\n

Web

It is a shame that many developers do not understand the fundamentals of web development. We are creating web apps without even knowing how the Internet (or the web) works. That’s why junior developers do not understand what params are and what triggers the different types of HTTP requests. The result is that often a junior developer has a weak foundation in fundamental web principles and largely understands programming as some sort of magic. Unfortunately, with a rails-centric education in programming, a junior developer relies more on the “magic” of rails than an understanding of programming.

\n\n

If you feel confident in your basic web knowledge and want to dive deeper in all aspects, read the free ebook High-Performance Browser Networking.

\n\n

\n
This book provides a hands-on overview of what every web developer needs to know about the various types of networks (WiFi, 3G/4G), transport protocols (UDP, TCP, and TLS), application protocols (HTTP/1.1, HTTP/2), and APIs available in the browser (XHR, WebSocket, WebRTC, and more) to deliver the best, fast, reliable, and resilientâ€”user experience.
\n

\n\n

High-Performance Browser Networking by Ilya Grigorik

\n\n

Linux

A lot of us come to web development with Windows desktops. But even if Ruby can be installed on Windows, I recommend using a Linux/Unix based machine for Ruby development. Either a machine running a dedicated Linux/Unix OS or a virtual machine running Linux/Unix in Windows works just fine. The world of web servers (VPS) is all about Linux, so it is a good idea to be very familiar with Linux and be able to perform basic Linux tasks, performance tuning, and advanced web server setup for your application within a Linux environment.

\n\n

Ubuntu
DistroWatch TOP

\n\n

IDE

You can write Ruby code in any text editor, but using a more sophisticated IDE increases productivity.

\n\n

Editors like SublimeText and Atom require some additional plugin setup

\n\n

The most full-featured IDE is RubyMine, but it is not free.\nDue to the dynamic nature of Ruby, it is hard for IDEs to do correct autocompletion most of the time. This is why RubyMine is not as powerful as similar IDEs for other languages, but it still provides quite a lot of additional integrated tools.

\n\n

\n\n\n

Gems

\n\n

Before adding any utility gem to the project, try to search for alternatives, and be sure that you chose a minimal solution â€“ one that still has developer support and a community contributing to it. It is also useful to browse through curated “awesome” lists.

\n\n

The Ruby Toolbox
Curated Awesome Ruby List

\n\n

Be aware! Don’t be gem obsessed! Most of the time, you can write the code on your own, without any gems. Your own code is much easier to customize, polish, and build into your architecture. It does only what it is supposed to do, with no ballast.

\n\n

If you do decide to use a gem, look at the code inside it and try to understand what it does, and how it is implemented. A lot of gem links provided in this guide show you the most popular solution (which is usually not the simplest solution) and examples of simpler, better solutions for the topic. Investigating other people’s open source code gives you a few advantages:

\n\n

you can learn how to do something from other good coders
you don’t need documentation for the gem (if the code is clear), as you can see the public interface and usage logic
or you discover that the gem is so bad and unoptimized that you definitely need to throw it away, and write your own implementation (and you already know at least one way NOT to do it)

\n\n\n

Ruby on Rails

\n\n

\n
Most Rails developers do not write object-oriented Ruby code. They write MVC-oriented Ruby code by putting models and controllers in the expected locations. Most will add utility modules with class-methods in lib/, but that’s it. It takes 2-3 years before developers realize: “Rails is just Ruby. I can create simple objects and compose them in ways that Rails does not explicitly endorse!”\n– Mike Perham
\n

\n\n

RoR is a good starting point for a young web developer, but it is important that our education does not end there. Learn to separate what is pure Ruby and what is Rails. Correctly recognize architectural and design issues that appear in your app, and that most of these issues are caused by misusing oversimplified approaches from Rails.

\n\n

TODO: Add more points to be aware of in Rails

\n\n

Confusing environments

\n\n

Rails comes with the following ways to alter config according to the environment:

\n\n

Environment initializers (in the config/environments folder)
YAML inheritance
\nENV variables
Or you can replace config files on deploy

\n\n

Often, all of these approaches are mixed without any separation or consideration.\nThey can usually all be replaced by ENV vars that change the value of primitive configs and env initializers, to make bigger structural changes in initialization flow.

\n\n

You don’t need ActiveRecord for every kind of model

\n\n

What Rails teaches you first is to model data with AR classes, and that works great while you are following “The Rails Way.” Unfortunately, that teaches us to think that model structure is inseparable from the persistence layer (literally from the DB table structure).

\n\n

That causes issues:

\n\n

All data that is not saved to the DB flows into the app as primitive data structures (e.g. Array of Hashes).
There is a tendency to structure data in a way that is easy to map into a relational DB, rather than a way that clearly reflects the business logic.
Anything that is not an AR class is put into the lib folder.

\n\n

It is an open secret: even a PORO can be a model, if it encapsulates the data and actions of an entity. Models are not required to have find and save actions (those are merely the Active Record pattern. Recognize it!). You can, and ideally should, separate models as data containers from other classes that handle persistence. It does not matter whether we get/save it via a DB, or get/send it via a REST API.

\n\n

Before filter/action

\n\n

The main purpose of the before_action hook is to authorize the call to the action – literally, to decide to allow this user to run the action or not. But often we can find “pre-population” code like this:

\n\n

 1 before_filter :find_item, only: [:update, :show, :edit]\n 2 before_action :authenticate_user!\n 3 \n 4 def show\n 5 end\n 6 \n 7 private\n 8 def find_item\n 9   @item = Item.find(params[:id])\n10 end\n

\n\n\n\n

Firstly, there is no difference between before_filter and before_action. They are aliases, and before_filter is deprecated in Rails 5.0.

\n\n

Secondly, do you think this is DRY? No. It is misleading when you forget what @variables are available in what actions/views.\nBe explicit in such cases:

\n\n

 1   before_action :authenticate_user!\n 2 \n 3   def show\n 4     @item = find_item(params[:id])\n 5   end\n 6 \n 7   private\n 8   def find_item(id)\n 9     Item.find(id)\n10   end\n

\n\n\n\n

This does not violate the DRY principle, even if you repeat the find_item call 10 times in different actions.

\n\n

HTML helpers. Decorators.

\n\n

This is the first place where young RoR developers put their view helper code. It is fine to do things like this, in the very beginning.

\n\n

1 module ApplicationHelper\n2   def page_title(title)\n3     title += \" | \" if title.present?\n4     title += \"My Site\"\n5   end\n6 end\n

\n\n\n\n

Unfortunately, helpers become overcomplicated very quickly with:

\n\n

a lot of semi-domain logic
mixed responsibilities
being included into controllers (because you also want to do some semi-domain logic in controller)
a lot of HTML concatenation

\n\n

I almost consider global view helpers as an antipattern which leads to messy code. The solution is to apply the Decorator pattern approach, with view helpers encapsulated in specialized Decorator classes, and helpers that generate a lot of HTML using partials with ERB instead of HTML string concatenation.

\n\n

A Decorator could be as simple as this:

\n\n

 1 class Coffee\n 2   def cost\n 3     2\n 4   end\n 5 \n 6   def origin\n 7     \"Colombia\"\n 8   end\n 9 end\n10 \n11 require 'delegate'\n12 \n13 class Decorator < SimpleDelegator\n14   def class\n15     __getobj__.class\n16   end\n17 end\n18 \n19 class Sugar < Decorator\n20   def cost\n21     super + 0.2\n22   end\n23 end\n24 \n25 class Milk < Decorator\n26   def cost\n27     super + 0.4\n28   end\n29 end\n30 \n31 coffee = Coffee.new\n32 Sugar.new(Milk.new(coffee)).cost   # 2.6\n33 Sugar.new(Sugar.new(coffee)).cost  # 2.4\n34 Milk.new(coffee).origin            # Colombia\n35 Sugar.new(Milk.new(coffee)).class  # Coffee\n

\n\n\n\n

Or it could be something more sophisticated, like the functionality provided in the Drapper or Disposable::Twin gems.

\n\n

Active Job and business logic

\n\n

Active Job is a very convenient tool, but it is very easy to write unmaintainable code with it. When you put your actual job logic inside process method it is very hard to test this logic and impossible to reuse without the Active Job context.

\n\n

The main idea that is hidden behind Active Job - it is an application-framework boundary, where the framework got data from to “external world” and transfer these data to you application code. It should follow the same rules as the controller does. If you follow the idea of “skinny controller”, you should also apply the “skinny job” principle. It should not contain SQL queries or business logic manipulations inside but just call to model or operation object.

\n\n

Look at the following similarities of ActiveJob::process and Controller::[action_name] classes:

\n\n

it is the first entry point where your code naturally “gets the wheel” and where you can do all the manipulations
this method receives parameters from the “outside worlds”
browser and job queue - are representatives of the “outside world”
controller and job classes do parsing and unification of params for your code

\n\n

Your job should look as simple as this:

\n\n

1 class BigComplexJob < ApplicationJob\n2   queue_as :default\n3 \n4   def perform(*params)\n5     MyComplexLogicClass.do_a_lot_of_work(params)\n6   end\n7 end\n

\n\n\n\n

And you cover MyComplexLogicClass with simple Unit tests with the whole set of params conditions.

\n\n

Another aspect is a job queue backend. Delayed Job seems to be a good starting point as it does not require additional infrastructure, just a database. But it quickly became a bottleneck if you have a lot of quick jobs. Redis (im-memory storage) based solutions should be used as more reliable and performant alternatives: Resque or Sidekiq.

\n\n\n

Alternative frameworks

\n\n

The Ruby ecosystem does not end at Ruby on Rails. There are a number of alternative frameworks which excel in different areas or provide a more lightweight way to build web apps.\nHere are some of the most notable:

\n\n

Full-featured

\n\n

Hanami.rb

\n\n

Hanami proposes a cleaner approach with less metaprogramming than Rails. Some interesting architectural decisions are: multi-app architecture with shared parts (that delays and simplifies the decision to break your app into smaller parts), data mapper/entity-repository approach for the persistence layer, separated actions, explicit exposition of variables for views, and more.

\n\n

What is Hanami? Where is it going?

\n\n

Specialized

\n\n

Grape

\n\n

Grape is an opinionated framework for creating REST-like APIs in Ruby. It has built-in support for common conventions, including: multiple formats, subdomain/prefix restriction, content negotiation, versioning, and much more. All these elements are described via a simple DSL.

\n\n

Mini

\n\n

The Mini framework focuses on providing a web request routing layer and leaves everything else to us. All Ruby web frameworks support, or are based on, Rack - a minimal interface for Ruby webservers, which standardizes how web requests are handled. Rack allows us to create a chain of “middlewares” (small specific handlers) that give us many basic things such as variable parsing, cookie and session management, etc â€“ things that we tend to consider as a “given.”

\n\n

dry-web
Padrino
Rack
Roda
Sinatra

\n\n\n

Architecture

\n\n

MVC is not an app architecture. This may not be obvious due to the reign of MVC-based frameworks, which teach us to use routing + model + view rendering as the way to build web apps. Unfortunately, business logic has no place in this list.

\n\n

The “fat model, skinny controller” approach does not solve the issue either. It just sweeps the dust under the carpet, and you will still suffer from fat models used in numerous contexts. Changing code for one usage context will break another usage context.

\n\n

As a general rule in OOP code, you should break code into smaller classes with smaller responsibilities. Ideally, this code should follow SOLID principles (Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion).

\n\n

In the book “Practical Object-Oriented Design in Ruby: An Agile Primer,” Sandi Metz proposes that just being SOLID is not enough – code should also be TRUE.

\n\n

\n
If you define easy to change as
\n\n
\n
Changes have no unexpected side effects
\n
Small changes in requirements require correspondingly small changes in code
\n
Existing code is easy to reuse
\n
The easiest way to make a change is to add code that in itself is easy to change.
\n
\n\n
Then the code you write should have the following qualities. Code should be
\n\n
\n
\nTransparent - The consequences of change should be obvious in the code that is changing, and in the distant code that relies upon it.
\n
\nReasonable - The cost of any change should be proportional to the benefits the change achieves.
\n
\nUsable - Existing code should be usable in new and unexpected contexts.
\n
\nExemplary - The code itself should encourage those who change it to perpetuate these qualities.
\n
\n

\n\n

TODO: Describe approaches like Form Model, Service Object, Context

\n\n

Trailblazer

\n\n

Trailblazer is a powerful architectural framework. It can be used with any Ruby web framework, and has special adapters for Rails. It provides the missing pieces to organize business logic.

\n\n

Operations are composable entities that encapsulate an action with a context, validations, and permission checks. Almost everything you would normally write in the controller should be placed here.
Active Record models are only used for simple finding, saving, and managing relations. They are limited to a single responsibility: data persistence operations.
Forms are provided per operation, unbound from the single context of a Fat Model.
Cells are small, encapsulated pieces of reusable view logic. They replace messy app helpers.
Representers describe presentation rules for serializing and deserializing documents. These are used in a variety of places, from the internal parameter representation of Operations to the representation of data in a JSON API.

\n\n

Operation example

\n\n

 1 # CRUD action Operation\n 2 class Comment::Create < Trailblazer::Operation\n 3   include Model\n 4   model Comment, :create\n 5 \n 6   contract do\n 7     property :body, validates: {presence: true}\n 8   end\n 9 \n10   def process(params)\n11     validate(params[:comment]) do\n12       contract.save\n13     end\n14   end\n15 end\n16 \n17 # Run Operation\n18 op = Comment::Create.(comment: {body: \"MVC is so 90s.\"})\n19 # Get a Model from it\n20 model = op.model\n

\n\n\n\n

Cell example

\n\n

 1 #Cell class\n 2 class Comment::Cell < Cell::ViewModel\n 3     property :body\n 4     property :author\n 5 \n 6     def show\n 7       render\n 8     end\n 9 \n10   private\n11     def author_link\n12       link_to author.email, author_path(author)\n13     end\n14   end\n15 \n16 # Template\n17 - # app/concepts/comment/views/show.haml\n18   %li\n19     = body\n20     By #{author_link}\n21 \n22 # Testing\n23   describe Comment::Cell do\n24     it do\n25       html = concept(\"comment/cell\", Comment.find(1)).()\n26       expect(html).to have_css(\"h1\")\n27     end\n28   end\n

\n\n\n\n

Representable example

\n\n

 1 # Class\n 2 class SongRepresenter < Representable::Decorator\n 3   include Representable::JSON\n 4 \n 5   property :id\n 6   property :title\n 7 \n 8   property :artist, decorator: ArtistRepresenter\n 9 end\n10 \n11 # Serialize\n12 SongRepresenter.new(song).to_json\n13 #=> {\"id\": 1, title\":\"Fallout\", artist:{\"id\":2, \"name\":\"The Police\"}}\n14 \n15 # Restore object\n16 song = Song.new # nothing set.\n17 \n18 SongRepresenter.new(song).\n19     from_json('{\"id\":1,title\":\"Fallout\",artist:{\"id\":2,\"name\":\"The Police\"}}')\n20 \n21 song.artist.name #=> \"The Police\"\n

\n\n\n\n

Trailblazer (#Trbr) concepts are somewhat difficult to understand and use properly at first, but they definitely make more and more sense as you become familiar with them. It is very hard to describe the whole Trailblazer philosophy in a short text. Nick Sutterer, the author of Trbr, has quite a lot of documentation with detailed descriptions, and has written a book that covers building a Rails app with Trbr, step-by-step.

\n\n

It is definitely worth a try if you want to start making your Ruby apps better.

\n\n

Trailblazer
Trailblazer Book

\n\n

ROM.rb (Ruby Object Mapper)

\n\n

Ruby Object Mapper (ROM) is a Ruby persistence library with the goal of providing powerful object mapping capabilities without limiting the full power of your datastore.

\n\n

Isolate the application from persistence details
Provide minimum infrastructure for mapping and persistence
Provide shared abstractions for lower-level components
Provide simple use of the underlying datastore when desired

\n\n

All ROM components are stand-alone – they are loosely coupled, can be used independently, and follow the single responsibility principle. A single object that handles coercion, state, persistence, validation, and the all-important business logic, rapidly becomes complex. Instead, ROM provides the infrastructure that allows you to easily create small, dedicated classes for handling each concern individually, and then tie them together in a developer-friendly way.

\n\n

1 TODO: ROM example\n

\n\n\n\n

rom-rb

\n\n

dry-rb

\n\n

Dry-rb Is a collection of next-generation Ruby libraries, each intended to encapsulate a common task while remaining decoupled and reusable.

\n\n

TODO: Add extended dry-rb gems description

\n\n

dry-rb
list of all dry gems

\n\n

Rectify

\n\n

The Rectify gem provides some lightweight classes that make it easier to build Rails applications in a more maintainable way. It is built on top of several other gems and adds improved APIs to make things easier.

\n\n

Currently, Rectify consists of the following concepts:

\n\n

Form Objects
Commands
Presenters
Query Objects

\n\n

You can use these separately or together, to improve the structure of your Rails applications.

\n\n

The main problem that Rectify tries to solve is where your logic should go. Commonly, business logic is either placed in the controller or the model, and the views are filled with too much logic as well. The opinion of Rectify is that these places are incorrect and that your models, in particular, are doing too much.

\n\n

Rectify’s opinion is that controllers should just be concerned with HTTP related things, and models should just be concerned with data relationships. The problem then becomes how and where you implement validations, queries, and other business logic.

\n\n

Using Rectify, Form Objects contain validations and represent the input data of your system. Commands then take a Form Object (as well as other data) and perform a single action, which is invoked by a controller. Query objects encapsulate a single database query, and any logic it needs. Presenters contain the presentation logic in a way that is easily testable, and keeps your views as clean as possible.

\n\n

Rectify is designed to be very lightweight and allows you to use some or all of its components. We also advise that you use these components where they make sense, not just blindly everywhere. More on that later.

\n\n

Here is an example controller that shows details about a user, and also allows a user to register an account. This creates a user, sends some emails, does some special auditing, and integrates with a third party system:

\n\n

 1 class UserController < ApplicationController\n 2   include Rectify::ControllerHelpers\n 3 \n 4   def show\n 5     present UserDetailsPresenter.new(:user => current_user)\n 6   end\n 7 \n 8   def new\n 9     @form = RegistrationForm.new\n10   end\n11 \n12   def create\n13     @form = RegistrationForm.from_params(params)\n14 \n15     RegisterAccount.call(@form) do\n16       on(:ok)      { redirect_to dashboard_path }\n17       on(:invalid) { render :new }\n18       on(:already_registered) { redirect_to login_path }\n19     end\n20   end\n21 end\n

\n\n\n\n

The RegistrationForm Form Object encapsulates the relevant data that is required for the action, and the RegisterAccount Command encapsulates the business logic of registering a new account. The controller is clean, and business logic now has a natural home:

\n\n

1 HTTP             => Controller   (redirecting, rendering, etc)\n2 Data Input       => Form Object  (validation, acceptable input)\n3 Business Logic   => Command      (logic for a specific use case)\n4 Data Persistence => Model        (relationships between models)\n5 Data Access      => Query Object (database queries)\n6 View Logic       => Presenter    (formatting data)\n

\n\n\n\n

Learn OOP design

\n\n

By learning to design small pieces – objects, in OOP – and put them together, you automatically learn how to make good app architecture overall. There is no a magical library that will suddenly make your code better. Good code comes from the combination of many tiny aspects.

\n\n

\n\n\n

Dependency Injection and IoC containers

\n\n

This technique is widely used in many programming languages, from Java to PHP and JavaScript. In brief, it removes direct dependencies from your classes, replacing them with dependencies upon abstractions instead. Concrete instances of the abstractions are “injected” in the initializer as parameters. This is Inversion of Control â€“ objects do not instantiate their own dependencies, the dependencies are provided from the outside. Alas, it can be very messy handling all the injected dependencies manually, especially when you have a cascade of dependencies. An IoC Container is that mysterious “someone” who instantiates all objects in the app. It uses class annotations to instantiate the correct dependencies to inject. The concrete classes for each abstraction are often specified in the IoC config.\nInterfaces are natural abstraction identifiers, in languages that support them, but Ruby does not have interfaces. That is why dependency-injected classes require a synthetic dependency specification in Ruby.

\n\n

Some time ago, DHH wrote a critique of DI usage in Ruby, but Piotr Solnica demonstrated reasonable examples of good DI usage. Also, Sandi Metz provides good arguments and examples in her POODR book.

\n\n

With the dry-container and dry-auto_inject libs, DI/IoC in Ruby could look something like this:

\n\n

 1 my_container = Dry::Container.new\n 2 \n 3 my_container.register(:data_store, -> { DataStore.new })\n 4 my_container.register(:user_repository, -> { container[:data_store][:users] })\n 5 my_container.register(:persist_user, -> { PersistUser.new })\n 6 \n 7 # set up your auto-injection function\n 8 AutoInject = Dry::AutoInject(my_container)\n 9 \n10 # then simply include it in your class, specifying the dependencies that\n11 # should be injected automatically from the configured container\n12 class PersistUser\n13   include AutoInject[:user_repository]\n14 \n15   def call(user)\n16     user_repository << user\n17   end\n18 end\n

\n\n\n\n

\n\n\n

The magical world of Metaprogramming

\n\n

Metaprogramming is a special feature of some languages (including Ruby) used to define code dynamically, at runtime. It is code that generates other code. This is responsible for a lot of the “magic” in Rails, for example: some_route_path helpers, and find_by_%attr_name% in ActiveRecord.

\n\n

It seems like an awesome feature at first, until it is misused, and unfortunately it is misused most of the time.\nThe downsides of metaprogramming are:

\n\n

Difficult to locate method source code.
Hidden intention in the codebase.
IDEs can’t locate these methods for auto-complete.

\n\n

There is a famous saying: “if you have a problem and think that metaprogramming could help you, then congratulations! Now you have two problems.” Many times, the coding challenges that you solve with metaprogramming could be solved in a simpler way, with better code quality, separation of concerns, and clearness.

\n\n

Here is an example of unnecessary metaprogramming in the rest-client gem:

\n\n

1 POSSIBLE_VERBS = ['get', 'put', 'post', 'delete']\n2 \n3 POSSIBLE_VERBS.each do |m|\n4   define_method(m.to_sym) do |path, *args, &b|\n5     r[path].public_send(m.to_sym, *args, &b)\n6   end\n7 end\n

\n\n\n\n

Bala Paranj: 7 Deadly Sins of Ruby Metaprogramming

\n\n\n

Mixin/Module include - it is not composition

\n\n

“Divide et impera” (Divide and rule) is a well known saying from ancient Rome. In programming, we also try to break our code into smaller parts, compose them, and reuse them. In Ruby, we can use include and extend to add methods from other modules. But just because your code is DRY does not mean it exhibits composition.

\n\n

Yes, now your class/object can respond to a new set of messages, but there is a dark side: mixins create implicit (hidden) pollution of an object’s public interface. Do these methods really belong to this class/object? You should ask yourself this question every time you use a mixin (e.g. including a Concern in Rails).

\n\n

Mixins make sense when they use the internal state of an Object (@attributes or methods of the host object). It also makes some sense to use them for static helpers that do not use the host object itself, only input parameters.

\n\n

Real composition should be based on Dependency Injection and Separation of Concerns. Your methods should be grouped by an explicit receiver (e.g not obj.a_m1, obj.a_m2, obj.b_m1, but obj.a.m1, obj.a.m2, obj.b.m1). Composition in this case literally means opting not to mixin A and B, but to inject instances of A and B, and assign them to the a and b properties inside obj. In that way, your dependencies are not hard-coded, and you can substitute them dynamically. The main advantage of this approach is that A and B are self-contained, and can be reused.

\n\n

Just think about the following use-cases, in the context of a Rails app. Do they really make sense?

\n\n

Path helpers mixed into controller/view
Application helpers mixed into controller/view

\n\n

Another issue is that mixin modules make too many assumptions about the host class interface. They expect the host class to have certain methods, or even worse, expect that the host class already includes another mixin. These expectations are completely hidden – for example, try to add the errors capability from ActiveModel into a PORO.

\n\n\n

Document your code

\n\n

Code documentation is more than just writing human-readable code comments. It is also about creating functional comments in specific formats (like RDoc or YARDOC) that are clear to other developers, and that can be interpreted by your IDE.

\n\n

Remember that this documentation can help your IDE to make correct autocompletions of returned values, and object attributes/methods.

\n\n

\n\n\n

SQL

\n\n

One of the biggest advantages of Active Record is that the developer does not need to write raw SQL queries to perform basic data manipulation in the DB. And like everything in nature, if you don’t use it, you lose it. In that way, we have a bunch of Rails developers that are scared of anything more complex than SELECT * FROM users. That is pretty depressing.

\n\n

Learn SQL and the capabilities of specific databases!
If you use Rails, open the console and try to understand what SQL is being generated for each AR query.
Do not immediately reach for the “simplest” AR code. That makes a lot of unnecessary queries (N+1 queries, etc.). Think about how the DB will be accessed. Think in SQL!
If you use Rails, use the power of AR query composition. That’s fine. You do not need to write raw SQL all the time. But when you need to compose a complex query, and do not know how to do it with AR, write it in SQL first, and then gradually transform it into AR notation.
Some queries, especially those using special abilities of the DB (like PARTITION BY, etc.), are better to leave in raw SQL. Think about other developers who will need to support this code. Some things are clearer in AR notation, some are clearer in pure SQL. Just consider the options.

\n\n

Also, consider that different databases are best suited to different use cases. One web application can make use of multiple databases simultaneously. Think about the type of data you want to operate upon. You can even combine relational DBs (PostgreSQL, MySQL) with document oriented DBs (MongoDB). For graph-like data (“friends of my friends” relations) there is another class of DB, like Neo4J. There are even multiparadigm DBs like ArangoDB.

\n\n

You should also keep an eye on the DB world. It is changing as fast as web languages and frameworks. It is up to the web developer to propose and use the best data storage solution for the situation, based on the type of data and common query patterns.

\n\n

To keep productivity high while using special features of specific databases, you can use the Sequel lib. It is very similar to ActiveRecord, but not coupled to Rails, and has a wide selection of plugins and extensions.

\n\n

Khan Academy. Intro to SQL: Querying and managing data
PostgreSQL Tutorials
PostgreSQL Exercises
PostgreSQL
MongoDB
Neo4J
ArangoDB
Sequel

\n\n\n

Debug

\n\n

Many people are creating apps without using even standard debugging techniques. We tend to stay as “puts debuggers” because it is easy, stable and reliable. But we lose a lot of troubleshooting productivity without good debugging skills. The first step is to discover the Pry (binding.pry) and Byebug (byebug) debuggers. They allow you to set a breakpoint, stop app execution there, and print out current variables on the stack. But debugging is not limited to breakpoints. The next step is learning how to walk step-by-step inside the app â€“ stepping into functions, etc.

\n\n

Great results can be achieved by combining both of these solutions with pry-byebug, which adds the navigation commands from Byebug to the Pry command line.

\n\n

The best debugging experience would be provided via a visual debugger, like in the IntelliJ RubyMine IDE. It requires an additional Gem, and the app must be run using a special launcher, but as a result you can set breakpoints and step through code right in your IDE. You can also see all the variables on the stack at each step. Such a high density of visual debug info can dramatically increase productivity, and decrease the time needed to track down an error.

\n\n

Tenderlovemaking: I am a puts debuggerer
Debugging Rails Appliction
Byebug
Pry
Ruby default debugger
IntelliJ RubyMine Visual Debugger

\n\n\n

Tests

\n\n

The Ruby community is well known for its adoption of good testing practices. For example, the PHP community is not even close the same level of understanding of the importance of testing in every stage of app development. Moreover, the average PHP developer does not write nearly as many tests as the average Ruby developer does. One of the secrets of Ruby’s testing success is its great tools. Ruby testing tools provide powerful syntax and features, made possible by metaprogramming and DSLs.

\n\n

Let’s not pat ourselves on the back too quickly, though. As always, great power comes with great responsibility. These tools are a double-edged sword. You need to recognize the good parts and the not-so-good parts, so as not to hurt yourself.

\n\n

Testing rules:

\n\n

Tests should be simple and obvious. They should not require testing, themselves.
Each test should do only one thing.
Tests should have clear assertions.
Tests should be predictable and repeatable, producing the same result on each run.

\n\n

Unit tests

\n\n

Unit tests cover code-level logic. It instantiates an object, and makes assertions on the result of a method or function call. There are two popular unit testing solutions in Ruby: Minitest and RSpec.

\n\n

RSpec is a very popular gem that provides an expressive DSL for all aspects of testing. It allows writing test in a BDD “expects” style. Its assertions tend to be human-readable, and it has lots of special extensions. However, its main advantage is also its main drawback – you need to learn a large DSL and assertion syntax. RSpec extensions make this worse, requiring you to put in quite a lot of effort to learn everything. RSpec has community-backed best practices that can be accessed on betterspecs.

\n\n

 1 RSpec.describe \"Using an array as a stack\" do\n 2   def build_stack\n 3     []\n 4   end\n 5 \n 6   before(:example) do\n 7     @stack = build_stack\n 8   end\n 9 \n10   it 'is initially empty' do\n11     expect(@stack).to be_empty\n12   end\n13 \n14   context \"after an item has been pushed\" do\n15     before(:example) do\n16       @stack.push :item\n17     end\n18 \n19     it 'allows the pushed item to be popped' do\n20       expect(@stack.pop).to eq(:item)\n21     end\n22   end\n23 end\n

\n\n\n\n

Minitest became a part of the Ruby standard library, and that is why it is preferable for testing gems and libs, as it does not require additional dependencies. It provides a very small assertions interface, that is easy to learn and adopt. The main advantage of Minitest is that tests are just POROs. That is why you do not need to learn anything new to structure your tests – it is just pure Ruby. Use the same techniques as in your other code. Code initialization and calls are almost identical to real usage.\nIMHO Minitest is the better choice for writing simple, clear and predictable tests.

\n\n

 1 class TestMeme < Minitest::Test\n 2   def setup\n 3     @meme = Meme.new\n 4   end\n 5 \n 6   def test_that_kitty_can_eat\n 7     assert_equal \"OHAI!\", @meme.i_can_has_cheezburger?\n 8   end\n 9 \n10   def test_that_it_will_not_blend\n11     refute_match /^no/i, @meme.will_it_blend?\n12   end\n13 \n14   def test_that_will_be_skipped\n15     skip \"test this later\"\n16   end\n17 end\n

\n\n\n\n

Minitest also provides a Spec style, which has a lot of RSpec syntactic sugar, but still has a dramatically simpler code base (when you look inside Minitest gem code).

\n\n

 1 describe Meme do\n 2   before do\n 3     @meme = Meme.new\n 4   end\n 5 \n 6   describe \"when asked about cheeseburgers\" do\n 7     it \"must respond positively\" do\n 8       @meme.i_can_has_cheezburger?.must_equal \"OHAI!\"\n 9     end\n10   end\n11 \n12   describe \"when asked about blending possibilities\" do\n13     it \"won't say no\" do\n14       @meme.will_it_blend?.wont_match /^no/i\n15     end\n16   end\n17 end\n

\n\n\n\n

Stay consistent, don’t write tests in different styles with Minitest. Choose the one you like the most, and write all tests in it. But remember that using Spec style with Minitest reduces its advantages, like normal Ruby syntax and usage of normal OOP techniques.

\n\n

Minitest
RSpec

\n\n

Test Behavior, not Configuration

\n\n

The shoulda-matchers gem is very popular for testing aspects of ActiveRecord model configuration, like has_one.

\n\n

1 class Person < ActiveRecord::Base\n2   has_one :partner\n3 end\n4 \n5 class PersonTest < ActiveSupport::TestCase\n6   should have_one(:partner)\n7 end\n

\n\n\n\n

But why do we need to test indirect signs of expected behavior instead of testing the behavior directly?

\n\n

We could better write behavior tests like this:

\n\n

1 class PersonTest < Minitest::Test\n2   def test_has_parter\n3     person = Person.new\n4     partner = Partner.new\n5     assert_equal partner, person.partner\n6   end\n7 end\n

\n\n\n\n

The test above will continue passing, regardless of any changes to the implementation of person.partner. This is exactly how your app expects the Person class to behave, so why should your tests be different, and rely upon the internal implementation?

\n\n

Test Behavior, not Configuration

\n\n

Integration tests

\n\n

Ruby allows you to write integration tests. These emulate the real interaction between the web app and the browser. They usually contain a set of commands to click on links, visit certain pages, fill in form fields, and validate the results of these actions.

\n\n

Integration tests can be written using the Capybara framework. Basically, it acts as a “fake browser,” making requests to your Rack app and parsing the responses, but is not capable of running JavaScript. To fully emulate an end-user browser, you need to use the Poltergeist or Capybara Webkit add-ons. They run the same commands inside a headless Webkit browser. Of course, this incurs a speed penalty. Tests with JS run slower than tests without JS. You need to be aware of that, and activate JS per test, only in the tests that require it.

\n\n

Understand that integration tests should not make assertions against the internal state of the web app. They should not make assertions on code variables, etc. They should only assert external output, like the response body and HTTP status codes.

\n\n

Also, do not overuse integration tests. Keep in mind that in any (ANY!) case, integration tests are an order of magnitude slower than unit tests. When you write bad quality code – e.g. putting a lot of logic into Controllers – the only way to test it is to visit the corresponding page. You will need to execute the whole app request cycle to test only tiny things. That should encourage you to remove logic from the controller, put it into separate classes, and just call the new classes from the controller. That way, you can test 90% of the logic via unit tests (which are fast) and make only a few “smoke tests” on the controller action (to test success/failure scenarios, but not every part of the business logic).

\n\n

Capybara
\nPoltergeist (PhantomJS)
Capybara-WebKit

\n\n

Test data: Fixtures vs Factories

\n\n

Stub external services call

\n\n

Your tests should not depend on the availability of external services. Ideally, you should be able to run all tests without Internet access, but that doesn’t mean that external integrations should not be tested.\nIf your app makes a request to an external service, this request should be stubbed. Instead of making a real call, it should “pretend” and return a ready-made response (there could be a couple of different responses, to test success/failure). Gems like Webmock and VCR can help you to catch real responses and then reuse them for subsequent test runs, or to write your own response content.

\n\n

Stub request with Webmock:

\n\n

1 stub_request(:post, \"www.example.com\")\n2     .with(:query => {'user' => 'Ievgen'})\n3     .to_return(:body => \"Nice work!\")\n

\n\n\n\n

Catch requests and return a “fake” response with VCR:

\n\n

1   VCR.use_cassette(\"synopsis\") do\n2       response = Net::HTTP.get_response(URI('http://www.iana.org/domains/reserved'))\n3       assert_match /Example domains/, response.body\n4     end\n

\n\n\n\n

\n\n

Speed-up test

To achieve fast tests, stub behavior, heavy computations, and external web calls, in addition to mocking dependencies.\nYou can also run tests in parallel – another reason to keep them completely independent from one another.

\n\n

Gem: parallel_tests

\n\n

Learn Tests Design

\n\n

To write cost-efficient and effort-efficient tests – tests that should not be rewritten from scratch after any small refactoring – you should design your tests almost as well as you design your other code.

\n\n

Only test public interface of classes
Don’t test tiny sensitive private methods (they are very likely to change often)
Reuse repetitive test via mixins
Avoid redundantly testing the same functionality multiple times. Code should be organized in layers that are testable separately from each other.

\n\n

\n\n\n

Authentication & Authorization

\n\n

One of the first serious issues that are usually not covered by a framework is an authentication. In the Rails world, people tend to take the well known Devise lib, integrate it into the app with devise :database_authenticatable, :registerable, and forget about auth. That is, until the awkward moment when you need to customize any tiny aspect of it - anything from templates to auth logic (the latter is harder).

\n\n

The truth is, you can implement auth by yourself very quickly. Just create a users table with login and password fields, encrypt the password with something like the bcrypt-ruby gem, store the hashed password in the DB, and write 3-5 controller actions to handle forms. Your users table will not be cluttered with lots of unknown fields, and you will have an idea of what they are for (or you can rely on these fields for other business logic).

\n\n

A less obtrusive, but still more automated, option is to use Sorcery. Another option is the Tyrant gem â€“ part of the Trailblazer philosophy â€“ that tries to use just a single field of a model.

\n\n

The fewer hidden pieces of data flow in your app, the easier it is to track down errors and change behavior. In such a sensitive part of the app as authentication, this is very important.

\n\n

Once users can be identified inside the app, the second requirement is to distinguish their abilities. One approach is to assign a marker for each user, like role = 'admin', and check this model attribute all over the app. This is not flexible, however, and when your permission rules change, it requires changes to many different parts of the codebase. Permission logic can be quite complicated, so it should be encapsulated. A good example of simple authorization logic organization is Pundit.

\n\n

Unfortunately, I do not know of a good example of RBAC implemented in Ruby. The piece gem comes close, where roles contain sets of permissions, and all of them can be assigned to a user dynamically with business rules (rules should be implemented as code that checks restrictions).

\n\n

\n\n\n

Know your App Server!

\n\n

Running a Rails app starts a WEBrick server by default. This is good enough for the development environment, but not for production. WEBrick runs code in a single thread, and can not handle requests concurrently.

\n\n

It is very important to understand the different operating models of threaded and event-loop based servers, to select the most reliable and efficient server for your app.

\n\n

Another aspect is how static files are handled. Do not waste CPU time by giving this task to a Ruby app. Give this work to reverse proxy servers like Nginx. They can also handle other things, like proxying (e.g. 3000 port to 80 port), multi-domain setup, limiting requests per second to prevent DDoS, “slow client” attack, etc.

\n\n

TODO: Make a brief description of different models

\n\n

\n\n\n

Know your CLI!

\n\n

Everybody knows that you should use Rake tasks to run code from the CLI. But we also need to understand that Rake is more than just a part of Rails. It is an independent tool, and deserves consideration about whether it should be used or not. The main downside of Rake tasks is that they are hard to test â€“ due to their DSL nature, they require special initialization. You should be very careful when putting business logic into Rake tasks. It is just as harmful as putting business logic into controllers in a web framework.

\n\n

As with any tool, Rake is not limited to namespace, task and desc. You should learn how to use all of the benefits and functionality hidden inside. Try to look into the advanced Rake docs.

\n\n

Also, we need to understand that there are much cleaner alternatives, like Thor. Thor provides the same simple functionality for writing your own CLI tools, but does so in a much cleaner, OOP way.

\n\n

Rake
Thor
hanami-cli

\n\n\n

Admin

\n\n

ActiveAdmin is a very popular solution. It provides handy DSL to display CRUD interface for ActiveRecord Models. From the very beginning it helps to spare time, but the at later development stages it will require much more time to make even minor customization.

\n\n

For projects, where you can’t change requirements in favor of the “tool capability”, prefer solutions that help to scaffold (generate) admin section files. It could look like a lot of repetitive boilerplate code, but in future, it allows customize each screen separately without a headache.

\n\n

\n\n\n

Templates

\n\n

Ruby comes with a built-in templating solution, ERB, that embeds Ruby into a text document. It has a number of advantages. It is very close to pure HTML, so it is easy to convert HTML into ERB, and it does not introduce any new entry barriers. It is similar to approaches in other languages (PHP, ASP), so it is transferable, common web development knowledge.

\n\n

Other popular alternative templating solutions include Haml, it’s successor Slim, and other Haml-like languages. Slim template code looks like this:

\n\n

1     div id=\"footer\"\n2       = render 'footer'\n3       | Copyright Â© #{year} #{author}\n

\n\n\n\n

This approach has the advantage of being more clear, due to the removal of “unneeded” elements like closing tags and extra brackets. But the disadvantages are obvious: it has a larger entry barrier, it is harder to migrate HTML markup to it (especially during big redesign sprints), and it is not a transferable skill outside of Ruby.

\n\n

So stick with ERB unless all of your developers and designers are familiar with Slim, or you are building a home-made, 15-min blog.

\n\n

An Introduction to ERB Templating
Slim

\n\n\n

Cache

\n\n

Caching is a multilayer technique. Each type of content requires its own caching approach.

\n\n

Static content

\n\n

Static files, images, and documents could be cached on the server or CDN level by filename or meta-information. Cache invalidation could be done via conditional requests or filename param modification.

\n\n

Dynamic content

\n\n

Dynamic content is much harder to cache as it requires clear invalidation criteria. Even harder is personalized content (that is unique per user) - be careful with it, sometimes caching and invalidating this cache could be even more resource consumption, than having no cache at all!

\n\n

The most obvious solution for a personalized content is to cache on application level: whole pages, fragments or long queries. It is up to you to distinguish and measure what part of long page generation process is the slowest.

\n\n

Nginx page microcache

\n\n

The whole page could be cached on the web server level. Nginx server has a “microcache” feature that could be applied to the whole site or selected locations and cache even dynamic content for a short period of time (about 1 minute). For example, even if you have a highly dynamic page with ranked posts, that changes each 10 seconds (according to votes and number of comments), it seems that you need to generate it on each request to show actual data. But if you have a highload site with 1000 simultaneous visitors (that refresh a page each minute) you can do only 1 page generation instead of 1000+. Of course, it depends on the sensitivity of the data (you won’t cache stock data) and you need to adjust appropriate cache lifetime while your users would not notice that data is “dramatically outdated”.

\n\n

Application level key-value cache

\n\n

A more correct way to do caching, without tricks with total microcaching, is to have a strict cache key and to regenerate content when this key changes. Very often in-memory key-value storages like Redis and Memcached are used to store cached data (due to high speed of data access).

\n\n

But even a file-cache could be productive if you cache operation that takes tens of seconds (the only thing to remember: file-system operation could be a performance bottleneck as disk read speed is very limited, so it should not be very often).

\n\n

Another thing to remember - saving Ruby data structures like Hash or Array to the external cache (file or memory based) requires to serialize it into text representation (and vice versa on reading). This operation takes CPU resources and time. Usually, it is a JSON or YAML representation and not all data structures could be represented into the string automatically. Also Ruby provides a special Marshal class to serialize Objects.

\n\n

Let’s imagine the same page with the ranged list of posts, you want to cache just a plain data of ranged list and automatically rebuild cache when needed. You can make a cache key that includes data like last post date (when a new post is added, you cache key is changed and the page is regenerated). As you see here, to determine cache key you still need to perform one DB query (to get latest post date). It is a reasonable tradeoff of you spare 10-20 or more queries with this caching.

\n\n

The main rule here is - cache key computation should be as simple as possible. Don’t make too many dependencies in the cache key.

\n\n

\n\n\n

Fulltext search

\n\n

TODO

\n\n

Multi-table Full Text Search in Postgres
PostgreSQL full text seach with ts_vector
Textacular gem
Scenic gem
Sphinx
Elastic Search
Algolia

\n\n\n

Style guide and style checker

\n\n

While Ruby does not have a lot of curly brackets {}, code style issues are not as painful as languages like PHP. In any case, we can write code with different paddings, spaces, and line breaks. To avoid confusion and repeated whitespace changes in your codebase - you should adopt a style guide. All team members should agree upon it.

\n\n

Also, there are tools like RuboCop that can make automatic static code analysis and propose fixes or recommendations.

\n\n

\n\n\n

Frontend

\n\n

Sad but true story…

\n\n

There was a time when any web developer was a full stack. And we all made a frontend HTML/CSS “as good as we could”. But now. being a backend developer (literally developing a server side code) means that your primary put your efforts in mastering backend language, getting deeper in SQL and different databases, server provisioning, and system administration. And there is less and less time for the frontend. While frontend grew from tiny pices of HTML+CSS+JavaScript to a huge monster of Frameworks. Even JavaScript developers are complaining about “how fast the World is moving forward”, not to mention us “backend developers” - we are completely lost. We are still in the jQuery era. That is not so bad, that is just how it goes.

\n\n

EcmaScript 2015 / ES6 or how backend developers lost JavaScript

\n\n

But in any case, we need to keep in touch with Frontend world evolution. Ideally, it is real and possible to have limited full stack skills to be able to cover all aspects of the web product. You are not required to be able to build the new Facebook alone. But that is what I think essential:

\n\n

HTML / CSS

\n\n

Basic HTML/CSS knowledge are still required. Good news are there are very few basic CSS things that are not supported across different browser (while huge new features are not cross browser).

\n\n

Learn Layout

\n\n

FlexBox is relatively new CSS approach. It can help you in case you need complex CSS positioning but do not need to support very old browsers. I recommend getting used to it.

\n\n

\nFlexBox Froggy - learn FlexBox in very interactive way!

\n\n

And almost a must to have basic knowledge of existing CSS framework to be able to compose quick and dirty GUI, that at least is not ugly. There a number of them, but 2-3 are most popular. They provide sets of ready-made GUI components - static and dynamic (with bundled JS). If to get a deeper understanding of such kind of a framework you can customize it and build even complex interfaces on top of it, while relying on stable foundation (with a lot of cross browser issues solved).

\n\n

JavaScript

\n\n

TODO: Whole this section :)

\n\n

jQuery

\n\n

Debug JavaScript

\n\n

Breakpoints

\n\n

Server-side rendered JS

“replaceWith” trick

\n\n

Modern JavaScript

Frameworks, Bower\nModules and loaders\nTry to keep away from Sprockets

\n\n\n

Performance

\n\n

As a general rule, if your web page generation time in production is close to one second (or more), that is not perfect. You should invest some time in performance optimization. But before you start optimizing, you should locate the bottlenecks. Almost always, the issues are not where you think they are. Measure!

\n\n

You can use special profilers that give detailed stats per function call, like PerfTools, or use continuous high-level performance monitoring with widget-like add-ons, like Rack mini profiler. Rack mini profiler will display a toolbar at the top of all pages, with a breakdown of the raw page load time.

\n\n

There are also external services like New Relic that can gather code runtime performance, even on the production server. It can give general insight into the most time-consuming code and SQL queries.

\n\n

TODO: Add gems that help to track N+1 queries and SQL performance

\n\n

Benchmarks

\n\n

Sometimes, in the development stage, you need to measure the performance of a couple of different implementations. To get measurable timing results, the code being benchmarked should be run repeatedly, for many iterations. There are ready-made tools that can help with such measurements.

\n\n

Benchmark ips
Scientist

\n\n\n

Deployment and Server

\n\n

TODO

\n\n

Capistrano

\n\n

Alternative solutions like Mina do not have any major advantages at the moment.\nOr a custom Deploy workflow for big projects with tools like Ansible

\n\n

VPS, Dedicated server

\n\n

Linode
\nDigitalOcean (my ref link ;) you receive $10 credit after registration)
Amazon Web Services
https://github.com/open-guides/og-aws
\nNamecheap, domains registrator (my ref link ;) )

\n\n

PaaS

\n\n

Heroku

\n\n

CI

\n\n

DevOps

\n\n

TODO

\n\n

Ansible
Chef
Puppet
Docker

\n\n

Local development

\n\n

TODO

\n\n

Vagrant
Docker

\n\n

Local tunnels. Exposing dev env in the Internet

\n\n

The solution for a question “how do I expose a local server behind a NAT or firewall to the internet?”. Literally when your dev machine does not have a dedicated IP, but you need to…

\n\n

make a demo of localhost web app (and can not deploy it to some server)
make a quick test of web app (api) on your mobile device
accept a webhook from some service or oAuth redirect

\n\n

Local tunnels allows you to easily share a local web service development machine without messing with DNS and firewall settings. And here are some free tools:

\n\n

Ngrok is a very powerful standalone tool. Has a lot of paid options, but very basic are given for free.

\n\n

no dependencies, just download ngrok binary
web page with connection stats
supports config file

\n\n

Expose localhost:3000 as easy as

\n\n

1 ngrok http 3000\n

\n\n\n\n

You’ll get url like this https://83832de1.ngrok.io

\n\n

Another way, if you already use Vagrant - the easies way is to use Vagrant Share

\n\n

1 vagrant share\n

\n\n\n\n

You will need to make one time registration at https://atlas.hashicorp.com/, then to run vagrant login with registered credentials.

\n\n

Vagrant detects where your HTTP server is running in your Vagrant environment and outputs the endpoint that can be used to access this share.
\nYou’ll get url like this http://lucky-man-7777.vagrantshare.com\nAs a bonus it supports SSH sharing via

\n\n

1 vagrant share --ssh\n

\n\n\n\n

Ngrok
Vagrant Share

\n\n

Protect non-production servers with HTTP Auth

\n\n

Basic Auth could be used as the main form of authentication for very simple apps, or admin backends. It is often used to prevent access to staging servers by strangers and search engines (to prevent indexing of non-production pages).

\n\n

In Rails, the simplest basic auth could be added like this:

\n\n

1 class ApplicationController < ActionController::Base\n2   http_basic_authenticate_with name: \"admin\", password: \"hunter2\"\n3 end\n

\n\n\n\n

More advanced ways can be found in the Rails docs.

\n\n

In any other Rack based server, you can use the Rack::Auth::Basic middleware:

\n\n

1 use Rack::Auth::Basic, \"Restricted Area\" do |username, password|\n2   [username, password] == ['admin', 'pass']\n3 end\n

\n\n\n\n\n

Web Application Security

\n\n

Frameworks are great because, not only do they simplifying our web app code, they silently provide security restrictions and best practices. But this magic security only works when you stick to the defaults. When you start to do “advanced” coding, you need to know where common web app vulnerabilities are hidden, and where you need to take care of them.

\n\n

Common vulnerabilities include:

\n\n

SQL injection: unfiltered parameters concatenated into raw SQL queries. This allows hackers to run malicious SQL queries.
CSRF: allows hackers to send requests to your app without the user’s knowledge or consent.
XSS: allows hackers to submit malicious JavaScript to your site (e.g. in the comments) which can steal session data from other users.

\n\n

There are many more potentially dangerous things. You can find more details on the OWASP website.

\n\n

OWASP Vulnerabilities list

\n\n\n

Stay open-minded, stay hungry!

\n\n

\n\n\n

Community

\n\n

Official Ruby site
Ruby IRC
Conferences
\nRubyFlow - community news

\n\n\n

Follow great Ruby developers

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n

Person	Why?	Blog	Twitter	GitHub
Aaron Patterson	active Ruby ecosystem contributor, great blogger	tenderlovemaking.com	@tenderlove	@tenderlove
Luca Guidi	author of Hanami.rb framework	lucaguidi.com	@jodosha	@jodosha
Nick Sutterer	author of Trailblazer	nicksda.apotomo.de	@apotonick	@apotonick
Piotr Solnica	author of dry-rb	solnic.eu	@solnic	@solnic
Sandi Metz	author of “POODR” book	sandimetz.com	@sandimetz	@skmetz
Avdi Grimm	author of “Objects on Rails” book	devblog.avdi.org	@avdi	@avdi
Katrina Owen	creator of http://exercism.io, great speaker	kytrinyx.com	@kytrinyx	@kytrinyx
Andrzej Krzywda	DDD and Event Sourcing evangelist	\nandrzejonsoftware.blogspot.com + blog.arkency.com\n	@andrzejkrzywda	@andrzejkrzywda
Robert Pankowecki	author of Domain-Driven Rails	\nmedium.com/@pankowecki + blog.arkency.com\n	@pankowecki	@paneq
Ryan Bigg	author of technical books on Ruby, Rails and Elixir	ryanbigg.com	@ryanbigg	@radar
Jeremy Evans	creator of Sequel and Roda		@jeremyevans0	@jeremyevans

\n\n\n

Books

\n\n

TODO: Add more books

\n\n

\nObjects on Rails by Avdi Grimm.

\n\n

\n\n","tocStructure",[355,356,357,358,359,360,361,362,363,364,365,366,367,368,369,370,371,372,373,374,375,376,377,378,379,380,381,382,383,384,385,386,387,388,389,390,391,392,393,394,395,396,397,398,399,400,401,402,403,404,405,406,407,408,409,410,411,412,413,414,415,416,417,418,419,420],{"_75":76,"_42":77,"_69":-5,"_78":79,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":85,"_69":-5,"_78":86,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":91,"_69":-5,"_78":92,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":94,"_69":-5,"_78":95,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":97,"_69":-5,"_78":98,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":100,"_69":-5,"_78":101,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":104,"_69":-5,"_78":105,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":108,"_69":-5,"_78":109,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":111,"_69":-5,"_78":112,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":114,"_69":-5,"_78":115,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":117,"_69":-5,"_78":118,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":121,"_69":-5,"_78":122,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":125,"_69":-5,"_78":126,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":128,"_69":-5,"_78":129,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":131,"_69":-5,"_78":132,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":134,"_69":-5,"_78":135,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":137,"_69":-5,"_78":138,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":140,"_69":-5,"_78":141,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":144,"_69":-5,"_78":145,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":147,"_42":148,"_69":-5,"_78":149,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":151,"_69":-5,"_78":152,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":147,"_42":154,"_69":-5,"_78":155,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":157,"_69":-5,"_78":158,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":160,"_69":-5,"_78":161,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":164,"_69":-5,"_78":165,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":168,"_69":-5,"_78":169,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":172,"_69":-5,"_78":173,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":176,"_69":-5,"_78":177,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":180,"_69":-5,"_78":181,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":184,"_69":-5,"_78":185,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":188,"_69":-5,"_78":189,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":192,"_69":-5,"_78":193,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":195,"_69":-5,"_78":196,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":198,"_69":-5,"_78":199,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":201,"_69":-5,"_78":202,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":204,"_69":-5,"_78":205,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":207,"_69":-5,"_78":208,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":210,"_69":-5,"_78":211,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":213,"_69":-5,"_78":214,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":217,"_69":-5,"_78":218,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":221,"_69":-5,"_78":222,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":225,"_69":-5,"_78":226,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":229,"_69":-5,"_78":230,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":233,"_69":-5,"_78":234,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":237,"_69":-5,"_78":238,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":240,"_69":-5,"_78":241,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":243,"_69":-5,"_78":244,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":246,"_69":-5,"_78":247,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":249,"_69":-5,"_78":250,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":253,"_69":-5,"_78":254,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":257,"_69":-5,"_78":258,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":261,"_69":-5,"_78":262,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":264,"_69":-5,"_78":265,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":267,"_69":-5,"_78":268,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":147,"_42":270,"_69":-5,"_78":271,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":147,"_42":273,"_69":-5,"_78":274,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":147,"_42":276,"_69":-5,"_78":277,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":147,"_42":279,"_69":-5,"_78":280,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":282,"_69":-5,"_78":283,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":286,"_69":-5,"_78":287,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":289,"_69":-5,"_78":290,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":293,"_69":-5,"_78":294,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":297,"_69":-5,"_78":298,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":301,"_69":-5,"_78":302,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":305,"_69":-5,"_78":306,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":309,"_69":-5,"_78":310,"_71":80,"_87":-5,"_88":-5,"_89":-5},"publicChapterContent","nextChapter","sections",[],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]

Stay open-minded, stay hungry!

Table of Contents

Intro

Why not “Ruby On Rails” and not “The Right Way”?

Damaged ecosystem

Manifesto

You can help here

My Dream Stack

Ground knowledge

Web

Linux

IDE

Gems

Ruby on Rails

Confusing environments

You don’t need ActiveRecord for every kind of model

Before filter/action

HTML helpers. Decorators.

Active Job and business logic

Alternative frameworks

Full-featured

Hanami.rb

Specialized

Grape

Mini

Architecture

Trailblazer

ROM.rb (Ruby Object Mapper)

dry-rb

Rectify

Learn OOP design

Dependency Injection and IoC containers

The magical world of Metaprogramming

Mixin/Module include - it is not composition

Document your code

SQL

Debug

Tests

Unit tests

Test Behavior, not Configuration

Integration tests

Test data: Fixtures vs Factories

Stub external services call

Speed-up test

Learn Tests Design

Authentication & Authorization

Know your App Server!

Know your CLI!

Admin

Templates

Cache

Static content

Dynamic content

Nginx page microcache

Application level key-value cache

Fulltext search

Style guide and style checker

Frontend

Sad but true story…

HTML / CSS

JavaScript

jQuery

Debug JavaScript

Server-side rendered JS

Modern JavaScript

Performance

Benchmarks

Deployment and Server

VPS, Dedicated server

PaaS

CI

DevOps

Local development

Local tunnels. Exposing dev env in the Internet

Protect non-production servers with HTTP Auth

Web Application Security

Stay open-minded, stay hungry!

Community

Follow great Ruby developers

Books