DEV Community

Cover image for Learn Ruby on Rails Best Practices With One Exercise
hexdevs profile image Thiago Araujo
Thiago Araujo for hexdevs

Posted on • Originally published at thd.codes on

Learn Ruby on Rails Best Practices With One Exercise

#ruby #rails

You want to write smooth professional-looking code.

You're craving some squeaky-clean code. But all you have for lunch every day is a big bowl of legacy spaghetti code.

You consider yourself a decent developer, but you're never sure how to organize a project. How to name things. Where some piece of business logic should live.

How can you become a Ruby on Rails expert if the code you read every day stinks? 🦨

Is it possible to learn and follow best practices when you're trapped in a big ball of stale legacy code?

Of course, it is!

Start changing your coding diet today by consuming something healthier.

Yes, it's going to take some work. But don't get discouraged. If you want to advance your skills, you've gotta try something different.

Ready to get started?

First: Be Careful When You Ask for Advice

You're committed to advancing your skills. When you ask people for guidance, they tell you to read a bunch of books and start throwing these terms at you:

Skinny controllers, fat models, service objects, design patterns, DRY, SOLID, OOP...

The list goes on.

Is this information really helpful to you? What are you supposed to do with all of that?

The problem is that it's not actionable information, just a bunch of ideas and vague suggestions.

There is a more practical way to learn all this stuff. Here's how.

One Exercise to Teach You Ruby on Rails Best Practices

Instead of reading another book or watching youtube videos about pasta making during your lunch break, do this exercise instead:

Exercise

  1. Set a timer for 10 minutes.
  2. Open this link in another tab: practice.rb from Upcase by Thoughtbot
  3. Read the app/services/practice.rb class.
  4. Ask yourself: What's going on here?
  5. Come back here when the time is up! ⌛

Sounds good?

Okay, now go do it!
I'll wait for you.

...

...

...

⏰ beep! beep! beep! beep!

Now that the time is up, answer at least one of these questions:

  • Why is this class so short? It's less than a hundred lines!
  • Why is the variable trails being passed down to the initialize constructor?
  • Did you notice these methods promoted_unstarted_trails and unpromoted_unstarted_trails? Why do you think they were given these names, and what's the difference between them?
  • What is this class responsible for? 🤔
  • What else picked your interest?

Write down the questions and your answers to make them stick.

Last but not least:

  • Repeat this exercise tomorrow, but pick a different class from the same repository.
  • Add a daily reminder to your calendar so you don't forget about it. 📅

It's okay if you don't understand anything

The goal of this exercise is to notice some patterns. Not to understand every single line of code.

Use your answers to the questions above as a study guide. Even if you answered "I don't know", that's useful information.

It's okay if you feel uncomfortable

Feeling uncomfortable means you're doing something different. You're challenging yourself. You're learning and growing.

If you're thinking "OMG this code is too clean and my code is super dirty!" or "I'll never be able to work on such a clean codebase!", don't worry!

That's okay. That's not the point of this exercise.

The point of this exercise is to read the code and notice anything that looks different or any interesting pattern.

How am I going to learn anything just by reading one class?

It might seem like it's not much.

If you do this every day, here's what's going to happen:

  • At the very least, you're going to learn how the Upcase codebase works.
  • You will pick up new ideas and patterns.
  • You will end up with a list of things you don't understand. That's a great guide on what you need to focus on.
  • You will see how other experts structure a project to make the code neat and clean.
  • You will learn how to find answers to your own questions and how to read source code.

That's pretty good, right?

All professional developers and experts have these skills. It comes from practice.

Why Pick a Well-Written Codebase?

Good question. You have to be exposed to good code if you want to advance your skills. Especially if you don't have this opportunity at work.

If your goal is to learn best practices, you have to read a well-written codebase.

Thoughtbot, the company behind Upcase, is well-known in the Ruby on Rails community for setting industry standards and following good coding practices.

What if I get stuck?

When that happens, ask one of your colleagues for help.

If that doesn't work or you don't feel comfortable doing that, ask Rails Forum or Reddit.

