Categories
Coaching Series

FAT MODELS AND PREFERRING COMPOSITION OVER INHERITANCE

Today I’m gonna talk about Fat Models.

Fat Models are unavoidable when you are learning Rails. That’s because when they teach you MVC— that is model, view, controller— they tell you: Don’t put your business logic into your view. And then they tell you don’t put your business logic into your controllers. So where do you put your business logic?

Unfortunately, you’re sometimes taught or encouraged to put them into the models. Thus, the models get very large. And when I say large I mean hundreds and hundreds of lines of code.

This is not something you should do. Instead, you should understand your models as the bare-bones operations that read or write to your database only. Then you should learn and use the other patterns I’m going to talk about today to build what we call a business domain.

This lesson can be considered an Introduction to Domain Driven Design, which will discuss explicitly later on.

Today we’ll look is meant when we say “prefer composition over inheritance.”

Perhaps you have heard the term: “prefer composition over inheritance.” But what does it really mean understand what that means?

Well, give me a few minutes of your time and I’m going to take you in this lesson into a broad overview of 9 different patterns you can use to break out of the MVC cycle.

Fat Models Skinny Controllers

In the early days of Rails people said “fat models, skinny controllers.”

In the really early days when the apps themselves were much smaller. People only actually said “fat models skinny controllers” for a short time because then the models got unmanageably large.

Rails was pioneering in the basic concept of splitting Models (persistency logic), Views (view logic) and Controllers (display and response logic).

Notice that the descriptions I used were very intentional and specific. Most people teach the “M” in MVC as “business logic” and the “V” as “view logic or display logic.” Then they try to describe what a controller is. What’s a controller, exactly?

Hmm. Well, for Rails, in the context of a GET request, it:

1) typically prepares a query in anticipation of view being rendered (like setting up a query, may be based on search criteria)

2) Handles authentication, authorization and access control if appropriate. (Arguably, the implemented class Contrtoller doesn’t typically handle this, but the Controller object, as a concept, is where this is responsible)

3) Interacts with the Rails request layer for params, headers, etc.

That’s pretty much it. In other languages, Controllers are sometimes called ViewControllers. You shouldn’t think a Controller as really anything more than a set of code that deals with how to present stuff and respond to things.

That’s why I call it “display logic and response logic”

Breaking out of the MVC Antipattern

If you’re new to Rails or programming, the first thing you learn is MVC (model, view, controller). Then, you should unlearn it.

In domain-driven design, which really I won’t even get to until pattern #6 below, we separate out Rails models from the business domain. That is, we think the ‘M’ in the traditional Rails sense as only what is necessary to read to and write from the database. This way, we still get to use all of the good parts of ActiveRecord while working towards what is fundamentally a domain layer that doesn’t live in any of the models, views, or controllers.

That, in a nutshell, is the bird’s eye view of what I’m going to talk about today.

We might do this by creating simple methods that will instantiate these service objects when needed.

Service objects have the unique property of coming into memory when needed and then disappearing when your code finishes running on each request.

The name of the game here is to compose the other objects of multiple smaller objects that will keep the business logic in the business domain layer.

Today is a broad overview of some answers to the question “How do I deal with fat models?” We’re gonna look at

1. Classic Delegation

2. Inheritance (bad)

Then I’ll talk about the classic composition patterns, including:

3. Composition with Modules (& Using Helpers in Rails View) and Composition with Rails Concerns

(And I’ll cover what a Rails cocern is and how it adds to normal Ruby modules.)

Then I’ll cover patterns found in larger Rails apps:

4. Service Objects

Then we have the aforementioned Introduction to domain-driven design, and other “out-of-the-box” architecture concepts, like:

5. Domain Context Interaction as per James Coplien in Lean Architecture

A look the Trailblazer gem – a complete domain driven design system that separates business logic from persistence logic.

At this point, you will understand what I mean when I say we are “separating business logic from persistence logic.”

Then we’ll take a quick look at 3 more patterns:

6. The “pub-sub” pattern: Publish-Subscribe and we’ll have a quick look at a Gem called Whisper

7. The “Interactor” Pattern: Interactor and ActiveInteraction, and U Case gems – to perform complex business operations together

