Forem: Meagan Waller

Reading Rails: Understanding how accepts_nested_attributes_for works

Meagan Waller — Sat, 27 Feb 2021 03:09:39 +0000

As I've progressed in my career as a software developer, I've found it extremely helpful to read not only documentation but also to read code. Early on in my career, this was a little bit intimidating, but it's a practice I highly recommend. Rails is a great codebase to read, especially if you're familiar with using Rails because so much of what we might view as magic is Ruby we can understand and read behind the scenes.

In a previous post we took a deep dive into how to use accepts_nested_attributes and has_many through to create complex nested forms. While writing that post, I took a dive into the Rails codebase to understand how accepts_nested_attributes actually works and found it interesting and wanted to share if this was something you may be curious about well.

When I'm looking for a method in a codebase, I search the method name in the search bar on the repo. Typing in accepts_nested_attributes_for takes me here.

The method accepts_nested_attributes_for looks like this:

def accepts_nested_attributes_for(*attr_names)
  options = { allow_destroy: false, update_only: false }
  options.update(attr_names.extract_options!)
  options.assert_valid_keys(:allow_destroy, :reject_if, :limit, :update_only)
  options[:reject_if] = REJECT_ALL_BLANK_PROC if options[:reject_if] == :all_blank

  attr_names.each do |association_name|
    if reflection = _reflect_on_association(association_name)
      reflection.autosave = true
      define_autosave_validation_callbacks(reflection)

      nested_attributes_options = self.nested_attributes_options.dup
      nested_attributes_options[association_name.to_sym] = options
      self.nested_attributes_options = nested_attributes_options

      type = (reflection.collection? ? :collection : :one_to_one)
      generate_association_writer(association_name, type)
    else
      raise ArgumentError, "No association found for name `#{association_name}'. Has it been defined yet?"
    end
  end
end

The interesting that we will be looking at is this line.

generate_association_writer(association_name, type)

This method is the crucial thing that feels like "magic" that rails is doing when you use accepts_nested_attributes_for. It defines an attributes writer for the specified attributes.

def generate_association_writer(association_name, type)
  generated_association_methods.module_eval <<-eoruby, __FILE__, __LINE__ + 1
    silence_redefinition_of_method :#{association_name}_attributes=
    def #{association_name}_attributes=(attributes)
      assign_nested_attributes_for_#{type}_association(:#{association_name}, attributes)
    end
  eoruby
end

Let's go through this line by line.

generated_association_methods.module_eval <<-eoruby, __FILE__, __LINE__ + 1

generated_association_methods is defined here.

def generated_association_methods
  @generated_association_methods ||= begin
    mod = const_set(:GeneratedAssociationMethods, Module.new)
    private_constant :GeneratedAssociationMethods
    include mod

    mod
  end
end

const_set is a Ruby method that sets the named constant to the given object and returns it. This method is inside the ClassMethods module, creating a module called GeneratedAssociationMethods in the model's namespace that the accepts_nested_attributes_for is defined. The pantry application in the previous blog post linked above creates this on-demand where we called accepts_nested_attributes_for. (On-demand meaning, when we first invoke those methods, on the /recipes and recipes/:id pages.)

Recipe::GeneratedAssociationMethods
Ingredient::GeneratedAssociationMethods
RecipeIngredient::GeneratedAssociationMethods

Side note: Something I like to do to get a handle on what's going on is to clone the codebase to my local machine and then point my gem in the Gemfile to the path where it lives. So this is in my Pantry Gemfile.

gem 'rails', path: '../rails'

Now in the local version of rails, I can add puts statements to inspect what's going on.

def generated_association_methods # :nodoc:
  @generated_association_methods ||= begin
    mod = const_set(:GeneratedAssociationMethods, Module.new)
    private_constant :GeneratedAssociationMethods
    include mod
    puts mod.inspect
    mod
  end
end

That allowed me to see what mod is.

Now, back to the method at hand.

def generate_association_writer(association_name, type)
  generated_association_methods.module_eval <<-eoruby, __FILE__, __LINE__ + 1
    silence_redefinition_of_method :#{association_name}_attributes=
    def #{association_name}_attributes=(attributes)
      assign_nested_attributes_for_#{type}_association(:#{association_name}, attributes)
    end
  eoruby
end

So we're creating a module at Recipe::GeneratedAssociationMethods, we're silencing the redefinition of the method (see what that means here). Next, we are creating a method inside of the newly created module and setting it dynamically to #{association_name}_attributes=(attributes). The association name for our Recipe example is recipe_ingredients. Now we have a method called def recipe_ingredients_attributes=(attributes) inside of our newly created module.

Now that recipe_ingredients_attributes might look familiar! Good catch if you thought that. We use this of our strong parameters.

def recipe_params
  params.require(:recipe).permit(:title, recipe_ingredients_attributes: [:amount, :description, :_destroy, :id, ingredient_attributes: [:name, :id]])
end

Now let's inspect what the type is. For our recipe, it's collection. This means that we need to find the method called assign_nested_attributes_for_collection_association, that lives here. The documentation for that method is well defined, we won't go into how this method works precisely. It assigns the attributes that get passed into it (in our example above, the hash with {amount:, description:, _destroy:, id:, ingredient_attributes: {name:, id:}}) to the collection association. It either updates the record if an id is given, creates a new one without an id, or destroys the record if _destroy is a truthy value.
It should be apparent why in our nested params, we need to have our nested attributes named a certain way because they are referring to method names that get dynamically created.

How I finally learned to get to inbox zero using Gmail filters

Meagan Waller — Tue, 23 Feb 2021 03:34:24 +0000

If you're anything like me, your Gmail inbox is a mess. You've signed up for newsletters, eCommerce site mailing lists, random software subscriptions, and tons of other content over the years, and now you've got something like thousands of unread emails. You have no real way of knowing what's urgent, you're continually missing important emails, aren't able to keep up with existing emails, and your inbox causes some anxiety in your everyday life. Maybe you've just decided to select all and delete everything with the promise to be better about staying on top of it. However, just hours after deleting, you've got dozens of new emails, and the cycle continues.

I've finally learned how to break through that cycle. I've organized my inbox. Only important or uncategorized emails come into my inbox, and the rest are categorized neatly into respective folders without me having to do anything except receiving the emails. Keep reading to break yourself from the neverending cycle of Gmail inbox overload.

Assessing & Unsubscribing

This first step will be the most intense and will take the most time. You need to go through what is currently in your inbox and decide to unsubscribe or keep. I don't recommend using any services that will allow you to roll-up and unsubscribe from emails in bulk because I haven't seen any that aren't just a front for collecting and selling your data 🤷‍♀️.

Let's take a look at the current state of my inbox. I've let it run a little wild and have subscribed to new newsletters to illustrate this step.

I will go through each of these emails and decide whether to unsubscribe or keep them. If I choose to unsubscribe, I will follow the unsubscribe link in the email, go through the unsubscribe process, and then I will delete every email from this source. I figure that if I'm unsubscribing, I probably won't need the past emails. This process may or may not be the case for each email, but it's usually my flow. To delete every email from this source, you'll need to open up the email, hit the "More" menu item at the top, click "Filter messages like these," and then Gmail will find all the emails from this email list, hit search. Now you can select all and delete.

You'll want to repeat this for the majority of the emails in your inbox. A reasonable cut-off is to do this for the last week or two of emails. Many older emails than that you'll probably want to mass delete and handle in this same way as they arrive in the coming days and weeks. You may want to tackle more than that, but for me, that task was too daunting, so I mass deleted my emails.

For emails you want to keep, don't do anything with them just yet; let them stay in your inbox. We will categorize them in a second.

Categorizing Emails You Want to Keep

Some might be sticklers for defining inbox zero as being every single email is read. I don't subscribe to that. I categorize my emails, and the ones in categories aren't necessarily priorities because they are expected emails. The emails in my labels are newsletters, online stores, receipts, etc. These aren't time-sensitive priorities, meaning anything that arrives in my inbox (potentially) needs my immediate attention. My inbox is where emails from individuals, new newsletters/subscriptions, or anything that I haven't already categorized will live.

My email workflow is to go through my inbox each morning, categorize any new emails using my filtering workflow, respond to other emails or defer them, but make sure to be aware of everything in my inbox. Employing this process also means that my notification for unread emails reflects actual unread, unanticipated emails.

For each email you want to keep, you'll want to go through the same flow as before, go into the email, click "Filter messages like these," and instead of pressing "Search," click "Create filter." I've got an email from Sezzle regarding a successful payment confirmation. The Sezzle email is from a financial institution, so I'm going to label it as 'Finances & Budget.' You can use whatever labeling conventions you want and create new labels or nested labels right inside the panel as needed.

Now, you'll want to repeat this process for each of the emails you want to keep. You can adjust the search values; for instance, you may receive multiple different types of emails from the same domain and categorize them differently by fine-tuning the search parameters. You can hone your filters and make them as specific or as general as you desire.

Here's a screenshot of all my labels. Occasionally I will go into the labels and do the unsubscribe process, especially if a category starts accumulating many emails or I find myself deleting without reading; this is most common in my "Online Shopping" category 😬.

Editing Existing Filters

This workflow serves me well for 99% of my use cases, but sometimes my filtering can be too general, and things get swept up into a category that I'm not expecting or don't want to be filtered or categorized in a certain way. To remedy your filters, click the cog icon in the top menu and go to "See All Settings," once in the settings menu, go to the "Filters and Blocked Addresses" tab and find the filter you want to edit.

Wrapping up

I hope this workflow serves you as well as it has for me. Implementing the filters is a high cost of time at first, but I've found that it has really paid off, and as long as I stay diligent with it, I feel in control of my inbox. Here's to taking control of our inboxes in 2021 and beyond. ✨

Convert Rows to Columns with Ruby's Transpose Method

Meagan Waller — Thu, 18 Feb 2021 20:43:51 +0000

The first time I used the transpose method, I was solving a particular problem. I was creating a tic-tac-toe game during my software apprenticeship. I had split up the game into a few classes. I had a class called Board that represented the tic-tac-toe board and was responsible for holding the board's state after each move. The Board class was initialized with an array called spaces to represent the board's spaces; the default was an array with nine spaces [0, 1, 2, 3, 4, 5, 6, 7, 8]. I had a method that would return the rows named rows.

def rows
  [@spaces[0..2],
   @spaces[3..5],
   @spaces[6..8]]
end

I also needed a method to give me the columns. I could have written something like this.

def columns
  [@spaces[0], @spaces[3], @spaces[6],
   @spaces[1], @spaces[4], @spaces[7],
   @spaces[2], @spaces[5], @spaces[8]]
end

But instead, my method took advantage of Ruby's transpose method.

def columns
  rows.transpose
end

Transpose turned my rows into columns, and this was a fair use case for this because I was able to create a method that held all the possible winning solutions for a game. You win by getting your marker in 3 consecutive spaces in tic-tac-toe, either across a row, a column or diagonally.

def winning_solutions
  winning_solutions = []
  rows.map { |row| winning_solutions << row }
  columns.map { |col| winning_solutions << col }
  winning_solutions << diagonal_ltr
  winning_solutions << diagonal_rtl
end

def diagonal_ltr
  [@spaces[0], @spaces[4], @spaces[8]]
end

def diagonal_rtl
  [@spaces[2], @spaces[4], @spaces[6]]
end

(Disclaimer for the above code: I wrote this code only months into my software journey, I would do things differently now.)

Transposing is perfect when you have a grid and want to transform the rows into columns for easy access.

Use a nested dynamic form with a has_many :through association in Rails.

Meagan Waller — Sun, 17 Jan 2021 16:39:12 +0000

`has_many :through` at a high-level.

A has_many :through association is how we setup many-to-many connections with another model. When we define a has_many :through relationship on a model, we're saying that we can potentially link the model to another model by going through a third model. I think the Rails guides do a great job of illustrating an example of how to use this relationship. Let's think of a different example. Say we have a company, a company has employees through an employment.

class Company < ApplicationRecord
  has_many :employments
  has_many :employees, through: :employments
end

class Employment < ApplicationRecord
  belongs_to :employee
  belongs_to :company
end

class Employee < ApplicationRecord
  has_many :employments
  has_many :companies, through: :employments
end

Our migrations would look like this:

class CreateCompanies < ActiveRecord::Migration[6.0]
  def change
    create_table :companies do |t|
      t.string :name
      t.timestamps
    end

    create_table :employees do |t|
      t.string :name
      t.timestamps
    end

    create_table :employments do |t|
      t.belongs_to :employee
      t.belongs_to :company
      t.datetime :start_date
      t.datetime :end_date
      t.string :role
      t.timestamps
    end
  end
end

When an employee "leaves" a company, we don't have to create the employee all over again. We make a new employment linked to their employee record and their new company.

When should I reach for `has_many :through`

In the example above, we touched on when you should go for this association type. We don't want an employee tied to a company. We want there to be some intermediary relationship that links the two things together. In this case, it's because we want to store some extra data on the employment table, like start date, end date, and role name. An employee will have multiple employments throughout their life. Now we have a table that keeps track of them. A relationship allows us to ask employee.companies and shortcut through the employments relationship to grab all the companies for which an employee has worked. My advice is to reach for has_many :through when you need additional data on the association.

Introducing Pantry

I'm big on meal prepping, recipe saving, and cooking in general. I thought a recipe organization application would be a great example because it is interesting, fresh (not a to-do app!), and provides some potential challenges.

Pantry will be the name of the application that we'll be building to illustrate how to use has_many :through, nested forms, nested_attributes, and dynamic fields using a third-party library. Let's get started.

First, we need to set requirements, expectations and then think through this application's business logic/relationships.

Pantry is a proof-of-concept application. There will be no extraneous styling or interactivity. We're talking bare bones to illustrate a concept only. We will create a recipe using a form, and a recipe has a name and ingredients. Ingredients have a name, an amount, and a description.

I think our relationships will likely look something like this:

There are many more attributes each of these could have, and I might expand on that in a future blog post to illustrate other concepts, but we are keeping it as simple as possible for now.

Getting started

Before we dive in, you can find the completed code here. I will break out each section into branches and link them as we get to them.

I'm using Rails version 6.1.1 and Ruby version 2.7.2.

First things first, we need to create our Rails application:

rails new pantry
cd pantry
rails db:create
rails webpacker:install