You can also send me a DM on Twitter and I'll be happy to help.

Now that you've done this exercise, you will improve your Rails skills every time you practice.

It's just a matter of consistently exposing yourself to good code. Keep using the suggested questions as a guide, or come up with different ones. Pick a different class every day, and keep going.

You've already done the hardest part: getting started. Now keep practicing.

Let me know what you've learned by practicing this exercise.

Bookmark this post to keep the questions on hand. Share it with a friend who will find this exercise helpful. ⭐

Happy learnings! 📓

Do you want to become an expert developer?

I write about Ruby and Software Development on hexdevs and on Twitter. Let's connect!

Top comments (3)

Collapse
 
nathanael_79 profile image
Imanuel Ronaldo •

Hi thiago, thanks for sharing. I have difficulties to understand the syntax of ruby itself. When i tried my best to learn about RoR, i realize that its similar with laravel for directory structure, but i still have difficulties understanding the syntax. Is there any advice for it?

i also learn js, golang and java, but the syntax is not so difficult to understand like ruby.

Collapse
 
thdaraujo profile image
Thiago Araujo • • Edited

Hi, Imanuel!

For sure, Ruby's syntax is a little different. But after you get used to it, writing Ruby code will give you a lot of joy.

You find Ruby a little harder to understand probably because you're used to JS/Go/Java, as they are very similar in style (C-style).

The big difference between Ruby and these other languages is that Ruby is all about objects sending messages to other objects. It's a slightly different way of thinking.

In case you're curious, Ruby is closer to languages like Smalltalk and Lisp. It's a very flexible language based on a small number of basic building blocks.

That flexibility allows you to make your code very readable and descriptive, it's almost like writing english text.

To learn the syntax and the style of a new language, one thing that helps a lot is to look at the basic building blocks of one language and compare it to another.

Then you can try to translate a small piece of code from one language that you understand well to another you're trying to learn.

That's how you spot the differences and similarities, and understand how to apply these ideas in different scenarios.

Let me give you an example.

How would you write a piece of code that prints numbers from 1 up to 10 in Go and Ruby?

Maybe something like this:

# Go
for i := 1; i <= 10; i++ {
  fmt.Println(i)
}

# Ruby
(1..10).each do |n| 
  puts n
end
Enter fullscreen mode Exit fullscreen mode

You can probably see big differences in style. Some basic building blocks we can spot are:

  • a range 1..10
  • the usage of an each iterator instead of a for-loop
  • a block do ... end with a parameter n
  • a puts n method being called with one argument, and no parenthesis

If you compare the two implementations, you might ask these questions:

  • Ruby has for loops, but why are we iterating over a range here?
  • Is each a method call on range?
  • Why are we using do |n| ... end instead of { |n| ... }?
  • What if you change the code to puts(n)?

Or even a slightly harder question:

  • Would you be able to send a message to a variable or object in Go? Why not? Example: 
# sending a message instead of calling a method
 (1..10).send(:each) { |n| puts n }
Enter fullscreen mode Exit fullscreen mode

You can learn a lot about Ruby just by trying to answer one of these questions. And then trying to write a similar piece of code by yourself and practice what you've just learned.

You'll learn not only the style and syntax of Ruby, but also the mindset behind it. This exercise is useful for learning any other language, just change the questions a bit and practice.

Hope that helps!

Collapse
 
nathanael_79 profile image
Imanuel Ronaldo •

Hi Thiago, thanks for the advice, it helped me a lot, time to Learn Ruby more! thanks!

Read next

alexandrecalaca profile image

BCrypt::Errors::InvalidHash (invalid hash)

Alexandre Calaça -

aliosm profile image

Enforcing Phlex Adoption in Rails: A GitHub Action to Prevent New ERB Files

Ali Hamdi Ali Fadel -

hamajyotan profile image

Smart way to update multiple models simultaneously in Rails

Takashi SAKAGUCHI -

fv2024 profile image

A nice Ruby-based command-line time tracker

Frank Vielma -