8. The “mutation” pattern: Mutations using a gem called (unsurprisingly) Mutations

It’s a big lesson so be sure to take your time with it. As well, I will return to some of the higher-level concepts in future courses to get more hands-on with these ideas.

Again, these nine types of abstraction are presented here without strong bias (except #2 which is generally considered bad). You should learn them all and learn how to reach for the right abstraction at the right time. I’ll have another lesson in this course about too early abstractions. For now, I’m presenting this as a very high-level overview so that new and intermediate developers understand the landscape of possibilities.

Well, in truth the sky is the limit! But in the real world, these patterns as outlined here are based decades of industry -wide working and re-working of what are commonly known as “design patterns.”

Although the classic “design patterns” in programming languages that predate Ruby are more numerous than these 9, I’ve chosen these 9 to focus on because they are a great way to teach someone who has only learned about MVC what the alternatives are.

1. Classic Delegation

Ok so the first topic is called delegation.

Delegation is simply we move logic out of a class and delegate it to another class. It is a common pattern and one of the first ones you learn. Consider for example a Thing object that can export itself to XML, JSON, or CSV

class Thing
  # no delegation — all export methods are here
  def as_csv
    #...
  end

  def as_xml
    #...
  end

  def as_json
    #...
  end
end

As our model gets “fat,” we’ll want to move those specialized methods out of it. Delegation is our first strategy.

Examine our new Thing object, and another object called Converter::Thing

class Thing
  # delegate to a converter, passing self as the object
  def converter
    Converter::Thing.new(self)
  end
end
class Converter::Thing
  attr_reader :thing
  def initialize(thing)
    @thing = thing
  end

  def as_xml
    # ...
  end

  def as_json
    # ...
  end

  def as_csv
    # ...
  end
end

Here we’re simply moving the methods out of the original object and into another object. It is important to note it is a “simple” move.

In other words, we’re just fundamentally moving code around and splitting it out into new objects. We aren’t actually changing anything fundamental about how we think about functionality and objects — we’re just changing where we think about functionality and objects.

As the complexity of your app grows, the more basic solutions (like this one, “delegation”) will only be building blocks. This is fundamentally abstraction.

Let’s move on to pattern #2.

2. Inheritance

Classical inheritance is what they teach you when learning computer science as, well, classical inheritance. Its name offically means “inherticance using classes,” but as a tounge-in-cheek joke the double entdre is now that it is “classic” as in outdated. The easiest way to describe classical inheritance is this way:

models/animal.rb

class Animal
def blood_temperture
raise "superclass must implement"
end
end

models/mammal.rb

class Mammal < Animal
  def blood_temperature
    "warm"
  end
end

models/bear.rb

class Bear < Mammal

end

Ok so what have we achieved? We can ask questions about the animal and, for example, if we want to implement a different species or genus, we would know where to implement things like: Does the animal have hair? Does it have skin or fur? How does it reproduce?

Species of animals lend themselves particularly well to the teaching about classical inheritance. It’s a great use case for teaching, but unfortunately, classical inheritance isn’t often as useful or practical in the real world.

Some may think that categorization and graphing of this complex hierarchy is the stuff of OO developers. In some ways it is and in some ways, it isn’t. In some ways, an obsession with over-categorization is what gets OO a bad rap.

Think about a developer who learns a pattern— like inheritance— and then everything they implement is done with inheritance. It’s like they keep repeating the same solution for every problem. Why? Because our brains operate in the mechanism that our brains were just operating.

That is— once you start doing something one way, you are cognitively biased to repeat the same solution to every new problem that same way. This doesn’t actually make sense and you shouldn’t be that developer.

Because more often than categorization and graphing of a complex hierarchy you as the developer are considering how and why external users— that is, an end user— come into play with the data.

Experienced OO developers say “prefer composition over inheritance” so let’s a take a look at composition.

The rest of this lesson, along with the other 29 lessons in this course is available on Teachable + a special bonus: the Rails Coach cheat sheet mailed directly to you.

Categories
Coaching Series

RAILS MAGIC AUTOLOAD

This post is part of my Stepping Up Rails: Go From Good to Great series. Get the complete series on Teachable!

Rails Autoloading is what happens in the background that most developers don’t even think about. The Rails Autoload is something that is important for you to know about. Rails will automatically load certain files your Rails app application when it boots up.

When you first learn Rails you learn about its basic structure:

App/

Models/

Views/

controllers/

We call this “MVC” for “model-view-controller.”

Then you get a little more experience and you learn about domain architecture and services. Perhaps you make a new Rails app and you notice an empty folder

Controllers/concerns/

And you look at this folder and you think, “What do I put there?”

Sometimes you must use the ‘require’ keyword to load files—- as you see in specs often— but sometimes you don’t. When do you use ‘require’ and when don’t you?

Rails has an important piece of magic that’s significant for every new Rails dev to know: the autoload with same-name, or correctly named, files. That is, Rails will autoload files for you if you meet the three conditions below.

Before letting you in on the secret, lets review the concepts of underscores, titlecase and namespaces.

Underscore

An underscore is a character on your keyboard (probably to the right of the 0 on your number line). On most keyboards you press SHIFT-(-). Press SHIFT and the dash key to produce an underscore, which looks like this: _ . The underscore appears where the underline would just below where a letter would be, but denotes that there is no letter or number. Do not confuse the underscore with the dash, which appears in the middle of the line. On your keyboard, you don’t hold SHIFT to create a dash character, and you do hold shift to create an underscore.

What does the underscore mean? The underscore means the space of “no character” when in fact it does represent a character in the computer’s implementation. Because loading from operating systems is finicky with spaces, we don’t use spaces in our file names. Instead we use underscores.

Here are some examples of Ruby files with underscores in them. You always use underscores when naming the actual files on your disk. (Even though your operating system might actually allow you to put a space in a file name, don’t do this when naming Ruby files.)

payment_adjustor.rb

line_item.rb

subscriptions_controller.rb

Titlecase:

Titlecase refers to a special syntax used by Ruby and some other programming languages to represent objects. In short, if you have several words, you make each of the first letters of each word uppercase and then you string the words together. So, if you have a phrase like “something wicked this way comes” to make it title case would look like:

SomethingWickedThisWayComes

Note how we capitalize (uppercase) the first letter of each word but the other letters are not capitalized. Also notice how there are no spaces or underscore separating the words. We call this titlecase and it is how we write all objects in Ruby. (Do not confuse titlecase with camelcase, often found in other programming languages, which is very similar to titlecase but the very first letter of the whole object name is lower case. In our example, the camelcase of what we have above would be somethingWicketThisWayComes with lowercase s in something)

Namespace or Namespacing

A namespace, or namespacing (the act of applying a namespace), is really just when we want to group things together and give them a common element in their name, typically prepended (or put before). In Rails, we have a special way to namespace (explained below) using subfolders. But, if, for example, we wanted all parts of our application involving subscription management to be under the name ‘subscriptions,’ we might (actually, as I will explain below, we can and should) move our Ruby objects into a subfolder called ‘subscriptions’ and also namespace our objects by renaming them Subscriptions:: plus what we first called them.

A namespace is really just a way for programmers to group ideas together (and truly, it is probably a relatively poor way to think about object abstraction. The examples provided in this post provide examples of what I would call good use of namespacing. If you find a large system that is highly namespaced or is overly convoluted, you may have some antipatterns. This is because developers overused namespacing, or relied on it when they should have created more extensible encapsulations. This advanced subject is beyond the scope fo this post. Just keep in mind that namespacing, while a quick way to clean up small messes, should not be overused when what you really need are better abstractions.)

OK, now the 3 magic rules of the Rails autoload:

Your Rails files will be loaded by Rails if (and only if):

1) they are in the folders models, views, controllers, or test, or spec, and

