Rob Race's Dev Zone | Articles

Print Smarter in Ruby - Know When and How to Use Each Method

Mon, 19 May 2025 00:00:00 GMT

If you’ve ever stared at a blob of console output wondering what the hell you just printed, you’re not alone. Ruby gives you a handful of ways to print stuff, but knowing when to use which one is the real trick. In this post, we’ll go through the five most common ways to print output in Ruby, plus one gem that makes your console look like it’s had a glow-up.

`puts`: Standard Output with Automatic Newlines

puts is your go-to for dumping simple output to the console. It stands for “put string” and adds a newline at the end of each argument. It’s as friendly and low-drama as it sounds:

puts "Hello, World!"
puts 123
puts ["Ruby", "Rails"]

Output:

Hello, World!
123
Ruby
Rails

Arrays get printed line-by-line, so don’t be surprised when each item shows up on its own line.

`print`: Continuous Output Without Newlines

Want to print multiple things on the same line? Use print. It’s like puts, but without the automatic newlines:

print "Hello, "
print "World!"

Output:

Hello, World!

If you want a newline, you’ll have to add it manually:

print "Hello, World!\n"

`p`: Debugging with Inspect Output

p is the debug sibling of puts. It shows the inspect version of the object and means strings keep their quotes, and you get more detail:

p "Hello, World!"
p [1, 2, 3]
p({name: "Rob", age: 39})

Output:

"Hello, World!"
[1, 2, 3]
{:name=>"Rob", :age=>39}

If you’re debugging and want raw visibility into what you’re working with, p is your friend.

`pp`: Pretty Print for Enhanced Readability

For more complex stuff like nested hashes, pp (pretty print) makes things readable:

require 'pp'

complex_hash = {name: "Rob", hobbies: ["coding", "fitness", {sports: ["cycling", "lifting"]}]}
pp complex_hash

Output:

{:name=>"Rob",
 :hobbies=>["coding", "fitness", {:sports=>["cycling", "lifting"]}]}

Think of it like p, but with spatial awareness.

`y`: YAML Output in IRB

The y method is only available in IRB (Interactive Ruby), but it’s a great way to spit out YAML-formatted data without much effort:

# In IRB
data = {name: "Rob", languages: ["Ruby", "JavaScript"]}
y data

Output:

---
:name: Rob
:languages:
- Ruby
- JavaScript

It’s tidy, structured, and way more readable when you’re dealing with nested stuff.

Quick Summary

Method	When to Use
`puts`	General output, automatic newline
`print`	Continuous output without newline
`p`	Debugging with inspect details
`pp`	Pretty printing for readability
`y`	YAML-formatted output (IRB only)

If you just want something quick and readable, puts and p will get you far. But if you’re working with nested hashes from an API and don’t want to burn your eyes out reading the raw dump then read on.

`awesome_print`: Enhanced Pretty Printing with Style

If pp gets the job done, awesome_print gets the job done with flair. It pretty-prints Ruby objects in full color, indents them beautifully, and makes your console output feel like VS Code decided to move in.

Installation

Using Bundler:

group :development do
  gem 'awesome_print'
end

Then run:

bundle install

Or install it directly:

gem install awesome_print

Usage

require 'awesome_print'

data = {
  name: "Rob",
  hobbies: ["coding", "fitness", { sports: ["cycling", "lifting"] }]
}

ap data

Output:

{
    :name => "Rob",
    :hobbies => [
        [0] "coding",
        [1] "fitness",
        [2] {
            :sports => [
                [0] "cycling",
                [1] "lifting"
            ]
        }
    ]
}

To make it the default in IRB:

require 'awesome_print'
AwesomePrint.irb!

Once you’ve used awesome_print, going back to puts feels like reading minified JSON with no line breaks.

That’s your tour of Ruby’s printing options. Use puts and p when you’re starting out. Graduate to pp and awesome_print when your objects get gnarly. And next time you’re knee-deep in nested hashes wondering why nothing looks right, don’t forget your options.

Avoiding N+1 Queries in Rails: Easy Performance Wins for Beginners

Wed, 14 May 2025 00:00:00 GMT

Performance issues in Rails apps can sneak up on you, especially if you’re working with ActiveRecord and unaware of the infamous N+1 query problem. This post will walk you through what N+1 queries are, how to detect them, and how to fix them using simple techniques. If you’re a beginner or intermediate Rails developer, this is one of the easiest ways to level up your performance game.

What is an N+1 Query?

Imagine going to the store with a shopping list of 10 items and making a separate trip for each one instead of buying them all at once. That’s what an N+1 query does: it performs 1 query to fetch a list of records (say Post.all), and then 1 additional query for each associated record (like post.comments).

# N+1 problem example
Post.all.each do |post|
  puts post.comments.count
end

This triggers one query to get all posts, and then one query per post to fetch its comments. If you have 10 posts, that’s 11 queries. Scale that up to 100 posts, and you’re dealing with 101 queries, most of them unnecessary.

How to Detect N+1 Queries

1. Check Your Logs

In development, check your log/development.log or Rails server output. You’ll often see the same query being run repeatedly.

2. Use the `bullet` Gem

The bullet gem is designed to catch N+1 queries and notify you.

Setup:

# Gemfile
group :development do
  gem 'bullet'
end

Configuration:

config/environments/development.rb

config.after_initialize do
  Bullet.enable = true
  Bullet.alert = true
  Bullet.bullet_logger = true
  Bullet.rails_logger = true
end

You’ll get an alert in your browser or console when Bullet detects a potential N+1.

How to Fix N+1 Queries

Use Eager Loading with `.includes`

Eager loading tells Rails to fetch associated records in the same query using LEFT OUTER JOIN.

# Fixing the N+1 problem
Post.includes(:comments).each do |post|
  puts post.comments.count
end

Now, instead of 11 queries for 10 posts, you only make 2: one for the posts, and one for the associated comments.

When to Use `.joins` or `.preload`

Use .joins when you’re filtering or ordering based on associated data.
Use .preload when you want to load associations but don’t need joins.

Common Mistakes and Gotchas

Forgetting to use eager loading in controllers or views.
Not eager loading nested associations (post.comments.user requires Post.includes(comments: :user)).
Overusing .includes can also hurt performance if you load too much data.

Real-World Example

Say you’re building a blog app and rendering a list of posts with their comments:

<% @posts.each do |post| %>
  <h2><%= post.title %></h2>
  <% post.comments.each do |comment| %>
    <p><%= comment.body %></p>
  <% end %>
<% end %>

If @posts = Post.all, you’re triggering N+1 queries. Instead, use:

@posts = Post.includes(:comments)

This change alone can dramatically cut down your query count and improve performance.

Preventing N+1s Going Forward

Use the bullet gem in development to get real-time alerts.
Build a habit of checking logs when building or refactoring features.
Write performance tests if your app grows in size or complexity.

Want to keep improving your Rails performance? There’s a performance chapter in my Build A SaaS App in Ruby on Rails 8 book that covers this and more.

How to Build a Twitter Clone with Rails 8 Inertia and React

Tue, 14 Jan 2025 00:00:00 GMT

While I have written a bunch lately about using the “Rails way” to build applications, I have been keeping an eye on InertiaJS via internet friends, especially those in the Laravel space.

InertiaJS is a way to build single-page applications (SPAs) without creating an API. Specifically, using the inertia-rails gem, you can easily make a Rails application that uses InertiaJS to add frontend libraries.

rails new blabber --main --css=bootstrap

Rails will do its thing: install the application, install the gems, and process the Bootstrap and dependencies installs.

Next, we can review the model, controller, and routing setup before proceeding to the InertiaJS and React components.

rails g model Post username body:text likes_count:integer repost_count:integer

To keep this closely resembling the formerly bird app that we are cloning, we’ll add the same validation in the Post model:

class Post < ApplicationRecord
  validates :body, length: { minimum: 1, maximum: 280 }
end

We’ll make a few small adjustments to the generated migration file to add some database-level defaults (and allows us to keep the code around Post creation simple):

class CreatePosts < ActiveRecord::Migration[6.0]
  def change
    create_table :posts do |t|
      t.string :username, default: 'Blabby'
      t.text :body
      t.integer :likes_count, default: 0
      t.integer :repost_count, default: 0

      t.timestamps
    end
  end
end

Ok! Now, we’re ready to run that migration!

rails db:migrate

Before going forward with the controller, now that you have the database and model set, we should install the inertia-rails gem as it will dictate some differences in the controller and view layer (through frontend components).:

gem 'inertia_rails'

With the gem installed, we can run the installer:

bundle install
bin/rails generate inertia:install

The installer is interactive and will ask a few questions:

Do you want to install Vite Ruby? This library is the build tool for handling the front-end assets through InertiaJS. I selected yes, and I assume if you choose no, you would already be running some other front-end build process.
Would you like to use TypeScript? I use TypeScript in my projects, so I selected yes. If you are not familiar with TypeScript, you can choose no.
What framework do you want to use with Inertia? [react, vue, svelte4, svelte] I selected React, as that is what we are using in this tutorial.
Would you like to use Tailwind CSS? I selected no, as we are using Bootstrap in this tutorial.

The installer will install all those dependencies and set up the Rails application to use InertiaJS. It will also create a demo controller and “Page” component to show you how to use InertiaJS. Those files are found at app/controllers/inertia_example_controller.rb and app/javascript/pages/InertiaExample.tsx.

With everything added, you should be able to run bin/dev and see the Rails server and Vite server running. You can visit http://localhost:3000/inertia_example to see the demo page.

With the inertiaJS install out of the way, we can move on to the controller and corresponding view templates!

class PostsController < ApplicationController

  def index
    @posts = Post.all.order(created_at: :desc)
    render inertia: 'Posts', props: {
      posts: @posts.as_json
    }
  end

  def create
    post = Post.new(post_params)

    if post.save
      redirect_to posts_path
    else
      redirect_to new_post_path, inertia: { errors: post.errors }
    end
  end

  def like
    Post.find_by(id: params[:post_id]).increment(:likes_count).save
    redirect_to posts_path
  end

  def repost
    Post.find_by(id: params[:post_id]).increment(:repost_count).save
    redirect_to posts_path
  end

  private

  def post_params
    params.expect(post: [:body])
  end

end

Simple controller. The index action returns a list of posts to @post and renders a Posts “page” in the front-end, which we will add shortly. create creates a new Post and redirects back to the Post component or the form if it fails. InertiaJS handles the routing in the front end to ensure the correct React rendering is happening. like and repost are similar, except they increment the respective count columns.

Let’s wire up a few routes to match up to those controller actions. Yes, these aren’t perfect RESTful routes, but 1) They work. 2) This is a 10-minute tutorial.

Rails.application.routes.draw do
  get 'inertia-example', to: 'inertia_example#index'
  # Define your application routes per the DSL in https://guides.rubyonrails.org/routing.html

  # Reveal health status on /up that returns 200 if the app boots with no exceptions, otherwise 500.
  # Can be used by load balancers and uptime monitors to verify that the app is live.
  get "up" => "rails/health#show", as: :rails_health_check

  # Render dynamic PWA files from app/views/pwa/* (remember to link manifest in application.html.erb)
  # get "manifest" => "rails/pwa#manifest", as: :pwa_manifest
  # get "service-worker" => "rails/pwa#service_worker", as: :pwa_service_worker

  # Defines the root path route ("/")
  resources :posts, only: %i[index create] do
    get 'like'
    get 'repost'
  end

  root "posts#index"
end

The inertia install modified the application.html.erb file to include the Inertia and Vite tags. To make sure everything is copasetic, here is the entire file:

<!DOCTYPE html>
<html>
  <head>
    <title inertia><%= content_for(:title) || "Blabber" %></title>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <meta name="apple-mobile-web-app-capable" content="yes">
    <meta name="mobile-web-app-capable" content="yes">
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>

    <%= yield :head %>

    <%# Enable PWA manifest for installable apps (make sure to enable in config/routes.rb too!) %>
    <%#= tag.link rel: "manifest", href: pwa_manifest_path(format: :json) %>

    <link rel="icon" href="/icon.png" type="image/png">
    <link rel="icon" href="/icon.svg" type="image/svg+xml">
    <link rel="apple-touch-icon" href="/icon.png">

    <%# Includes all stylesheet files in app/assets/stylesheets %>
    <%= stylesheet_link_tag :app, "data-turbo-track": "reload" %>
    <%= javascript_importmap_tags %>
    <%= stylesheet_link_tag "application", "data-turbo-track": "reload" %>
    <%= vite_react_refresh_tag %>
    <%= vite_client_tag %>
    <%= vite_typescript_tag "inertia" %>
    <%= inertia_ssr_head %>
    <%= vite_javascript_tag 'application' %>
    <!--
      If using a TypeScript entrypoint file:
        vite_typescript_tag 'application'

      If using a .jsx or .tsx entrypoint, add the extension:
        vite_javascript_tag 'application.jsx'

      Visit the guide for more information: https://vite-ruby.netlify.app/guide/rails
    -->

  </head>

  <body>
    <%= yield %>
    <%= console %>
  </body>
</html>

This covers most of the initial changes needed on the traditional Rails side, and we can now start adding the React components.

import { Head } from "@inertiajs/react";
import { PostForm } from "../components/PostForm";
import { PostList } from "../components/PostList";
import { Post } from "../types/Post";

export default function Posts({ posts }: { posts: Post[] }) {
  return (
    <>
      <Head title="Posts" />

      <div className="container">
        <h1>Blabber</h1>
        <h4>A Rails, Inertia, React demo!</h4>
        <PostForm />
        <PostList posts={posts} />
      </div>
    </>
  );
}

A great thing about using React is the composability of the components that you would typically not get with ERB templates. The Posts component is a wrapper for the PostForm and PostList components. You may also notice that we’re pulling in a Post type to the PostList component. This import is a TypeScript type that we will define in a moment. Lastly, as mentioned before, inertiaJS will handle routing and rendering of these components. Thus, they provide a Head component for the page’s title.

For quick reference, here is the Post type:

app/javascript/types/Post.ts

export interface Post {
  id: number;
  username: string;
  body: string;
  repost_count: number;
  likes_count: number;
  created_at: string;
}

The PostForm component is a simple form that will allow the user to create a new post:

app/javascript/components/PostForm.tsx

import { useForm } from "@inertiajs/react";

export const PostForm = () => {
  const { data, setData, post, processing, errors, reset } = useForm({
    body: "",
  });

  function submit(e: React.FormEvent) {
    e.preventDefault();
    post("/posts", {
      onSuccess: () => reset("body"),
    });
  }

  return (
    <form className="my-4" onSubmit={submit}>
      <div className="mb-3">
        <textarea
          className="form-control"
          rows={3}
          value={data.body}
          placeholder="Enter Your Blab"
          onChange={(e) => setData("body", e.target.value)}
        />
        {errors.body && <div>{errors.body}</div>}
      </div>
      <div className="mb-3">
        <button type="submit" className="btn btn-primary" disabled={processing}>
          Blab
        </button>
      </div>
    </form>
  );
};

InertiaJS does a lot of the heavy lifting for you, including form handling. The useForm hook is a custom hook that InertiaJS provides to handle form data, submission, and errors. The submit function is a simple function that will post the form data to the create action in the PostsController. The form is a straightforward Bootstrap form with a textarea and a submit button.

The PostList component is a simple list of posts:

app/javascript/components/PostList.tsx

import { useEffect, useState } from "react";

import { Post } from "../types/Post";

import { PostItem } from "../components/PostItem";

export const PostList = ({ posts }: { posts: Post[] }) => {

  return (
    <>
      {posts.map((post: Post) => (
        <PostItem key={post.id} post={post} />
      ))}
    </>
  );
};

The PostList is relatively small component as it maps over the posts prop and renders a PostItem component for each post.

