Organization, organization, organization.

The deeper I get into programming the more I envy my father-in-law's ability to pack his car for summer camping trips.

It's impossible (particularly given the 4-week timeframe we had) to even begin to scratch the surface of the Rails 190,000 line Framework ... but what we were able to do is start to see the elegance of it's organizational capacities. The real challenge, though, is in structuring how we CREATE the project in the first place. So, in true "Notes to Myself" fashion, that's what I'd like to focus on in this blog post.

Step One: Create your App

Pretty basic.

rails new app-name

Rails convention is to hyphenate multi-word names. After everything is loaded you can add whatever you like to your Gemfile (gem 'pry', gem 'bcrypt') and then bundle.

bundle install

Step Two: GIT!

The number of times I forget to do this... woof! Crazy important, though. Create a new repository and commit constantly. A couple of tips:

a) Don't worry about adding a README, gitignore, or license. The first two are generated when you created the Rails app, and the last one you can do later.
b) You are creating a new repository (not pushing).
c) Skip "echo # asdf".
d) Do "git add ." instead of "git add README.md".

Also remember how to commit.

git add .
git commit -m 'some pithy comment'
git push

Step Three: Create Models

I like to use the model generator here. The great thing about it is that it creates your migrations for you.

rails g model model_name model_attribute:attribute_type --no-test-framework

The syntax here: rails, g (for "generate"), model, the name of the model, and then each attribute you would like in that model. You can add as many attributes here as you like (name, email, gender), just make sure that each one is followed by a colon and it's corresponding type (integer, string, text). Rails will automatically create tests when you use the generate method, so if you don't want them, add "--no-test-framework" to the end of each command.

Step Four: Migrate

Just because Rails gave you some beautiful migrations doesn't mean you have anything going on in the database!

rake db:migrate

Step Five: Create Controllers

Again, I really like to use Rails to generate my controllers because they will automatically give you some empty actions, routes and corresponding views.

rails g controller users index show create --no-test-framework

The syntax here: rails, g (for "generate"), controller, the name of the controller, and then each action you would like in that controller. It's pretty awesome.

Step Six: Fix or Create Routes

As I mentioned, Rails will create routes for you when you use the controller generator, but they're pretty messy. Each route is written individually instead of using resources, and if you want anything custom you'll have to do it yourself anyway. So, I recommend jumping into your config/routes.rb file and doing some cleaning.

resources :users, only: [:index, :show, :create]

The syntax here: resources, the name of the controller. If that's all you put, you'll get the full 7 RESTful routes, but you can also specify "only" or "except" to limit which routes are added.

Step Seven: Model Associations & Validations

Before you can start any real work on your controller or views, you need to set up your associations (has_many, belongs_to), and while you're there you might as well start getting some validations together.

class User < ApplicationRecord
  include ActiveModel::Validations
  has_secure_password

  validates_presence_of :username, :email
  validates_uniqueness_of :username, :email

  has_many :instruments
  has_many :makers, through: :instruments
end

has_secure_password belongs to the Bcrypt gem, so be sure to add that to your Gemfile if you haven't already and create a migration for your users table that adds a column for 'password_digest'.

class AddColumnToUser < ActiveRecord::Migration[6.1]
  def change
    add_column :users, :password_digest, :string
  end
end

Step Eight: Controller Basics

This next step is a matter of preference. Because a lot of the controller actions are the same or VERY similar between models, I like to do some of the simple logic that I know they all could use. Instance variables, strong params. That sort of thing. These can be adjusted later, but if I have several controllers with identical actions I'll fill one of them in, copy it, paste it into the other controllers and simply change the model name.

class UsersController < ApplicationController
before_action :set_user, only: [:show, :edit, :update, :destroy]

  def index
    @users = User.all
  end

  def new
    @user = User.new
  end 

  def create 
    @user = User.new(user_params)
  end

  def show
  end

  def edit
  end

  def update
  end

  def destroy
  end

  private

  def set_user
    @user = User.find_by(id: params[:id])
  end

  def user_params
    params.require(:user).permit(:username)
  end
end

Step Nine: Forms & Partials

Now that all of the pieces are in place, it's time to set up our forms. And because the "new" and "edit" forms are often identical, it's worth creating a partial or two to save yourself from some unnecessary code. I have a few other blog posts I'm writing that cover forms in Rails, so I'm not going to go too deeply into that here, but I will copy a fairly comprehensive form page that I have in my project.

<%= form_for @instrument do |form| %>

<div><%= form.label "Type"%></div>
  <%= form.collection_select :category_id, banjo_categories, :id, :name %>