2) The name of the file matches, using the correct underscore-to-titlecase conversion when writing your Ruby class names. Put another way, your file names must be in underscores (and lowercase), and your Ruby classes that each file defines must match exactly (in titlecase) the name of its file.

3) When a file appears in a subfolder, which is encouraged, you must namespace it –– the folder’s name (or namespace) is titlecased and prepended to the class name with ::

Those 3 rules are key. If you get them, you will master the the Rails autoload.

Rails has all kinds of reasons why you would want to create sub folders INSIDE of other folders. For example, let’s say you have a polymorphic set of Products. That is, you have a Product object with a type column that Rails will use to instantiate the objects.

A Basic Polymorphic Example

class Product < ApplicationRecord

end

class Shirt < Product

end

class Purse < Product

end

In the type column, you will see the name of the subclass directly. I will start by making a new Purse called “Little Clutch”

2.6.4 :004 > Purse.create(name: “Little Clutch”)

   (0.2ms)  begin transaction

  Purse Create (2.0ms)  INSERT INTO “products” (“name”, “type”, “created_at”, “updated_at”) VALUES (?, ?, ?, ?)  [[“name”, “Little Clutch”], [“type”, “Purse”], [“created_at”, “2020-05-13 16:55:49.132712”], [“updated_at”, “2020-05-13 16:55:49.132712”]]

   (2.0ms)  commit transaction

 => #<Purse id: 1, name: “Little Clutch”, type: “Purse”, created_at: “2020-05-13 16:55:49”, updated_at: “2020-05-13 16:55:49”> 