Next up is the aforementioned PostItem component:

app/javascript/components/PostItem.tsx

import { Post } from "../types/Post";
import { Link } from "@inertiajs/react";

export const PostItem = ({ post }: { post: Post }) => {
  return (
    <div className="card mb-2" id={`post_${post.id}`}>
      <div className="card-body">
        <h5 className="card-title text-muted">
          <small className="float-right">Posted at {post.created_at}</small>
          {post.username}
        </h5>
        <div className="card-text lead mb-2">{post.body}</div>
        <Link href={`/posts/${post.id}/repost`} className="card-link">
          Repost ({post.repost_count})
        </Link>
        <Link href={`/posts/${post.id}/like`} className="card-link">
          Like ({post.likes_count})
        </Link>
      </div>
    </div>
  );
};

The PostItem component is a simple Bootstrap card that displays the post’s username, body, and creation date. It also includes two links to repost and like the post. The links are InertiaJS Link components that will handle the routing and rendering of the repost and like actions.

Alright! That is all the React components we need to build the clone. If you head to your Rails app, you should be able to see the posts form and a list of posts. You can create a new post, which will appear in the list. Plus, you can like and repost posts.

However, if you have followed along with any of the other clone tutorials, you know that we are missing one key feature: real-time updates. In this tutorial, we will use ActionCable to add real-time updates and a npm package called use-action-cable to handle the front-end subscription.

First, we can add the ActionCable side to get the backend ready for the front-end subscription. We’ll start by adding a new channel to handle the posts (which will, in turn, add a few new default files as well):

bin/rails g channel PostsChannel

Next, we’ll add the subscribed method to the PostsChannel class to stream from the PostsChannel:

app/channels/posts_channel.rb

class PostsChannel < ApplicationCable::Channel
  def subscribed
    stream_from "PostsChannel"
  end

  def unsubscribed
    # Any cleanup needed when channel is unsubscribed
  end
end

Also, we’ll edit the Connection file to identify the Cable connection with the browser session ID:

module ApplicationCable
  class Connection < ActionCable::Connection::Base
    identified_by :session_id

    def connect
      self.session_id = request.session.id
    end
  end
end

Lastly, for the backend, we’ll add a broadcast to the Post model to broadcast the post to the PostsChannel:

app/models/post.rb

class Post < ApplicationRecord
  validates :body, length: { minimum: 1, maximum: 280 }

  after_commit :broadcast, on: [:create, :update, :destroy]

  def broadcast
    ActionCable.server.broadcast('PostsChannel', {
      posts: Post.all.order(created_at: :desc).as_json
    })
  end
end

This change will broadcast the posts to the PostsChannel after they are created, updated, or destroyed. Yes, this is ultra simplistic by returning all of the posts, but it will work for this tutorial. You would want to scope this down in a production application.

Alright, that’s it for the ActionCable backend! Next up is the React side of the application.

We will use a more current fork of the original use-action-cable package. This package will allow us to subscribe to the PostsChannel and handle the incoming posts.

yarn add react-use-action-cable-ts

This package utilizes a few custom hooks to add a connection to an ActionCable channel easily. We’ll use the useActionCable and useChannel hooks to subscribe to the PostsChannel and handle the incoming posts.

app/javascript/pages/Posts

import { useEffect, useState } from "react";

import { Post } from "../types/Post";

import { useActionCable, useChannel } from "react-use-action-cable-ts";
import { PostItem } from "../components/PostItem";

export const PostList = ({ posts }: { posts: Post[] }) => {
  const [postData, setPostData] = useState<Post[]>(posts);
  const { actionCable } = useActionCable("ws://127.0.0.1:3000/cable");
  const { subscribe, unsubscribe } = useChannel(actionCable, {
    receiveCamelCase: false,
    verbose: false,
    sendSnakeCase: false,
  });

  useEffect(() => {
    subscribe(
      {
        channel: "PostsChannel",
      },
      {
        received: (data: unknown) => {
          const cableData = data as { posts: Post[] };
          setPostData(cableData.posts);
        },
      }
    );
    return () => {
      unsubscribe();
    };
  }, []);
  return (
    <>
      {postData.map((post: Post) => (
        <PostItem key={post.id} post={post} />
      ))}
    </>
  );
};

The changes here will start with adding useState and useEffect to the PostList component. These hooks will allow us to set the incoming posts from the PostsChannel broadcast. We’ll also add the useActionCable and useChannel hooks to handle connecting to the PostsChannel. We will connect to "ws://127.0.0.1:3000/cable" to access the local ActionCable server output. Still, you should utilize another method of getting the current host if you put this code in Production. The hook returns an actionCable object that we can use to subscribe to the PostsChannel.

The useChannel hook will use that actionCable object to set up a function to subscribe to the PostsChannel and set a few settings for the channel. Specifically, the receiveCamelCase and sendSnakeCase settings are set to false to match the Rails backend. The verbose setting is set to false to reduce the console output.

The useEffect React hook will take the subscribe function from the useChannel hook and subscribe to the PostsChannel. The subscribe function takes two arguments: the channel name and an object with a received function that will handle the incoming data. The received function will set the incoming posts to the postData state. The useEffect hook will also return an unsubscribe function that will unsubscribe from the PostsChannel when the component is unmounted.

With all these changes, you should have a fully functioning clone that uses InertiaJS and React for the front end and ActionCable for real-time updates. You can create, like, and repost posts, which will be updated in real-time across all clients.

You can head back to https://localhost:3000 and see the posts in real-time now!

There you go! I bet that with a fast enough system to work through the Rails, gem, and Javascript package installs, you could complete this tutorial in less than 10 minutes!

Adding Sign Up to the Rails 8 Authentication Generator

Thu, 03 Oct 2024 00:00:00 GMT

This article spurned from writing about the new Rails 8 Authentication Generator in my Build A SaaS App in Ruby on Rails 8 book, and I wanted to share this small tip from the chapter on Users and Authentication.

Within the book, I set up a Rails 8 application with authentication using the bin/rails generate authentication command. This command creates a User model, a Sessions controller, and a few views to get you started. However, it does not include a Sign-up process at all.

In this quick article, we will add a Sign-Up form to the application.

Prerequisites

Before we start, ensure you have the Rails 8 application set up with the authentication generator.

rails new myapp --main
cd myapp
bin/rails generate authentication
bin/rails db:migrate

To add a Sign-Up form, we will need to add a few things:

A route to the Sign Up form
A controller action to render the Sign-Up form
A view to display the Sign Up form
A controller action to handle the form submission

Route

In the config/routes.rb file, add a route to the Sign Up form in addition to the routes created by the authentication generator:

config/routes.rb

Rails.application.routes.draw do
  resource :session
  resource :registration, only: %i[new create]
  resources :passwords, param: :token
end

Controller

Create a new controller called RegistrationsController:

app/controllers/registrations_controller.rb

class RegistrationsController < ApplicationController
  allow_unauthenticated_access

  def new
    @user = User.new
  end

  def create
    @user = User.new(user_params)
    if @user.save
      start_new_session_for @user
      redirect_to root_path, notice: 'Successfully signed up!'
    else
      render :new
    end
  end

  private

  def user_params
    params.require(:user).permit(:email_address, :password, :password_confirmation)
  end
end

It’s pretty standard stuff here. First, allow_unauthenticated_access is a method that allows unauthenticated access to the new and create actions. Otherwise, we could use this controller with a valid session. The only other thing that is not standard Rails controller CRUD is the start_new_session_for @user, which allows the app to be signed in (add session record, secure cookie, etc.) after the user is created.

View

Create a new view file called new.html.erb in the app/views/registrations directory (view assumes Tailwind was added and has some classes):

app/views/registrations/new.html.erb

<div class="mx-auto md:w-2/3 w-full">
  <% if alert = flash[:alert] %>
    <p class="py-2 px-3 bg-red-50 mb-5 text-red-500 font-medium rounded-lg inline-block" id="alert"><%= alert %></p>
  <% end %>

  <% if notice = flash[:notice] %>
    <p class="py-2 px-3 bg-green-50 mb-5 text-green-500 font-medium rounded-lg inline-block" id="notice"><%= notice %></p>
  <% end %>

  <h1 class="font-bold text-4xl">Sign up</h1>

  <%= form_with model: @user, url: registration_url, class: "contents" do |form| %>
    <div class="my-5">
      <%= form.email_field :email_address, required: true, autofocus: true, autocomplete: "username", placeholder: "Enter your email address", value: params[:email_address], class: "block shadow rounded-md border border-gray-400 outline-none px-3 py-2 mt-2 w-full" %>
    </div>

    <div class="my-5">
      <%= form.password_field :password, required: true, autocomplete: "current-password", placeholder: "Enter your password", maxlength: 72, class: "block shadow rounded-md border border-gray-400 outline-none px-3 py-2 mt-2 w-full" %>
    </div>

    <div class="my-5">
      <%= form.password_field :password_confirmation, required: true, autocomplete: "current-password", placeholder: "Confirm your password", maxlength: 72, class: "block shadow rounded-md border border-gray-400 outline-none px-3 py-2 mt-2 w-full" %>
    </div>

    <div class="col-span-6 sm:flex sm:items-center sm:gap-4">
      <div class="inline">
        <%= form.submit "Sign up", class: "rounded-lg py-3 px-5 bg-blue-600 text-white inline-block font-medium cursor-pointer" %>
      </div>

      <div class="mt-4 text-sm text-gray-500 sm:mt-0">
        <%= link_to "Forgot password?", new_password_path, class: "text-gray-700 underline" %>
      </div>
    </div>
  <% end %>
</div>

Form Submission

If you were to try to submit the form now, it would work, but redirect to the registration form as there is no root path or authenticated path to test this all out on. Let’s create a quick controller and route to handle this:

app/controllers/home_controller.rb

class HomeController < ApplicationController
  def index
    render plain: "Welcome to the app!"
  end
end

config/routes.rb

Rails.application.routes.draw do
  get 'home/index'
  root to: 'home#index'
  resource :session
  resource :registration, only: %i[new create]
  resources :passwords, param: :token
end

If you visit the root path of your application, you should see the Sign-Up form. You can fill it out and submit it to create a new user. Upon successful creation, you should be redirected to the root path with the message “Welcome to the app!”

Bonus Idea

Usually, when building an app, there is a different layout when you are logged in than when you are on one of the “authentication adjacent” pages. You can add a method to the ApplicationController to determine if the user is authenticated or not:

app/controllers/application_controller.rb

class ApplicationController < ActionController::Base
  before_action :set_layout

  def set_layout
    @layout = user_signed_in? ? 'application' : 'authentication'
  end
end

Then, in your app/views/layouts directory, create two layout files: application.html.erb and authentication.html.erb. In the application.html.erb file, you can add a navigation bar, footer, etc. You can add a different navigation bar, footer, etc., in the authentication.html.erb file.

Leveraging Turbo 8: Best Additions to Implement in Rails 8 Projects

Thu, 26 Sep 2024 00:00:00 GMT

This article will explore Turbo 8’s powerful features and a little bit of code. I swear, you will be surprised by how little extra code is needed to implement all of this!

We will be starting over but using many of the same concepts from the previous article. Let’s get into it!

Setup

First, we can create a new Rails app from the main branch to get all of the Rails 8 goodies (though, soon, this will be available through alpha/beta gem releases).

rails new --main blabber

Now, as we will be adding a few features related to user interactions, we will need to create users and a way to log them in. Short of using the new Rails 8 authentication generators, we can add two quick models, a small number of controller methods, and a few view templates.

First, the models via Rails generators:

rails g model user email:string password_digest:string
rails g model post user:references message:text

These generators will create two models and migrations for the Users and Posts. Let’s add a few lines to the User model for validation and authentication:

class User < ApplicationRecord
  validates :email, presence: true, uniqueness: true
  has_secure_password

end

The significant addition here is the has_secure_password line which includes code to set and authenticate passwords via bcrypt. Now, on the Post model, the user reference should exist, and we can add a quick validation:

class Post < ApplicationRecord
  belongs_to :user

  validates :message, length: { minimum: 1, maximum: 280 }
end

Finally, here is a quick bin/rails db:migrate to get those tables created.

Now, we can move on to the controller and views for logging in. We want to make this simple, just for this tutorial, so we’ll handle logging in and logging out, their responsive routes, and some basic views.

First, the routes:

Rails.application.routes.draw do
  get "/login", to: "sessions#new", as: "login"
  post "/sessions", to: "sessions#create"
  get "/logout", to: "sessions#destroy", as: "logout"

  resources :posts, only: %i[index create]

  root "posts#index"
end

These will be all the routes we need for the whole app: the first three for sessions, a resource helper for posts, and setting the root route.

Now we can add the SessionsController at app/controllers/sessions_controller.rb:

class SessionsController < ApplicationController

  def create
    @user = User.find_by(email: params.dig(:user, :email))
    if @user && @user.authenticate(params.dig(:user, :password))
      sign_in(@user)
      redirect_to root_path, notice: "You have successfully logged in!"
    else
      flash.now[:alert] = "There was a problem logging in."
      render :new, status: 422
    end
  end

  def destroy
    sign_out
    redirect_to login_path, notice: "You have successfully logged out!"
  end

  private

  def sign_in(user)
    session[:user_id] = user.id
  end

  def sign_out
    session.delete(:user_id)
  end
end

Pretty simple here. If we find a user and that user authenticates with the included authenticate method from the User model, we will call sign_in, which sets a session for the user. Real quick, we can add a helper method in ApplicationController to use current_user throughout controllers and views through the app:

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

Next, we can quickly add a PostsController that resembles much of what we used in the last tutorial, aside from now having a user_id:

class PostsController < ApplicationController
  before_action :require_login

  def index
    @posts = Post.all.order(created_at: :desc)
    @post = Post.new
  end

  def create
    @post = Post.new(post_params.merge(user_id: current_user.id))
    respond_to do |format|
      if @post.save
        redirect_to posts_path
      else
        render :index
      end
    end
  end

  private

  def post_params
    params.require(:post).permit(:message)
  end
end

Both the index and create actions are reasonably straightforward Rails-like methods for listing and creating Posts. The last part of the authentication puzzle here would be to add the before_action:require_login method to the ApplicationController and use the Rails Console to create two users (thus, we skipped building a signup interface).

app/controllers/application_controller.rb


## redirect to login, if there is no current_user, meaning there is no authenticated user session
def require_login
  redirect_to login_path, alert: 'You must be logged in to access this page.' if current_user.nil?
end

Lastly, we can go ahead and knock out a few views to get all of the authentication, Bootstrap, and basic Post markup out of the way

app/views/layouts/application.html.erb

<!DOCTYPE html>
<html>
  <head>
    <title><%= content_for(:title) || "Blabber" %></title>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <meta name="apple-mobile-web-app-capable" content="yes">
    <meta name="mobile-web-app-capable" content="yes">
    <% if current_user %>
      <meta name="current-user-id" content="<%= current_user.id %>">
    <% end %>
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>
    <%= turbo_refreshes_with method: :morph, scroll: :preserve %>
    <%= yield :head %>

    <%# Enable PWA manifest for installable apps (make sure to enable in config/routes.rb too!) %>
    <%#= tag.link rel: "manifest", href: pwa_manifest_path(format: :json) %>

    <link rel="icon" href="/icon.png" type="image/png">
    <link rel="icon" href="/icon.svg" type="image/svg+xml">
    <link rel="apple-touch-icon" href="/icon.png">

    <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/css/bootstrap.min.css" rel="stylesheet" type="text/css" />
    <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/js/bootstrap.bundle.min.js"></script>

    <%# Includes all stylesheet files in app/views/stylesheets %>
    <%= stylesheet_link_tag :app, "data-turbo-track": "reload" %>
    <%= javascript_importmap_tags %>
  </head>

  <body class="">
    <nav class="navbar navbar-expand-lg navbar-light bg-light">
         <div class="container-fluid">
           <a class="navbar-brand" href="/">Blabber</a>
           <span class="navbar-text">
             <% if current_user %>
               <%= current_user.email %>
               <%= link_to "Logout", logout_path, method: :delete, class: "btn btn-outline-danger" %>
             <% else %>
               <%= link_to "Login", login_path, class: "btn btn-outline-primary" %>
             <% end %>
            </span>
          </div>
      </nav>

    <% if flash[:notice] %>
      <div class="alert alert-success" role="alert">
        <%= flash[:notice] %>
      </div>
    <% end %>
    <% if flash[:alert] %>
      <div class="alert alert-danger" role="alert">
        <%= flash[:alert] %>
      </div>
    <% end %>
    <div class="container mt-5">
      <%= yield %>
    </div>

  </body>
