Understanding Polymorphic Associations in Rails

When first trying to get an understanding of polymorphic associations in Rails, I was completely lost. At this point in my learning curve, polymorphic associations are a high-level concept in Rails which allows the programmer to reuse a single model to be useful for other models. It’s difficult to describe without an example. So… here we go.

An example of a polymorphic association is as follows. Let’s say you’re building a sports history database. Baseball players and basketball players are both athletes, but you want to be able to keep the baseballers separate from the basketballers. One way to do that is to create an Athletes model.

The Athlete model would be a way to tie the sports together.

Coding The Polymorphic Association

This requires a migration where we connect the athletes with the sports they play:

rails g migration AddSportToAthlete sport_id:integer sport_type:string

First we set the polymorphic association model:

class Athlete < ApplicationRecord
  belongs_to :sport, polymorphic: true

Then we assign that association to the baseballers and the basketballers:

class Baseballer < ApplicationRecord
  has_many :athletes, as: :sport

class Basketballer < ApplicationRecord
  has_many :athletes, as: :sport

irb rbenv: pry: command not found – FIXED

$ irb
rbenv: pry: command not found

The `pry' command exists in these Ruby versions:

I was having the issue in which I was attempting to test code using irb and the irb command wasn’t opening the Ruby REPL.

Apparently, pry was interrupting my usage of irb.

To fix it, I just updated pry:

gem install pry
irb rbenv: pry: command not found

Now it’s updated and working correctly. Here are my related software versions:

$ rails -v
Rails 5.2.1
$ pry -v
Pry version 0.11.3 on Ruby 2.5.1
$ irb -v
Pry version 0.11.3 on Ruby 2.5.1

Seeing a Rails App Develop From Looking at Git Changes

I’m deep diving into Ruby on Rails this week. One of the things I find interesting is how the scaffolding creates new parts of a Rails app. This is a helpful tool for understanding the stack so I’m stepping through it looking at the changes made which we can see better with git.

Below is a step by step view of the files created when developing a new Rails App. 

Stepping Through Rails and Watching Git Changes

rails new appName

  • git status => All code related to Ruby on Rails

appName => bundle update

  • git status => No changes

appName => bundle install

  • git status => No changes

appName => bin/rails generate controller name_of_controller

  • git status =>
    • app/assets/javascripts/ian.coffee
    • app/assets/stylesheets/ian.scss
    • app/controllers/ian_controller.rb
    • app/helpers/ian_helper.rb
    • test/controllers/ian_controller_test.rb

Note: git changes do NOT note that when generating a new controller, Rails also generates an empty views folder. This is an important thing to be aware of as your view templates will go here related to your new controller.

appName => bin/rails generate model name_of_model title:string body:text slug:string

  • git status =>
    • app/models/tree.rb
    • db/migrate/
    • test/fixtures/trees.yml
    • test/models/tree_test.rb

Creates the new files needed to maintain a model, it’s test data and test process.

appName => bin/rails db:migrate

  • git status =>
    • db/schema.rb

This process specifically reflects your new model’s functionality with the database.

Yuba River Scuttle – Emerald Pools to Washington City, CA

There is an adventure that I had been thinking of doing for a long time, but had never actually done.

I call this adventure the Yuba River Scuttle.

It goes from the Emerald Pools in Northern California to a little town called Washington City, CA. I’m not aware of anyone who has done this. Before we did it, I had never heard of anyone else doing it.

What is a River Scuttle

Nevada County, California, USA: Yuba River
Yuba River – Taken in 2011

A river scuttle is a journey in which you carry nothing but a waterproof bag. The scuttler carries that bag on their arm or shoulder. They use it as a floating device when swimming through challenging spots.

The idea is that you are 100% prepared to be aquatic. You are carrying everything you need to camp for a day or two in a waterproof bag. I’m guessing that it’s an 11 mile trip based on the calculation below.

Emerald Pools to Washington City, California
My rough estimate is 10.95 miles worth of river scuttling. The start is on the right. The end where the red marker is.

Waterproof bags will need to have space for warm cloths, a hammock, some food and a bit of water. I’m guessing this is a 2 day trip.

River Scuttle Statistics

  • Start altitude of 4,500 feet at the Emerald Pools
  • End altitude of 2,589 feet in Washington City, CA
  • Altitude change of 1,911 feet
  • Descent rate of 174 feet per mile

The elevation drop is about the same as the height of the second tallest building in the world.

We are started on Saturday afternoon at 5:00 p.m.

More River Scuttle Maps

The above map is a line drawn using an elevation mapping tool. The bar chart below represents the elevation change related to the image above marked with the red line.

North Fork of Yuba River Large Sized Topography Map

Notes on the Adventure

The Yuba River Scuttle is challenging.

Everyone in our group was enthusiastically athletic. Despite that, we were all exhausted by the end of the adventure. Our feet were sore, the bags became heavier, and the river started feeling colder. People started making mistakes that led to uncontrolled slides. It was getting dangerous.

River scuttling is extremely slow. I’d guess we cover between .15 and .25 miles an hour. Swimming is slow. Rock climbing is slower. My estimate of eleven miles in 2 days was misguided at best.

Yuba river scuttling is also uncomfortably cold. In August, when the river is at it’s lowest and the day is at it’s hottest, the cold water takes the scuttler’s breath away.

There is a road that runs along the river for the last 4-5 miles. If it weren’t for that road, we would have had to camp another night on the river.
Camping on the river is very cold. The hammocks are not great for keeping a person warm. V said something of note, “I’m never sleeping in a hammock again.”

The river is stunningly beautiful. Over and over the beauty of the river astonished us. Towards the end, I would come upon another beautiful waterfall and think to myself, ‘Ugh, do we have to swim it?’

The journey was a constant process of problem-solving. There is a new beautiful waterfall cavern. How are we getting around it? Phew, I don’t want to swim in the shadows. Can we make the climb to get around it? That kind of thing was the name of the game.

It was genuinely fun. It was awful challenging. It was legitimately dangerous. If I were to do it again, I would give myself 3-4 days.

On Benefits – Letter 1

By Lucius Annaeus Seneca

I’m thinking of reading each of these letters and putting them out as a podcast. If you’d like me to continue, please let me know in the comments section.

Source – Gutenberg.org

Letter 1

Among the numerous faults of those who pass their lives recklessly and without due reflexion, my good friend Liberalis, I should say that there is hardly any one so hurtful to society as this, that we neither know how to bestow or how to receive a benefit.

It follows from this that benefits are badly invested, and become bad debts: in these cases it is too late to complain of their not being returned, for they were thrown away when we bestowed them. Nor need we wonder that while the greatest vices are common, none is more common than ingratitude: for this I see is brought about by various causes.

The first of these is, that we do not choose worthy persons upon whom to bestow our bounty, but although when we are about to lend money we first make a careful enquiry into the means and habits of life of our debtor, and avoid sowing seed in a worn-out or unfruitful soil, yet without any discrimination we scatter our benefits at random rather than bestow them.

It is hard to say whether it is more dishonorable for the receiver to disown a benefit, or for the giver to demand a return of it: for a benefit is a loan, the repayment of which depends merely upon the good feeling of the debtor. To misuse a benefit like a spendthrift is most shameful, because we do not need our wealth but only our intention to set us free from the obligation of it; for a benefit is repaid by being acknowledged.

Yet while they are to blame who do not even show so much gratitude as to acknowledge their debt, we ourselves are to blame no less. We find many men ungrateful, yet we make more men so, because at one time we harshly and reproachfully demand some return for our bounty, at another we are fickle and regret what we have given, at another we are peevish and apt to find fault with trifles.

By acting thus we destroy all sense of gratitude, not only after we have given anything, but while we are in the act of giving it. Who has ever thought it enough to be asked for anything in an off-hand manner, or to be asked only once?

Who, when he suspected that he was going to be asked for any thing, has not frowned, turned away his face, pretended to be busy, or purposely talked without ceasing, in order not to give his suitor a chance of preferring his request, and avoided by various tricks having to help his friend in his pressing need? and when driven into a corner, has not either put the matter off, that is, given a cowardly refusal, or promised his help ungraciously, with a wry face, and with unkind words, of which he seemed to grudge the utterance. Yet no one is glad to owe what he has not so much received from his benefactor, as wrung out of him.

Who can be grateful for what has been disdainfully flung to him, or angrily cast at him, or been given him out of weariness, to avoid further trouble? No one need expect any return from those whom he has tired out with delays, or sickened with expectation.

A benefit is received in the same temper in which it is given, and ought not, therefore, to be given carelessly, for a man thanks himself for that which he receives without the knowledge of the giver.

Neither ought we to give after long delay, because in all good offices the will of the giver counts for much, and he who gives tardily must long have been unwilling to give at all. Nor, assuredly, ought we to give in offensive manner, because human nature is so constituted that insults sink deeper than kindnesses; the remembrance of the latter soon passes away, while that of the former is treasured in the memory; so what can a man expect who insults while he obliges? All the gratitude which he deserves is to be forgiven for helping us.

On the other hand, the number of the ungrateful ought not to deter us from earning men’s gratitude; for, in the first place, their number is increased by our own acts. Secondly, the sacrilege and indifference to religion of some men does not prevent even the immortal gods from continuing to shower their benefits upon us: for they act according to their divine nature and help all alike, among them even those who so ill appreciate their bounty.

Let us take them for our guides as far as the weakness of our mortal nature permits; let us bestow benefits, not put them out at interest. The man who while he gives thinks of what he will get in return, deserves to be deceived.

But what if the benefit turns out ill? Why, our wives and our children often disappoint our hopes, yet we marry—and bring up children, and are so obstinate in the face of experience that we fight after we have been beaten, and put to sea after we have been shipwrecked. How much more constancy ought we to show in bestowing benefits! If a man does not bestow benefits because he has not received any, he must have bestowed them in order to receive them in return, and he justifies ingratitude, whose disgrace lies in not returning benefits when able to do so.

How many are there who are unworthy of the light of day? and nevertheless the sun rises. How many complain because they have been born? yet Nature is ever renewing our race, and even suffers men to live who wish that they had never lived.

It is the property of a great and good mind to covet, not the fruit of good deeds, but good deeds themselves, and to seek for a good man even after having met with bad men. If there were no rogues, what glory would there be in doing good to many? As it is, virtue consists in bestowing benefits for which we are not certain of meeting with any return, but whose fruit is at once enjoyed by noble minds.

So little influence ought this to have in restraining us from doing good actions, that even though I were denied the hope of meeting with a grateful man, yet the fear of not having my benefits returned would not prevent my bestowing them, because he who does not give, forestalls the vice of him who is ungrateful. I will explain what I mean.

He who does not repay a benefit, sins more, but he who does not bestow one, sins earlier.

The 12-Factor App – Notes and Reflections

What follows are my own notes and summations after reading what makes a 12 factor application. Reading this has been a great glimpse into why we do certain things.

I’m currently working with a friend (Ginger Nomad) on building a web app. He is the expert so I follow his lead even though it seems needlessly complex at times.

After reading this, I get it. Why obfuscate the config.js file and the .env files with these additional node modules? Because it’s smart. This document helped me get off the, “Why are we making this so complex”-train.

That’s the why. Here are my notes.

I. Codebase

A deployment is a running instance of an application. This of a deployment like a play. Trey and Matt wrote the Book of Mormon, but the Eugene O’Neill Theatre puts an instance of the play on when they perform it.

Each application should have a single codebase. If multiple apps make up a software project, that isn’t an app. It’s a distributed system made up of apps. Each app that makes up a distributed system should be a 12 factor app on it’s own.

II. Dependencies

A 12 factor app doesn’t depend on system-wide packages. When building a 12 factor app, I should be able to send a new developer the project and they should be able to run it with a working version of node and a simple npm install XXX command.

III. Config

12  factor apps should contain everything that is likely to vary between deploys in a single place. This is often the .env file for us NodeJS developers. This file will include things like:

  • Database Connection Keys – URI, Username, Password, etc.
  • External service credentials – API keys for example
  • Canonical values like hostname – We use path – npm

When we build NodeJS apps, we use the env – npm package to put all the config information in one place.

They warn against storing config variables as constants across the whole application. I’m unsure if this is for security reasons, or if it’s because they just want all the config variables in one place. When deploying multiple instances of an application, it makes sense to have all that data in one place for easy (or algorithmic) editing.

IV. Backing Services

There should be no distinction between local and third party services. To me, this means the app should be able to swap a local MongoDB with a database hosted on mLab, for example, without changing the codebase.

Other backing services could include Amazon S3, Google Maps, Twitter, and Postmark to name a few.

Why? Imagine you’re running an instance of your application and the server gets hit by a bus. That would cause the server to stop working and the database to explode into an inferno. How would you clean it up?

Well, because your backing services are all connected the same way, you would just adjust the config file and create a new instance of the database from backup. You could be back up and running in 10 minutes.

V. Build, Release, and Run

12 factor application development calls for separated build, release and run stages.

  • Build Stage – Where you transform a code repo into an executable bundle. This is where the server fetches dependencies and compiles the assets.
  • Release Stage – Combined build procedure with deploy’s config resulting in a release which can actually be run by humans.
  • Run Stage – Here you run the app by running it’s processes against a selected release. Otherwise put, you use it. Click away brave soldier!

VI. Process

The document calls for executing the app as one or more stateless processes. These processes should be stateless and share-nothing. All persistent data should be stored in a backing service like a database.

To be honest, I don’t entirely get this. I relate it to the way Redux adjusts state in single bursts, but I’m unsure if that is a worthwhile comparison (let me know in the comments below if you know more about this).

VII. Port Binding

12 factor apps should be self-contained and should not rely on runtime injections of a web-server into the execution environment.

I don’t know what self-contained means exactly. It’s possible that NodeJS was built to be self-contained so I’ve never experienced this problem. When building a Node application, one of the first steps is to set the port for the server to listen from.

VIII. Concurrency

Processes are first-class citizens.

In 12 factor apps, the processes share nothing and are horizontally portionable so adding concurrency is simple and reliable.

To me this is like… returning books at the library. The application is the library and it can put a box out to collect returned books. If the library has an especially busy day of book collection, they can just put out an additional box. That way the two boxes are accepting books at the same time, but they books aren’t getting mixed up or returned out of order….

Does that make sense? If you have something to add, please do so in the comments below.

IX. Disposability

Robustness in applications is maximized with graceful shutdowns and fast starts. Therefore, 12 factor apps should be able to be stopped and started at a moments notice.

SIGTERM is the signal from a process manager which should be able to shut down your application.

Idempotent – A property of an operation that means the operation can be applied multiple times without changing the result beyond the initial application.

In the article they mentioned a database technology called CouchDB. I’d like to return to it one day. I love the idea of idempotent operations.

X. Development and Production Parity

Development, staging and production should have similar execution environments. Also, they time distance between a developer making a change and the production side of the app seeing that change should be short.

No more working on code for six months and launching it once. Continuous development is an important characteristic for 12 factor apps.

XI. Logs

12 factor apps should treat logs as event streams. Therefore a 12 factor app should not be concerned with routing or storing it’s output stream.

XII. Administrative Processes

Administration processes should be one-off processes.

Administration code should also ship with the application code and run against a release using the same codebase and config process.

12 Factor App Checklist

  • Does your application require a single code base?
  • Are all required external dependencies loaded into the app? Can a new node developer run ‘npm install’ and get it working?
  • Are all your config variables and settings in a single file?
  • If you pushed your codebase to an open source repository like GitHub, would your config information be automatically hidden?
  • Does your codebase interact with backing services without editing the codebase?
  • Are your build, release and runs stages strictly separated?
  • Are your application’s processes stateless? Do they share nothing with other processes? Is your backing service stored in persistent backing services?
  • Does your app NOT require injections of a webserver?
  • Have you bound processes to a specific port?
  • Does your app NOT daemonize or write PID files?
  • Can your app be started and stopped at a moments notice without losing important data?
  • Are the development and production environments similar?
  • Does your app not care if it’s storing logging output streams?
  • Does your admin code ship with the application? Is the admin code connected to the release number, the codebase and the config file?

If you answered yes to tall the above questions, it seems you have a 12-factor app. Please let me know what it is in the comments below as I’d like to see what you’re working on.

Learn HTTP – My Notes

I’m trying to write a server/API that interacts with client side API. To do that, I need to learn HTTP in depth. These are my notes from doing a deep dive into how HTTP works.

I wish there was a good tutorial where someone teaches you how to write a bunch of server integrations using HTTP requests quickly. I love to learn using muscle memory, but information related to HTTP is always very technical and dense.

My goal is to write a web app where server side Express code speaks with a SurveyJS based client side front-end efficiently.

Learning HTTP is an important step to achieving that.

WebDev Cave

HTTP Explained (Video)

It was helpful to watch this video closely before moving onto the more dense TutorialsPoint HTTP tutorial. It’s a bit boring, but we learn some important things and it preps the learner to go deeper. Specific valuable notes include:

  • HTTP is the most used protocol in the world
  • HTTP = The internet’s Postal Service
  • TCP/IP based protocol
    • To me, this means HTTP is just a checklist for communication across the internet
  • Connectionless protocol – The request for information and the response are not part of a single connection. Each request and response is a fresh connection between client and server.
  • The most reliable way to move data on the web

Request – Response Cycle

The user generates a request (HTTP Message). The request is sent to the server. The client then disconnects and waits for a response.

The server processes the request, prepares the response, establishes the connection again with the user and sends back the response in the form of a HTTP message. The server disconnects after the HTTP message is sent.

What an HTTP Message Looks Like

HTTP Request

Start line

  • METHOD – describes what to do.
    • GET | POST |DELTE | UPDATE (See below for what these all do)
  • URI – This describes where the resources we want are are.
  • Version – This tells us what version of HTTP to Use (e.g. HTTP/1.0)

Header – Key value pairs that describes language, host and the media type we are using. For example:

  • Host = www.example.com
  • Accept-language = en-us
  • Accept: text/html (image/gif, text/html etc…)

HTTP Response

Start line

  • Version – This tells us what version of HTTP to Use (e.g. HTTP/1.0)
  • Status Code – How the connection faired. See below for a more in depth description of status codes. (e.g. 404 = fail or 200 = success)

Header – Key value pairs that describes language, host and the media type we are using. For example:

  • Host = www.example.com
  • Accept-language = en-us
  • Accept: text/html (image/gif, text/html etc…)

Body – A path to where the response data is. An example would be __dirname + /events

Tutorials Point HTTP

TutorialsPoint HTTP

This HTTP tutorial is very helpful because it lays out the specifics of the technology. HTTP is actually quite simple.

HTTP Status Codes

Status codes always confused me, though after reading the tutorial, they make a lot more sense. Here’s how they break down.

  • 1xx: Informational – Status codes that begin with 1 tell the developer that things are fine and the code is just providing us information.
  • 2xx: Success – Status codes that begin with 2 tell the developer that something has been accepted, received or understood.
  • 3xx: Redirection – Status codes that begin with 3 tell the developer that further action needs to be taken before the request can be completed
  • 4xx: Client Error – Status codes that begin with 4 tell the developer/user that the request is written incorrectly or that the request cannot be fulfilled.
  • 5xx: Server Error – Status codes that begin with 5 tell the developer/user that the server failed to do something, despite the request being a valid one.

HTTP Methods

  • GET – This retrieves information from a server based on the given URI. This should only retrieve data and have no effect on the data stored within the server
  • HEAD – This is GET but without the entity-body.
  • POST – Used when the client wants to send data to the server.
  • PUT – Requests the server stores something included in the HTTP request. The server stores the data and sends a response back tot he client saying the data has been created.
  • DELETE – Requests the server deletes a file at a specific location based on the URL. The server will delete the file and will then send a response to confirm deletion.
  • CONNECT – Used to establish a connection to a server. When the client does this, they receive a response based on the current configuration.
  • TRACE – This echos the contents of the HTTP request back to the requester. This is used for debugging purposes during development. When the server processes the request, it will send a message in response to the request.


Ok so HTTP requests are not that complex. It’s just a computer system of interaction where the process of information is exact singular. Make a request, close communication. Create a response, close communication.

The part I’m really struggling with is how the HTTP requests are sent around using ExpressJS. That’s what I’ll focus on tomorrow.

Thank you for reading. Leave a comment below if you have some quality insights I’ve missed here. If you found this helpful, please let me know below as well.

Now | The Summer in Reno, Software and Looking for a Bus Location

At this point, I’m deciding between contributing to the WordPress core, or to continue to build a web app with some friends around event organization.

Software development is fairly hard so I’m spending as much time as I can studying and writing code at Beacon CoWork

This is a photo series of my walk from our apartment in downtown Reno, Nevada. It’s quite beautiful in the summer.

We are seeking a place to get the bus up and cash flowing again. I just find software to be far more interesting, and beneficial in the long run.