Then, I will create a Shirt called “Button down”

2.6.4 :005 > Shirt.create(name: “Button-down”)

   (0.1ms)  begin transaction

  Shirt Create (0.6ms)  INSERT INTO “products” (“name”, “type”, “created_at”, “updated_at”) VALUES (?, ?, ?, ?)  [[“name”, “Button-down”], [“type”, “Shirt”], [“created_at”, “2020-05-13 16:56:05.042379”], [“updated_at”, “2020-05-13 16:56:05.042379”]]

   (1.0ms)  commit transaction

 => #<Shirt id: 2, name: “Button-down”, type: “Shirt”, created_at: “2020-05-13 16:56:05”, updated_at: “2020-05-13 16:56:05″> 

In the example above, the three Ruby files (Product, Shirt, Purse) all appear in the root of the models/ folder

Polymorphic Autoload Example

Now let’s say we have many products and we want to move them into a sub folder called products/

We’ll want to do this with a little change to our class objects. Here’s what our new files & folders will look like:


Notice we did some things here: One, the superclass Product (was product.rb) has been renamed to products/base.rb

The class names now have namespaces— that’s because they are in the products/ folder. You must always match the folder name to the namespace, but you will titleize the namespace and keep the folder names lowercase.

So our new Purse becomes

class Producs::Purse < Products::Base

end

And now, our Shirt becomes

class Products::Shirt < Products::Base

end

One last thing, in our Products::Base we’ll need to set the table name:

class Products::Base < ApplicationRecord
self.table_name = 'products'
end

Now, Rails knows how to magically load your files. Never do anything else– like put non-namespaced files into subfolders. That is a Very Bad Thing and Very Bad Things will happen to you if you do.

Remember, Rails will magically load all of your objects in models/ controllers/ but only when the name of the object matches exactly— including the namespace to it titleized form— with the name of your Ruby class. THE RAILS COACH

EXAMPLE APP FOR THIS POST CAN BE FOUND AT

https://github.com/the-rails-coach/rails-magic-autoloading

Categories
Coaching Series

UNINITIALIZED CONSTANT (INSIDE OF A RAKE TASK!)

This post is part of my Stepping Up Rails: Go From Good to Great series. Get the complete series on Teachable!

So you’re inside of a Rake task and you invoke an object in your app. In a classic blunder, your Rails app tells you

Uninitialized Constant: Thingy

What?! “Where’s Thingy!” you proclaim. It can’t be. You check the spelling. You double-check Rails’ object-file name to make sure it’s the same name as the object. (This way, Rails will autoload your file — there’s a post dedicated to that coming up in this series.) In other words, it checks out.

The Rake task: the Rails’ developer’s best friend. A utility knife of utility knives— the Rake task is where you get stuff done. But unfortunately not when it can’t find your Rails objects.

You can do all kinds of things in Rake tasks.

Background jobs are the primary function of Rake tasks.

For instance, queues are run in Rake tasks.