</html>

A few code blocks to note:

<% if current_user %>
  <meta name="current-user-id" content="<%= current_user.id %>">
<% end %>

…will add the user ID to the front end for use in StimulusJS later.

<%= turbo_refreshes_with method: :morph, scroll: :preserve %>

…will allow Turbo 8 to morph the incoming DOM changes sent by Turbo.

Finally, Bootstrap is added over CDN for the simplicity of this tutorial, as well as a simple navbar and alerts.

Ok, three Post templates, and we’re done with setup.

To display the list of posts, you can create an index.html.erb file in the app/views/posts directory. Here’s an example of how the index view could look like:

<div class="container">
  <h1>Blabber</h1>
  <h4>A Rails, Hotwire demo</h4>

  <%= render partial: 'form' %>

  <%= render @posts %>
</div>

This code uses the _post.html.erb partial to render each post in the @posts collection.

<div class="card mb-2" id="<%= dom_id(post) %>">
  <div class="card-body">
    <h5 class="card-title text-muted">
      <small class="float-right">
        Posted <%= time_ago_in_words(post.created_at) %> ago
      </small>
      <%= post.user.email %>
    </h5>
    <div class="card-text lead mb-2"><%= post.message %></div>
  </div>
</div>

…and then the _form.html.erb

<%= form_with model: @post, id: dom_id(@post), html: {class: 'my-4' } do |f| %>
  <% if @post.errors.any? %>
    <div id="error_explanation">
      <h2>
        <%= pluralize(@post.errors.count, "error") %> prohibited this post from
        being saved:
      </h2>

      <ul>
        <% @post.errors.full_messages.each do |msg| %>
        <li><%= msg %></li>
        <% end %>
      </ul>
    </div>
  <% end %>
  <div class="form-group" data-controller="typing">
    <%= f.text_area :message, placeholder: 'Enter your blab', class: 'form-control',rows: 3 %>
  </div>

  <div class="actions my-2">
    <%= f.submit class: "btn btn-primary" %>
  </div>
<% end %>

This code uses the form_with helper to create a form for the @post object. The text_area helper creates a textarea input for the post’s message attribute.

Ok! That’s enough setup code!

Turbo Morph

If you followed along with the previous tutorial, there are only a couple of lines to add to get morphed updates out of the box! Earlier, we pre-empted the code to add with the line to the partial. To finish this off, we will add a line to the Post model and two through the Post views.

First, the line to the model:

class Post < ApplicationRecord
  belongs_to :user

  broadcasts_refreshes ## New line

  validates :message, length: { minimum: 1, maximum: 280 }
end

app/views/posts/index.html.erb

<div class="container">
  <h1>Blabber</h1>
  <h4>A Rails, Hotwire demo</h4>

  <%= render partial: 'form' %>


  <%= turbo_stream_from 'posts' %> <!-- This is that streams from the post collection -->
  <%= render @posts %>
</div>

app/views/posts/_post.html.erb

<%= turbo_stream_from post %> <!-- This is that streams from each post -->
<div class="card mb-2" id="<%= dom_id(post) %>">
  <div class="card-body">
    <h5 class="card-title text-muted">
      <small class="float-right">
        Posted <%= time_ago_in_words(post.created_at) %> ago
      </small>
      <%= post.user.email %>
    </h5>
    <div class="card-text lead mb-2"><%= post.message %></div>
  </div>
</div>

That’s it! If you create two users in the console, log on in, and then log another in on an incognito tab, you will see each page get updated with new posts from each user!

Presence Channel

Presence channels are a great way to show who is online in your application.

In our case, we will use an indicator next to the users’ email addresses in the Post card. This indicator will be a simple green dot if the user is online and a red dot if the user is offline.

The first step here will be to include icons to use a circle and then color it based on the user’s presence. We can easily include Bootstrap icons by adding the following line to the application.css file:

@import url("https://cdn.jsdelivr.net/npm/bootstrap-icons@1.11.3/font/bootstrap-icons.min.css");

Now, we can generate a quick migration to add an online boolean to the User model:

rails g migration add_online_to_users online:boolean
rails db:migrate

Next, we can add two simple methods to the User to adjust a user’s presence status using the online boolean. We will also add a method to broadcast changes to the presence channel after a user’s status changes and check for the online_previously_changed? (a built-in ActiveRecord field status method) in that method used by the callback:

app/models/user.rb

class User < ApplicationRecord
  validates :email, presence: true, uniqueness: true
  has_secure_password

  after_commit :broadcast_changes

  def broadcast_changes
    if online_previously_changed?
      Turbo::StreamsChannel.broadcast_refresh_to(:presence)
    end
  end

  def came_online
    update!(online: true) unless online?
  end

  def went_offline
    update!(online: false) if online?
  end
end

Finally, we can add a line to the application.html.erb to listen for changes to the presence channel and then update the _post partial to include the presence indicator:

app/views/layouts/application.html.erb

...
 <%= turbo_stream_from :presence, channel: PresenceChannel if current_user %>
...

The turbo_stream_from:presence will use the turbo_stream helpers from the turbo-rails gem to handle the automatic subscription to the presence channel. The PresenceChannel argument in this method sets which Channel will be specifically used in the streaming process.

app/views/posts/_post.html.erb

<%= turbo_stream_from post %>
<div class="card mb-2" id="<%= dom_id(post) %>">
  <div class="card-body">
    <h5 class="card-title text-muted">
      <small class="float-right">
        Posted <%= time_ago_in_words(post.created_at) %> ago
      </small>
      <i class="bi bi-circle-fill align-middle text <%= post.user.online? ? 'text-success' : 'text-danger'%>" style="font-size: .5rem"></i>
      <%= post.user.email %>
    </h5>
    <div class="card-text lead mb-2"><%= post.message %></div>
  </div>
</div>

This uses the bi-circle-fill icon from Bootstrap and changes its color based on the user’s presence status.

Lastly, we can create the PresenceChannel in the app/channels directory:

app/channels/presence_channel.rb

class PresenceChannel < ActionCable::Channel::Base
      extend Turbo::Streams::Broadcasts, Turbo::Streams::StreamName
      include Turbo::Streams::StreamName::ClassMethods

  def subscribed
    stream_from "presence"
    current_user.came_online
  end

  def unsubscribed
    current_user.went_offline
  end
end

This channel extends and includes some Turbo::Streams modules, so that it can broadcast to the presence channel and handle the stream name. The subscribed method will stream from the presence channel and then call the came_online method on the current user. The unsubscribed method will call the went_offline method on the current user. unsubscribe is a method that is called when the client disconnects from the channel by closing the window or logging out.

Now, if you tried to use the browser, you would see errors from your channel in the logs, as we have to set up one last piece, the current_user in the Connection class. This class is much like an ApplicationController but for the ActionCable connections. We can add a method to the Connection class to set the current_user:

app/channels/application_cable/connection.rb

module ApplicationCable
  class Connection < ActionCable::Connection::Base
    identified_by :current_user

    def connect
      self.current_user = find_verified_user
    end

    private
      def find_verified_user
        if current_user = User.find_by(id: @request.session[:user_id])
          current_user
        else
          reject_unauthorized_connection
        end
      end
  end
end

This module will set the current_user to the user found by the session[:user_id], which was set during the login, or reject the connection if the user is not found.

If you were to open two browsers (your current browser window and an incognito would work!) now and log into each user, you would see the presence indicator change in real time!

Typing Indicators

The last feature we’ll build here is a typing indicator, which will show when a user is typing a message, much like you see in Slack. Of course, as this is just a simple app to demonstrate the capability, the typing indicator will be shown to all users but not the user typing.

First, we can generate a channel to handle the typing events and pin a debounce library to handle the typing events in a javascript controller a few files later:

bin/rails generate channel typing
bin/importmap pin lodash.debounce

Inside the TypingChannel, we can add a few methods to handle the typing and typing stopped events from the “Cable” side:

app/channels/typing_channel.rb

class TypingChannel < ApplicationCable::Channel
  def subscribed
    stream_from "typing"
  end

  def typing
    ActionCable.server.broadcast("typing", { action: 'typing', uid: current_user.id.to_s, user_email: current_user.email } )
  end

  def typing_stopped
    ActionCable.server.broadcast("typing", { action: 'typing_stopped', uid: current_user.id.to_s, user_email: current_user.email } )
  end

  def unsubscribed
    # Any cleanup needed when channel is unsubscribed
  end
end

This channel will stream from the typing channel and then broadcast the typing and typing_stopped events to the channel. The typing event will include the current user’s uid and user_email. This information is needed to do two things. One, the user_id will be used to filter out the currently typing user from seeing the typing indicator. Second, the email address is used to display the message so as not to send the data to the front end differently. The unsubscribed method was added to the channel by default during the generation of the channel but can be removed as it is not needed.

With that out of the way, the next place to add some code is the markup by adjusting and adding some StimulusJS to the Posts form:

app/views/posts/_form.html.erb

<%= form_with model: @post, id: dom_id(@post), html: {class: 'my-4' } do |f| %>
  <% if @post.errors.any? %>
    <div id="error_explanation">
      <h2>
        <%= pluralize(@post.errors.count, "error") %> prohibited this post from
        being saved:
      </h2>

      <ul>
        <% @post.errors.full_messages.each do |msg| %>
          <li><%= msg %></li>
        <% end %>
      </ul>
    </div>
  <% end %>
  <div class="form-group">
  <div class="form-group" data-controller="typing">
    <%= f.text_area :message, placeholder: 'Enter your blab', class: 'form-control', rows: 3 %>
    <%= f.text_area :message, placeholder: 'Enter your blab', class: 'form-control', data: { turbo_permanent: true, action: 'keydown->typing#typing keyup->typing#typingStopped' }, rows: 3 %>
    <div id="typingHint" class="form-text" data-typing-target="display"></div>
  </div>

  <div class="actions my-2">
    <%= f.submit class: "btn btn-primary" %>
  </div>
<% end %>

We replace two lines, adding StimulusJS markup of <div class="form-group" and action: 'keydown->typing#typing keyup->typing#typingStopped' for the StimulusJS controller to listen for keydown and keyup events. We add turbo_permanent: true so that the turbo morph updates will not clear out the form’s current state (i.e., text that has been typed or bound javascript that StimulusJS is handling). Finally, the data-typing-target="display" will be used to update the message in the view when someone is typing.

Finally, we can add the StimulusJS controller to the app/javascript/controllers directory:

app/javascript/controllers/typing_controller.js

import { Controller } from "@hotwired/stimulus";
import consumer from "channels/consumer";
import debounce from "lodash.debounce";

export default class extends Controller {
  static targets = ["display"];

  initialize() {
    this.typingStopped = debounce(this.typingStopped, 1000);
  }

  connect() {
    this.subscription = consumer.subscriptions.create("TypingChannel", {
      received: (data) => {
        if (data.uid != this.userId) {
          this.displayTarget.innerHTML =
            data.action == "typing" ? `${data.user_email} is typing...` : "";
        }
      },
    });
  }

  typing(_event) {
    this.subscription.perform("typing");
  }

  typingStopped(_event) {
    this.subscription.perform("typing_stopped");
  }

  get userId() {
    return document.head.querySelector("meta[name=current-user-id]")?.content;
  }
}

This controller has many moving parts; we’ll go through them by behavior.

First, we create a getter for the userId, which will get the current-user-id from the meta tag in the head of the document, which was added way earlier when we first modified the application.html.erb. This will be used later in the event filtering process.

Then, in the connect method, we create a subscription to the TypingChannel and then listen for the received event. The received happens when the broadcast is sent from the TypingChannel. We’ll come back to the if statement in a moment.

In the view, we used keydown->typing#typing to call the typing function when that event happens in the browser. The typing function then calls the perform method on the subscription to send the typing event to the TypingChannel. This event triggers the typing method in the TypingChannel to broadcast the typing event to the typing channel, which is handled by the received handler.

Additionally, we used keyup->typing#typingStopped in the view to call the typingStopped function. Here, we debounce the typingStopped function to only call it once every 1000 milliseconds or one second. This function will prevent the typingStopped method from being called too frequently and basically allow the controller to wait for the typing to be stopped. Using a debounce function is a common pattern in JavaScript to prevent a function from being called too frequently. We are using debounce from the lodash library to do this and was added in the import statement at the top of the file. The trick to getting the StimulusJS-based keydown event to use the lodash debounce is to set the controller’s typingStopped function in the initializer to itself inside the debounce function call.

The typingStopped function then calls the perform method on the subscription to broadcast the typing_stopped event to the TypingChannel much like the same round trip for typing.

To get the controller ready to display text, we added data-typing-target="display" in the view to display the typing indicator and then added a static targets = ["display"]; to allow this controller to interact with that element.

Now, finally getting back to the code inside the received handler, we check if the uid in the data object does not equal the userId from the meta tag. If the uid is not equal to the userId, then we update the displayTarget with the user’s email and a message that they are typing. Inside the innerHTML setter, we use a ternary operator to check if the action in the data object equals typing. If it is, we set the innerHTML to the user’s email and a message they are typing. If the action is not equal to typing, then we set the innerHTML to an empty string which clears the message in the browser.

Now, suppose you were to open two browsers (again, a current browser and an incognito would work!) and log into each user. In that case, you would see the typing indicator change in real time as one user types; the other would see the indicator on their browser!

Conclusion

Anyway, closing out these tutorials always feel weird. Hope you learned something from this and leave a comment with any questions or feedback!

Rails Console in the Browser (on-demand)

Tue, 24 Sep 2024 00:00:00 GMT

Why in the browser?

While doing some research and working on some details for my new book Realtime Rails, I came across an issue where making changes to ActiveRecord objects in the terminal’s rails console were not showing up in the web browser. When working in development, based on default settings for ActionCable and the Rails server, for the broadcast to show up, it needs to be using the same process instead of the separate process spaned by the rails console in the terminal.

Also, having the console show up in the browser on demand is a pretty cool setup. You can see the changes in real time and interact with the objects in the browser.

How to set it up

If you need to set up the Rails console in the browser yourself instead, you will need to add the web-console gem to your Gemfile:

gem 'web-console', group: :development

Then, run bundle install to install the gem.

Once installed, you can add a web console to any view file by adding <%= console %>, then interact with the Rails console in the browser.

Taking it a step further

If you want to add some convenience to this process, you can add route, controller, and view (that are development only) to have the browser show up in the browser on a specific page in your application.

First, adding the development-only route:

if Rails.env.development?
  get '/console', to: 'console#show'
end

Then, create the controller:

class ConsoleController < ApplicationController
  def show
  end
end

And finally, the view:

<h1>Rails Console</h1>
<%= console %>

Now, when you visit /console in your development environment, you will have a console in the browser.

Alternate Idea

Another idea is to add a link to the console in your application’s footer. This way, you can easily access the console from any page in your application.

Then, add the link to the console in your application.html.erb layout file, but since we’re not relying on the route to show the console in the development environment only, we will need to add a conditional check in the template:

<% if Rails.env.development? %>
  <%= console %>
<% end %>

Personally, I’d rather have the console appear on a specific page, but this is a good alternative if you want the console available on every page in your application.

How to Build a Twitter Clone with Rails 8 and Turbo 8

Mon, 16 Sep 2024 00:00:00 GMT

Hotwire, StimulusJS, and Turbo have been out for the better part of half a decade, and there have been sweeping changes in the Turbo Broadcast and Stream patterns this past year. All of this gets bundled with Rails 8, plus other new features to make development even quicker, such as SolidQueue, SolidCache, and SolidCable. Two of those three make it dead simple to get this clone up and running super quick!

Without further ado, let’s get started with a new app:

rails new blabber --main --css=bootstrap

Rails will do its thing:

Install the application.
Install the gems.
Process the Bootstrap installation.
Install the yarn packages.

Hotwire and Turbo are now part of Rails, so installing anything extra is unnecessary! Just fire up bin/dev and start writing some code.

Now, let’s make a model to hold the data to clone a tweet in this Twitter clone called Blabber. All basic attributes:

rails g model Post username body:text likes_count:integer repost_count:integer

To keep this closely resembling the previous article, we’ll add the same validation in the Post model:

app/models/post.rb

class Post < ApplicationRecord
  broadcasts_refreshes

  validates :body, length: { minimum: 1, maximum: 280 }
end

One difference you see is the broadcasts_refreshes line. This line is part of Turbo 8, where the backend changes (here, changes to the model) are broadcast as a refresh event in Turbo, to be picked up by the turbo.js front end. Hidden behind the scenes is all the work Rails does to connect browsers, expecting that particular model instance to have updates and all the connecting parts such as ActiveJob, ActionCable, SolidQueue, and SolidCable.

We’ll make the same few minor adjustments to the generated migration file to add some database-level defaults (and allow us to keep the code around Post creation simple):

class CreatePosts < ActiveRecord::Migration[6.0]
  def change
    create_table :posts do |t|
    t.string :username, default: 'Blabby'
    t.text :body
    t.integer :likes_count, default: 0
    t.integer :repost_count, default: 0

    t.timestamps
    end
  end
end

Ok! Now, we’re ready to run that migration!

rails db:migrate

Another change with this process of refreshes and streams is that our controller can now be unaware of the streams and does not need to have format-based responses or template files that closely resemble the same partials used for the non-dynamic part of the app.

class PostsController < ApplicationController

  def index
    @posts = Post.all.order(created_at: :desc)
    @post = Post.new
  end

  def create
    @post = Post.new(post_params)
    respond_to do |format|
      if @post.save
        redirect_to posts_path
      else
        render :index
      end
    end
  end

  def like
    Post.find_by(id: params[:post_id]).increment(:likes_count).save
    redirect_to posts_path
  end

  def repost
    Post.find_by(id: params[:post_id]).increment(:repost_count).save
    redirect_to posts_path
  end

  private

  def post_params
    params.require(:post).permit(:body)
  end
end

Simple controller. The index action returns a list of posts to @post. create uses StrongParameters, creates a new Post, and redirects back to the index template. like and repost are similar, except they increment the respective count columns.

Let’s wire up a few routes to match up to those controller actions. Yes, these aren’t perfect RESTful routes, but 1) They work. 2) This is a 10-minute tutorial. 3) POST requests did not get the other browser window to update with the changes in my small app here. (If anyone knows why, I’d be happy to hear!)

Rails.application.routes.draw do
  resources :posts, only: %i[index create] do
    get 'like'
    get 'repost'
  end

  root to: 'posts#index'
end

With a Model, Controller, and routes, we can put together some view templates. We can now add the “magic sauce” to the application layout to listen for refresh broadcasts.

<!DOCTYPE html>
<html>
  <head>
    <title><%= content_for(:title) || "Blabber" %></title>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <meta name="apple-mobile-web-app-capable" content="yes" />
    <meta name="mobile-web-app-capable" content="yes" />
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>
    <%= turbo_refreshes_with method: :morph, scroll: :preserve %>
    <%= yield :head %>
    <%# Enable PWA manifest for installable apps (make sure to enable in config/routes.rb too!) %>
    <%#= tag.link rel: "manifest", href: pwa_manifest_path %>

    <link rel="icon" href="/icon.png" type="image/png" />
    <link rel="icon" href="/icon.svg" type="image/svg+xml" />
    <link rel="apple-touch-icon" href="/icon.png" />

    <%# Includes all stylesheet files in app/views/stylesheets %>
    <%= stylesheet_link_tag :app, "data-turbo-track": "reload" %>
    <%= javascript_importmap_tags %>
    <%= stylesheet_link_tag "application", "data-turbo-track": "reload" %>
  </head>

  <body>
    <%= yield %>
  </body>
</html>

The yield :head by the rails new command, and just above it, we added <%= turbo_refreshes_with method: :morph, scroll: :preserve %> to tell the application to listen for refreshes.

The first view template up is the app/views/posts/index.html.erb:

<div class="container">
  <h1>Blabber</h1>
  <h4>A Rails, Hotwire demo</h4>

  <%= render partial: 'form' %>
  <%= turbo_stream_from 'posts' %>
  <%= render @posts %>
</div>

The view is a relatively simple Rails template. It uses a render @posts method to render the collection of @posts using a posts/_post partial. The turbo_stream_from:posts hooks up the view layer to listen to the Post model’s broadcasts.

The partial is some pretty standard singular object markup with some Bootstrap classes thrown in to make it look half-decent:

app/views/posts/_posts.html.erb

<%= turbo_stream_from post %>
<div class="card mb-2" id="<%= dom_id(post) %>">
  <div class="card-body">
    <h5 class="card-title text-muted">
      <small class="float-right"> Posted at <%= post.created_at %> </small>
      <%= post.username %>
    </h5>
    <div class="card-text lead mb-2"><%= post.body %></div>
    <%= link_to post_repost_path(post), { class: 'card-link', data: { turbo_prefetch: false }} do %>
      Repost (<%= post.repost_count %>)
    <% end %>
    <%= link_to post_like_path(post), { class: 'card-link', data: { turbo_prefetch: false }} do %>
      Likes (<%= post.likes_count %>)
    <% end %>
  </div>
</div>

Another turbo_stream command is used to listen for broadcasted updates and deletions, and the dom_id helper is used to create conventional Rails View IDs model_resource-id. In this case, it would look like posts_1, etc.

Up next is a straightforward Rails form:

<%= form_with model: @post, id: dom_id(@post), html: {class: 'my-4' } do |f| %>
  <% if @post.errors.any? %>
    <div id="error_explanation">
      <h2>
        <%= pluralize(@post.errors.count, "error") %> prohibited this post from
        being saved:
      </h2>

      <ul>
        <% @post.errors.full_messages.each do |msg| %>
          <li><%= msg %></li>
        <% end %>
      </ul>
    </div>
  <% end %>
  <div class="form-group">
    <%= f.text_area :body, placeholder: 'Enter your blab', class: 'form-control',
    rows: 3 %>
  </div>

  <div class="actions"><%= f.submit class: "btn btn-primary" %></div>
<% end %>

If you remember the index.html.erb, another frame wrapped the form’s render call. Thus, we included the dom_id to allow the controller’s create action to enable Turbo to manage the streams’ markup.

Now we’ll head back to the controller to talk about the create action in depth:

def create
    @post = Post.new(post_params)
    respond_to do |format|
      if @post.save
        redirect_to posts_path
      else
        render :index
      end
    end
  end

Previously, at this point, we’d discuss returning streams in the markup to be appended to the top-level frame, but Turbo 8’s refreshes and broadcasts manage all of that without any extra changes.

At this point, you should have an app that you can open in two browsers, which should look like this!

There you go! If everything went well, this was the fastest Twitter clone tutorial yet and probably required the least lines of code! Time will tell how all of this will play well together and scale in complex real-world Rails applications, but for now, the reduction in developer complexity is a huge win!

How to get a User's Timezone into Rails

Thu, 27 Jul 2023 15:00:00 GMT

You may have noticed most applications that you interact with and care about your timezone will, at one point, as you for your timezone and normally prepopulate the dropdown with your location’s timezone.

However, if you look for this functionality out-of-the-box in Rails, it does not seem to be there (or at least through all my sleuthing for My new app I am building). Though, I have the answer for how you can add this in about ten lines of code through one StimulusJS controller and your neighborhood Rails helpers.

First thing first, you will want to ditch the time_zone_select helper as the values used in there are not the same as what the browser will use in identifying time zones (I think Rails is not using the standard here, but I didn’t dig into too much while solving the technical issue). Instead, we will use a regular select and modify the array sent to a select tag:

<div data-controller="timezone">
  <%= f.select :timezone, ActiveSupport::TimeZone.all.collect {|tz| ["(UTC#{ActiveSupport::TimeZone.seconds_to_utc_offset(tz.utc_offset)}) #{tz.name}", tz.tzinfo.name]}, {}, data: {"timezone-target" => "tz"} %>
</div>

When using a select tag, you can provide the second argument an array of strings to represent the “text” and option “value” in the dropdown options. Here "(UTC#{ActiveSupport::TimeZone.seconds_to_utc_offset(tz.utc_offset)}) #{tz.name}" will construct a string with the offset and Rails timezone name (i.e., (UTC-08:00) Pacific Time (US & Canada)) and have the options value as the more accepted America/Los_Angeles. Additionally, at the very end, you can see where we are setting up the StimulusJS controller to interact with our select element, data: {"timezone-target" => "tz"}, which will produce data-timezone-target="tz" in the markup. Lastly, this select tag was wrapped in a div with an attribute to use the Timezone controller, data-controller="timezone".

Next, we can jump to the StimulusJS controller, which will also be simple. It is easiest to use the Rails CLI command to create the controller and update any other files that include controllers into the application.js:

bin/rails g stimulus timezone

Note - If you do not have Stimulus installed, you can do so with instructions here: https://github.com/hotwired/stimulus-rails.

In the new timezone_controller.js, you can add the following code:

import { Controller } from "@hotwired/stimulus"

export default class extends Controller {

  static targets = ['tz']

  initialize() {
    this.tzTarget.value = Intl.DateTimeFormat().resolvedOptions().timeZone;
  }
}

The Intl.DateTimeFormat().resolvedOptions().timeZone; is the browser’s javascript command for retrieving the timezone. Then, this.tzTarget.value = sets the dropdown value when the StimulusJS controller initializes.

That’s it! About five lines of custom code and another handful of edits to existing Rails tools to pre-select the user’s timezone in your Rails application!

This code, as-is, will not work for select boxes that need to be updated as it does not account for not overwriting an existing selected timezone provided by the backend. That’d be as easy as checking for the selected target’s value in Stimulus.

How to Build a Twitter Clone with Rails and Hotwire

Sun, 27 Dec 2020 00:00:00 GMT

Hotwire is fresh out of the Basecamp Github and has set the Rails community ablaze. This quick write up is an update from How to Build a Twitter Clone with rails, ActionCable, and React to show a comparison between the two approaches.

Now, this doesn’t mean to throw away any React code you may be using or StimulusReflex if you have already gone down that path. Those approaches are both more mature and widely discoverable.

I may follow this up with a video to do a more side-by-side look at these two approaches.

Without further ado, let’s get started with a new app:

rails new blabber --no-spring

Rails will do its thing, install the application, install the gems, process the Webpacker install, and install the NPM packages.

Next, we will want to add the hotwire-rails gem to get the libraries needed:

gem "hotwire-rails", "~> 0.1.1"

Bundle and run the installer command for Hotwire:

bundle install
rails hotwire:install

Now, let’s make a model to hold the data to clone a tweet in this Twitter clone called Blabber. All basic attributes:

rails g model Post username body:text likes_count:integer repost_count:integer

To keep this closely resembling the CableReady/StimulusReflex/React article, we’ll add the same validation in the Post model:

class Post < ApplicationRecord
  after_create_commit { broadcast_prepend_later_to 'posts' }
  after_update_commit { broadcast_replace_later_to 'posts' }
  after_destroy_commit { broadcast_remove_to 'posts' }

  validates :body, length: { minimum: 1, maximum: 280 }
end

One difference you see is the callbacks. When using Hotwire, the prevailing convention is to use ActiveRecord callbacks. While working on the model collection, you can set up callbacks for create, update, and destroy broadcasts.

We’ll make a few small adjustments to the generated migration file to add some database-level defaults (and allows us to keep the code around Post creation simple):

class CreatePosts < ActiveRecord::Migration[6.0]
  def change
    create_table :posts do |t|
      t.string :username, default: 'Blabby'
      t.text :body
      t.integer :likes_count, default: 0
      t.integer :repost_count, default: 0

      t.timestamps
    end
  end
end

Ok! Now, we’re ready to run that migration!

rails db:migrate

With the Model and Database layer out of the way, we can move on to the controller and corresponding view templates!

def index
  @posts = Post.all.order(created_at: :desc)
  @post = Post.new
end

def create
  @post = Post.new(post_params)
  respond_to do |format|
    if @post.save
      format.html { redirect_to posts_path }
    else
      format.html { render :index }
      format.turbo_stream { render turbo_stream: turbo_stream.replace(@post, partial: 'posts/form', locals: { post: @post }) } ## New for this article
    end
  end
end

def like
  Post.find_by(id: params[:post_id]).increment(:likes_count).save ## New for this article
  redirect_to posts_path
end

def repost
  Post.find_by(id: params[:post_id]).increment(:repost_count).save ## New for this article
  redirect_to posts_path
end

private

def post_params
  params.require(:post).permit(:body)
end

Simple controller. The index action returns a list of posts to @post. create uses StrongParameters, creates a new Post, and addresses some Turbo::Stream usage (more on that soon), and redirects back to the index template. like and repost are similar except they increment the respective count columns.

Let’s wire up a few routes to match up to those controller actions. Yes, these aren’t perfect RESTful routes, but 1) They work. 2) This is a 10-minute tutorial. 3) Are GET requests making sure we do not have to worry about AJAX/fetch/CSRF in the front-end. You would work around these issues in a production application.

Rails.application.routes.draw do
  resources :posts, only: %i[index create] do
    get 'like'
    get 'repost'
  end

  root to: 'posts#index'
end

With a Model, Controller, and routes, we can put together some view templates. We’ll start by adding Bootstrap CDN CSS. This way, we can wire up some UI interfaces pretty quickly!

<!DOCTYPE html>
<html>
  <head>
    <title>Blabber</title>
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>

    <%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
    <link href="https://stackpath.bootstrapcdn.com/bootstrap/4.4.1/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-Vkoo8x4CGsO3+Hhxv8T/Q5PaXtkKtu6ug5TOeNV6gBiFeWPGFN9MuhOf23Q9Ifjh" crossorigin="anonymous">
    <%= yield :head %>
    <%= turbo_include_tags %>
    <%= stimulus_include_tags %>
  </head>

  <body>
    <%= yield %>
  </body>
</html>

The yield :head, turbo_include_tags, and stimulus_include_tags were all added earlier by the hotwire:install command.

The first view template up is the app/views/posts/index.html.erb:

<div class="container">
  <h1>Blabber</h1>
  <h4>A Rails, Hotwire demo</h4>

  <%= turbo_frame_tag 'post_form' do %>
    <%= render partial: 'form' %>
  <% end %>

  <%= turbo_stream_from :posts %>
  <%= turbo_frame_tag 'posts' do %>
      <%= render @posts %>
  <% end %>
</div>

The view is a relatively simple usage of Rails, with a render @posts method, rendering the collection of @posts, using a posts/_post partial. The turbo_frame_tag’s will allow the Turbo libraries to instantiate the “frames” that will manage the HTML partials sent over the wire from the broadcasted changes. A lot is going on with that process, but Hotwire and Rails are taking care of it all and merely managing the markup. Specifically, turbo_stream_from :posts hooks up the view layer to listen to the Post model’s broadcasts.

