What are some Rails concepts that will make me a better dev?

I've been using Rails for 2 years now, and feel confident enough. However, I don't know what I don't know. Below are a few examples of concepts I've learned over the years that aren't mentioned in beginner tutorials.

* Single Table Inheritance
* ActiveRecord::Enum
* Using Scopes
* Avoiding N+1 Queries

What are some other concepts or best practices do you recommend?


10 thoughts on “What are some Rails concepts that will make me a better dev?”

  1. > Single Table Inheritance

    IMO, don’t use this regularly. Only use it in very specific cases. It causes maintenance issues over time.

    > What are some other concepts or best practices do you recommend?

    Generally speaking, understand Rails best practices. You don’t necessarily need to treat each one as gospel, but at least know where the industry is moving in general. So, read up on stuff like [Sandy Metz’s rules](https://robots.thoughtbot.com/sandi-metz-rules-for-developers) and [Service/Query/etc Objects](https://codeclimate.com/blog/7-ways-to-decompose-fat-activerecord-models/).

    And then also, start to understand how the rest of the stack works. How does a database work? Knowing this will help you build more effective models and data structures. Knowing SQL well even though you have ActiveRecord will help you identify things like N+1 queries, issues where you’re missing an index, issues where you do actually need to break out of AR, or just generally prep you for larger scale projects. Learn about how web servers operate – what’s a load balancer, for example? Background/async jobs. What’s a crontab? Etc etc..

  2. Testing! Rails has a rich testing ecosystem that supports a number of styles of test. You can learn a lot about testing in Rails that will apply to any language/framework.

  3. **SQL.**

    Especially in the dialect of SQL you most commonly use as the backend for the application(s) you work on the most frequently. Specifically indexing and database performance tuning as you can leverage that knowledge to performance-tune your Rails apps. _Learn how to read those query-execution plans._ If you use PostgreSQL I highly recommend [PEV](http://tatiyants.com/pev/#/plans/new) to help with this.

    SQL fluency isn’t even a Rails concept/best-practice per-se, but SQL _familiarity_ (much less fluency,) is one of the weakest skills I see when I’m hiring green Rails developers.

    Besides, having strong SQL skills is a valuable cross-language/framework skill to have.

  4. Learn how to work with more than the MVC that Rails provides using design patterns that Rails use and that you can use with Rails:

    \- NullObject

    \- ServiceObject

    \- PolicyObject

    \- ViewObject (Presenter)

    \- Decorator

    \- ValueObject

    \- FormObject

    \- QueryObject


  5. * Most of the time it’s better to write your code which is readable and maintainable even if it’s not the most optimised
    * Avoid writing long methods, prefer lots of methods with meaningful names. Almost all methods should be about 5 lines max. And should not use variables much.
    * Use services classes that do only one thing with only one public method
    * Use memoization [https://www.justinweiss.com/articles/4-simple-memoization-patterns-in-ruby-and-one-gem/](https://www.justinweiss.com/articles/4-simple-memoization-patterns-in-ruby-and-one-gem/)

    Quick example :

    class ImportUserBankBalanceService
    def initialize(bank_api_client, user)
    @bank_api_client = bank_api_client
    @user = user

    def call
    raise “Error fetching bank balance:, #{external_resource.error}” if external_resource.error



    attr_reader :bank_api_client, :user

    def external_resource
    # this memoization pattern allows us to only fetch the data once but call the method multiple times
    @external_resource ||= bank_api_client.fetch_balance(user.external_id)

  6. I thing to be a good dev, it’s better to learn concepts outside rails. Look at sinatra and hanami, check out different orms (rom, sequel) and different approaches (dry and trailblazer). It’s also make sense to look at different languages.

    Experience you’ll get learning things outside the rails’ box is universal,


Leave a Comment