In other words, lots of Rails operates on Rake tasks. They are the underpinning of most SAAS (Software-As-A-Service) back-ends that are written in Ruby on Rails.

Remember you must always specify to the task the symbol :environment . That’s the key, like so:

task my_task: :environment do
  # do some stuff here
end

If you fail to do this, Rails will load your task, but won’t load your environment, so it won’t have access to your models or application objects. You’ll get funny errors, like Uninitialized Constant and the like.

Always remember, load your environment in Rake tasks.

Categories
Coaching Series

Who is N+1?

This post is part of my Stepping Up Rails: Go From Good to Great series. Get the complete series on Teachable!

Ahh, the elusive N+1 query. Perhaps you’ve heard of him from your engineering pit, cursed under the breath of engineers or beshrewed out load when such an engineer encounters an endpoint (or web request) that’s slow, slow, slow. The N+1 query is very often the culprit.

See, in web development, we like things fast, fast, fast. That is, we want our webpages to load really fast. (And typically that means 200ms or faster).

Let’s say you have a database of teachers and students. Your teachers have many students.

Teachers have many students

In Rails, this might be expressed as a Rails class Teacher that has_many :students.

Let’s load the students in the HAML via the association.

This teacher teacher.name has teacher.students.count students

When viewed in the browser, it might look something like so:

Example output showing count of studetns

Finally, if you examine the Rails console, you’ll see Rails makes 3 queries: 1) to load up the teacher, 2) to count the number of students (this is because I explicitly asked for the count of students) , and 3) it the loads all of the associated students in the final query.

Example SQL output showing count query

Let me propose making this slightly more complex to demonstrate how to create an N+1 query. Remember, N+1 queries are not something we want. I’m going to show you how to create an N+1 query and then how to fix it.

Teacher Student ReportCard ERD Entity Relationship Diagram

Students have many ReportCards. In this simple example, we’re going to be querying for the last report card for each student.

We have some HAML that looks like this:

ruby source code HAML showing teacher and students output

Here I want to show an unordered list of the name of the students and the last report card for each student.

When we run this, we’ll see this in our browser:

Students list example output showing report card with N+1 query

In our console, we will see:

Example console Rails log output showing N+1 queries

Take a look at that nasty N+1 query. See how repetitive it is? For these seven records, it might seem fast now. But as your app grows, your database server will strain and struggle to keep up.

Won’t Fly With N+1 Queries

While it might look trivial now, those “ReportCard Load” lines are telling you something important: Your app won’t scale with N+1 queries.

As a result of the object relational mapping (ORM) we are doing with Active Record, we will do something called pre-fetching. That’s when we tell Rails to fetch all of the ReportCards we will need to display quickly in one single query.

As you can see from the query, without telling Rails to side-load the related data, Rails must loop through the Student results as it fetches each of the “last” report cards for the student, causing it to query 8 times, 7 times for the report cards and once for the student (thus, “n + 1”). In fact, it does it the other way around, but we call the phenomenon “n+1” and not “1+n”.

As the developer you must know N+1 Queries

Using an ActiveRecord helper method called :includes(:____) we will chain this instruction to load the associated objects onto our ActiveRecord query.