The partial is some pretty standard singular object markup with some Bootstrap classes thrown in to make it look half decent:

app/views/posts/_posts.html.erb

<%= turbo_stream_from post %>
<div class="card mb-2" id="<%= dom_id(post) %>">
  <div class="card-body">
    <h5 class="card-title text-muted">
      <small class="float-right">
        Posted at <%= post.created_at %>
      </small>
      <%= post.username %>
    </h5>
    <div class="card-text lead mb-2"><%= post.body %></div>
    <a class="card-link" href="<%= post_repost_path(post) %>">
      Repost (<%= post.repost_count %>)
    </a>
    <a class="card-link" href="<%= post_like_path(post) %>">
      Likes (<%= post.likes_count %>)
    </a>
  </div>
</div>

Another turbo_stream command to listen for broadcasted updates and deletions, and the dom_id helper to create conventional Rails View IDs model_resource-id. In this case, it would look like posts_1, etc.

Up next is a straightforward Rails form:

<%= form_with model: @post, id: dom_id(@post), html: {class: 'my-4' } do |f| %>
<% if @post.errors.any? %>
<div id="error_explanation">
  <h2>
    <%= pluralize(@post.errors.count, "error") %> prohibited this post from
    being saved:
  </h2>

  <ul>
    <% @post.errors.full_messages.each do |msg| %>
    <li><%= msg %></li>
    <% end %>
  </ul>
</div>
<% end %>
<div class="form-group">
  <%= f.text_area :body, placeholder: 'Enter your blab', class: 'form-control',
  rows: 3 %>
</div>

<div class="actions">
  <%= f.submit class: "btn btn-primary" %>
</div>
<% end %>

If you remember the index.html.erb, another frame wrapped the form’s render call. Thus we included the dom_id to allow the controller’s create action to enable Turbo to manage the streams’ markup.

Now we’ll head back to the controller to talk about the create action in depth:

def create
  @post = Post.new(post_params)
  respond_to do |format|
    if @post.save
      format.html { redirect_to posts_path }
    else
      format.html { render :index }
      format.turbo_stream { render turbo_stream: turbo_stream.replace(@post, partial: 'posts/form', locals: { post: @post }) }
    end
  end
end

On a failed save, it will instruct the form’s partial to update the form frame with the form template, but this time with the errors markup triggered.

At this point, it should look like this!

There you go! I bet with a fast enough system to work through the Rails install, gem install, and javascript package installs, you could make it through this tutorial in less than 10 minutes!

How to Build a Twitter Clone with Rails and Hotwire

Sun, 27 Dec 2020 00:00:00 GMT

Now, this doesn’t mean to throw away any React code you may be using or StimulusReflex if you have already gone down that path. Those approaches are both more mature and widely discoverable.

I may follow this up with a video to do a more side-by-side look at these two approaches.

Without further ado, let’s get started with a new app:

rails new blabber --no-spring

Rails will do its thing, install the application, install the gems, process the Webpacker install, and install the NPM packages.

Next, we will want to add the hotwire-rails gem to get the libraries needed:

gem "hotwire-rails", "~> 0.1.1"

Bundle and run the installer command for Hotwire:

bundle install
rails hotwire:install

Now, let’s make a model to hold the data to clone a tweet in this Twitter clone called Blabber. All basic attributes:

rails g model Post username body:text likes_count:integer repost_count:integer

To keep this closely resembling the CableReady/StimulusReflex/React article, we’ll add the same validation in the Post model:

class Post < ApplicationRecord
  after_create_commit { broadcast_prepend_later_to 'posts' }
  after_update_commit { broadcast_replace_later_to 'posts' }
  after_destroy_commit { broadcast_remove_to 'posts' }

  validates :body, length: { minimum: 1, maximum: 280 }
end

We’ll make a few small adjustments to the generated migration file to add some database-level defaults (and allows us to keep the code around Post creation simple):

class CreatePosts < ActiveRecord::Migration[6.0]
  def change
    create_table :posts do |t|
      t.string :username, default: 'Blabby'
      t.text :body
      t.integer :likes_count, default: 0
      t.integer :repost_count, default: 0

      t.timestamps
    end
  end
end

Ok! Now, we’re ready to run that migration!

rails db:migrate

With the Model and Database layer out of the way, we can move on to the controller and corresponding view templates!

def index
  @posts = Post.all.order(created_at: :desc)
  @post = Post.new
end

def create
  @post = Post.new(post_params)
  respond_to do |format|
    if @post.save
      format.html { redirect_to posts_path }
    else
      format.html { render :index }
      format.turbo_stream { render turbo_stream: turbo_stream.replace(@post, partial: 'posts/form', locals: { post: @post }) } ## New for this article
    end
  end
end

def like
  Post.find_by(id: params[:post_id]).increment(:likes_count).save ## New for this article
  redirect_to posts_path
end

def repost
  Post.find_by(id: params[:post_id]).increment(:repost_count).save ## New for this article
  redirect_to posts_path
end

private

def post_params
  params.require(:post).permit(:body)
end

Rails.application.routes.draw do
  resources :posts, only: %i[index create] do
    get 'like'
    get 'repost'
  end

  root to: 'posts#index'
end

With a Model, Controller, and routes, we can put together some view templates. We’ll start by adding Bootstrap CDN CSS. This way, we can wire up some UI interfaces pretty quickly!

<!DOCTYPE html>
<html>
  <head>
    <title>Blabber</title>
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>

    <%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
    <link href="https://stackpath.bootstrapcdn.com/bootstrap/4.4.1/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-Vkoo8x4CGsO3+Hhxv8T/Q5PaXtkKtu6ug5TOeNV6gBiFeWPGFN9MuhOf23Q9Ifjh" crossorigin="anonymous">
    <%= yield :head %>
    <%= turbo_include_tags %>
    <%= stimulus_include_tags %>
  </head>

  <body>
    <%= yield %>
  </body>
</html>

The yield :head, turbo_include_tags, and stimulus_include_tags were all added earlier by the hotwire:install command.

The first view template up is the app/views/posts/index.html.erb:

<div class="container">
  <h1>Blabber</h1>
  <h4>A Rails, Hotwire demo</h4>

  <%= turbo_frame_tag 'post_form' do %>
    <%= render partial: 'form' %>
  <% end %>

  <%= turbo_stream_from :posts %>
  <%= turbo_frame_tag 'posts' do %>
      <%= render @posts %>
  <% end %>
</div>

The partial is some pretty standard singular object markup with some Bootstrap classes thrown in to make it look half decent:

app/views/posts/_posts.html.erb

<%= turbo_stream_from post %>
<div class="card mb-2" id="<%= dom_id(post) %>">
  <div class="card-body">
    <h5 class="card-title text-muted">
      <small class="float-right">
        Posted at <%= post.created_at %>
      </small>
      <%= post.username %>
    </h5>
    <div class="card-text lead mb-2"><%= post.body %></div>
    <a class="card-link" href="<%= post_repost_path(post) %>">
      Repost (<%= post.repost_count %>)
    </a>
    <a class="card-link" href="<%= post_like_path(post) %>">
      Likes (<%= post.likes_count %>)
    </a>
  </div>
</div>

Up next is a straightforward Rails form:

<%= form_with model: @post, id: dom_id(@post), html: {class: 'my-4' } do |f| %>
<% if @post.errors.any? %>
<div id="error_explanation">
  <h2>
    <%= pluralize(@post.errors.count, "error") %> prohibited this post from
    being saved:
  </h2>

  <ul>
    <% @post.errors.full_messages.each do |msg| %>
    <li><%= msg %></li>
    <% end %>
  </ul>
</div>
<% end %>
<div class="form-group">
  <%= f.text_area :body, placeholder: 'Enter your blab', class: 'form-control',
  rows: 3 %>
</div>

<div class="actions">
  <%= f.submit class: "btn btn-primary" %>
</div>
<% end %>

Now we’ll head back to the controller to talk about the create action in depth:

def create
  @post = Post.new(post_params)
  respond_to do |format|
    if @post.save
      format.html { redirect_to posts_path }
    else
      format.html { render :index }
      format.turbo_stream { render turbo_stream: turbo_stream.replace(@post, partial: 'posts/form', locals: { post: @post }) }
    end
  end
end

On a failed save, it will instruct the form’s partial to update the form frame with the form template, but this time with the errors markup triggered.

At this point, it should look like this!

There you go! I bet with a fast enough system to work through the Rails install, gem install, and javascript package installs, you could make it through this tutorial in less than 10 minutes!

Using Action Mailbox in Rails 6 to Receive Mail

Sun, 12 Jul 2020 19:00:08 GMT

Sending mail from a Rails application has been covered by hundreds or thousands of articles, however, there is not a ton of articles about receiving, parsing and using the new ActionMailbox.

The following is an excerpt from my book Build A SaaS App in Rails 6 and is used in a new product I am building Mail Buffer. Thus, I am standing by the tutorial here with real world usage!

Lastly, as this is an excerpt, this takes into account the chapter leading up to this section where the reader will have created an application, models for a Standup, Todo/Did/Blockers (which are Tasks) and a few mailers for outgoing mail.

Here goes nothing…

Another aspect of email within a SaaS application is receiving mail. While this is far less normal or used in comparison to sending, it can be a great way to make end user’s responses to email or action items quicker.

At a high level, there are a few different layers to this. The topmost layer is the email service, and this book’s case, Sendgrid. This service handles sending outbound emails, as well as routing incoming emails to an address/domain name specified in their interface. Once the email is routed, it will be redirected to a route and processor file in your application. This file will be responsible for parsing the incoming email address and using logic to decide what to do with it.

In the case of the Standup App we are building, we can have directions to respond to an Email Reminder to create a new standup right from their email response! Some of the tools that we will be using are Sendgrid’s email routing service and ngrok, an HTTP tunneling service. ngrok is very useful for a few solutions throughout the remainder of this book. It allows you to have a web-accessible URL, which tunnels(connects) to ports within your local machine. Meaning, that you will have a http://somesubdomain.ngrok.com that will forward to your computer and a specific port specified when you start ngrok. This allows you to test with external services such as Sendgrid, Stripe(later), Github(later), and more!

Let’s get started with some setup:

Download and use ngrok
- Download ngrok
- Unzip and move the executable file to where you would like.
- In *nix OS’s, open ngrok with: path/to/ngrok HTTP start 3000. This will be dependent on the port you are using for your Rails server. ngrok will now fire up a tunnel service with a randomly generated URL.
- Add config.hosts << "yoursubdomain.ngrok.io" to config/environments/development.rb
- Optionally, if you upgrade to a paid version of ngrok, you can set a subdomain, so you do not have to change your settings elsewhere every time you restart ngrok.
Follow your domain’s DNS provider’s instructions for adding an MX record for the subdomain or domain name you have chosen to use for inbound email. The MX record will be mx.sendgrid.net, with a priority of 10.

Now, before we head to the next part, we need to create and store a password for the incoming mail. You can use any method you like to create a password, and if you just can’t think of any way to do so, you can run SecureRandom.alphanumeric in Rails bash.

Now, to store this password you just came up with, we will need to introduce a new small, but powerful, feature, Rails Credentials. Since Rails 5.2, Rails provides a built-in way for storing secure credentials, that are encrypted.

To start using Rails Credentials, you will want to fire off the edit command:

EDITOR="atom --wait" rails credentials:edit

The editor I am using in this example is Atom. However, you can use any editor you like, and it’s command line caller. Also, --wait is used to make sure that the editor will wait for Rails to finish decrypting the file before opening it in the editor.

Now that we have the encrypted file open, add the following lines:

action_mailbox:
  ingress_password: *password you just made*

Save the file and close the tab/editor to make sure Rails saves the file and encrypts it. You will notice when Rails first opened the file, there was some output text in your terminal. Which includes the master key, DO NOT LOSE THIS KEY. It will need to be used a the only text in a config/master.key to be able to encrypt and decrypt the credentials.

Now, with that out of the way, there is a little bit more setup we need to do for Action Mailbox.

First, two commands to get Rails and some tables set up for inbound email:

bin/rails action_mailbox:install
bin/rails db:migrate

Lastly, add the following line to the config/application.rb file to let Rails know we’re using Sendgrid:

config.action_mailbox.ingress = :sendgrid

Ok, back to Sendgrid’s setup:

In Sendgrid, go to the Inbound Parse link, under settings, to create the email route that will send the email. Enter the following settings:
- Enter app.yourdomain.com for the domain field. You can optionally choose an additional subdomain to receive emails within the Inbound Parse.
- Enter http://actionmailbox:THEPASSWORDFROMBEFORE@yoursubdomain.ngrok.io/rails/action_mailbox/sendgrid/inbound_emails as the destination URL.
- Check POST the raw, full MIME message, before pressing the submit button.

Ok, we’re getting nearly done with the setup here. Next, we will need to set up the applications inbound email route and run a command to generate that mailbox class. First, in the application_mailbox.rb file that was created just a few commands ago, you will add routing /standups\.[0-9a-fA-F]{8}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{12}@/i => :standups. This says when an incoming mail matches that email address syntax, it will be routed to the standups mailbox class for processing.

After that, to create the mailbox file, you will just need to run a Rails generator:

bin/rails generate mailbox forwards

A few changes will be needed to allow Action Mailbox and its files to capture text from incoming replies.

First, we will update the EmailReminderMailer to create a unique reply-to address and include that email address as part of the outgoing email:

class EmailReminderMailer < ApplicationMailer
  def reminder_email(user, team)
    @user = user
    @team = team
    reply_to = "'Standups App' <standups.#{@user.id}@app.yourdomain.com>"
    make_bootstrap_mail(
      to: @user.email,
      subject: "#{team.name} Standup Reminder!",
      reply_to: reply_to
    )
  end
end

Here we are adding the reply_to string to so when someone replies to a reminder email, the reply will be routed through Sendgrid, to Action Mailbox, and then finally by the Standup Mailbox class.

Next, we will update the mailer template to have ##- Please type your reply above this line -## and some text letting the email recipient know they can add a standup by replying:

<div class="container">
  <span class="text-secondary text-center" style="font-size:8px">##- Please type your reply above this line -##</span>
  <h1 class="text-center mb-4">
    Standup App
  </h1>
  <div class="card mb-4">
    <div class="card-body">
      <h3 class="text-center mb-4"><%= @team.name%> Reminder! </h3>
      <p class="mb-4">
        Just wanted to remind you to add your standup for
        the team: <%= @team.name %>
      </p>
      <%= link_to "Add Your Standup", new_standup_url(), {class: "btn btn-primary btn-lg mx-auto mt-2", style: "width:95%"} %>
    </div>
  </div>
</div>

Lastly, we will need to add an extra column to the Standups table to track the Message-ID coming from the Mailgun routed emails. As you can not count on an email service to provide “just once” delivery, we will need to track these unique IDs ourselves on the Standup table.

rails g migration AddMessageIdToStandups message_id

Next, before the end of the newly created migrations change method, you will want to add add_index :standups, :message_id. This index will allow quick lookups as the Standups table grows. Finally, migrate the actual change:

rails db:migrate

Lastly, to make sure sidekiq picks up the queues that Rails uses for Action Mailbox, we will need to adjust the worker in the Procfile.dev to:

worker: bundle exec sidekiq -q default -q mailers -q action_mailbox_routing -q active_storage_analysis

With those changes out of the way we can now add the new StandupsMailbox class that will parse the incoming email:

class StandupsMailbox < ApplicationMailbox
  TASK_TYPE_HASH = {
    '[d]' => 'Did',
    '[t]' => 'Todo',
    '[b]' => 'Blocker'
  }

  def process
    # Get a user id from reply-to or bail
    reply_user = mail.to.first&.split('<')&.last&.split('@')&.first&.split('.')&.last
    return if reply_user.blank?

    # Find a user by the id or bail
    user = User.find_by(id: reply_user)
    return if user.nil?

    # Bail if standup with incoming message-id exists
    return if Standup.exists?(message_id: inbound_email.message_id)

    # Bail if a standup for today exists
    today = Date.today.iso8601
    return if Standup.exists?(standup_date: today)

    # Get content or bail
    safe_body = Rails::Html::WhiteListSanitizer.new.sanitize(mail_body)
    tasks_from_body = safe_body.scan(/(\[[dtb]{1}\].*)$/)
    return if tasks_from_body.blank? || tasks_from_body.empty?

    build_and_create_standup(
      user: user,
      tasks: tasks_from_body,
      date: today,
      message_id: inbound_email.message_id
    )
  end

  private

  def build_and_create_standup(user:, tasks:, date:, message_id:)
    standup = Standup.new(
      user_id: user.id,
      standup_date: date,
      message_id: message_id
    )

    tasks.each do |task|
      task_type, task_body = task.first.scan(/(\[[dtb]\])(.*)$/).flatten
      standup.tasks << Task.new(type: TASK_TYPE_HASH[task_type], title: task_body)
    end

    standup.save
  end

  def mail_body
    @mail_body ||= begin
      if mail.multipart?
        mail.parts[0].body.decoded
      else
        mail.decoded
      end
    end
  end
end

The class is relatively simple, but let’s go over it section by section:

class StandupsMailbox < ApplicationMailbox
  TASK_TYPE_HASH = {
    '[d]' => 'Did',
    '[t]' => 'Todo',
    '[b]' => 'Blocker'
  }

  ...

Here we are setting up the StandupsMailbox to inherit from the ApplicationMailbox class, which handles the routing. Additionally, we are creating a hash to later use in the text content to Task type conversion.

...

def process
  # Get a user id from reply-to or bail
  reply_user = mail.to.first&.split('<')&.last&.split('@')&.first&.split('.')&.last
  return if reply_user.blank?

  # Find a user by the id or bail
  user = User.find_by(id: reply_user)
  return if user.nil?

  # Bail if standup with incoming message-id exists
  return if Standup.exists?(message_id: inbound_email.message_id)

  # Bail if a standup for today exists
  today = Date.today.iso8601
  return if Standup.exists?(standup_date: today)

  # Get content or bail
  safe_body = Rails::Html::WhiteListSanitizer.new.sanitize(mail_body)
  tasks_from_body = safe_body.scan(/(\[[dtb]{1}\].*)$/)
  return if tasks_from_body.blank? || tasks_from_body.empty?

...

Here we are grabbing some information used in the parsing, as well as giving the process method chances to exit early if the incoming email is not sufficient for processing and Standup creation. In the first section, the incoming email address is parsed to find the user’s id. That string is then used to find a User. If there is no user, the method returns without adding a Standup.

The next line will exit the method early if there is already a standup with the current Message-ID. Again, this is making sure to guard against email providers, not guaranteeing “just once” delivery. That is followed up by generating a variable for the current date and making sure there is no standup with the current_user and current_date.

To get the mail’s content, we will want to do two things, make sure we get the correct body from the mail object as email clients can send both an HTML and plain text version. Then we will want to make sure we only grab the content above the ##- Please type your reply above this line -## string by using the split method (which splits a string into as many parts based on the separator specified in the argument):

def mail_body
    @mail_body ||= begin
      body = if mail.multipart?
        mail.parts[0].body.decoded
      else
        mail.decoded
      end
      body.split('##- Please type your reply above this line -##').first
    end
  end

Finally, the actual email content is parsed with a regular expression. Regular Expression is a programming language that allows you to pattern match on a string and even capture parts of the pattern matching. This particular pattern(which you can get a more thorough syntax explanation here) searches for lines that begin with [d], [t] or [r]. If those are present, it captures the content to the end of the line. The .scan method on the content’s body allows it to catch all occurrences of the above pattern. If the scan’s output is empty, the process method exits.

  build_and_create_standup(
      user: user,
      tasks: tasks_from_body,
      date: today,
      message_id: email.headers["Message-ID"]
    )
  end

  private

  def build_and_create_standup(user:, tasks:, date:, message_id:)
    standup = Standup.new(
      user_id: user.id,
      standup_date: date,
      message_id: message_id
    )

    tasks.each do |task|
      task_type, task_body = task.first.scan(/(\[[dtb]\])(.*)$/).flatten
      standup.tasks << Task.new(type: TASK_TYPE_HASH[task_type], title: task_body)
    end

    standup.save
  end
end

The last section here is a culmination of all of the stored information so far to be saved into a new Standup. The user, tasks_from_body, today, and message_id are all passed into a method that will hand the actual save. The build_and_create_standup method creates a new Standup, with the user’s ID, date, and message_id. Once the object is created, the task’s strings are iterated over to build the Task with a type and assigned as child objects with the << syntax. Finally the new Standup object with children Tasks will be saved with standup.save

Lastly, you can test this all works if you reply back to an email(that was sent through Sendgrid SMTP and not letter_opener) with the following text:

[d] Did a thing
[d] And Another
[t] Something to do
[b] Something in the way. Some really long line about something or another

Testing this will require a new spec file with a few it blocks to test all the branches the StandupMailbox may encounter.

First, we will need to add one small change to the rails_helper.rb file to make sure RSpec has access to the Rails Action Mailbox test helpers. I’ll add the new lines and a few lines above each, so you know where to put the new stuff:

...

require 'support/system_macros'
include Warden::Test::Helpers
require 'action_mailbox/test_helper' # <-- new line

...

RSpec.configure do |config|
  config.include Devise::Test::ControllerHelpers, type: :controller
  config.include Devise::Test::ControllerHelpers, type: :view
  config.include ActionMailbox::TestHelper, type: :mailbox # <-- new line

...

…and now the actual spec file itself:

require 'rails_helper'
include ActiveJob::TestHelper

RSpec.describe StandupsMailbox, type: :mailbox do
  let(:user) { FactoryBot.create(:user) }
  let(:to_email) { "standups.#{user.id}@app.buildasaasappinrails.com" }
  let(:body) do
    %Q(
      [d] Did a thing
      [d] And Another
      [t] Something to do
      [b] Something in the way. Some really long line about something or another

      ##- Please type your reply above this line -##
    )
  end

  subject do
    receive_inbound_email_from_mail(
      from: user.email,
      to: to_email,
      subject: 'Re: Reminder',
      body: body
    )
  end

  before do
    ActiveJob::Base.queue_adapter = :test
  end

  it 'saves standup record' do
    expect { subject }.to change(Standup, :count).by(1)
  end

  it 'saves task records' do
    expect { subject }.to change(Task, :count).by(4)
  end

  context 'fails on bad to email' do
    let(:to_email) {"standups@app.buildasaasappinrails.com"}

    it 'does not save standup record' do
      expect { subject rescue nil }.to_not change(Standup, :count)
    end
  end

  context 'fails on no user' do
    let(:to_email) {"standups.9a859af8-30ca-4473-b073-47105352d936@app.buildasaasappinrails.com"}

    it 'does not save standup record' do
      expect { subject rescue nil }.to_not change(Standup, :count)
    end
  end

  context 'fails on useless body' do
    let(:body) { 'asdj;oisaduaskd' }

    it 'does not save standup record' do
      expect { subject rescue nil }.to_not change(Standup, :count)
    end
  end

  context 'fails on empty body' do
    let(:body) { '' }

    it 'does not save standup record' do
      expect { subject rescue nil }.to_not change(Standup, :count)
    end
  end
end

While long and containing six examples, this spec is actually pretty straightforward. It is first testing the happy path where everything is set up and working. Then checks each failing path that doesn’t create a standup, in order as those paths appear in the StandupsMailbox’s .process method.

How to inspect a Ruby Object

Sun, 31 May 2020 00:00:00 GMT

Imagine this, you adding a new object in your view, you reload the page, and you are greeted with Undefined method for nil:NilClass. “Ok, I’ll just print the object”, you think to yourself:

puts AwesomeObject.new
#<AwesomeObject:0x00007fd9a142a748>

Well, that didn’t help. Let’s go over the ways to print and inspect Ruby objects.

Printing an Object

First, what happens when you print an object?

When you puts an object instance it will call .to_s method on that object. In the cases of built-in Object types in Ruby, this is handled for you. Such as when you puts a number:

puts 7
7
=> nil

When you do that on an object, like above, the default behavior of to_s on an object is to print the Object’s class name (this part AwesomeObject) and the object_id (this part 0x00007fd9a142a748>).

We can update the class to include a to_s to control the output of an object’s instance in a puts statement:

class AwesomeObject
  def to_s
    "This is some awesome output"
  end
end

Then, once you run puts on it, the output from the to_s method will be used:

puts AwesomeObject.new
This is some awesome output

Inspecting an Object

Another method defined on all objects and usually overridden by the specific uses-cases of the individual classes is the inspect method.

Let’s make out AwesomeObject a little more complicated:

class AwesomeObject

  def initialize(name, age)
    @name = name
    @age = age
  end

  attr_reader :name, :age

  def to_s
    "This is some awesome output: #{name}, #{age}"
  end
end

To go back over the puts which uses to_s and is customized in the class above:

puts AwesomeObject.new("Rob", 42)
This is some awesome output: Rob, 42

Now, by default, the inspect method will print out the class name and object_id, much like the build in to_s method on the Object class. Then it will display the attributes/instance methods on the object. This it would display the name and age, like so:

AwesomeObject.new("Rob", 42).inspect
#<AwesomeObject:0x00007fd9a15720b0 @name="Rob", @age=42>

Just like the to_s method used in puts, you can also customize and override the inspect method in your own class. Imagine we used the following inspect method and called inspect on the object’s instance:

class AwesomeObject

  def initialize(name, age)
    @name = name
    @age = age
  end

  attr_reader :name, :age

  def inspect
    "This is some awesome output: #{name}, #{age}"
  end
end

Then, in your IRB or console, you can run .inspect on the instance:

AwesomeObject.new("Rob", 42).inspect
 => "This is some awesome output: Rob, 42"

There you have it! Two ways to get the data from an object and how you can override them! I implore you to use puts and .inspect on the objects you may use daily, such as ActiveRecord objects, instances from gems, or clients such as HTTP clients or API clients. You will usually be able to see relevant information to debug any issue you come across.

Integrating Bootstrap 4 into Rails 6

Wed, 27 May 2020 19:00:08 GMT

We’ve all been there, you start building a new Rails application and you realize there is no style on any of your generic Rails pages. So you know in the back of your head you can grab Bootstrap and an Admin theme to get things moving. You may then find yourself asking, “What’s the best way to get Bootstrap into Rails?” and “How do I add the theme itself to the application?”. Let’s did into those questions and more in this post!

To install the a Bootstrap theme, we are going to be adding some packages, updating some configuration and adding a few additional gems/libraries to make life developing easier.

The first thing to do is to add another version manager! Since we are using Yarn/NPM/Node, it is a good idea to manage the version of Node a particular application or directory will be using. To do so, we will use NVM, and you can install NVM with the following line. If you are one to look at the github repo or the install scripts, you can here.

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh | bash

That line grabs the install script from Github and runs it as Bash.

Now the current LTS (Long Term Stable) version of Node is version 12. LTS versions in the OSS (Open Source) communities is the version in which you can rely on long term stability. To install Node use the following command:

nvm install 12

This line installs the latest updated version of version 10. Meaning, as small updates and bugfixes are released to the version 10 pipeline, they bump the version numbers under 12 (i.e., 12.3.4 -> 12.3.5). Once installed, you can tell your terminal window/pane to use node 12 with the following command:

nvm use 12

When you created your new app, Rails should have made sure brew and yarn were added. Thus, you should now be able to install AdminLTE, Bootstrap, and a few other dependencies needed to get AdminLTE up and running in your application.

First, to install a version of AdminLTE that is compatible with Bootstrap 4, we will need to install through Yarn on a specific Github branch

yarn add admin-lte@3

This command is saying, install admin-lte and use the version 3. Next, we also install the packages for Bootstrap, jQuery and Popper.js to make sure they are available to the Rails application:

yarn add bootstrap jquery popper.js

That should take care of making sure all of the packages we need for the theme are there, but it seems as though Rails does not entirely install everything needed for Webpacker to get up and running. To remedy this issue, let’s run the Webpacker install.

rails webpacker:install

Alright, we are getting close to being done with setup! However, we should digress a bit in regards to Webpacker.

Webpacker

Webpacker is the Ruby (Rails mostly) wrapper gem around the Javascript tool, Webpack. Webpack is a tool that allows you to pre-process, bundle and use ES6 like syntax inside Javascript. Webpacker then takes all of those features and starts to merge the ES6 Javascript world with the Asset pipeline for CSS and other more static assets.

Webpacker introduces a concept of “packs” which are ES6 syntax Javascript files that you can then include in any template with a pack_tag helper. Think of packs as entry points of javascript files into specific spots in a Rails app.

The most basic pattern is the /app/javascript/application.js pack file, which is then included in the applications’ layout file by default.

As your application grows, using packs to specify specific libraries and functionality within specific templates or sections of your application helps make sure your Javascript stays modular and compartmentalized.

Running A Webpack Dev Server

If you have used Heroku or other hosting vendors, you may see reference to Procfile. The simplest definition of a Procfile is that it allows you to specify a list of different process types and lets another system(Heroku, Foreman gem, etc.) handle startup and shutdown. Allow all of that to be dealt with one line and one terminal session/tab/pane.

When developing locally, the easiest step to take is to use the gem Foreman. To add this gem, add it to the development group in your Gemfile and bundle install:

...

group :development do
  gem 'foreman'

...

Once added, you can add your Procfile to the root of your app’s folder structure. Meaning the same level as your Gemfile.

web: bundle exec puma -t 5:5 -p ${PORT:-3000} -e ${RACK_ENV:-development}

You may notice that instead of rails s, you see bundle exec puma. This change is due to how you would want to run Puma directly in most environments.

If you were to start your environment with Foreman and this procfile, you would use the following on the command line:

foreman start

That command starts up a process for each line in your Procfile. Thus, in this case, a process for Puma, to run the Rails server. However, if you visit your instance of the app, first you may notice it is now at http://localhost:5000, and it is also not outputting development logs.

So, how can we make development use rails s to keep the fancy logs? We can create a secondary Procfile that is utilized just for development.

web: bin/rails s -p ${PORT:-3000}
webpacker: ./bin/webpack-dev-server

What is webpack-dev-server?

Very simply, it is a server that runs in the background that allows you to develop your Javascript, handles automatic reloads and makes sure packs are served to you your development Rails server.

To get this Procfile running instead, you simply just need to add a field to your command line syntax:

foreman start -f Procfile.dev

We’re getting closer! Now if you visit http://localhost:5000, you should see the output in the terminal from your request. However, we’re still on port 5000. This problem is easy to fix, just supply the command line with the environment variable used in the command to choose the port.

PORT=3000 foreman start -f Procfile.dev

Now, you can quickly start everything up and get it running in one terminal tab.

Final Webpacker Setup

Ok, we’re getting so close to getting everything up and running. We’re down to adding just a few additions to the Webpack javascript configuration.

config/webpack/environment.js

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

const webpack = require("webpack");

// Add an additional plugin of your choosing : ProvidePlugin
environment.plugins.prepend(
  "Provide",
  new webpack.ProvidePlugin({
    $: "jquery",
    jQuery: "jquery",
    jquery: "jquery",
    "window.Tether": "tether",
    Popper: ["popper.js", "default"] // for Bootstrap 4
  })
);