<div><%= form.label "Maker" %></div>
<%= form.text_field :maker_name, list: "makers_autocomplete" %>
<datalist id="makers_autocomplete">
<% Maker.all.each do |maker| %>
<option value="<%= maker.name %>">
<% end %>
</datalist> 

<div><%= form.label "Price"%></div>  
<%= form.number_field :price%>
<div><%= form.label "Year"%></div>
<%= form.number_field :year%>
<div><%= form.label "Description"%></div>
  <%= form.text_area :description%>

<div><%= form.submit "Add Instrument"%></div> 
<% end %>

This page utilizes 3 types of input: collection_select, datalist, and the normal input for a form_for page. Most of this (excluding the opening and closing tags) can be encapsulated in a partial. Partials are named beginning with an underscore and then followed by the name of the view folder they're in.

_instruments.html.erb

The repetitive information is put into this file and then the view file has a render method that essentially yields to the partial.

<%= render partial: "instruments", locals: { form: form, family: @family, instrument: @instrument } %>

The syntax here: "render partial:", the name of the partial, "locals:" and then a hash with key/value pairs linking established variables from the controller to local variables in the partial.

Step Ten: Controller Logic

This is the big one. Get into a comfy chair. Lock the door. Put the 6-pack of Dr.Pepper next to you and get to work. If 20% of your time is spent setting everything up, and another 20% is cleaning up/refactoring, then 60% will be figuring out how everything actually needs to work. I also have some blog posts dedicated to routes and what I call the "Client's Journey", but the pattern I feel I use for every Controller action is this:

-What's coming in?
-What would you like to do here?
-Where is it going after?

The first question is a params issue. Whether it's coming from the database, a form, or just a GET query ... there always seems to be useful information right at the top of any action. The second piece is how you want to manipulate that data. Most of the time that question is answered for you by which action you're in. I'm in the index? I must want to show some information, so I probably need an instance variable. I'm in the update action? I need to connect with the database and use what's coming in to alter it. And finally, where do you want to redirect the user to after? This tends to be the most malleable of the decisions. Some of them are fairly obvious (edit will go to the edit view), but others are a matter of choice. When you finish updating a User's info you could go to their page, but you could also go to a homepage, or really anywhere you want to take them. It can get a little overwhelming when you start to add in validations and protections against bad data, but sticking with those 3 steps will get you pretty far!

Step Eleven: Helper Methods

There are several types of helper methods. Some go in the model, some in the controller, and some in the helpers folder (which are specific to views). But at the end of the day, helper methods are simply ways to clean up your code so that looking at your controller doesn't feel like you're seeing the Matrix for the first time.

View helpers keep SQL queries out of of your actual view pages. This helper is in my instruments helper folder and is accessed in my instruments "new" page.

  def banjo_categories
    Category.where(id: [1...5])
  end

This is a scope method helper that I have in my Maker class which is accessed in the index of my Makers Controller.

scope :search, ->(name) { where("name LIKE ?", name) }

And then, of course, you have regular helper methods like this one in my Instrument Controller to help alleviate repetition.

  def set_instrument
    @instrument = Instrument.find_by(id: params[:id])
  end

There's also a helper_method that you can use to expose Controller methods to your views. Apparently it's not ideal, but it is useful in certain situations such as accessing a current users params.

class ApplicationController < ActionController::Base
  helper_method :current_user

  def current_user
    @current_user = User.find_by(id: session[:user_id])
  end

  def require_login
    redirect_to "/login" if !current_user
  end
end

Step Twelve: Error Messages

Last but not least! Well, it is actually kind of least. But still important because it has to do with user experience. Most of these steps were either to get an app up and running or to clean up an app so that 10yrs down the line you (or another coder) can look at it and easily understand what's going on and fix things quickly and efficiently. Error Messages are our way of guiding the user through our program. It took me awhile to grasp the concept of an error being an object, but there it is. And as with all other objects, errors have attributes that we can call upon and display. This is a pretty common error syntax.

 <% if instrument.errors.any? %>
  <div id="error_explanation">
    <h2>Oops!  We noticed  
      <%= pluralize(instrument.errors.count, "error") %>
      when trying to process your information.
    </h2>
    <ul>
    <% instrument.errors.full_messages.each do |msg| %>
      <li><%= msg %></li>
    <% end %>
    </ul>
  </div>
<% end %>

The first line checks to see if our instrument object had any errors. If it did, there will be a hash containing messages about those errors. In the h2 we count the number of errors committed, and in the ul we display each of them with the full_messages method.

I wish I could say "And that's it!". Hahaha Remember: 190,000 lines of code. We haven't even scratched the surface. But these 12 steps will hopefully help guide you (and me!) through our next Rails adventure with a little less sweat than the first one.

Peace