(Do not confuse this with the ruby command include [singular], which is to load a Ruby file other than the one you are executing—they are unrelated: include is Ruby and looks like this

include ‘byebug’

.includes, on the other hand (notice the dot ‘.’) comes after an Active-Relation (also known as an “AREL”), like so:

@teacher.students.includes(:report_cards)

This directive tells Active Record to smartly fetch the student data in “as few queries as possible.” You will note I’ve put this in quotation marks because Rails actually does some advanced stuff under the hood to choose one of two loading strategies: JOINing the table in the original query or pre-fetching when the data is needed in a single, composite query for all of the associated Students.

using includes(:___) to prefetch

Notice in this example that Rails makes precisely two queries to the database (and remember, each query has overhead, or a time that it takes for the webserver to communicate with the database server and for the database server to process the request): once for the students and then again for all of the report cards.

SELECT `students`.* FROM `students` WHERE `students`.`teacher_id` = 4  [["teacher_id", 4]]

  ReportCard Load (0.6ms)  SELECT `report_cards`.* FROM `report_cards` WHERE `report_cards`.`student_id` IN (22, 23, 24, 25, 26, 27, 28)

Boom! Your N+1 query is gone. Take special note that Rails has queried for the students associated with teacher_id 4 and found that they all have ids of 22, 23, 24, 25, 26, 27, and 28. Since we only need those report cards records for the seven associated students, Rails has concatenated the ids of the students in the second query, to form the WHERE clause. As in: WHEREIN (22, 23, 24, 25, 26, 27, 28)

This technique is called pre-fetching or eager loading. We’re telling Rails that we’ll need the associated report_cards on each student when we are looping through the students.

Prefetching fixes N+1 queries

The key to fixing your N+1 queries is to realize that Active Record relations are instantiated in one place and then invoked “just-in-time,” that is, typically when the view is rendered.

N+1 query is fixed in the Rails log output

Now, finally, here there one more thing to note: AR has three different methods for loading your associations: includes, eager_load, and preload. A fourth method, joins, allows you to join a table in your SQL without necessarily loading the associated records.

Includes will load all of related the records referenced as arguments in the includes method. Typically includes will load the records like you see above (in a separate query using WHERE … IN (…) syntax)

However, if you have a where or order clause that references a relationship, includes will instead us a left outer join.

Rails has two ways of dealing with N+1s: 1) “big join” and 2) “separate queries.”

.includes — uses either strategy #1 or #2 depending on whether or not there is a where or order clause that references a relationship. .eager_load always uses strategy #1 and .preload uses #2.

I recommend that you always start with .includes. When your app gets large and your queries are slow, then you will be forced to optimize, which means measure and tweak your queries to make them faster. During this process is when you will experiment with .eager_load vs. .preload and determine on a case-by-case basis which one is most optimized for you.

I hope you’ve enjoyed this brief introduction to N+1 queries.

THE EXAMPLE APP FOR THIS POST CAN BE FOUND AT

https://github.com/the-rails-coach/who-is-en-plus-one

Categories
Coaching Series

Identity Crisis

This post is part of my Stepping Up Rails: Go From Good to Great series. Get the complete series on Teachable!

Javascript developers talk about the hoist, where a reference to a variable inside of a given scope in a section of code below affects code above it, effectively hoisting the variable up into the reserved namespace. Did you know that Rails has its own hoist effect?

This little puzzle comes in an oft-confused part of Rails & Ruby. The attribute getter (attr_getter) that is made available to all Rails ActiveRecord objects automatically.

Remember that a Ruby object has ApplicationRecord as its base object (or ActiveRecord::Base before Rails 5), and ApplicationRecord makes certain things available to the object-relational mapping (ORM), which is essentially what ActiveRecord is. This ORM is what marries the Ruby object to the database object. Think of ORM like a two-way tunnel— the Ruby object needs data so it pulls it from the database, the database takes data that is updated from the Ruby object.

But POROs (Plain Old Ruby Objects) don’t actually have a database behind them. Rails objects do. That’s where the ApplicationRecord magic comes in.

The Rails Magic Loading Getter

One quirk to remember for Rails developers is that inside of Ruby ApplicationRecord object, there’s a secret (and magic) getter for any attribute in your database. Let’s say in a Person class you might have

class Person < ApplicationRecord
  def name
    first_name + " " + last_name
  end
end

This works because Rails looks to the Ruby object first for a first_name and last_name. Assuming you haven’t overridden them, Rails doesn’t find them on your Ruby object and falls through to method_missing (that’s the secret method that is called when a Ruby object doesn’t have a method object— it’s how so much Ruby magic works.)

The method_missing implementation looks for these fields on the Rails class which now comes from the ORM (or the database). So basically it’s like having an attr_reader — or a ‘getter’ — automatically for any of your database fields.

But keep in mind this doesn’t work in reverse! There is no setter field that allows you to do first_name = "John"

That’s why when you’re setting a Rails object, you must always use the self keyword followed by dot (.)

self.first_name = “John”

Getter Not Setter For the Hoist