module.exports = environment;

One of the additions are the 8 lines of plugin code that is used to make sure jQuery, Popper.js and Tether are available throughout the bundled javascript.

The Application Pack

When adding Javascript to a Rails application, there are javascript libraries, setup or variables you want throughout the application. In the world of Rails 6 and Webpacker, these items go in the Application Pack, located at app/javascript/packs/application.js. The good news is that this file is created when you used the Rails command to create a new Rails app. Let’s go over the additions to get AdminLTE’s needs fulfilled.

// This file is automatically compiled by Webpack, along with any other files
// present in this directory. You're encouraged to place your actual application logic in
// a relevant structure within app/javascript and only use these pack files to reference
// that code so it'll be compiled.

require("@rails/ujs").start();
require("turbolinks").start();
require("@rails/activestorage").start();
require("channels");

var jQuery = require("jquery");

// import jQuery from "jquery";
global.$ = global.jQuery = jQuery;
window.$ = window.jQuery = jQuery;

require("bootstrap");
require("admin-lte");

// Uncomment to copy all static images under ../images to the output folder and reference
// them with the image_pack_tag helper in views (e.g <%= image_pack_tag 'rails.png' %>)
// or the `imagePath` JavaScript helper below.
//
// const images = require.context('../images', true)
// const imagePath = (name) => images(name, true)

The commented code and the first four lines of requires are added by default. These are libraries or packages that Rails needs for most applications. The new lines are adding jQuery and variables that other packages or libraries may expect to exist. Lastly, bootstrap and admin-lte are required to make available to the entire Rails application.

Why require and not import

If you have done any recent javascript development, you may question why we are using require and not import. The answer here is rather simple. Based on the packages we are using and adding in, they expect other’s to have loaded first. Most specifically, admin-lte expects the global variable jQuery to exist when it loads. Using require guarantees code is executed in the order of the file, whereas import usually is pre-processed and executed out of order.

The Application Stylesheet

Lastly, we need to add some imports to the bottom of the automatically created Application Stylesheet. If you have done any Rails development in the last few years, you may have interacted with the Asset Pipeline, which is the way Rails handled the inclusion of javascript, stylesheets and any other static assets.

You’ll notice that the name of the file is different than what was generated by Rails. For import the extension scss needs to be used, signaling the Asset Pipeline to run the file as Sass, then CSS.

/*
 * This is a manifest file that'll be compiled into application.css, which will include all the files
 * listed below.
 *
 * Any CSS and SCSS file within this directory, lib/assets/stylesheets, or any plugin's
 * vendor/assets/stylesheets directory can be referenced here using a relative path.
 *
 * You're free to add application-wide styles to this file and they'll appear at the bottom of the
 * compiled file so the styles you add here take precedence over styles defined in any other CSS/SCSS
 * files in this directory. Styles in this file should be added after the last require_* statement.
 * It is generally better to create a new file per style scope.
 *
 *= require_tree .
 *= require_self
 */

@import url("https://fonts.googleapis.com/css?family=Source+Sans+Pro:300,400,600,700&lang=en");

@import "bootstrap";
@import "admin-lte/dist/css/adminlte";

In Sass CSS, you can include other stylesheets or fonts by using the @import syntax. In this stylesheet above, we are adding a font from Google Fonts that are referenced in AdminLTE’s stylesheets. Next, we include stylesheets for Bootstrap and AdminLTE.

In the following section, we are going to add some Controllers and Templates to added the necessary markup to structure the application.

Before we begin implementing the layout, we need to apply a route and controller to bypass the default welcome page. We also will be using this controller in the application as we go along.

Let’s also pause to mention that Rails comes with built-in command line generators to generate controllers, models, mailers. As well as generating database migration file or even generating a scaffold of all of those combined. In our case, let’s focus on the controller generator. The general format for this generator is:

rails generate controller Activity mine feed

It created a controller with empty methods for the actions we included in the command line. It created template files, test files, and other auxiliary files.

Let’s make one quick edit to the route file to define a default route, adding “root to: ‘activity#mine’” to the bottom of the route file, as follows:

Rails.application.routes.draw do
  get 'activity/mine'
  get 'activity/feed'
  root to: 'activity#mine'
end

As we had set up the theme package, application javascript file and application stylesheet file earlier in the chapter, we can get into writing the markup needed to implement this theme rather quickly.

First, we can modify the main layout file to include the necessary elements and classes to wrap the content that will be provided by routed templates.

File: app/views/layouts/application.html.erb:

<!DOCTYPE html>
<html>
  <head>
    <title>Some App</title>
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>
    <%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
    <%=  javascript_pack_tag 'application', 'data-turbolinks-track': 'reload' %>
    <script src="https://kit.fontawesome.com/6d90f39943.js"></script>
    <-- Make your own FontAwesome Kit on their site -->
  </head>
  <body class="sidebar-mini">
    <div class="wrapper">
      <%= render partial: "layouts/header" %> <%= render partial:
      "layouts/sidebar" %>
      <div class="content-wrapper">
        <%= yield %>
      </div>
      <%= render partial: "layouts/footer" %>
    </div>
  </body>
</html>

The details of this file are not all pertinent to the addition of the Bootstrap theme, so we’ll only touch on those that matter. First, a class is added to the body element, “body class=“sidebar-mini”“. Next, “

” and “

” are added as wrapping elements to the first the page and then the inner content. You may notice there is some included Ruby code in there as well. Those render partial: calls allow us to add markup from other template files, in that position. In this case, it adds various larger parts of the application template such as the header, sidebar or footer. Plus, it keeps the layout to only the most necessary foundational elements to build the page structure. Then, “<%= yield %>” which is the Rails’ template method for adding the template from the controller and action called.

Since we are using partial templates, we go ahead and create the header file next.

One thing to note here is the use of the underscore in the template file’s name. In Rails, partial template files are designated with an underscore at the beginning of the file name. What are partials? Partials are simply a way to break down templates into smaller chunks. This approach comes into far greater play in situations such as looping over a collection of items. There, you would make the template chunk to display item information a partial. For example, the header template is titled _header.erb.

app/views/layout/_header.erb

<nav
  class="main-header navbar navbar-expand navbar-white navbar-light border-bottom"
>
  <!-- Left navbar links -->
  <ul class="navbar-nav">
    <li class="nav-item">
      <a class="nav-link" data-widget="pushmenu" href="#"
        ><i class="fas fa-bars"></i
      ></a>
    </li>
    <li class="nav-item d-none d-sm-inline-block">
      <a href="index3.html" class="nav-link">Home</a>
    </li>
    <li class="nav-item d-none d-sm-inline-block">
      <a href="#" class="nav-link">Contact</a>
    </li>
  </ul>
  <!-- SEARCH FORM -->
  <form class="form-inline ml-3">
    <div class="input-group input-group-sm">
      <input
        class="form-control form-control-navbar"
        type="search"
        placeholder="Search"
        aria-label="Search"
      />
      <div class="input-group-append">
        <button class="btn btn-navbar" type="submit">
          <i class="fas fa-search"></i>
        </button>
      </div>
    </div>
  </form>
  <!-- Right navbar links -->
  <ul class="navbar-nav ml-auto">
    <!-- Messages Dropdown Menu -->
    <li class="nav-item dropdown">
      <a class="nav-link" data-toggle="dropdown" href="#">
        <i class="far fa-comments"></i>
        <span class="badge badge-danger navbar-badge">3</span>
      </a>
      <div class="dropdown-menu dropdown-menu-lg dropdown-menu-right">
        <a href="#" class="dropdown-item">
          <!-- Message Start -->
          <div class="media">
            <img
              src="http://placehold.it/128x128"
              alt="User Avatar"
              class="img-size-50 mr-3 img-circle"
            />
            <div class="media-body">
              <h3 class="dropdown-item-title">
                Brad Diesel
                <span class="float-right text-sm text-danger"
                  ><i class="fas fa-star"></i
                ></span>
              </h3>
              <p class="text-sm">Call me whenever you can...</p>
              <p class="text-sm text-muted">
                <i class="far fa-clock mr-1"></i> 4 Hours Ago
              </p>
            </div>
          </div>
          <!-- Message End -->
        </a>
        <div class="dropdown-divider"></div>
        <a href="#" class="dropdown-item">
          <!-- Message Start -->
          <div class="media">
            <img
              src="http://placehold.it/128x128"
              alt="User Avatar"
              class="img-size-50 img-circle mr-3"
            />
            <div class="media-body">
              <h3 class="dropdown-item-title">
                John Pierce
                <span class="float-right text-sm text-muted"
                  ><i class="fas fa-star"></i
                ></span>
              </h3>
              <p class="text-sm">I got your message bro</p>
              <p class="text-sm text-muted">
                <i class="far fa-clock mr-1"></i> 4 Hours Ago
              </p>
            </div>
          </div>
          <!-- Message End -->
        </a>
        <div class="dropdown-divider"></div>
        <a href="#" class="dropdown-item">
          <!-- Message Start -->
          <div class="media">
            <img
              src="http://placehold.it/128x128"
              alt="User Avatar"
              class="img-size-50 img-circle mr-3"
            />
            <div class="media-body">
              <h3 class="dropdown-item-title">
                Nora Silvester
                <span class="float-right text-sm text-warning"
                  ><i class="fas fa-star"></i
                ></span>
              </h3>
              <p class="text-sm">The subject goes here</p>
              <p class="text-sm text-muted">
                <i class="far fa-clock mr-1"></i> 4 Hours Ago
              </p>
            </div>
          </div>
          <!-- Message End -->
        </a>
        <div class="dropdown-divider"></div>
        <a href="#" class="dropdown-item dropdown-footer">See All Messages</a>
      </div>
    </li>
    <!-- Notifications Dropdown Menu -->
    <li class="nav-item dropdown">
      <a class="nav-link" data-toggle="dropdown" href="#">
        <i class="far fa-bell"></i>
        <span class="badge badge-warning navbar-badge">15</span>
      </a>
      <div class="dropdown-menu dropdown-menu-lg dropdown-menu-right">
        <span class="dropdown-item dropdown-header">15 Notifications</span>
        <div class="dropdown-divider"></div>
        <a href="#" class="dropdown-item">
          <i class="fas fa-envelope mr-2"></i> 4 new messages
          <span class="float-right text-muted text-sm">3 mins</span>
        </a>
        <div class="dropdown-divider"></div>
        <a href="#" class="dropdown-item">
          <i class="fas fa-users mr-2"></i> 8 friend requests
          <span class="float-right text-muted text-sm">12 hours</span>
        </a>
        <div class="dropdown-divider"></div>
        <a href="#" class="dropdown-item">
          <i class="fas fa-file mr-2"></i> 3 new reports
          <span class="float-right text-muted text-sm">2 days</span>
        </a>
        <div class="dropdown-divider"></div>
        <a href="#" class="dropdown-item dropdown-footer"
          >See All Notifications</a
        >
      </div>
    </li>
    <li class="nav-item">
      <a
        class="nav-link"
        data-widget="control-sidebar"
        data-slide="true"
        href="#"
        ><i class="fas fa-th-large"></i
      ></a>
    </li>
  </ul>
</nav>

This template contains the structure to have the app title/logo, dropdowns and any additional links you may need for navigation. To get the app template structure setup, we can leave in some of the demo data and elements to show how the dropdowns would look and work.

The next partial to create is the _sidebar template:

app/views/layouts/_sidebar.erb

<aside class="main-sidebar sidebar-dark-primary elevation-4">
    <!-- Brand Logo -->
  <a href="index3.html" class="brand-link">
    <span class="brand-text font-weight-light">Standup App</span>
  </a>
<!-- Sidebar -->
  <div class="slimScrollDiv" style="position: relative; overflow: hidden; width: auto; height: 652px;"><div class="sidebar" style="min-height: 652px; overflow: hidden; width: auto; height: 652px;">
    <!-- Sidebar user panel (optional) -->
    <div class="user-panel mt-3 pb-3 mb-3 d-flex">
      <div class="image">
        <img src="http://placehold.it/160x160" class="img-circle elevation-2" alt="User Image">
      </div>
      <div class="info">
        <a href="#" class="d-block">User Name</a>
      </div>
    </div>
<!-- Sidebar Menu -->
    <nav class="mt-2">
      <ul class="nav nav-pills nav-sidebar flex-column" data-widget="treeview" role="menu" data-accordion="false">
        <!-- Add icons to the links using the .nav-icon class
             with font-awesome or any other icon font library -->
        <li class="nav-item has-treeview menu-open">
          <a href="#" class="nav-link active">
            <i class="nav-icon fas fa-tachometer-alt"></i>
            <p>
              Activity
              <i class="right fas fa-angle-left"></i>
            </p>
          </a>
          <ul class="nav nav-treeview">
            <li class="nav-item">
              <a href="./index.html" class="nav-link active">
                <i class="far fa-circle nav-icon"></i>
                <p>Mine</p>
              </a>
            </li>
            <li class="nav-item">
              <a href="./index2.html" class="nav-link">
                <i class="far fa-circle nav-icon"></i>
                <p>Feed</p>
              </a>
            </li>
          </ul>
        </li>
      </ul>
    </nav>
    <!-- /.sidebar-menu -->
  </div>
  <!-- /.sidebar -->
</aside>

As you see, the sidebar partial is a bit smaller and more straightforward. It contains a little bit of user information and links to other parts of the application that we change later.

The last major piece of the layout is the footer. It is simple, and it is short. Again, it is another partial. Here is the ERB markup:

app/views/layouts/_foooter.erb

<footer class="main-footer">
  <strong>Copyright © 2019 Your Stuff.</strong>
  All rights reserved.
</footer>

Now, to have all of this show up on a page, you can edit the root controller action’s template to use the theme’s div classes

app/views/activity/mine.html.erb

<div class="content-header">
  <div class="container-fluid">
    <div class="row mb-2">
      <div class="col-sm-6">
        <h1 class="m-0 text-dark">Some Page</h1>
      </div>
    </div>
  </div>
</div>
<section class="content">
  <div class="container-fluid">
    <div class="row">
      <div class="col-lg-12">
        <div class="card">
          <div class="card-body">
            <span>Stuff</span>
          </div>
        </div>
      </div>
    </div>
  </div>
</section>

That’s about it to get set up with Bootstrap 4 and Rails 6.

19 Must-Have Gems for 2020

Tue, 19 May 2020 19:00:08 GMT

An application can only be as good as the features it is providing for its end-users. Every developer toes the line between indiscriminately adding gems and building new functionality themselves. When time is of the essence, these are the gems I reach for:

local_time - An relatively older gem and stable, but this is a gem that includes a view helper and javascript helper to display relative time (i.e. ‘updated 2 minutes ago’)
devise - Devise is still the go-to gem for authentication in most Rails apps. Its ease of use and existing features make it dead-simple to add authentication. For those looking for a simpler gem with a smaller footprint, Authlogic gets a runner up in this list for authentication.
Interactor - When you start to follow the Service Object pattern, adding Interactor can help guide your context and result of those objects through a common interface.
rolify and cancancan - Rolify allows us to assign roles such as User or Admin then CanCanCan will enable us to take those roles and apply authorization policies. However, there is a case for Pundit for those who like the Policy Object approach’s simplicity.
Lockbox - When you need to encrypt data in your database for compliance or even client security, Lockbox makes it very easy to do. Working with plenty of types out of the box, such as most database types, other Rails tools(ActiveStorage), and third-party gems(Shrine).
Sidekiq - This is the gem when it comes to running asynchronous tasks. Sidekiq is backed by Redis and has been long supported by the ActiveJob Rails abstractions.
Kaminari - A simple yet powerful approach to adding pagination into your Rails applications. In many places, it is as simple a few drop-in changes, but can be used to on anything from ActiveRecord collections to plain Arrays. It also has templates to be used in many of the most known CSS frameworks such as Bootstrap.
Bootstrap Email - Take the guesswork out of email design and CSS inlining inside of Rails Mailers. This gem allows you to use Bootstrap-like HTML structures, use a Bootstrap like design, and inline the CSS to work in most email browser/apps. Quite the timesaver!
money-rails - This will help standardize around common issues found when calculating money as well as providing a few template helpers.
Rack Mini Profiler - Everyone should know what their application is doing and where it is spending its time. This gem adds a profiler to the development pages and can include some nifty flame graphs when you really want to dig into the data.
rspec-rails, factory_bot_rails, simplecov - I personally like to use RSpec over the default Rails test framework. Though, the community can be quite divisive on testing tools! With every test suite, I include FactoryBot to easily spin up objects for those specs and SimpleCov to dig into my test coverage.
letter_opener - Still my #1 gem for working with email in a Rails app. In your local development, it catches the outgoing mail and opens in a browser, rendering it as it would an email.
Faraday or HTTParty - When I am looking to handle an extensive HTTP API or system, I will reach for the infinitely configurable Faraday. Still, when there are only a few HTTP interactions needed, HTTParty is super simple to use to make HTTP calls.