(You may not have to do the webpacker:install step, I did because I didn't have yarn installed already.)

Now we can view our rails application at localhost:3000.

rails server

Creating the models

First, we will create the Recipe.

rails g model Recipe title

And the migration this generation creates.

class CreateRecipes < ActiveRecord::Migration[6.1]
  def change
    create_table :recipes do |t|
      t.string :title

      t.timestamps
    end
  end
end

Next, let's create the Ingredient.

rails g model Ingredient name

And the migration this generation creates.

class CreateIngredients < ActiveRecord::Migration[6.1]
  def change
    create_table :ingredients do |t|
      t.string :name

      t.timestamps
    end
  end
end

Last, we create RecipeIngredient.

rails g model RecipeIngredient amount description recipe:belongs_to ingredient:belongs_to

And the migration this generation creates.

class CreateRecipeIngredients < ActiveRecord::Migration[6.1]
  def change
    create_table :recipe_ingredients do |t|
      t.string :amount
      t.string :description
      t.belongs_to :recipe, null: false, foreign_key: true
      t.belongs_to :ingredient, null: false, foreign_key: true

      t.timestamps
    end
  end
end

We are going to add an index to the belongs_to fields.

class CreateRecipeIngredients < ActiveRecord::Migration[6.1]
  def change
    create_table :recipe_ingredients do |t|
      t.string :amount
      t.string :description
      t.belongs_to :recipe, null: false, foreign_key: true
      t.belongs_to :ingredient, null: false, foreign_key: true

      t.timestamps
    end
  end
end

Now, let's run the migrations!

rails db:migrate

Set up the associations inside of our models.

app/models/recipe.rb

class Recipe < ApplicationRecord
  has_many :recipe_ingredients
  has_many :ingredients, through: :recipe_ingredients
end

app/models/ingredient.rb

class Ingredient < ApplicationRecord
  has_many :recipe_ingredients
  has_many :recipes, through: :recipe_ingredients
end

app/models/recipe_ingredient.rb

class RecipeIngredient < ApplicationRecord
  belongs_to :recipe
  belongs_to :ingredient
end

Let's import the recipe for Best Ever Grilled Cheese Sandwich into our seeds file.

db/seeds.rb

grilled_cheese = Recipe.create(title: "Grilled Cheese")
butter = Ingredient.create(name: "Butter")
bread = Ingredient.create(name: "Sourdough Bread")
mayonnaise = Ingredient.create(name: "Mayonnaise")
manchego_cheese = Ingredient.create(name: "Manchego Cheese")
onion_powder = Ingredient.create(name: "Onion Powder")
white_cheddar = Ingredient.create(name: "Sharp White Cheddar Cheese")
monterey_jack = Ingredient.create(name: "Monterey Jack Cheese")
gruyere_cheese = Ingredient.create(name: "Gruyere Cheese")
brie_cheese = Ingredient.create(name: "Brie Cheese")

RecipeIngredient.create(recipe: grilled_cheese, ingredient: butter, amount: "6 tbsp", description: "softened, divided")
RecipeIngredient.create(recipe: grilled_cheese, ingredient: bread, amount: "8 slices")
RecipeIngredient.create(recipe: grilled_cheese, ingredient: mayonnaise, amount: "3 tbsp")
RecipeIngredient.create(recipe: grilled_cheese, ingredient: manchego_cheese, amount: "3 tbsp", description: "finely shredded")
RecipeIngredient.create(recipe: grilled_cheese, ingredient: onion_powder, amount: "1/8 tsp")
RecipeIngredient.create(recipe: grilled_cheese, ingredient: white_cheddar, amount: "1/2 cup", description: "shredded")
RecipeIngredient.create(recipe: grilled_cheese, ingredient: gruyere_cheese, amount: "1/2 cup", description: "shredded")
RecipeIngredient.create(recipe: grilled_cheese, ingredient: brie_cheese, amount: "4 oz", description: "rind removed and sliced")

When we run this rails task, it will execute the contents of the db/seeds.rb file.

rails db:seed

We can check out what our data looks like in the rails console.

# In the rails console
± rails c

irb(main):005:0> Recipe.first
  Recipe Load (0.1ms)  SELECT "recipes".* FROM "recipes" ORDER BY "recipes"."id" ASC LIMIT ?  [["LIMIT", 1]]
=> #<Recipe id: 3, title: "Grilled Cheese", created_at: "2021-01-14 02:05:16.753424000 +0000", updated_at: "2021-01-14 02:05:16.753424000 +0000">
irb(main):006:0> Recipe.first.ingredients
  Recipe Load (0.2ms)  SELECT "recipes".* FROM "recipes" ORDER BY "recipes"."id" ASC LIMIT ?  [["LIMIT", 1]]
  Ingredient Load (0.2ms)  SELECT "ingredients".* FROM "ingredients" INNER JOIN "recipe_ingredients" ON "ingredients"."id" = "recipe_ingredients"."ingredient_id" WHERE "recipe_ingredients"."recipe_id" = ? /* loading for inspect */ LIMIT ?  [["recipe_id", 3], ["LIMIT", 11]]
=> #<ActiveRecord::Associations::CollectionProxy [#<Ingredient id: 16, name: "Butter", created_at: "2021-01-14 02:05:16.762877000 +0000", updated_at: "2021-01-14 02:05:16.762877000 +0000">, #<Ingredient id: 17, name: "Sourdough Bread", created_at: "2021-01-14 02:05:16.766733000 +0000", updated_at: "2021-01-14 02:05:16.766733000 +0000">, #<Ingredient id: 18, name: "Mayonnaise", created_at: "2021-01-14 02:05:16.770198000 +0000", updated_at: "2021-01-14 02:05:16.770198000 +0000">, #<Ingredient id: 19, name: "Manchego Cheese", created_at: "2021-01-14 02:05:16.773554000 +0000", updated_at: "2021-01-14 02:05:16.773554000 +0000">, #<Ingredient id: 20, name: "Onion Powder", created_at: "2021-01-14 02:05:16.776771000 +0000", updated_at: "2021-01-14 02:05:16.776771000 +0000">, #<Ingredient id: 21, name: "Sharp White Cheddar Cheese", created_at: "2021-01-14 02:05:16.779594000 +0000", updated_at: "2021-01-14 02:05:16.779594000 +0000">, #<Ingredient id: 23, name: "Gruyere Cheese", created_at: "2021-01-14 02:05:16.784709000 +0000", updated_at: "2021-01-14 02:05:16.784709000 +0000">, #<Ingredient id: 24, name: "Brie Cheese", created_at: "2021-01-14 02:05:16.789495000 +0000", updated_at: "2021-01-14 02:05:16.789495000 +0000">]>
irb(main):007:0> Recipe.first.recipe_ingredients
  Recipe Load (0.1ms)  SELECT "recipes".* FROM "recipes" ORDER BY "recipes"."id" ASC LIMIT ?  [["LIMIT", 1]]
  RecipeIngredient Load (0.2ms)  SELECT "recipe_ingredients".* FROM "recipe_ingredients" WHERE "recipe_ingredients"."recipe_id" = ? /* loading for inspect */ LIMIT ?  [["recipe_id", 3], ["LIMIT", 11]]
=> #<ActiveRecord::Associations::CollectionProxy [#<RecipeIngredient id: 5, amount: "6 tbsp", description: "softened, divided", recipe_id: 3, ingredient_id: 16, created_at: "2021-01-14 02:05:16.801631000 +0000", updated_at: "2021-01-14 02:05:16.801631000 +0000">, #<RecipeIngredient id: 6, amount: "8 slices", description: nil, recipe_id: 3, ingredient_id: 17, created_at: "2021-01-14 02:05:16.805122000 +0000", updated_at: "2021-01-14 02:05:16.805122000 +0000">, #<RecipeIngredient id: 7, amount: "3 tbsp", description: nil, recipe_id: 3, ingredient_id: 18, created_at: "2021-01-14 02:05:16.808517000 +0000", updated_at: "2021-01-14 02:05:16.808517000 +0000">, #<RecipeIngredient id: 8, amount: "3 tbsp", description: "finely shredded", recipe_id: 3, ingredient_id: 19, created_at: "2021-01-14 02:05:16.812203000 +0000", updated_at: "2021-01-14 02:05:16.812203000 +0000">, #<RecipeIngredient id: 9, amount: "1/8 tsp", description: nil, recipe_id: 3, ingredient_id: 20, created_at: "2021-01-14 02:05:16.815748000 +0000", updated_at: "2021-01-14 02:05:16.815748000 +0000">, #<RecipeIngredient id: 10, amount: "1/2 cup", description: "shredded", recipe_id: 3, ingredient_id: 21, created_at: "2021-01-14 02:05:16.819594000 +0000", updated_at: "2021-01-14 02:05:16.819594000 +0000">, #<RecipeIngredient id: 11, amount: "1/2 cup", description: "shredded", recipe_id: 3, ingredient_id: 23, created_at: "2021-01-14 02:05:16.825120000 +0000", updated_at: "2021-01-14 02:05:16.825120000 +0000">, #<RecipeIngredient id: 12, amount: "4 oz", description: "rind removed and sliced", recipe_id: 3, ingredient_id: 24, created_at: "2021-01-14 02:05:16.829869000 +0000", updated_at: "2021-01-14 02:05:16.829869000 +0000">]>

Now, let's create another recipe that uses some of the same ingredients. I'll be using this Gruyere and White Cheddar Mac and Cheese recipe.

db/seeds.rb

# Creating another recipe that uses some of the same ingredients, switch to find_or_create_by so I don't create duplicate records.
grilled_cheese = Recipe.find_or_create_by(title: "Grilled Cheese")
mac = Recipe.find_or_create_by(title: "Gruyere and White Cheddar Mac and Cheese")


butter = Ingredient.find_or_create_by(name: "Butter")
bread = Ingredient.find_or_create_by(name: "Sourdough Bread")
mayonnaise = Ingredient.find_or_create_by(name: "Mayonnaise")
manchego_cheese = Ingredient.find_or_create_by(name: "Manchego Cheese")
onion_powder = Ingredient.find_or_create_by(name: "Onion Powder")
white_cheddar = Ingredient.find_or_create_by(name: "Sharp White Cheddar Cheese")
monterey_jack = Ingredient.find_or_create_by(name: "Monterey Jack Cheese")
gruyere_cheese = Ingredient.find_or_create_by(name: "Gruyere Cheese")
brie_cheese = Ingredient.find_or_create_by(name: "Brie Cheese")
elbows = Ingredient.find_or_create_by(name: "Elbow Macaroni")
breadcrumbs = Ingredient.find_or_create_by(name: "Seasoned Breadcrumbs")
flour = Ingredient.find_or_create_by(name: "Flour")
milk = Ingredient.find_or_create_by(name: "Milk")
half_and_half = Ingredient.find_or_create_by(name: "Half and Half")
nutmeg = Ingredient.find_or_create_by(name: "Nutmeg")
salt = Ingredient.find_or_create_by(name: "Salt")
pepper = Ingredient.find_or_create_by(name: "Pepper")
parmigiano = Ingredient.find_or_create_by(name: "Parmigiano Reggiano")
olive_oil = Ingredient.find_or_create_by(name: "Olive Oil")

RecipeIngredient.find_or_create_by(recipe: grilled_cheese, ingredient: butter, amount: "6 tbsp", description: "softened, divided")
RecipeIngredient.find_or_create_by(recipe: grilled_cheese, ingredient: bread, amount: "8 slices")
RecipeIngredient.find_or_create_by(recipe: grilled_cheese, ingredient: mayonnaise, amount: "3 tbsp")
RecipeIngredient.find_or_create_by(recipe: grilled_cheese, ingredient: manchego_cheese, amount: "3 tbsp", description: "finely shredded")
RecipeIngredient.find_or_create_by(recipe: grilled_cheese, ingredient: onion_powder, amount: "1/8 tsp")
RecipeIngredient.find_or_create_by(recipe: grilled_cheese, ingredient: white_cheddar, amount: "1/2 cup", description: "shredded")
RecipeIngredient.find_or_create_by(recipe: grilled_cheese, ingredient: gruyere_cheese, amount: "1/2 cup", description: "shredded")
RecipeIngredient.find_or_create_by(recipe: grilled_cheese, ingredient: brie_cheese, amount: "4 oz", description: "rind removed and sliced")

RecipeIngredient.find_or_create_by(recipe: mac, ingredient: elbows, amount: "1 lb")
RecipeIngredient.find_or_create_by(recipe: mac, ingredient: gruyere_cheese, amount: "1 lb", description: "grated")
RecipeIngredient.find_or_create_by(recipe: mac, ingredient: white_cheddar, amount: "1 lb", description: "grated")
RecipeIngredient.find_or_create_by(recipe: mac, ingredient: breadcrumbs, amount: "1/3 cup")
RecipeIngredient.find_or_create_by(recipe: mac, ingredient: butter, amount: "1/2 stick")
RecipeIngredient.find_or_create_by(recipe: mac, ingredient: flour, amount: "1/4 cup")
RecipeIngredient.find_or_create_by(recipe: mac, ingredient: milk, amount: "3 cup")
RecipeIngredient.find_or_create_by(recipe: mac, ingredient: half_and_half, amount: "1 cup")
RecipeIngredient.find_or_create_by(recipe: mac, ingredient: nutmeg, amount: "pinch")
RecipeIngredient.find_or_create_by(recipe: mac, ingredient: salt, description: "to taste")
RecipeIngredient.find_or_create_by(recipe: mac, ingredient: pepper, description: "to taste")
RecipeIngredient.find_or_create_by(recipe: mac, ingredient: parmigiano, description: "to taste")
RecipeIngredient.find_or_create_by(recipe: mac, ingredient: olive_oil)

We can jump back into the rails console and see our new data.

± rails c

irb(main):001:0> Recipe.first
=> #<Recipe id: 3, title: "Grilled Cheese", created_at: "2021-01-14 02:05:16.753424000 +0000", updated_at: "2021-01-14 02:05:16.753424000 +0000">
irb(main):002:0> Recipe.last
=> #<Recipe id: 4, title: "Gruyere and White Cheddar Mac and Cheese", created_at: "2021-01-14 02:15:40.205860000 +0000", updated_at: "2021-01-14 02:15:40.205860000 +0000">
irb(main):003:0> Ingredient.count
=> 19
irb(main):004:0> RecipeIngredient.count
=> 21

See the code at this point

Creating controllers

We're going to create our controller. We won't have a way to make standalone ingredients, so we only need a recipe controller.

rails g controller recipes

Let's setup our routes now.

config/routes.rb

Rails.application.routes.draw do
  resources :recipes
end

We can see what using the resources method in our routes provided for us.

± rails routes | grep recipes

recipes     GET    /recipes(.:format)                recipes#index
            POST   /recipes(.:format)                recipes#create
new_recipe  GET    /recipes/new(.:format)            recipes#new
edit_recipe GET    /recipes/:id/edit(.:format)       recipes#edit
recipe      GET    /recipes/:id(.:format)            recipes#show
            PATCH  /recipes/:id(.:format)            recipes#update
            PUT    /recipes/:id(.:format)            recipes#update
            DELETE /recipes/:id(.:format)            recipes#destroy

Let's flesh out our controller.

First, let's start up the Rails server.

rails s

Go to localhost:3000/recipes in your browser. You should see an error. Let's fix that.

app/controllers/recipes_controller.rb

class RecipesController < ApplicationController

  def index
    @recipes = Recipe.all
  end
end

app/views/recipes/index.html.erb

<h1>Recipes</h1>

<% @recipes.each do |recipe| %>
  <h2>
    <%= recipe.title %>
  </h2>

  <ul>
  <% recipe.recipe_ingredients.each do |recipe_ingredient| %>
    <li>
      <%= recipe_ingredient.amount %> <%= recipe_ingredient.ingredient.name %>, <%= recipe_ingredient.description %>
    </li>
  <% end %>
  </ul>
<% end %>

Now refresh to see our index. We will see our listing of the recipes we created.

app/controllers/recipes_controller.rb

class RecipesController < ApplicationController

  def index
    @recipes = Recipe.all
  end

  def show
    @recipe = Recipe.find(params[:id])
  end
end

app/views/recipes/show.html.erb

<h1><%= @recipe.title %></h1>

<ul>
  <% @recipe.recipe_ingredients.each do |recipe_ingredient| %>
    <li>
      <%= recipe_ingredient.amount %> <%= recipe_ingredient.ingredient.name %>, <%= recipe_ingredient.description %>
    </li>
  <% end %>
</ul>

<%= link_to "Back to all recipes", recipes_path %>

Visit this page by going to localhost:3000/recipes/RECIPE_ID_HERE, find the recipe id in your console, Recipe.first.id, etc.

app/controllers/recipes_controller.rb

class RecipesController < ApplicationController

  def index
    @recipes = Recipe.all
  end

  def show
    @recipe = Recipe.find(params[:id])
  end

  def new
    @recipe = Recipe.new
  end
end

app/views/recipes/new.html.erb

<h1>Create a new recipe</h1>

<%= form_with model: @recipe do |form| %>
  <%= form.text_field :title, placeholder: "Recipe Title" %>
  <%= form.submit %>
<% end %>

Visit this page at localhost:3000/recipes/new. If you try and create a recipe, you will get an error because our create action isn't defined yet.

app/controllers/recipes_controller.rb

class RecipesController < ApplicationController

  def index
    @recipes = Recipe.all
  end

  def show
    @recipe = Recipe.find(params[:id])
  end

  def new
    @recipe = Recipe.new
  end

  def create
    @recipe = Recipe.create(recipe_params)

    if @recipe.save
      redirect_to @recipe
    else
      render action: "new"
    end
  end

  protected
  def recipe_params
    params.require(:recipe).permit(:title)
  end
end

Refresh the new page and create a recipe. You'll see that we're able to save a recipe without a title. Let's add a validation to ensure every recipe at least has a title.

app/models/recipe.rb

class Recipe < ApplicationRecord
  has_many :recipe_ingredients
  has_many :ingredients, through: :recipe_ingredients

  validates_presence_of :title
end

Now we get kicked back to the new page. We're not going to worry about flash messages or anything at this time. We might find we need them later, though.

Let's add our edit action now.

app/controllers/recipes_controller.rb

class RecipesController < ApplicationController

  def index
    @recipes = Recipe.all
  end

  def show
    @recipe = Recipe.find(params[:id])
  end

  def new
    @recipe = Recipe.new
  end

  def create
    @recipe = Recipe.create(recipe_params)

    if @recipe.save
      redirect_to @recipe
    else
      render action: "new"
    end
  end

  def edit
    @recipe = Recipe.find(params[:id])
  end

  protected
  def recipe_params
    params.require(:recipe).permit(:title)
  end
end

app/views/recipes/edit.html.erb

<h1>Edit <%= @recipe.title %></h1>

<%= form_with model: @recipe do |form| %>
  <%= form.text_field :title, placeholder: "Recipe Title" %>
  <%= form.submit %>
<% end %>

Visit the edit page of a recipe with localhost:3000/recipes/RECIPE_ID/edit. Once again, we'll see that we can't edit a recipe because the update action doesn't exist yet.

app/controllers/recipes_controller.rb

class RecipesController < ApplicationController

  def index
    @recipes = Recipe.all
  end

  def show
    @recipe = Recipe.find(params[:id])
  end

  def new
    @recipe = Recipe.new
  end

  def create
    @recipe = Recipe.create(recipe_params)

    if @recipe.save
      redirect_to @recipe
    else
      render action: "new"
    end
  end

  def edit
    @recipe = Recipe.find(params[:id])
  end

  def update
    @recipe = Recipe.find(params[:id])

    if @recipe.update(recipe_params)
      redirect_to @recipe
    else
      render action: "edit"
    end
  end

  protected
  def recipe_params
    params.require(:recipe).permit(:title)
  end
end

Now try and edit a recipe.

Lastly, let's add an action to destroy a recipe, we won't go over deleting recipes in this tutorial, but we've added it to our controller for completion's sake. At the end of this tutorial, I have ideas to further this application. Adding deletion functionality is one enhancement you could add.

class RecipesController < ApplicationController

  def index
    @recipes = Recipe.all
  end

  def show
    @recipe = Recipe.find(params[:id])
  end

  def new
    @recipe = Recipe.new
  end

  def create
    @recipe = Recipe.create(recipe_params)

    if @recipe.save
      redirect_to @recipe
    else
      render action: "new"
    end
  end

  def edit
    @recipe = Recipe.find(params[:id])
  end

  def update
    @recipe = Recipe.find(params[:id])

    if @recipe.update(recipe_params)
      redirect_to @recipe
    else
      render action: "edit"
    end
  end

  def destroy
    @recipe = Recipe.find(params[:id])
    @recipe.destroy

    redirect_to recipes_url
  end

  protected
  def recipe_params
    params.require(:recipe).permit(:title)
  end
end

In our recipes form, we're only inputting the title of the recipe. In the next section, we will look into how to create a nested form to add ingredients to a recipe.

View all the code up to this point

Rendering nested forms

We want to create recipe_ingredients when we make a recipe. We do that by using the fields_for that Rails form builder provides. For now, we will only include one field on the recipe_ingredient fields to keep this focused.

app/views/recipes/new.html.erb

<h1>Create a new recipe</h1>

<%= form_with model: @recipe do |recipe_form| %>
  <%= recipe_form.text_field :title, placeholder: "Recipe Title" %>
  <h2>Ingredients</h2>
  <%= recipe_form.fields_for :recipe_ingredients do |recipe_ingredient_form| %>
    <%= recipe_ingredient_form.text_field :amount, placeholder: "Amount" %>
  <% end %>

  <br />
  <%= recipe_form.submit %>
<% end %>

Now go to the new recipe page and create a recipe with a recipe_ingredient amount.

Let's go into the rails console and see what we just created.

± rails c
irb(main):001:0> Recipe.last
   (2.0ms)  SELECT sqlite_version(*)
  Recipe Load (0.1ms)  SELECT "recipes".* FROM "recipes" ORDER BY "recipes"."id" DESC LIMIT ?  [["LIMIT", 1]]
=> #<Recipe id: 7, title: "Cheesy Broccoli", created_at: "2021-01-14 15:26:17.638397000 +0000", updated_at: "2021-01-14 15:26:17.638397000 +0000">
irb(main):002:0> Recipe.last.recipe_ingredients
  Recipe Load (0.1ms)  SELECT "recipes".* FROM "recipes" ORDER BY "recipes"."id" DESC LIMIT ?  [["LIMIT", 1]]
  RecipeIngredient Load (0.4ms)  SELECT "recipe_ingredients".* FROM "recipe_ingredients" WHERE "recipe_ingredients"."recipe_id" = ? /* loading for inspect */ LIMIT ?  [["recipe_id", 7], ["LIMIT", 11]]
=> #<ActiveRecord::Associations::CollectionProxy []>

Our recipe has no recipe ingredients associated with it. Hmmm 🤔. Let's take a look at the logs when we submitted the form.

Started POST "/recipes" for 127.0.0.1 at 2021-01-14 10:26:17 -0500
Processing by RecipesController#create as HTML
  Parameters: {"authenticity_token"=>"[FILTERED]", "recipe"=>{"title"=>"Cheesy Broccoli", "recipe_ingredients"=>{"amount"=>"1 cup"}}, "commit"=>"Create Recipe"}
  Unpermitted parameter: :recipe_ingredients

Aha! There's the culprit. We tried to pass a parameter that our recipe_params method doesn't know about, recipe_ingredients. Let's remedy that.

Nested Attributes

Rails nested attributes have this naming convention. We append _attributes to the end of the collection name. We won't go into why/how it works, be aware that even though the parameters we saw above showed recipe_ingredients, we need to name them the way rails expect inside our recipe_params.

app/controllers/recipes_controller.rb

def recipe_params
  params.require(:recipe).permit(:title, recipe_ingredients_attributes: [:amount])
end

Okay, should we working now! Let's try and save a new recipe and check out the logs.

Started POST "/recipes" for 127.0.0.1 at 2021-01-14 10:31:26 -0500
Processing by RecipesController#create as HTML
  Parameters: {"authenticity_token"=>"[FILTERED]", "recipe"=>{"title"=>"Spaghetti", "recipe_ingredients"=>{"amount"=>"28 oz"}}, "commit"=>"Create Recipe"}
Unpermitted parameter: :recipe_ingredients

Still unpermitted! Because we have to tell the Recipe model to accept the nested attributes for recipe_ingredients (this accepts_nested_attributes is where Rails creates the #{model_name}_attributes method that it's using inside of the recipe_params.)

app/models/recipe.rb

class Recipe < ApplicationRecord
  has_many :recipe_ingredients
  has_many :ingredients, through: :recipe_ingredients

  validates_presence_of :title

  accepts_nested_attributes_for :recipe_ingredients
end

When we refresh the new page, we'll find that no field shows up on our form for recipe_ingredients. That's because we've got to build our first recipe_ingredient inside of the new action.

app/controllers/recipes_controller.rb

def new
  @recipe = Recipe.new
  @recipe.recipe_ingredients.build
end

Finally! We've got the recipe ingredient field showing. We're accepting nested attributes. Let's try to create a recipe with a recipe_ingredient on it.

Still not creating, and now the form is re-rendering new. At this point, we need to add flash messages so we can see errors in the form.

Adding flash notices

Inside of our controller, we're going to use the standard Rails way of creating and rendering flash messages for our create action.

app/controllers/recipes_controller.rb

def create
  @recipe = Recipe.new(recipe_params)
  respond_to do |format|
    if @recipe.save
      format.html { redirect_to @recipe, notice: "Recipe was successfully created."}
      format.json { render :show, status: :created, location: @recipe }
    else
      format.html { render :new }
      format.json { render json: @recipe.errors, status: :unproccessable_entity }
    end
  end
end

Below is the standard Rails way of rendering errors in a form.

app/views/recipes/new.html.erb

<h1>Create a new recipe</h1>

<%= form_with model: @recipe do |recipe_form| %>
  <% if @recipe.errors.any? %>
    <div id="error_explanation">
      <h2><%= pluralize(@recipe.errors.count, "error") %> prohibited this recipe from being saved:</h2>
      <ul>
      <% @recipe.errors.full_messages.each do |message| %>
        <li><%= message %></li>
      <% end %>
      </ul>
    </div>
  <% end %>

  <%= recipe_form.text_field :title, placeholder: "Recipe Title" %>
  <h2>Ingredients</h2>
  <%= recipe_form.fields_for :recipe_ingredients do |recipe_ingredient_form| %>
    <%= recipe_ingredient_form.text_field :amount, placeholder: "Amount" %>
  <% end %>

  <br />
  <%= recipe_form.submit %>
<% end %>

When we try and create our recipe again, we can see the error: Recipe ingredients, ingredient must exist. Okay, let's make an ingredient when we create a recipe_ingredient.

app/views/recipes/new.html.erb

<h1>Create a new recipe</h1>

<%= form_with model: @recipe do |recipe_form| %>
  <% if @recipe.errors.any? %>
    <div id="error_explanation">
      <h2><%= pluralize(@recipe.errors.count, "error") %> prohibited this recipe from being saved:</h2>
      <ul>
      <% @recipe.errors.full_messages.each do |message| %>
        <li><%= message %></li>
      <% end %>
      </ul>
    </div>
  <% end %>

  <%= recipe_form.text_field :title, placeholder: "Recipe Title" %>
  <h2>Ingredients</h2>
  <%= recipe_form.fields_for :recipe_ingredients do |recipe_ingredient_form| %>
    <%= recipe_ingredient_form.text_field :amount, placeholder: "Amount" %>
    <%= recipe_ingredient_form.fields_for :ingredient do |ingredient_form| %>
      <%= ingredient_form.text_field :name %>
    <% end %>
  <% end %>

  <br />
  <%= recipe_form.submit %>
<% end %>

We've added a nested fields_for inside of our recipe_ingredients fields_for, this time for an ingredient, and it's got one field, a text field for its name. Let's create a recipe and view the logs and see what's happening.

Started POST "/recipes" for 127.0.0.1 at 2021-01-14 10:51:28 -0500
Processing by RecipesController#create as HTML
  Parameters: {"authenticity_token"=>"[FILTERED]", "recipe"=>{"title"=>"Macaroni", "recipe_ingredients_attributes"=>{"0"=>{"amount"=>"1lb", "ingredient"=>{"name"=>"Elbow Noodles"}}}}, "commit"=>"Create Recipe"}
Unpermitted parameter: :ingredient

Alright, this is the same thing we saw above with recipe_ingredients. We know exactly how to tackle this.

app/controllers/recipes_controller.rb

def recipe_params
  params.require(:recipe).permit(:title, recipe_ingredients_attributes: [:amount, ingredient_attributes: [:name]])
end

We're still getting the same error:

1 error prohibited this recipe from being saved:

    Recipe ingredients ingredient must exist

We still need to make sure that recipe_ingredients accept the ingredients nested attributes. Look at our recipe_params, ingredients_attributes is nested inside recipe_ingredients_attributes.

app/models/recipe_ingredient.rb

class RecipeIngredient < ApplicationRecord
  belongs_to :recipe
  belongs_to :ingredient

  accepts_nested_attributes_for :ingredient
end

Like before, when we added the accepts_nested_attributes_for :recipe_ingredients to Recipe, the form for the ingredient isn't showing up. We need to build the initial recipe_ingredient in our controller.

app/controllers/recipes_controller.rb

def new
  @recipe = Recipe.new
  @recipe.recipe_ingredients.build.build_ingredient
end

Now we can save our recipe with recipe ingredients!

Adding more recipe ingredients to a recipe

Okay, but no recipe requires only one recipe ingredient. How do we add more to the form? You could build them all inside of the controller.

app/controllers/recipes_controller.rb

def new
  @recipe = Recipe.new
  10.times { @recipe.recipe_ingredients.build.build_ingredient }
end

If you view the form, you have ten inputs for recipe_ingredients (I've added some line breaks to the form to make them easier to view)

app/views/recipes/new.html.erb

<h1>Create a new recipe</h1>

<%= form_with model: @recipe do |recipe_form| %>
  <% if @recipe.errors.any? %>
    <div id="error_explanation">
      <h2><%= pluralize(@recipe.errors.count, "error") %> prohibited this recipe from being saved:</h2>
      <ul>
      <% @recipe.errors.full_messages.each do |message| %>
        <li><%= message %></li>
      <% end %>
      </ul>
    </div>
  <% end %>

  <%= recipe_form.text_field :title, placeholder: "Recipe Title" %>
  <h2>Ingredients</h2>
  <%= recipe_form.fields_for :recipe_ingredients do |recipe_ingredient_form| %>
    <%= recipe_ingredient_form.text_field :amount, placeholder: "Amount" %>
    <%= recipe_ingredient_form.fields_for :ingredient do |ingredient_form| %>
      <%= ingredient_form.text_field :name %>
    <% end %>
    <br />
  <% end %>

  <br />
  <%= recipe_form.submit %>
<% end %>

But, who can say that every recipe will have precisely ten ingredients? For some applications, this could be enough. Maybe we have an application where there is always an expected number of associations, and it never waivers from that. But for this application, we need this to be dynamic. We want to be able to add and remove recipe ingredients as required. So, let's get into it.

View the code up to this point

Adding and Removing Recipe Ingredients using Cocoon

To add and remove recipe ingredients, we're going to use my favorite gem for handling this. The gem is called cocoon.
Cocoon defines two helper methods, link_to_add_association and link_to_remove_association, these are aptly named because what they do is provide links that, when clicked, will either build a new association and create the appropriate fields or will create a link with the ability to mark an association for deletion.

Setting up cocoon

To set up cocoon, we first need to add it to our Gemfile. Stop the rails server and add the gem to your Gemfile.

Gemfile

gem 'cocoon'

Next, run bundle install to install the gem. Because we're using Rails 6, we also need to add the companion file for webpacker. Cocoon requires jQuery, so we need to install that as well.

yarn add jquery @nathanvda/cocoon

Next, let's add it to our application JavaScript.

app/javascripts/packs/application.js

require("jquery")
require("@nathanvda/cocoon")

Cocoon requires the use of partials. We won't get into how cocoon works, but these partials named expectedly are how cocoon knows what to render when we click 'add ingredient.'

app/views/recipes/new.html.erb

<h2>Ingredients</h2>
<div id="recipeIngredients">
  <%= recipe_form.fields_for :recipe_ingredients do |recipe_ingredient_form| %>
    <%= render "recipe_ingredient_fields", f: recipe_ingredient_form %>
  <% end %>
  <div class='links'>
    <%= link_to_add_association 'add ingredient', recipe_form, :recipe_ingredients %>
  </div>
</div>

Now when we refresh we see this error: Missing partial recipes/_recipe_ingredient_fields, application/_recipe_ingredient_fields with {:locale=>[:en], :formats=>[:html], :variants=>[], :handlers=>[:raw, :erb, :html, :builder, :ruby, :jbuilder]}. Searched in:

Let's create our partial.

app/views/recipes/_recipe_ingredient_fields.html.erb

<div class="nested-fields">
  <div>
    <%= f.label :amount %>
    <%= f.text_field :amount %>
  </div>

  <div class="ingredients">
    <%= f.fields_for :ingredient do |ingredient| %>
      <%= render "ingredient_fields", f: ingredient %>
    <% end %>
  </div>

  <div>
    <%= f.label :description %>
    <%= f.text_field :description %>
  </div>
</div>

And let's add our ingredient_fields partial as well.

app/views/recipes/_ingredient_fields.html.erb

<div>
  <%= f.label :name %>
  <%= f.text_field :name %>
</div>

We are also ready to remove the explicit building of recipe_ingredients in the new action in RecipesController.

Now, we have a form that has a link to add ingredient. However, nothing is happening when we click it. If I open up the dev tools, I see this message in the console:

Uncaught ReferenceError: jQuery is not defined

A quick Google search leads me to this page, and we still have a bit more configuration to do before jQuery is available in our application. Copy the code below into config/webpack/environment.js to define jQuery

config/webpack/environment.js

const { environment } = require('@rails/webpacker')

const webpack = require('webpack')
environment.plugins.prepend('Provide',
  new webpack.ProvidePlugin({
    $: 'jquery/src/jquery',
    jQuery: 'jquery/src/jquery'
  })
)

module.exports = environment

When we click add ingredient, a recipe ingredient form is available for us to fill in! How cool is that? However, the ingredient portion of the form doesn't exist, so it's not displaying. Let's figure out how to fix that.

Cocoon's link_to_add_association takes four parameters, the parameter html_options has some special options that we can take advantage of. We're going to look at the wrap_object option. The wrap_object option is a proc that wraps the object. We can use this to build our ingredient when we use the add ingredient link.

Replace the link_to_add_association with this updated version:

<%= link_to_add_association 'add ingredient', recipe_form, :recipe_ingredients, wrap_object: Proc.new { |recipe_ingredient| recipe_ingredient.build_ingredient; recipe_ingredient } %>

When we click add ingredient, the entire form, including the ingredient name, is available to fill in. When filling out my recipe and saving it, I noticed that the description for the recipe_ingredient didn't seem to be saving. Fix that by adding description to our recipe_params in the RecipeController

def recipe_params
  params.require(:recipe).permit(:title, recipe_ingredients_attributes: [:amount, :description, ingredient_attributes: [:name]])
end

Let's add the ability to remove a recipe ingredient now.

app/views/recipes/_recipe_ingredient_fields.html.erb

<div class="nested-fields">
  <div>
    <%= f.label :amount %>
    <%= f.text_field :amount %>
  </div>

  <div class="ingredients">
    <%= f.fields_for :ingredient do |ingredient| %>
      <%= render "ingredient_fields", f: ingredient %>
    <% end %>
  </div>

  <div>
    <%= f.label :description %>
    <%= f.text_field :description %>
  </div>

  <%= link_to_remove_association "remove ingredient", f %>
</div>

Now we can add and also remove our recipe ingredients! Awesome.

However, these changes only apply to the new form. We want to be able to edit recipes and have the same functionality. Let's do some refactoring and make that happen.

View the code at this point

Refactoring our form and updating recipes

We can pretty much reuse the same form for edit and new, so let's do that now. First, let's pull out the form and put it into a partial that we can render inside of the new view.

app/views/recipes/_form.html.erb

<%= form_with model: @recipe do |recipe_form| %>
  <% if @recipe.errors.any? %>
    <div id="error_explanation">
      <h2><%= pluralize(@recipe.errors.count, "error") %> prohibited this recipe from being saved:</h2>
      <ul>
      <% @recipe.errors.full_messages.each do |message| %>
        <li><%= message %></li>
      <% end %>
      </ul>
    </div>
  <% end %>

  <div>
    <%= recipe_form.label :title %>
    <%= recipe_form.text_field :title %>
  </div>

  <h2>Ingredients</h2>
  <div id="recipeIngredients">
    <%= recipe_form.fields_for :recipe_ingredients do |recipe_ingredient_form| %>
      <%= render "recipe_ingredient_fields", f: recipe_ingredient_form %>
    <% end %>
    <div class='links'>
      <%= link_to_add_association 'add ingredient', recipe_form, :recipe_ingredients, wrap_object: Proc.new { |recipe_ingredient| recipe_ingredient.build_ingredient; recipe_ingredient } %>
    </div>
  </div>

  <br />
  <%= recipe_form.submit %>
<% end %>

Now, our new view is much cleaner.

app/views/recipes/new.html.erb

<h1>Create a new recipe</h1>
<%= render "form" %>

Let's go ahead and do the same to our edit view.

app/views/recipes/edit.html.erb

<h1>Edit <%= @recipe.title %></h1>

<%= render "form" %>

Now our edit form allows us to add and remove recipe ingredients. While using the application, I noticed that we don't have a good way of viewing our recipes individually or getting to an edit page with a click. Let's add that to access an edit page to test out our functionality quickly.

Change the index page to be a listing of links to the recipes. We don't need to see the full recipe on the index page.

app/views/recipes/index.html.erb

<h1>Recipes</h1>

<% @recipes.each do |recipe| %>
  <h2>
    <%= link_to recipe.title, recipe %>
  </h2>
<% end %>

Now, on the show page, we can add a link to edit.

app/views/recipes/show.html.erb

<h1><%= @recipe.title %></h1>

<ul>
  <% @recipe.recipe_ingredients.each do |recipe_ingredient| %>
    <li>
      <%= recipe_ingredient.amount %> <%= recipe_ingredient.ingredient.name %>, <%= recipe_ingredient.description %>
    </li>
  <% end %>
</ul>

<%= link_to "Edit recipe", edit_recipe_path(@recipe) %> | <%= link_to "Back to all recipes", recipes_path %>

Now we can quickly get to our edit page. Let's ensure that things are working as expected. Try adding a new ingredient to a recipe and removing an existing ingredient. When checking to make sure that recipe ingredients get appropriately removed, I saw that they were not. Let's fix that.

Make sure recipe ingredients get removed

We need to make sure that _destroy, and id are permitted parameters in recipe_params.

def recipe_params
  params.require(:recipe).permit(:title, recipe_ingredients_attributes: [:amount, :description, :_destroy, :id, ingredient_attributes: [:name, :id]])
end

We also need to add allow_destroy: true to our accepts_nested_attributes. Now we can add and remove recipe ingredients successfully.

app/models/recipe.rb

accepts_nested_attributes_for :recipe_ingredients, allow_destroy: true

Let's make sure that we are taking advantage of the fact that we have a has_many :through. When it comes to ingredients, we want the name field to be unique. If we have an ingredient with a name of butter, every recipe named butter will use that ingredient instead of creating multiple ingredients of the same name. Down the road, we will be able to find all the recipes that have a particular ingredient.

Create or find ingredients

To our Recipe model, let's add a before_save hook so we can get at our ingredients before they get saved. We can use find_or_create_by when assigning an Ingredient to RecipeIngredient.

app/models/recipe.rb

class Recipe < ApplicationRecord
  has_many :recipe_ingredients
  has_many :ingredients, through: :recipe_ingredients

  validates_presence_of :title

  accepts_nested_attributes_for :recipe_ingredients, allow_destroy: true

  before_save :find_or_create_ingredients

  def find_or_create_ingredients
    self.recipe_ingredients.each do |recipe_ingredient|
      recipe_ingredient.ingredient = Ingredient.find_or_create_by(name:recipe_ingredient.ingredient.name)
    end
  end
end

Test it out by adding multiple recipe ingredients with the same ingredient name, and then go into the rails console, and we can see that an ingredient with the same name gets created once. I made a recipe called "Butter Two Ways," both recipe_ingredients have the name of butter. When I go into the rails console, I see that there is only one ingredient named butter and that both of my recipe_ingredients belong to it.

rails c

View your last Recipe in the rails console after you create it in the application.

recipe = Recipe.last
  Recipe Load (0.1ms)  SELECT "recipes".* FROM "recipes" ORDER BY "recipes"."id" DESC LIMIT ?  [["LIMIT", 1]]
=> #<Recipe id: 18, title: "Butter Two Ways", created_at: "2021-01-17 00:47:28.243659000 +0000", updated_at: "2021-01-17 00:47:28.243659000 +0000">

recipe.recipe_ingredients.count
   (0.2ms)  SELECT COUNT(*) FROM "recipe_ingredients" WHERE "recipe_ingredients"."recipe_id" = ?  [["recipe_id", 18]]
=> 2

recipe.recipe_ingredients.pluck(:ingredient_id)
   (0.1ms)  SELECT "recipe_ingredients"."ingredient_id" FROM "recipe_ingredients" WHERE "recipe_ingredients"."recipe_id" = ?  [["recipe_id", 18]]
=> [180, 180]

Ingredient.find(180)
  Ingredient Load (1.0ms)  SELECT "ingredients".* FROM "ingredients" WHERE "ingredients"."id" = ? LIMIT ?  [["id", 180], ["LIMIT", 1]]
=> #<Ingredient id: 180, name: "butter", created_at: "2021-01-16 23:17:33.293763000 +0000", updated_at: "2021-01-16 23:17:33.293763000 +0000">

Ta-da 🎉 Wow, we did it y'all! How does that feel?

View the code up to this point

Wrap Up

Phew, that was a doozy of a post. I hope it was informative and useful for you. Let's refresh what we did.

We learned what a has_many :through relationship is. It's a relationship that links two other models together. A recipe has many ingredients through its recipe ingredients. In practice, it creates a third database table that has at least a reference to both tables to which it belongs.
We learned when we need to use a has_many :through relationship, we use one because we wanted ingredients on our recipes to have additional information that was specific to the recipe only. Reach for a has_many :through when you need other data on the association.
We defined the Pantry app and its requirements
We built a Rails 6 application, using generators for our models, migrations, and controllers. Then we used a seed file to populate our database initially and the rails console to view our data. We also built out a CRUD controller for recipes and a form to input our recipe information into and save it.
We created nested forms using fields_for and accepts_nested_attributes_for, learned how to build out our ingredient so the ingredient fields would render
We added what we needed when we needed it, like when we added our flash notices when we needed more information about why our recipe wasn't saving.
We used the cocoon gem to make our nested form dynamic, allowing us to add and remove recipe ingredients
We pulled form partials out so we could reuse our form on the new and edit page
We used an ActiveRecord lifecycle hook (before_save) so that recipe_ingredients would either use an existing ingredient if it existed and, if not, create the ingredient.

Don't you feel accomplished?

I have some further challenges for you if you'd like to iterate more on this application. Add auto-completion to the ingredient name field, selecting an option from the auto-select dropdown could populate a hidden id field in the ingredient fields. Add specs. Ideally, we would do this before/alongside writing our code, but I wanted to focus on the code, still trying to figure out this balance. Add a way to use the destroy action from the RecipesController. Make the index page better, add a link to create new recipes. Add a way to search for recipes that include a specific ingredient. Think about how your controller would change if your Rails application were API only. How would the request payload look? What changes would you need? There are so many cool ways to expand on this application. I hope that this provides a good base and jumping-off point if you're so inclined.

I do enjoy writing these tutorials, but they take a lot of effort! If you appreciated this post, please share it on Twitter or other social media; that would make my day. Keep in mind that there are different ways to solve this problem; this happens to be my approach using my favorite tools. If you have any questions or comments, please tweet at me, I always appreciate lovely messages and constructive feedback.

Render Dynamic Pages in Gatsby Using File System Route API and YAML

Meagan Waller — Tue, 12 Jan 2021 18:09:12 +0000

I've been using Gatsby a bunch lately. I think it's an enjoyable framework and a great way to ramp up on React. This year, one of my goals is to get more comfortable in the frontend stack and become more proficient with JavaScript.
Gatsby has been a fantastic tool for helping me work towards that goal.

While doing the #100DaysOfGatsby challenege, I had to create dynamic pages. I decided to use a YAML file as my source of truth for the dynamic generation. Let's build a simple Gatsby app that generates some dynamic pages from a YAML file.

Okay, but why would I want to do that?

Before diving into the how of this tutorial, I'd like to discuss the motivations behind it; meet DOGWALKER. DOGWALKER is the newest application for finding someone to walk your dog. There need to be three pages for the application's initial release: Home, About, and Locations. There needs to be a list of all the locations that DOGWALKER is currently available on the locations page, and each location in that list will link to their own individual locations page.

For example, DOGWALKER is available in Jacksonville, Tampa, and Orlando. The locations page would have a list containing those three cities. Each city name links to its page. Nothing except the city name and description will be on each page, and this is an elementary proof of concept.

Theoretically, dynamic pages aren't needed. One could update the locations page and create a page for each new location. Manually adding pages is very tedious. It means that anytime the location template might change, say when the application moves from proof of concept into its first alpha release, the developer would need to change every single location page.

A developer could make their life a lot easier by having all the data stored in one place, in this case, it's a YAML file, and then have reusable templates. Each time the requirements for a location page change, the only update that needs to happen is in the location page template.

Have I convinced you that dynamic routing is worth learning? Let's jump in.

Creating a Gatsby Project

First things first, get Gatsby installed on your machine (you'll need node, npm, and git installed already if you're not sure how follow this guide to get your environment set up.)

npm install -g gatsby-cli

Now the gatsby command will be available to use, and this is how to generate your gatsby projects.

npm init gatsby

Follow the prompts. We won't need a CMS, any styling, or any additional plugins.

After the Gatsby site is created, change into the directory, mine is named dogwalker.

cd dogwalker

Get the site up locally with

npm run develop

In your browser, go to localhost:8000 to see the Gatsby congratulations page.

Making the DOGWALKER Proof of Concept

The proof of concept for DOGWALKER is three pages. Home, About, and Locations. Let's go ahead and remove the code from the index file so we can start fresh. Inside of src/pages/index.js, Replace everything with the code below.

import React from "react"

export default () => {
  return (
    <>
    <h2>DOGWALKER</h2>
    <p>This is the dogwalker homepage.</p>
    </>
  )
}

Let's add a link to our About page. We'll call it about.js.

import React from 'react'

export default () => (
  <>
  <h1>About DOGWALKER</h1>
  <p>We're somehow different than all the other dogwalker applications.</p>
  </>
)

Now, in your browser, go to localhost:8000/about, and you will see the about page we just created. We haven't linked it from the homepage, but we will get to that shortly.

Let's create our locations page now. The actual page that will be the list of our locations can also live inside src/pages, we will call it locations.js. There will be no dynamic content. We will include a header that says Location for the time being.

import React from 'react'

export default () => (
  <>
  <h1>Locations</h1>
  <p>Check out where you can use DOGWALKER</p>
  </>
)

Go to localhost:8000/locations to see the locations page.

If you're feeling lost, check out this branch to see the changes just for the above static pages.

Adding locations statically

Let's add the locations statically; this will help us determine what we can dynamically generate. Creating static pages first will also drive home how good dynamic rendering is for this type of content.

The first location DOGWALKER was available in was Jacksonville, so let's create the Jacksonville page. I'm going to put mine at src/pages/locations/jacksonville.js.

import React from 'react'

export default () => (
  <>
  <h1>Jacksonville</h1>
  <p>Yep, we started in Jacksonville, FL of all places.</p>
  </>
)

Visit this page at localhost:8000/locations/jacksonville to view the page we just created.

Repeat the process for Tampa and Orlando.

src/pages/locations/tampa.js

import React from 'react'

export default () => (
  <>
  <h1>Tampa</h1>
  <p>We're also in Tampa.</p>
  </>
)

src/pages/locations/orlando.js

import React from 'react'

export default () => (
  <>
  <h1>Orlando</h1>
  <p>We're also in Orlando.</p>
  </>
)

Once again, visit these pages at localhost:8000/locations/tampa, and localhost:8000/locations/orlando.

Now we can add our locations to our static locations page.

src/pages/locations.js

import React from 'react'
import { Link } from 'gatsby'

export default () => (
  <>
  <h1>Locations</h1>
  <p>Check out where you can use DOGWALKER</p>

  <ul>
    <li>
      <Link to="/locations/jacksonville">Jacksonville</Link>
    </li>
    <li>
      <Link to="/locations/tampa">Tampa</Link>
    </li>
    <li>
      <Link to="/locations/orlando">Orlando</Link>
    </li>
  </ul>
  </>
)

(Read about Gatsby's Link component here)

Okay, so this works. All our locations are linked; they live under the locations URL. What more could you want? Imagine six months down the line when DOGWALKER blows up and is available in 120 cities. Do you want to create 120 pages that all look the same except for the title and the city's description? I didn't think so. Let's generate these pages dynamically.

View the code at this point here.

Create & Query Locations

Let's create those dynamic pages. First, we need to create a YAML file to store all of our locations. YAML isn't the only option for storing our source of truth for the dynamic pages, but it's just the format I've chosen to work in for this example.

Each location page has a city name and a description. My YAML file is going to live at locations/locations.yml.

- name: "Jacksonville"
  description: "Yep, we started in Jacksonville, FL of all places."
- name: "Tampa"
  description: "We're also in Tampa."
- name: "Orlando"
  description: "We're also in Orlando."

Next, we need to tell gatsby about our YAML file. We need to install the gatsby-transformer-yaml package.

npm install gatsby-transformer-yaml

Now, inside of gatsby-config.js we can configure it, and we can also use gatsby-source-filesystem to tell Gatsby where the YAML file lives.

module.exports = {
  plugins: [
      {
        resolve: "gatsby-transformer-yaml",
        options: {
            typeName: ({node}) => {
            const name = node.sourceInstanceName
            if (name === `locations`) {
              return `Location`
            }
            return name
          },
        },
      },
      {
        resolve: "gatsby-source-filesystem",
        options: {
            path: "./locations",
            name: "locations",
        },
        __key: "locations",
      },
  ],
}

Let's open up our GraphQL playground and make sure things are working as expected. I'm unfortunately not going to go into GraphQL on this blog post. Gatsby docs once again are a great
place to learn more. A super quick overview of GraphQL is that GraphQL is Gatsby's Data Layer providing an API to query your data.

Go to localhost:8000/__graphql.

Paste this query into the query panel

query {
  allLocation {
    nodes {
      name
      description
    }
  }
}

You should see something like this:

{
  "data": {
    "allLocation": {
      "nodes": [
        {
          "name": "Jacksonville",
          "description": "Yep, we started in Jacksonville, FL of all places."
        },
        {
          "name": "Tampa",
          "description": "We're also in Tampa."
        },
        {
          "name": "Orlando",
          "description": "We're also in Orlando."
        }
      ]
    }
  },
  "extensions": {}
}

Great! Gatsby is aware of the YAML file, and we can query it using GraphQL. We can use this query inside of our application to get a hold of that data.

Take a look at the code at this point in the project here.

Creating Dynamic Locations Pages

Alright! It's time to create the dynamic location pages.

Let's first update our src/pages/locations.js file. We will change it from displaying a list of links to displaying a list of names, and then we will figure out how to add the links to it later.

src/pages/locations.js

import React from 'react'
import { Link, graphql } from 'gatsby'

export default ({data}) => (
  <>
  <h1>Locations</h1>
  <p>Check out where you can use DOGWALKER</p>

  <ul>
    {data.locations.nodes.map(location => (
      <li key={location.id}>
        {location.name}
      </li>
    ))}
  </ul>
  </>
)

export const query = graphql`
{
  locations: allLocation {
    nodes {
      name
    }
  }
}
`

The code above will give us an unordered list of the city names from the YAML file.

We want to link them; they should live at the same URL locations/city-name. We're going to replace our locations/tampa.js, locations/orlando.js, and locations/jacksonville.js with one file: locations/{Location.name}.js. Gatsby uses the curly braces in filenames to denote a dynamic URL segment. So, locations/{Location.name}.js will create a route like: locations/jacksonville, as we had before, except now we don't need separate files for every location.

Before we create that page, though, let me show you how we will query it using GraphQL. In GraphQL, we have query params, so we can pass a param and search by it. Let's give the name to the query and see if we can just get back that one individual location record.

query ($id: String!) {
  location(name: {eq: $id}) {
    name
    description
  }
}

Then we can pass the parameter of

{ "id": "Jacksonville" }

And receive this object back.

{
  "data": {
    "location": {
      "name": "Jacksonville",
      "description": "Yep, we started in Jacksonville, FL of all places."
    }
  },
  "extensions": {}
}

Let's create our Location template page:

src/pages/locations/{Location.name}.js

import React from 'react'
import { graphql } from 'gatsby'

export default (props) => {
  const { location } = props.data
  return (
    <>
    <h1>{location.name}</h1>
    <p>{location.description}</p>
    </>
  )
}

export const query = graphql`
query($id: String!) {
  location(id: { eq: $id }) {
    name
    description
  }
}
`

The id inside of this query is a unique identifier that Gatsby provides to simplify page queries.

Now, we can link to our location pages.

src/pages/locations.js

import React from 'react'
import { graphql, Link } from 'gatsby'

export default ({data}) => (

  <>
  <h1>Locations</h1>
  <p>Check out where you can use DOGWALKER</p>

  <ul>
    {data.locations.nodes.map(location => (
      <li key={location.id}>
        <Link to={location.nameSlug}>{location.name}</Link>
      </li>
    ))}
  </ul>
  </>
)

export const query = graphql`
{
  locations: allLocation {
    nodes {
      name
      nameSlug: gatsbyPath(filePath: "/locations/{Location.name}")
    }
  }
}
`

nameSlug here is just what I've decided to call this property. You could call it locationPath, or anything else you want. Gatsby slugifies every route and includes a gatsbyPath field, which takes an argument of the filePath it is trying to resolve.¹
Now when you go to localhost:8000/locations, you will see a list of links to all of the location pages, and they're all rendering via the Location template! How cool is that?

View the code at this point in the project

Finishing Touches

Let's go ahead and do one more thing, not entirely necessary, but let's add our links to the index page to click them instead of typing them into the browser whenever we want to visit them.

src/pages/index.js

import React from "react"
import { Link } from 'gatsby'

export default () => {
  return (
    <>
    <ul>
      <li>
        <Link to="/">Home</Link>
      </li>
      <li>
        <Link to="/about">About</Link>
      </li>
      <li>
        <Link to="/locations">Locations</Link>
      </li>
    </ul>
    <h2>DOGWALKER</h2>
    <p>This is the dogwalker homepage.</p>
    </>
  )
}

Fantastic! It's not pretty or styled, but it's functional. Except when you click on About or Location and then don't have a link back to the home page 🤔. Let's take it up a notch and create a Layout
that we can reuse on the pages that include our little menu.

I put my layout inside of the components directory.

src/components/Layout.js

import React from 'react'
import { Link } from 'gatsby'

const Layout = ({children}) => {
  return (
    <>
    <header>
      <nav>
        <Link to="/">Home</Link>
        <Link to="/about">About</Link>
        <Link to="/locations">Locations</Link>
      </nav>
    </header>

    <main>
      {children}
    </main>
    </>
  )
}

export default Layout

We need to add the Layout to every file that we want to render inside the layout. Those will be the children, and the files will now render inside of the <main></main> tags.

src/pages/index.js

import React from "react"
import Layout from '../components/Layout'

export default () => {
  return (
    <Layout>
    <h2>DOGWALKER</h2>
    <p>This is the dogwalker homepage.</p>
    </Layout>
  )
}

src/pages/about.js

import React from 'react'
import Layout from '../components/Layout'

export default () => (
  <Layout>
  <h1>About DOGWALKER</h1>
  <p>We're somehow different than all the other dogwalker applications.</p>
  </Layout>
)

src/pages/locations.js

import React from 'react'
import { graphql, Link } from 'gatsby'
import Layout from '../components/Layout'

export default ({data}) => (

  <Layout>
  <h1>Locations</h1>
  <p>Check out where you can use DOGWALKER</p>

  <ul>
    {data.locations.nodes.map(location => (
      <li key={location.id}>
        <Link to={location.nameSlug}>{location.name}</Link>
      </li>
    ))}
  </ul>
  </Layout>
)

export const query = graphql`
{
  locations: allLocation {
    nodes {
      name
      nameSlug: gatsbyPath(filePath: "/locations/{Location.name}")
    }
  }
}
`

src/pages/locations/{Location.name}.js

import React from 'react'
import { graphql } from 'gatsby'
import Layout from '../../components/Layout'

export default (props) => {
  const { location } = props.data
  return (
    <Layout>
    <h1>{location.name}</h1>
    <p>{location.description}</p>
    </Layout>
  )
}

export const query = graphql`
query($id: String!) {
  location(id: { eq: $id }) {
    name
    description
  }
}
`

See, not entirely necessary, but it's nice to know how to do this and makes clicking around possible.

View the code at this point in the project

Wrap Up

Gatsby makes creating simple applications super quick, but it's still powerful enough to be interesting. I'm excited to dig more into Gatsby and hopefully write more posts like this. I hope you enjoyed this tutorial. I'd love to start
writing more content like this and maybe expanding some tutorials into a series or to create an accompanying video. Let me know what you think on Twitter.

https://www.gatsbyjs.com/docs/reference/routing/file-system-route-api/#gatsbypath-example ↩

Looking at 2020, Goals for 2021

Meagan Waller — Sat, 02 Jan 2021 02:12:22 +0000

Going into 2020, I only had a few clear goals, and none of them were professional goals. As I said in my first blog post, I had been feeling burnt out and stagnant with tech, in general, the past few years.

My goals for 2020 were as follows:

Pay off all credit cards
Have three months salary in savings
Read seven books
Workout two to three times a week
Complete Couch to 5K
Lose 25lbs

I completed almost all of these goals.

💸 Financial Goals

Pay off all credit cards

2020 is the year I aggressively tackled my debt. I paid off all my credit cards, and I paid off my back taxes from the IRS that I had been paying monthly since 2014. Making these significant payments drained my savings slightly. Still, it made more sense to pay them off and stop paying interest versus letting the money sit in my savings account, accumulating a paltry amount of interest. Of course, there is a great deal of privilege in making that decision. I had job security throughout 2020, which wasn't the reality for many people.

Have three months salary in savings

At no point this year did I ever have three months' salary in my savings account. However, I made significant payments on credit cards and other debts. At the end of 2020, I put an offer on a house, and closing is in a couple of weeks! 🤞 Buying a home was what I wanted to accomplish with my savings; now, I will be rebuilding my savings in 2021. (More on that below.)

📚 Personal Goals

Read seven books

I made the modest goal of reading seven books this year. I had always been a big reader but had fallen off of regular reading in a big way. I am happy to report that I crushed that goal. I read 34 books this year. Most of them were fiction books, and most of them were new to me. I'm slowly working my way through my backlog of books because while I wasn't great at reading them, I was terrific at buying them.

🏃‍♀️ Fitness Goals

Note: There is talk of dieting/weight loss/body image issues below. Please proceed with caution or skip if you are sensitive to these topics 💛

Workout 2-3x a week

My fitness journey has been a long, storied one. It's way out of scope for this blog post, but I will say that I've always wanted to be an athlete. 2020 is the year the stars aligned, and something clicked for me, and I became one. In 2019 I started going to Crossfit. I enjoyed it but had an injury unrelated to Crossfit that put me out of commission for about 4-6 weeks, then the holidays came, and I just never went back. At the start of 2020, I found Orange Theory and fell in love with the classes. I was going diligently up until they closed towards the middle of March. Once gyms reopened in my state, I decided to go back after seeing the safety precautions my local OTF utilized. At one point, I was going five times a week, but I've reigned it in a bit and am currently going two times a week. I developed plantar fasciitis from running too frequently and heel striking. I've since recovered and have worked on my form a lot, and I am running again.

On days I don't do Orange Theory, I am following a powerlifting program four times a week with a bonus accessory workout on the fifth day and a 30-minute personal training session to work on form and do a more high-intensity weight lifting routine.

I would love to talk so much more about fitness, but I want to keep this relatively short.

Complete Couch to 5K

As I said above, I've always wanted to be an athlete. I specifically have always wanted to be a runner. I remember being in middle school and high school, promising myself that I would train over the summer and return to school and try out for track or cross country. I'd attempt training one day in the heat of a Florida summer and immediately give up when I wasn't great at it. I've downloaded and promised myself "tomorrow morning" I'd start couch-to-5k a thousand times over the past decade.

At the start of stay-at-home orders, I decided it was the perfect time to start couch-to-5k. I loved it. I've gone from around a 38 minute 5K after the program to a 32.5 minute 5K this year, a PR I hit on an "easy run" recently. I've also signed up for a 15k in March and have started training for that.

Lose 25lbs

Losing weight is the goal that was always at the top of my list every single year without fail. 2020 was the year I examined the why of why this goal loomed so large in my life. I'd been a chronic dieter since I was nine years old. Nine. Can you even imagine? Food, weight, and body have been an all-consuming thing for me for almost my entire life. I realized this year that no matter what amount I put on here to lose, I'd never be happy upon reaching it. I'd keep moving the goalposts. I needed to heal my mind-body connection and my relationship with food. I don't want to get too into this because it can be super triggering, and it's outside of the scope of this post. Weight, dieting, and body image are an ongoing struggle for me, being super real. I made huge strides towards mindful eating. I stopped drinking, stopped using nicotine, stopped numbing myself in other ways. I've started to divorce myself from the idea that weight loss falls into the "fitness" category. This will be an ongoing challenge for me. I have a lot of unlearning to do. However, I can happily say that 2021 will be the first year that a specific weight loss goal will be absent from my resolutions.

Things I did in 2020 that didn't make my initial goal list

I want to quickly list a few notable achievements that I didn't even think to ideate at the top of 2020.

Enter into the process of buying a house
Go back to school
Restart my blog
Start and follow a skincare routine (this is huge for me!)
Start waking up early and going to bed early

Goals for 2021

Now to set my intentions for 2021. I'm just going to list my goals, and then this time next year, I'll expand on them as I did in this blog post

Fitness Goals

Run 15k
Squat 200lbs
Deadlift 250lbs
Bench 100lbs
Get a strict pull-up
Run under a 9-minute mile

Financial Goals

3 months salary in savings
Continue to live debt-free

Personal Goals

Continue with school: 2 classes in spring, 2 in summer, 2 in the fall semester.
Read three books a month, two fun fiction or non-fiction, one professional/personal development

Professional Goals

Create and maintain my career/hype doc
Blog at least 2x a week
Do #100DaysOfGatsby
Contribute to an Open Source project
Complete JavaScript, CSS, React, Vue, Professional, Expert, and Computer Science learning tracks on Frontend Masters.
Launch the side project I'm super excited about! (I've imagined this side project since 2016)

Shooting-for-the-stars goals

These goals would be amazing to accomplish, but I know they are long-shots or might be best deferred to 2022 or beyond.

Make Senior Developer
Be a guest on a podcast
Get a blog post published in a newsletter
Look into creating video content
Look into live stream coding
Work on branding for my blog

Wrap Up

That's it for my 2020 wrap up and looking into 2021. What are your goals or intentions for the upcoming year? Did you reach your goals in 2020?

One Step Make and Change into a Directory

Meagan Waller — Tue, 29 Dec 2020 19:22:12 +0000

I've taken a lot of time to personalize my dotfiles. There are a couple of functions I wanted to share.

Make a Directory and Change Into It

My workflow often looked like this:

mkdir some-directory
cd some-directory

I wanted to put that workflow all into one command.

function mcd() {
  mkdir -p "$1" && cd "$1";
}

Now I can type

mcd some-directory

Add this function to your set up

To start using the mcd function, copy and paste the function above into your ~/.bashrc file (or ~/.zshrc file if you're using zsh), and run source ~/.bashrc (or source ~/.zshrc) to start using it.

Secret Santa Ruby Quiz

Meagan Waller — Tue, 22 Dec 2020 17:06:25 +0000

Happy Holidays everyone! I wanted to do something in the spirit of the season and thought the Secret Santa Ruby quiz would be the perfect puzzle to tackle. This puzzle is right on theme, but it's also really well-defined and small enough in scope that we can go through the process of solving it in a blog post. Let's get started.

To make sure everyone is on the same page, this won't be strictly for beginners to Ruby or programming. I will gloss over specific steps like initializing a repository with RSpec, running tests, and general Ruby conventions. Instead, I will link to references that provide more information.

The Puzzle Requirements

The quiz defines the rules as the following:

Feed the script a list of names on STDIN. It might look like

Alice Jones <alice@example.com>
Bob Jones <bob@example.com>
Carlos Jones <ricky@example.com>
Demi Smith <demi@example.com>
Eli Smith <eli@example.com>
Florence Williams <florence@example.com>

With a format of

FIRST_NAME space FAMILY_NAME space <EMAIL_ADDRESS> newline

To keep things simple: people only have two names (no Jrs, IIs, etc.).

The script should choose a Secret Santa for every name on the list. A person can't be their own Secret Santa. And you can't be assigned to anyone with the same FAMILY_NAME.
Finally, email the Santa and tell them who their person is.

To make the content more focused, I made the scope a little bit smaller by tweaking a few of the requirements. I'm reading from a text file instead of feeding the list through STDIN, and I will not be sending emails. I also gave myself about an hour to work on this puzzle.

My Thought Process

When starting a new Ruby project, the first thing I do is to initialize my directory with a testing framework. I use RSpec.

In an "ideal" scenario, whenever I sit down to tackle a problem, I start by thinking about the very first test. It should test exactly one thing, and it should fail. After I get that test to pass, I write another test that will fail, write enough code to make that test pass, and maintain passing status for all previous tests. I repeat this cycle, this is known as test-driven development.

However, real-life and what's ideal often diverge. I don't always practice "perfect" test-driven development, but I still try to let tests guide me.

These are the steps I wanted to take, removed from implementation:

Receive a list of names and emails and from that list create Santas.
From the Santas list, for each Santa, generate all possibilities for who their assignees could be.
Pick a random assignee from each potential assignment for each Santa.

I thought the steps above would be my basic algorithm going into this problem.

I would discover that I would need to tweak it a little bit for step three to work reliably. Picking a random person from each potential assignment for each Santa means that sometimes the same person gets assigned to multiple Santas. I would later change step three to look like this:

Pick a random person from the potential assignment for each Santa, keep re-picking until all the assignees are unique.

Not the most sophisticated or performant algorithm, but we're getting things done, and we're testing our expectations. This puzzle is still a great learning opportunity.

Code Walk Through

For this section, I want to walk you through each step I worked through, starting with my first test.

Step 1: Receive a list of names and make Santas

it "receives a list of names and emails and creates santas" do
  secret_santa = SecretSanta.new('./santas.txt')
  expect(secret_santa.santas).to_not be_empty
end

When it comes to writing the first test, I want to be as general as possible. I know that I will have a class called SecretSanta, and I want to initialize it with my text file full of my Secret Santas in the format we defined above. However, I don't want to tie myself to a particular implementation regarding how I store the santas attribute.

Tests that aren't dependent on implementation details are much easier to maintain.

After initializing the SecretSanta class, I want to make sure that there is something inside the santas attribute. That could be any number of data structures. I want to keep my tests general, so they don't have to change.

If I tied myself right away to expecting santas to be a particular data structure, but down the line, I decided I want them to be a different data structure, I would have to change my test. But, is it truly a failing test? It's still receiving a list of names and creating santas, but because it's tied to a specific implementation, the expectation needs to change.

Next, I write enough code to make the test pass.

class SecretSanta
  attr_reader :santas

  def initialize(file)
    @santas = File.open(file).read.split("\n")
  end
end

Step 2: For each Santa, find their potential assignees

I broke my rule here from above when I initially wrote this test. I tied myself to the implementation. And I tied myself to my outside inputs (the textfile I pass in to initialize).

it "doesn't allow someone to be assigned to their family member" do
  secret_santa = SecretSanta.new('./santas.txt')
  expect(secret_santa.potential_assignees[0]["Alice Jones"]).to eql [["Demi", "Smith", "<demi@example.com>"], ["Eli", "Smith", "<eli@example.com>"], ["Florence", "Williams", "<florence@example.com>"]]
end

I had an idea in my mind of how I wanted these potential_assignees to look. And I let it drive the test rather than the other way around. Not to mention, this isn't testing what it purports to it doesn't allow someone to be assigned to their family member. The test is setting up an expectation for how a data structure looks, nothing about behavior. We'll see how this bites us below.

The code below makes the test above pass.

class SecretSanta
  attr_reader :santas

  def initialize(file)
    @santas = File.open(file).read.split("\n").map { |s| s.split }
  end

  def potential_assignees
    @santas.map do |santa|
      { "#{santa[0]} #{santa[1]} "} => @santas.reject { |s| s[1] == santa[1] }}
    end
  end
end

I decided to assign each Santa an array of emails instead of the full name and email for each potential assignee. But the test is tied to the implementation above, so it fails.

The code that makes this test break:

def potential_assignees
  @santas.map do |santa|
    { "#{santa[0]} #{santa[1]}" => @santas.reject { |s| s[1] == santa[1] }.map { |s| s[2].flatten }
  end
end

Ouch. Testing this behavior is difficult with our current setup. I want a little more structure inside the santas attribute.

Maybe something like this?

class SecretSanta
  Santa = Struct.new(:first_name, :family_name, :email)

  attr_reader :santas

  def initialize(file)
    santa_info = File.open(file).read.split("\n")
    @santas = santa_info.each_with_object([]) do |santa, santas|
      first_name, family_name, email = santa.split
      santas << Santa.new(first_name, family_name, email)
    end
  end
end

The santas attribute is a collection of Structs; this gives us the attributes of first_name, family_name, and email on each Santa. Plus, our first test was general enough that even refactoring our santas attribute to look different keeps the test passing.

For the test to ensure no one gets assigned to a family member, I had to test a fair bit of the implementation. But this test isn't also tied to the text file we pass into the initializer.

it "doesn't allow a santa to be assigned a family member" do
  secret_santa = SecretSanta.new('./santas.txt')
  expect(secret_santa.santas.first.potential_assignees.map(&:family_name)).to_not include secret_santa.santas.first.family_name
end

I've also decided to include the potential_assignees as an attribute on each Santa Struct.

This test might know too much about how @santas look, but I feel it's valid for our use case. We need to understand how @santas looks because the way we're assigning potential_assignees depends on it.

class SecretSanta
  Santa = Struct.new(:first_name, :family_name, :email, :potential_assignees)

  attr_reader :santas

  def initialize(file)
    santa_info = File.open(file).read.split("\n")
    @santas = santa_info.each_with_object([]) do |santa, santas|
      first_name, family_name, email = santa.split
      santas << Santa.new(first_name, family_name, email)
    end
    set_potential_assignees
  end

  def set_potential_assignees
    @santas.map do |santa|
      santa.potential_assignees = @santas.reject { |s| s.family_name == santa.family_name }
    end
  end
end

I've also gone ahead and moved the creation of potential_assignees to the initializer; one less thing we have to call in the tests explicitly.
If I had more than an hour, I could develop a more elegant solution, but I am happy with this small puzzle solution. I've moved away from being dependent on two things: the text file AND the implementation. I'm dependent on the implementation only now, but at least the test is
testing what it says it is. The expectation is that the potential_assignee attribute won't include the family_name for that Santa.

Step 3: Pick randomly for each Santa

For this step, I initially had a naive implementation for the algorithm. I picked a random assignee for each Santa; this led to assignees that were not unique and some people not assigned. The code below relies on the code in step two before we refactored to Structs.

it "picks a random person from the potential assignees list" do
  secret_santa = SecretSanta.new('./santas.txt')
  potentials = secret_santa.potential_assignees
  picked = secret_santa.pick_assignees(potentials)
  assigned = picked.map do |santa|
    santa.map do |k, v|
      v
    end
  end

  expect(assigned.flatten.uniq.count).to eql secret_santa.santas.count
end

This test created the potential_assignees, called the pick_assignees function, and then created an array of the picked (assigned). The expectation was that all the unique values in assigned would be equal to the total number of santas. Each Santa should be assigned a unique person. This test was flaky, and I think I saw it pass one time out of the dozens and dozens of times I ran it. Here is the code for step three:

def pick_assignees(potentials)
  potentials.map do |potential|
    { "#{potential.keys[0]}" => potential.values.flatten.sample }
  end
end

This naive implementation maps through the potential_assignees (at this point that data structure looked like:

[{"First Name Family Name" => ["email", "email", "email"]}, {"First Name Family Name" => ["email", "email"]}]`)

for each potential it just picks a random email from it's values using sample, returning an array that looks like:

[{"First Name Last Name" => "email" }, {"First Name Last Name" => "email"}]

Step 3a. Keep re-picking until everyone has a unique assignee

I had to make the algorithm a little bit smarter. The simplest way I could think to do that was to keep calling pick_assignees until every Santa had a unique assignee.

def pick_assignees(potentials)
  picked = potentials.map do |potential|
    { "#{potential.keys[0]}" => potential.values.flatten.sample }
  end

  assigned = picked.map do |santa|
    santa.map do |k, v|
      v
    end
  end

  if assigned.flatten.uniq.count != @santas.count
    pick_assignees(potentials)
  else
    return picked
  end
end

Now the test passes consistently. We're using recursion (a function that calls itself) to solve this problem in a kind of brute-force way. If the unique assigned values don't equal the total number of @santas, try again; if they do return the assignments.

Let's refactor this to use our Santa Structs.

class SecretSanta
  Santa = Struct.new(:first_name, :family_name, :email, :potential_assignees, :assignee)

  attr_reader :santas

  def initialize(file)
    ...
    set_assignee
  end

  ...

  def set_assignee
    @santas.map do |santa|
      santa.assignee = santa.potential_assignees.sample
    end

    if @santas.map(&:assignee).map(&:email).uniq.count != @santas.count
      set_assignee
    else
      return
    end
  end
end

it "picks a random person from the potential santas list" do
  secret_santa = SecretSanta.new('./santas.txt')
  expect(secret_santa.santas.map(&:assignee).map(&:email).uniq.count).to eql secret_santa.santas.count
end

The test, at this point, reiterates what set_assignee does internally. We could figure out a better way to approach this test, but once again, I am happy with where we got for a short time-boxed puzzle.

Let's look at the SecretSanta class before our refactoring!

class SecretSanta
  attr_reader :santas

  def initialize(file)
    @santas = File.open(file).read.split("\n").map { |s| s.split }
  end

  def potential_santas
    # Gives a data structure that looks like:
    # [{ "First Name Family Name" => ["email", "email", "email"]}]
    @santas.map do |santa|
      { "#{santa[0]} #{santa[1]}" => @santas.reject { |s| s[1] == santa[1] }.map { |s| s[2]}.flatten }
    end
  end

  def pick_santas(potentials)
    picked = potentials.map do |potential|
      { "#{potential.keys[0]}" => potential.values.flatten.sample }
    end

    assigned = get_assigned(picked)

    if unique_assigneds(assigned) != @santas.count
      pick_santas(potentials)
    else
      return picked
    end
  end

  private
  def get_assigned(picked)
    picked.map do |santa|
      santa.map do |k, v|
        v
      end
    end
  end

  def unique_assigneds(assigned)
    assigned.flatten.uniq.count
  end
end

Not bad, but room for improvement. Something we didn't touch on here is pulling out methods into private methods. I am conflicted if this is the right way to approach a private method, but it's what I'm keen to do.

Our refactored version:

class SecretSanta
  Santa = Struct.new(:first_name, :family_name, :email, :potential_assignees, :assignee)

  attr_reader :santas

  def initialize(file)
    santa_info = File.open(file).read.split("\n")
    @santas = santa_info.each_with_object([]) do |santa, santas|
      first_name, family_name, email = santa.split
      santas << Santa.new(first_name, family_name, email)
    end
    set_potential_assignees
    set_assignee
  end

  def set_potential_assignees
    @santas.map do |santa|
      santa.potential_assignees = @santas.reject { |s| s.family_name == santa.family_name }
    end
  end

  def set_assignee
    @santas.map do |santa|
      santa.assignee = santa.potential_assignees.sample
    end

    if @santas.map(&:assignee).map(&:email).uniq.count != @santas.count
      set_assignee
    else
      return
    end
  end
end

I think this version is much easier to understand. The Struct makes our code more flexible while also providing the benefit of named attributes. No more passing around square brackets with index numbers inside. Human-readable names make the code much more approachable.

Conclusion & Further Reading

I had a lot of fun doing this Ruby Quiz. I attempted to do it during my apprenticeship and got stuck on my own. It reminds me of how much progress I have made over the past six-plus years. I'd love to see your solutions to this quiz.

Ruby's Tally Method

Meagan Waller — Sat, 19 Dec 2020 00:48:07 +0000

Ruby's tally method was introduced in 2.7. It's a super convenient method on Enumerable that I was recently able to use. Tally counts each element's occurrences and returns a hash where the key is the element, and the value is the count.

Pre-Tally

If you are like me, any time you needed to get back a count of the times an element showed up in a collection, you headed over to StackOverflow and looked up how to do it. You probably ended up implementing something that looked like one of the examples below:

list = ["a", "b", "b", "a", "c", "d", "d", "d", "e"]

list.group_by { |v| v }.map { |k, v| [k, v.size] }.to_h
#=> {"a"=>2, "b"=>2, "c"=>1, "d"=>3, "e"=>1}

list.each_with_object(Hash.new(0)) { |v, h| h[v] += 1 }
#=> {"a"=>2, "b"=>2, "c"=>1, "d"=>3, "e"=>1}

Maybe you needed to count how many times some value showed up in a collection of hashes.

hashes = [{name: "Meagan" }, { name: "Meagan" }, { name: "Lauren" }]

hashes.group_by(&:itself).map { |k, v| k.merge(count: v.length)}
#=> [{ :name => "Meagan", :count => 2}, { :name => "Lauren", :count => 1 }]

Using tally

Tally makes that collection into hash transformation so much easier.

list = ["a", "b", "b", "a", "c", "d", "d", "d", "e"]
list.tally
#=> {"a"=>2, "b"=>2, "c"=>1, "d"=>3, "e"=>1}

Bam. You did it. Let's use tally on our collection of hashes example.

hashes = [{name: "Meagan" }, { name: "Meagan" }, { name: "Lauren" }]
h.tally
#=> {{:name=>"Meagan"}=>2, {:name=>"Lauren"}=>1}

hashes.tally.map { |k, v| k.merge({count: v}) }
#=> [{:name=>"Meagan", :count=>2}, {:name=>"Lauren", :count=>1}]

It still requires a little bit of munging to get the same return we got in the pre-tally example.

Conclusion & Further Reading

I hope that you found this useful and can add tally to your toolkit. Knowing tally means one less Google search I'll need to do in the future when I've got to count occurrences of an element in an array.

The Splat Operator

Meagan Waller — Tue, 15 Dec 2020 14:55:19 +0000

This blog is a part of my "rework" series where I rewrite a blog post that I wrote while I was an apprentice software developer. I have lots more knowledge and want to revisit these old posts, correct where I'm wrong, and
expand where I now have more in-depth experience. If you'd like to, you can read my initial post about Ruby's splat operator.

What is the splat operator?

Programmers call ! bangs, . dots, => hash rockets (this one may be Ruby specific), and * splats. Calling the asterisk a splat has a history in computing. In Commodore file systems, an asterisk appearing next to a
filename was called a "splat file" ¹.

The splat operator is the *, think of it like saying etc when writing code. In Ruby, a splat is a unary operator that explodes an array (or an object that implements to_a) and returns an array.

This definition might seem kind of heady, so I'm going to bring it back down to earth with some concrete examples. First, we will start with some simple use cases to explore what's going on, and then we will dig into some
Ruby code that takes advantage of the splat.

Splats aren't exclusive to Ruby, but this post's scope only covers using them in Ruby.

Expected behaviors

Splats have a few different expected behaviors. We will explore how to use them to do various things and look at test cases from the Ruby language spec. The examples below are purely for illustrative purposes and are not necessarily examples of sophisticated code architecture.

Creating a method

An expected splat behavior is to create a method that accepts a variable number of arguments. Everything passed to the splatted parameter is collected inside an array with the same name as the parameter.

def example(a, *args)
  puts a
  puts args.inspect
end

example("a", "b", "c", "d")

a
["b", "c", "d"]

The rest of the array is now available inside of args.

The arguments you pass don't all have to be the same type either:

def example(a, *args)
  puts a
  puts args.inspect
end

example("a", 1, true, [1, 2, 3])

a
[1, true, [1, 2, 3]]

Splats can go anywhere

The most common place to put a splat is at the end of the parameter list; after all, it does act as the etc. But the splatted parameter can go anywhere.

def example(a, *args, c)
  puts a
  puts args.inspect
  puts c
end

example("a", 1, true, [1, 2, 3], "Hello")

a
[1, true, [1, 2, 3]]
Hello

While a splat can anywhere, it can't go everywhere. The limit is one splat per method argument list because how would Ruby know where one ends, and the other begins?

def example(*a, *b)
  puts a.inspect
  puts b.inspect
end

example("a", "b", "c", "d")

SyntaxError: unexpected *
def example(*a, *b)
                ^

Invoking a method

The above example is how to use a splat when defining a method. We can do the inverse and use a splat when invoking a method, too. We have a function that expects three arguments, name, age, favorite_color, and an array of triples (an array containing three items), but we don't want to destructure the triples and then pass them into the method. Splat is the operator to handle this, but first, let's look at how we might accomplish what we want without a splat:

def user_info(name, age, favorite_color)
  puts "#{name} is #{age} years old and their favorite color is #{favorite_color}"
end

users = [
  ["Meagan", 28, "pink"],
  ["Lauren", 25, "purple"],
  ["Bob", 32, "green"],
  ["Leonard", 7, "blue"]
]

users.each { |user| user_info(user[0], user[1], user[2]) }

Meagan is 28 years old and their favorite color is pink
Lauren is 25 years old and their favorite color is purple
Bob is 32 years old and their favorite color is green
Leonard is 7 years old and their favorite color is blue

A splat removes the need for the explicit destructuring step:

def user_info(name, age, favorite_color)
  puts "#{name} is #{age} years old and their favorite color is #{favorite_color}"
end

users = [
  ["Meagan", 28, "pink"],
  ["Lauren", 25, "purple"],
  ["Bob", 32, "green"],
  ["Leonard", 7, "blue"]
]

users.each { |user| user_info(*user) }

Meagan is 28 years old and their favorite color is pink
Lauren is 25 years old and their favorite color is purple
Bob is 32 years old and their favorite color is green
Leonard is 7 years old and their favorite color is blue

Array Destructuring

I hinted at it above, but what the splat is doing is destructuring arrays. When you break an array down into individual elements, that is destructuring.

name, age, favorite_color = ["Meagan", 28, "pink"]

puts name
#=> Meagan
puts age
#=> 28
puts favorite_color
#=> pink

Instead of naming every element in the array with a variable, we can use the splat operator.

Pop & Shift

The .pop and .shift method on Array in Ruby mutate the array they are invoked on. For example:

arr = [1, 2, 3, 4]
arr.shift
#=> 1
arr
#=> [2, 3, 4]

arr = [1, 2, 3, 4]
arr.pop
#=> 4
arr
#=> [1, 2, 3]

What if I want the first element, but I want to leave the array the way I found it?

arr = [1, 2, 3, 4]
first, *rest = arr
first
#=> 1
rest
#=> [2, 3, 4]
arr
#=> [1, 2, 3, 4]

If I just want the last element the splat goes at the beginning:

arr = [1, 2, 3, 4]
*first, last = arr
last
#=> 4
first
#=> [1, 2, 3]
arr
#=> [1, 2, 3, 4]

In either example, leave the splat unnamed if you only care about grabbing the first or last element.

arr = [1, 2, 3, 4]
first, * = arr
first
#=> 1

arr = [1, 2, 3, 4]
*first, last = arr
last
#=> 4

Other Array Use cases

You can also use a splat to flatten an array.

names = ["Meagan", "Lauren", "Leonard", "Bob"]
more_names = ["Alice", "John", *names, "Mary"]
more_names

=> ["Alice", "John", "Meagan", "Lauren", "Leonard", "Bob", "Mary"]

And you can use a splat to make an array.

arr = *"example"
#=> ["example"]

hsh ={a: "a", b: "b"}
splatted = *hsh
#=> [[:a, "a"], [:b, "b"]]

Ruby language spec examples

The Ruby language spec is a great place to look to see how something works. Let's look at a few test cases that explain what a splat is doing. For the examples below, I'll be referencing this file. I'm not going to get too into the how of these tests or their setup. Please reference the documentation to learn more. It's a cool project.

context "with a single splatted Object argument" do
  before :all do
    def m(a) a end
  end

  it "does not call #to_ary" do
    x = mock("splat argument")
    x.should_not_receive(:to_ary)

    m(*x).should equal(x)
  end

  it "calls #to_a" do
    x = mock("splat argument")
    x.should_receive(:to_a).and_return([1])

    m(*x).should == 1
  end
end

These tests show that x (the splatted argument) is turned into an array, by invoking .to_a on it (the should receive and return) when it is sent as a splatted argument to the m method (defined in the before :all block). Below is a test
that verifies the behavior we saw in the section "Invoking a method."

What would you expect this method invocation to return?

def m(a, b, *c, d, e)
  [a, b, c, d, e]
end

x = [1]
m(*x, 2, 3, 4)

Hold that expectation in your head and let's look at what the corresponding test says:

 context "with a leading splatted Object argument" do
  before :all do
    def m(a, b, *c, d, e) [a, b, c, d, e] end
  end
  it "calls #to_a" do
    x = mock("splat argument")
    x.should_receive(:to_a).and_return([1])

    m(*x, 2, 3, 4).should == [1, 2, [], 3, 4]
  end

  ...
end

c is turned into an empty array even though it came in the middle of the parameter list. Recall what we learned above, a splat can go anywhere in the parameter list, and Ruby is smart about resolving it. Because there are four
required arguments, *c doesn't gather up any of them into an array. There is no etc or rest.

What would happen if we invoked m with these arguments?

m(*x, 2, 3, 4, 5, 6, 7, 8, 9)

#=> [1, 2, [3, 4, 5, 6, 7], 8, 9]

Ruby knew it needed the last two arguments to assign to d and e. All the rest get shoveled into the array set to c.

I like to use the Ruby spec in tandem with the Ruby documentation. It's great to read about how something works, and reading test cases helps fill in my mental model even more.

Why would I use it?

You would use splat for a variety of reasons. If we look back at the Array Destructuring section, we can see how powerful it can be for building arrays without the need to coerce our types manually.
For some hash where there's a key of foo that has a value of some array, a typical use case sans splatting might look like:

Checking that the array exists, and creating it if not
Work regardless of someone passing in an array of strings or a single string

With splatting, that workflow looks like this:

hsh = {}

def add_foo
  ["bar", "baz"]
end

hsh[:foo] = [*hsh[:foo], *add_foo]
hsh
#=> {:foo=>["bar", "baz"]}

hsh = {}
hsh[:foo] = [*hsh[:foo], *"bar"]
#=> {:foo=>["bar"]}

Real-World Examples

The sinatra gem uses splat args multiple times in their codebase. Here's one example from their test suite

def use(*args)
  @use << args
end

before do
  @use = []
end

We don't need to get into the nitty-gritty of how they're using it in this particular use case. But we can see that the tests are setting up an empty array called @use, and they want to fill that array with elements, but they don't know how many, so use takes advantage of the splatted parameter.

Let's also look at thoughtbot's upcase source code. They're again using a splatted parameter in the test setup, and they're also invoking a method with a splatted argument.

it "doesn't render a CTA link" do
  render_trail completeables: []

  ...
end

# Creating a method with a splatted parameter
def render_trail(*trail_args)
  ...

  # Invoking a method with a splatted argument
  ...
  create_trail(*trail_args)
end

def create_trail(completeables:)
  ...

  completeables.each do |completeable|
    ...
  end

  ...
end

In the above code, first render_trail is invoked with completeables: []. trail_args is a splatted parameter; if we were to inspect it, it would look like [{completeables: []}]. Next, we invoke create_trail with a splatted argument, meaning we explode out trail_args, and pass completeables: [] to create_trail.

These are just two examples I quickly found while looking through repositories I found. There are so many examples of libraries using splats to accomplish so many cool things.

Conclusion & Further Reading

I hope that splats are more approachable after reading this post and seeing the examples. This post is only a jumping-off point, and there is a lot more you can do and tons of ways that Rubyists use splats, including lots of compelling use cases in popular libraries like Rails. Take a look around in your favorite Ruby codebases, and let me know if you see any examples. The links below go further into what you can do with splats or provide more information.

While this was a pretty comprehensive overview of the splat, we haven't even scratched the surface of the double-splat yet; if you're interested in a blog post about that, please let me know by sending me a tweet.

Asterisk wikipedia page ↩

My Favorite Professional Development Resources

Meagan Waller — Fri, 11 Dec 2020 16:20:44 +0000

I've been trying to be better about not getting stagnant in my career. However, I was feeling pretty burnt out in the tech industry for the past few years, and I took a big step back from growing and learning outside of work; this is okay, and you may be experiencing that currently. Come back to this post when you're ready to jump back in.

These lists are aimed mostly at mid-level software developers who focus on Ruby/Rails and at traditionally backend developers looking to transition to full-stack development/frontend development.

If you're looking for opportunities to grow and gain some new skills, please read on.

Courses & Video Content

These are a mix of paid and free courses and video content I've enjoyed or am excited to try out. Any of these I have purchased, I have paid for myself. No one is paying me to talk about these courses. I genuinely believe in them.

Frontend Masters: Frontend Masters, in my opinion, is a must-have resource for anyone looking to gain a more profound knowledge of frontend development. These courses are great for a variety of skill levels, from junior developers to senior developers. Some of my favorite courses I've taken are: JavaScript: The Hard Parts, JavaScript: From Fundamentals to Functional JS, v2, and Deep JavaScript Foundations, v3. A monthly subscription starts at $39, or you can get a year-long subscription for $390. Frontend Masters frequently updates with new courses. This subscription is worth every penny.
Upcase by thoughtbot: Upcase is the perfect platform for a junior Rails developer to gain experience. Lessons range from Test Driven Development, Vim, Advanced Rails Patterns, Refactoring, Git, and more. The best part is Upcase is free to use. However, I don't think they are updating or adding any new courses.
Ruby Tapas: Ruby Tapas are short screencasts of "Gourmet Ruby" by Avdi Grimm. Subscribing to the service gives you access to the entire backlog, 650+ with new screencasts added weekly. Most are under 10 minutes, so they're a perfect way to start your day and get your brain going. Categories range from APIs and Libraries to Testing to Patterns and Anti-Patterns, and more. A monthly subscription starts at $18 a month or $180 a year.
Flawless Ruby: Flawless Ruby is a course taught by Avdi Grimm. It's perfect for when you've learned Ruby and are wondering what comes next. It will make you a confident Ruby developer who understands Ruby's unique styles, idioms, and idiosyncrasies. This course is a one-time cost of $49.
Master The Object-Oriented Mindset in Ruby and Rails: Master The Object-Oriented Mindset (MOOM) is a course taught by Avdi Grimm. It was initially an 8-week live course. This course will demystify object-oriented programming and help you learn object design thinking. It will do it all with technique demos and pair programming sessions where you'll see two expert Rails developers add features to a real-world Rails application discussing practical object-oriented design along the way. I'm still taking this course, and it's a big one! But it's worth it. There's a one-time cost of $299.
Egghead.io: This is a new platform to me, but it looks super cool! There are many courses, mostly frontend focused, and the cool thing about them is that the video lessons are usually pretty quick and focused. Egghead is an excellent resource for a frontend developer looking to level up their skills or learn specific frameworks and libraries. Yearly membership is $250, or you can go month-to-month for $40/month.

Podcasts

I've only recently started to get into tech podcasts, so I only have a few recommendations here. I would love to hear your favorites.

Ladybug Podcast: I recently stumbled on the Ladybug Podcast, and I adore it. It's a tech podcast hosted by three (four starting in season 5!) woman developers that focuses on professional development and frontend development. They've had some great guests, and I'm almost through the entire backlog. My favorite episodes so far are: Creating Digital Content, Junior to Senior Developer: Career Progression For Programmers, All About Technical Portfolios, and Side Project Balancing Act.
The Rails with Jason Podcast: I've just started to listen to this podcast, but I like the in-depth technical discussions so far. I especially like the "How I'd Build It" episodes where Jason will interview a guest and ask them how they'd build a feature. I think they're great to listen to see how experienced developers approach and talk through requirements, solutions, pitfalls, and more. Check out this How I'd Build It Episode with Noah Gibbs on building a scheduling feature.
JSParty: This is a fun panel-style podcast focused on JavaScript and the web! I'm new to this one and started listening because one of the co-hosts of the Ladybug Podcast is on their rotating panel. I enjoyed the discussions around How to design a great API, and career progression.
Ruby on Rails Podcast: This podcast is about Ruby on Rails, open-source, and programming in general. Brittany Martin is the host and each week she conducts an interview and she and the guest have a pleasant conversation. I'm excited to dig more into this one. Each episode I've listened to I've enjoyed. The best part is that they're typically right around the 30-minute mark, so they're great for listening in the morning while you get your day started. My recommendations: Finance for Software Developers, and the interview with Jason Swett.

Books

These are technical books that I have personally read and enjoyed.

Eloquent Ruby by Russ Olsen: Even though this book is a bit older (published in 2011), I still think it holds up. The focus is on how to write great Ruby code, not specific syntax or versions. This book remains relevant even for modern Ruby development. I reread this in 2020 and walked away with some new A-Ha moments.
Practical Object-Oriented Design in Ruby by Sandy Metz: This book is a must-have for any Rubyist. I think it's excellent for novice Rubyists and advanced Rubyists who might need a better grasp on writing more manageable object-oriented Ruby code. I also reread this one in 2020, and it still definitely holds up.
You Don't Know JS, Yet Series by Kyle Simpson: I loved the first edition of this series, and so far, the second edition has also been fantastic. Get a deep-dive into the core mechanisms of JavaScript. Each book focuses on a specific part of JavaScript. These books are open sourced on GitHub so that you can read them for free, but if you can afford to, it's worth it to buy and have a physical copy to put on your shelves.
Testing Rails by thoughtbot: I bought this book when it initially launched and have been referencing it regularly ever since. The book is now available for free, as well as the companion GitHub repository. I think this book has some fantastic ideas about how to test a Rails application with tons of concrete examples and best practices.
Rails 5 Test Prescriptions by Noel Rappin: This is another excellent book about how to test Rails applications. This book will help you write durable tests that exercise all parts of your application and to use popular testing libraries like RSpec, factory_bot and Cucumber. This a super-comprehensive book, and I also reference it regularly.

Blogs

I am a frequent reader of these blogs. Blogs are my biggest category, so I'm breaking these down into company and personal blogs.

Company Blogs

Big Binary Blog: This is the blog to stay up to date on what's new in Rails. At work, we're about to upgrade to Rails 6, so their Rails 6.1 series is an incredible resource.
Stitch Fix Technology Blog: I am always coming back to this blog. The posts are so well-done and informative, so it's just a joy to read. From interviews to nitty-gritty data science and algorithm posts, there is always something interesting to read.
Thoughtbot Blog: I've been reading the thoughtbot blog since 2013. They write about various topics with a focus on Ruby, Rails, and team processes.
Dev.to: Dev is a fantastic platform for developers. I follow many different tags that I'm interested in, and every morning when I visit, I've got a newsfeed full of posts. It seems like a fantastic community, and so far, I've treated it as fairly read-only, but I'm planning on posting and interacting more in the upcoming year.

Personal Blogs

Ruby Yagi: Ruby, Rails, and Web Development blog posts. Updated pretty frequently.
We Learn Code: We Learn Code is a blog by Ali Spittel, you'll find thorough articles about software development focusing mostly on the frontend, career advice, and beginner's guides. Plus it's just a super cute website.
Ashlee M Boyer's Blog: Ashlee focuses on accessibility, disability, and mental health in the tech industry.
Gift Egwuenu's Blog: Gift is a frontend engineer who blogs about professional development, Nuxt.js, D3, CSS, and more.
Angie Jones' Blog: Angie Jones is a test automation and Java wizard, that's also the focus of her blog.
Sarah Drasner: Sarah writes mostly on CSS-Tricks and the Netlify blog and is an expert in SVG and Vue.js.

Newsletters

I am a newsletter addict. If your blog offers a newsletter, I have signed up for it. Here are some of my favorites:

Cassidoo Newsletter: A weekly newsletter about tech, featuring an interview question of the week, corny jokes, and mechanical keyboard pics from time-to-time. I always read this one when it arrives in my inbox.
JavaScript Weekly: A round-up of all things JavaScript from the previous week, articles, news, tools, and projects.
Ruby Weekly: A round-up of all things Ruby from the previous week. I've found so many great libraries and blogs through this newsletter.
Software Lead Weekly: This is a newsletter curated by Oren Ellenbogen, a round-up of articles about leadership, culture, and people in tech. I'm not a software lead (yet), but I enjoy this newsletter and the pieces that I've read from it.

Wrap Up

That's it for my favorite professional development resources. These lists are not exhaustive. I wish I could list every single resource I use and love, but I won't do that for the sake of trying to be somewhat concise. If I am missing some of your favorites or if you'd like more suggestions, please tweet at me and let me know.

Forem: Meagan Waller

Reading Rails: Understanding how accepts_nested_attributes_for works

How I finally learned to get to inbox zero using Gmail filters

Assessing & Unsubscribing

Categorizing Emails You Want to Keep

Editing Existing Filters

Wrapping up

Convert Rows to Columns with Ruby's Transpose Method

Use a nested dynamic form with a has_many :through association in Rails.

has_many :through at a high-level.

When should I reach for has_many :through

Introducing Pantry

Getting started

Creating the models

Creating controllers

Rendering nested forms

Nested Attributes

Adding flash notices

Adding more recipe ingredients to a recipe

Adding and Removing Recipe Ingredients using Cocoon

Setting up cocoon

Refactoring our form and updating recipes

Make sure recipe ingredients get removed

Create or find ingredients

Wrap Up

Render Dynamic Pages in Gatsby Using File System Route API and YAML

Okay, but why would I want to do that?

Creating a Gatsby Project

Making the DOGWALKER Proof of Concept

Adding locations statically

Create & Query Locations

Creating Dynamic Locations Pages

Finishing Touches

Wrap Up

Looking at 2020, Goals for 2021

💸 Financial Goals

Pay off all credit cards

Have three months salary in savings

📚 Personal Goals

Read seven books

🏃‍♀️ Fitness Goals

Workout 2-3x a week

Complete Couch to 5K

Lose 25lbs

Things I did in 2020 that didn't make my initial goal list

Goals for 2021

Fitness Goals

Financial Goals

Personal Goals

Professional Goals

Shooting-for-the-stars goals

Wrap Up

One Step Make and Change into a Directory

Make a Directory and Change Into It

Add this function to your set up

Secret Santa Ruby Quiz

The Puzzle Requirements

My Thought Process

Code Walk Through

Step 1: Receive a list of names and make Santas

Step 2: For each Santa, find their potential assignees

Step 3: Pick randomly for each Santa

Step 3a. Keep re-picking until everyone has a unique assignee

Conclusion & Further Reading

Ruby's Tally Method

Pre-Tally

Using tally

Conclusion & Further Reading

The Splat Operator

What is the splat operator?

Expected behaviors

Creating a method

Splats can go anywhere

Invoking a method

Array Destructuring

Pop & Shift

Other Array Use cases

Ruby language spec examples

Why would I use it?

Real-World Examples

`has_many :through` at a high-level.

When should I reach for `has_many :through`