Now, you’ve told Rails to update the ORM-backed object. Why does this distinction matter? Well, first of all first_name = "John" doesn’t actually do what you intended it to do (you probably intended it to update the object’s first name). What it does is it creates a local variable in the local scope with the name first_name, which, confusingly, has no effect on the Rails object’s field first_name.

Consider this method on an object that checks if someone can make a request. The API rate limits their requests to 10 requests in a rolling, 10-second timeframe.

def can_make_request?
  unless last_request_at.nil?
    secs_since_last_request = (Time.now - last_request_at).floor

    requests_available += secs_since_last_request
    requests_available = [10, self.requests_available].min
  end
end

The intention of this code is to update the requests available to either 10 (if the last request was more than 10 seconds ago), or to add the number of seconds since the last request to the current count, but never allow the count to exceed 10. Unfortunately, we aren’t actually saving the data back to the database.

Dropping a byebug into this method reveals a curious thing:

def can_make_request?
  unless last_request_at.nil?
    secs_since_last_request = (Time.now - last_request_at).floor
   byebug
    requests_available += secs_since_last_request
    requests_available = [10, requests_available].min
  end
end

Here, if we ask for either id or name, we get it. But if we ask for requests_available, Rails tells us the result is nil.

Notice that we haven’t even modified requests_available, and unlike id and name, this field, even when read (with the getter) comes up as nil:

4:

5:   def can_make_request?

6:     unless last_request_at.nil?

7:       secs_since_last_request = (Time.now - last_request_at).floor

8:       byebug
=>  9:       requests_available += secs_since_last_request

   10:       requests_available = [10, self.requests_available].min

   11:     end

   12:   end

   13:   

(byebug) id

1

(byebug) name

"Cruickshank Inc"

(byebug) requests_available

nil

Ruby Hoist

How does that make sense?
Well, it’s the Ruby hoist we were talking about before, and it demonstrates why Rails provides only a getter and not a setter. You see, inside of the scope of can_make_request? Ruby has already seen on line 8 that we are going to use a local variable called requests_available. When we call it on line 8, we actually get nil because Ruby has already hoisted the variable’s definition and namespace to the top of the local scope, just like in Javascript.

Here, the local variable — which hasn’t even been set yet— is returned to us instead of the Rails getter that calls through to the database. (which you can see when we call id and name).

This is easily fixed! Just remember to use self. whenever we want to save information back to the object. (You will also need to actually save the object too!)

The basic rule of thumb is:

You can get a Rails database field using the magic getter that is its own name, but if you want to save back to the database, use self.____ = instead.

Categories
Coaching Series

MATZ IS NICE AND SO WE ARE NICE

This post is part of my Stepping Up Rails: Go From Good to Great series. Get the complete series on Teachable!

It is said of Ruby’s creator Yukihero Matsumoto, ‘Matz is Nice and So Are We.’ It is this mantra about the Ruby community and programming language, the vision of Rubyists with an ethical calling towards treating each other nicely— an interdependence, of a kind, on the transitive property of niceness (that is, that nice can be passed on from one individual to another).

When we code we are nice. We treat one another with dignity and respect; we are good to ourselves; and we are good to the codebase itself. We don’t try to fit ugly code into structures. We are nice to the codebase and we are nice to us. Matz is nice.

When we make something work well, we proclaim, ‘NICE!‘ as an expression of triumph. We are nice.

Nice is about being considerate. It requires human empathy to understand the other person. Matz is nice.

Nice means we put-up other people up instead of putting them down. We are nice.

Nice is how we design a system— with “just enough” knowledge to guide our choices now, and nicely extensible for the future. Matz is nice.

Nice, to many people, means courteous and pleasant. To Rubyists, it means that but so much more. It’s a way of thinking, it’s a way of being, it’s a core value. What we put in we get out and what we get back and give back.

Before it was a Linux operating system, “Ubuntu” was a South African spiritual philosophy:

I am because you are because I am

In our inter-disciplined practice of Ruby, We are Nice Because Matz is Nice and We are Nice Because We are Nice— it is the core of our modern approach to Ruby and the Rails ecosystem of developers.

So be nice, because it will come back to you 1000 times.