How to Build a Twitter Clone with Rails, ActionCable and React

Mon, 04 May 2020 00:00:00 GMT

Let me start by saying I think the things the teams working on CableReady and StimulusReflex are pretty awesome. They are aiming to make working with Reactive web applications as easy as the first Rails Blog tutorials during Rails’ infancy.

With all of that being said, I am someone who prefers a bit more explicitness and work with tools I already know (and well, a lot more developers in the ecosystem).

I am not a video guy, don’t have a video set up, and really prefer not to hear the sound of my own voice. So this will be done through words!

Without further ado, let’s get started with a new app:

rails new blabber --no-spring --webpack=react

Rails will do its thing, install the application, install the gems, process the Webpacker install, and install the NPM packages needed for React.

We can jump right into making a model to hold the data to clone what would be a tweet in this Twitter clone. All basic attributes:

rails g model Post username body:text likes_count:integer repost_count:integer

To keep this closely resembling the CableReady/StimulusReflex, we’ll add the same validation in the Post model:

class Post < ApplicationRecord
  validates :body, length: { minimum: 1, maximum: 280 }
end

We’ll make a few small adjustments to the generated migration file to add some database-level defaults (and allows us to keep the code around Post creation simple):

class CreatePosts < ActiveRecord::Migration[6.0]
  def change
    create_table :posts do |t|
      t.string :username, default: 'Blabby'
      t.text :body
      t.integer :likes_count, default: 0
      t.integer :repost_count, default: 0

      t.timestamps
    end
  end
end

Ok! Now, we’re ready to run that migration!

rails db:migrate

With the Model and Database layer out of the way, we can move on to the controller and corresponding view templates!

class PostsController < ApplicationController
  def index
    @posts = Post.all.order(created_at: :desc)
    @post = Post.new
  end

  def create
    Post.create(post_params)
    ActionCable.server.broadcast(
      'PostsChannel',
      Post.all.order(created_at: :desc)
    )
    redirect_to posts_path
  end

  def like
    Post.find_by(id: params[:post_id]).increment!(:likes_count)
    ActionCable.server.broadcast(
      'PostsChannel',
      Post.all.order(created_at: :desc)
    )
    redirect_to posts_path
  end

  def repost
    Post.find_by(id: params[:post_id]).increment!(:repost_count)
    ActionCable.server.broadcast(
      'PostsChannel',
      Post.all.order(created_at: :desc)
    )
    redirect_to posts_path
  end

  private

  def post_params
    params.require(:post).permit(:body)
  end
end

Simple controller. The index action returns a list of posts, to @post. create uses StrongParameters, creates a new Post, broadcasts a message over Websockets (more on that soon), and redirects back to the index template. like and repost are similar except they increment the respective count columns.

Let’s wire up a few routes to match up to those controller actions. Yes, these aren’t perfect RESTful routes, but 1) They work. 2) This is a 10-minute tutorial. 3) Are GET requests making sure we do not have to worry about AJAX/fetch/CSRF in the front-end. You would obviously work around these issues in a production application.

Rails.application.routes.draw do
  resources :posts, only: %i[index create] do
    get 'like'
    get 'repost'
  end

  root to: 'posts#index'
end

With a Model, Controller, and routes, we can put together some view templates. We’ll start by adding the action_cable_meta_tag and Bootstrap CDN CSS. This way, we can wire up some UI interfaces pretty quick!

<!DOCTYPE html>
<html>
  <head>
    <title>Blabber</title>
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>

    <%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
    <link href="https://stackpath.bootstrapcdn.com/bootstrap/4.4.1/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-Vkoo8x4CGsO3+Hhxv8T/Q5PaXtkKtu6ug5TOeNV6gBiFeWPGFN9MuhOf23Q9Ifjh" crossorigin="anonymous">
    <%= javascript_pack_tag 'application', 'data-turbolinks-track': 'reload' %>
    <%= action_cable_meta_tag %>
  </head>

  <body>
    <%= yield %>
  </body>
</html>

First up is the app/views/posts/index.html.erb:

<div class="container">
  <h1>Blabber</h1>
  <h4>A Rails, Actioncable and React demo</h4>

  <%= render partial: 'form' %>

  <%= react_component("PostsWrapper", { posts: @posts }) %>

</div>

react_component( is a view helper that is included in react-rails, a gem we will install in a minute. Even if you don’t use every feature in the gem, it offers a great way to include a component into an existing view file and the props for its first load.

Up next is a straightforward Rails form:

<%= form_with model: @post, local: true, html: {class: 'my-4' } do |f| %>
<div class="form-group">
  <%= f.text_area :body, placeholder: 'Enter your blab', class: 'form-control',
  rows: 3 %>
</div>

<div class="actions">
  <%= f.submit class: "btn btn-primary" %>
</div>
<% end %>

Alright, that is all we need with ERB files, no we can move onto the ActionCable pieces.

First, we’ll edit the Connection file to identify the Cable connection with the browser session ID:

module ApplicationCable
  class Connection < ActionCable::Connection::Base
    identified_by :session_id

    def connect
      self.session_id = request.session.id
    end
  end
end

Next, we’ll create a new Posts channel:

rails g channel PostsChannel

…and specify the channel we will be using in the stream by a string, PostsChannel:

class PostsChannel < ApplicationCable::Channel
  def subscribed
    stream_from 'PostsChannel'
  end
end

That does it for the Actioncable backend!

Next up us the React side of the application. As we installed React with the Rails application command, we can jump to making sure that react-rails gem in installed:

gem 'react-rails'
gem 'webpacker', '~> 4.0'

With the Gemfile update, we can install the gem, use its installer, and add a package to helper connect to ActionCable in functional React components.

bundle install
rails generate react:install
yarn add use-action-cable

Almost there! We have two React components to add. First up, is a wrapper component that will allow you to wrap your true child component in the ActionCableProvider, which provides access to ActionCable through a React Context:

import React from "react";
import Posts from "./Posts";
import { ActionCableProvider } from "use-action-cable";

export default function PostsWrapper(props) {
  return (
    <ActionCableProvider url="/cable">
      <Posts {...props} />
    </ActionCableProvider>
  );
}

Inside the provider, there it passes the props to a Posts component. The Post component:

import React, { useState } from "react";
import PropTypes from "prop-types";
import { useActionCable } from "use-action-cable";

const Posts = props => {
  const [posts, setPosts] = useState(props.posts);

  const channelHandlers = {
    received: data => {
      console.log(`[ActionCable] [Posts]`, data);
      setPosts(data);
    }
  };

  useActionCable({ channel: "PostsChannel" }, channelHandlers);

  return (
    <React.Fragment>
      {posts.map(post => {
        return (
          <div key={post.id} className="card mb-2">
            <div className="card-body">
              <h5 className="card-title text-muted">
                <small className="float-right">
                  Posted at {post.created_at}
                </small>
                {post.username}
              </h5>
              <div className="card-text lead mb-2">{post.body}</div>
              <a className="card0link" href={`/posts/${post.id}/repost`}>
                Repost ({post.repost_count})
              </a>
              <a className="card0link" href={`/posts/${post.id}/like`}>
                Likes ({post.likes_count})
              </a>
            </div>
          </div>
        );
      })}
    </React.Fragment>
  );
};

Posts.propTypes = {
  posts: PropTypes.array,
  header_display: PropTypes.string
};

export default Posts;

This might be the most complicated file in the whole tutorial! First, we set up some internal state for Posts. This allows us to set the incoming posts prop as the state, to update when ActionCable passes new posts from a broadcast. channelHandlers sets up the handler for this ActionCable subscription to handler new data. Finally, for ActionCable setup, useActionCable ties the handler and channel name into a new front-end subscription.

The return statement returns the JSX template for each post. It is mostly Bootstrap markup but does include two links to reach the earlier created controller actions. As GET requests, they will follow the redirect and reload the index template.

There you go, at this point, it should look like this!

There you go! I bet with a fast enough system to work through the Rails install, gem install, and javascript package installs, you could make it through this tutorial in less than 10 minutes!

Installing Ruby through RVM

Wed, 29 Apr 2020 19:00:08 GMT

I recommend visiting the RMV website (https://rvm.io/). Upon the browser rendering the RVM website, you find two simple bash commands you can use to install RVM. I opted not to print the commands in here as 1) a digital security measure and 2) may change as time goes on.

Once installed, we can begin installing the latest version of Ruby.

rvm list known

This command lists the current versions of Ruby available to install. There may be a lot on the list, but we can focus on the primary interpreter MRI plus, the latest version(2.6.x as of writing). Now, the command to install:

rvm install 2.6.5

Now sit back or grab a coffee as the install can take anywhere from 1 to many minutes to complete. This wait is based on Ruby package availability, system speed, and plenty of other factors.

Once the gems are installed, you can now set up a gemset. A gemset is a way to group installed gems into a particular RVM based folder. Gemsets keep different projects and their various versions of gems from interfering with each other. Although with Bundler, this isn’t a huge issue, it doesn’t hurt to take the extra step and keep your gems tidy. Additionally, this command instructs RVM to use the recently installed version of Ruby at the same time:

rvm use 2.6.5@sample_app --create

The extra --create flag tells RVM to create the gemset if it doesn’t exist(which it doesn’t).

Now that we finally have our Ruby and Gemsets in order we can install Rails. We are starting a new sample project to show you the basics of a new Rails app. Later we rerun this command for the SaaS app’s creation. Please refer to the RVM documentation if you want to dig deeper into any other features of RVM past the basics in this chapter.

Setting up Rails and PostgreSQL

Wed, 29 Apr 2020 19:00:08 GMT

When building a production-ready application with Rails, the most popular database to use is PostgreSQL. However, Rails via ActiveRecord does support a few databases out of the box. These databases include PostgreSQL, MySQL, and SQLite3. Rails can support other databases through gems and their ORM.

Since it is most likely you are using both PostgreSQL and MacOS(OSX), I recommend just installing Postgres.app. Simply head to the postgres.app site. Then download and follow the simple instructions to have a PostgreSQL server and library installed on your box.

Another option you may use if you are skilled in the terminal is to install through Brew. Once you have Brew on your system, you can run brew install postgresql and follow the post install prompts.

`rails new` with pg

By default, Rails uses SQLite3 for development databases. This database type is used to ease install and development. However, since you are building an app that you intend to deploy, you are going to use PostgreSQL in all of your environments. When initializing a new Rails app, it is quite easy to change the default database type or other default settings.

rails new app_name -T --database=postgresql

After a minute or two, Rails will have installed all the required files for the base application. Rails then installed the base gems and ran a few other shell commands to get your application started.

Database Configuration

If everything in the install went correctly, you would be able to use a Rails command to create the database on your local PostgreSQL instance.

To be safe, take a look at the database configuration file and see what is in there. The database configuration file config/database.yml comes with information about installing the pg gem. Along with other option settings, you may change if you deviate at any point with your PostgreSQL setup. Here is the relevant development connection information:

default: &default
  adapter: postgresql
  encoding: unicode
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>

development:
  <<: *default
  database: app_name_development

Here Rails is setting up a shared configuration between all environments setting the adapter type, encoding, and connection pool settings. None of this is relevant to the default usage of Rails, but you may need to change this at some point in your application’s lifetime.

The development block specifies to use the default settings and also use a database_name of app_name_development. The default naming for Rails databases is appname_environment. Meaning your test database name would be app_name_test and so on.

Now, let’s change our directory to that of the Rails app and create the database for Rails to use.

cd app_name
rails db:create

How to get the names of all the files in a folder in Ruby

Thu, 23 Apr 2020 00:00:00 GMT

When it comes to working with directories Ruby comes with a class for dealing with directories and paths. Ruby Dir Doc Page.

If you want a quick demo of how to get the names of files in a directory, look no further!

## Gets the current path of your Ruby script/console
Dir.pwd

## ["array.rb", "of", "files.rb", "and", "folders"]
Dir.children(Dir.pwd)

You can also provide an instance a directory(Dir instance or string of file/folder name)

Dir.new(Dir.pwd).each {|f| puts "Got #{f}"}
Got .
Got ..
Got app

Rob Race's Dev Zone | Articles

Print Smarter in Ruby - Know When and How to Use Each Method

puts: Standard Output with Automatic Newlines

print: Continuous Output Without Newlines

p: Debugging with Inspect Output

pp: Pretty Print for Enhanced Readability

y: YAML Output in IRB

Quick Summary

awesome_print: Enhanced Pretty Printing with Style

Installation

Usage

Avoiding N+1 Queries in Rails: Easy Performance Wins for Beginners

What is an N+1 Query?

How to Detect N+1 Queries

1. Check Your Logs

2. Use the bullet Gem

How to Fix N+1 Queries

Use Eager Loading with .includes

When to Use .joins or .preload

Common Mistakes and Gotchas

Real-World Example

Preventing N+1s Going Forward

How to Build a Twitter Clone with Rails 8 Inertia and React

Adding Sign Up to the Rails 8 Authentication Generator

Prerequisites

Adding Sign Up

Route

Controller

View

Form Submission

Bonus Idea

Leveraging Turbo 8: Best Additions to Implement in Rails 8 Projects

Setup

Turbo Morph

Presence Channel

Typing Indicators

Conclusion

Rails Console in the Browser (on-demand)

Why in the browser?

How to set it up

Taking it a step further

Alternate Idea

How to Build a Twitter Clone with Rails 8 and Turbo 8

How to get a User's Timezone into Rails

How to Build a Twitter Clone with Rails and Hotwire

How to Build a Twitter Clone with Rails and Hotwire

Using Action Mailbox in Rails 6 to Receive Mail

How to inspect a Ruby Object

Printing an Object

Inspecting an Object

Integrating Bootstrap 4 into Rails 6

Webpacker

Running A Webpack Dev Server

What is webpack-dev-server?

Final Webpacker Setup

The Application Pack

Why require and not import

The Application Stylesheet

19 Must-Have Gems for 2020

How to Build a Twitter Clone with Rails, ActionCable and React

Installing Ruby through RVM

Setting up Rails and PostgreSQL

rails new with pg

Database Configuration

How to get the names of all the files in a folder in Ruby

`puts`: Standard Output with Automatic Newlines

`print`: Continuous Output Without Newlines

`p`: Debugging with Inspect Output

`pp`: Pretty Print for Enhanced Readability

`y`: YAML Output in IRB

`awesome_print`: Enhanced Pretty Printing with Style

2. Use the `bullet` Gem

Use Eager Loading with `.includes`

When to Use `.joins` or `.preload`

What is `webpack-dev-server`?

Why `require` and not `import`

`rails new` with pg