While many modern languages offer similar features, Ruby consistently delivers a seamless and joyful experience. Whether you're building a startup MVP, a scalable enterprise application, or a lightweight API, Ruby has you covered with frameworks like Rails and Sinatra.

Despite the growing popularity of JavaScript and Python, Ruby remains a valuable language to learn, not just for its utility, but for how it teaches you to write clean, expressive, and maintainable code.

If you've heard of Ruby but never used it, this tutorial is the perfect starting point. Designed to be completed in an afternoon, it offers a glimpse into what makes Ruby so beloved by developers. While it doesn't cover every aspect of the language, Ruby's intuitive nature ensures you'll be well prepared to dive right into frameworks like Sinatra or Rails after completing it.

Code Playbacks

Code playbacks are a unique way to learn about programming. They are guided walkthroughs of code, allowing you to see not just the code itself but also the thought process behind it. This approach helps you understand not only what the code does, but why it was written that way. Here is a short video to show how to move through a code playback:

By registering on Playback Press, you’ll gain access to an AI assistant that can answer your questions about the code. This makes learning even more interactive and personalized. Watch this video to see how to work with it:

A Brief Introduction to Ruby

You can find my entire collection of Ruby code playbacks in my free book, "A Brief Introduction to Ruby". Here's a quick look at what you'll learn:

Highlights

• 1.1 Hello Ruby!!!: Write your first Ruby program and learn how to run it from the terminal.

• 1.2 Variables and Types: Explore Ruby's variables, constants, and string interpolation.

• 1.3 Selection and Looping: Master control flow with if statements, loops, and ranges.

• 1.4 Arrays: Work with arrays, one of Ruby's most versatile data structures.

• 1.5 Hashes: Learn about hashes, Ruby's equivalent of dictionaries or associative arrays.

• 1.6 Methods: Write reusable code with methods, parameters, and return values.

• 1.7 Closures: Discover how to pass code into methods and execute it with yield.

• 1.8 Iterators: Simplify data iteration with Ruby's powerful higher-order methods.

• 1.9 Classes in Ruby: Build objects with classes, instance variables, and inheritance.

• 1.10 Interacting Classes: Create cooperating classes and explore Ruby's "duck typing."

• 1.11 Unit Testing in Ruby: Write tests to ensure your code works as expected.

Conclusion

Ready to start your Ruby journey? Begin with the first playback and experience how fun and intuitive Ruby can be. Whether you're a complete beginner or an experienced developer, there's something here for everyone!

I’d love to hear your thoughts! Feel free to share your comments, questions, or feedback via email: mark@playbackpress.com. Your input helps me improve and create even better content.

If you’ve found this tutorial helpful, consider supporting my work through GitHub Sponsors. Your contributions help cover hosting costs and keep Playback Press free for everyone. Thank you for helping me continue creating educational resources for the developer community!

Creating a category page is essential for most web applications these days. Different kinds of applications like blogs, ecommerce sites, movie streaming platforms, and many others have category features.

This article will show how to add categories to Ruby on Rails applications.

This is a beginner-friendly tutorial, so you can follow along even if you have very basic Ruby on Rails knowledge.

How to Generate the Blog Scaffold

Let's first create a new Rails project. Here, we will be using Rails version 6.1.7 and Ruby version 3.0. You can create the new Rails project using the command below:

rails new blog_categories

Now, let's create the new blog scaffold using the following command:

rails g scaffold blogs title:string description:text

This command will create all the necessary files for us to work with the blog's CRUD operations with two database fields title and description. Here, the title is the string field and the description is the text field.

You now need to run the migration with the rails db:migrate command.

Now, head up to your terminal, start the server, and visit the /blogs page. You can see the following result on the browser.

creating blogs

How to Generate the Categories Scaffold

Now, we have come to the main part of the tutorial which is to add categories to our blog articles.

For that, let's create the categories scaffold now with the command below:

rails g scaffold categories name:string

This command will create CRUD for the categories.

Also, you will need to run rails db:migrate to update the schema.

How to add an association between the blog and category models

Next, you need to add an association between the blog and category models.

In Blog.rb:

class Blog < ApplicationRecord
    belongs_to :category
end

And in `Category.rb`:

```ruby
class Category < ApplicationRecord
    has_many :blogs
end


Now, you need to add the `category_id` to the `blogs` table since each blog is associated with a category. You can go to your terminal and add the following migration:

```ruby
rails g migration add_category_id_to_blogs

This will create a new migration. You need to add the following code in this migration file:

add_column :blogs, :category_id, :integer

Rails has its own set of conventions and rules. And it's smart enough to recognize that this migration is to add a new database column named category_id to the blogs table.

You now need to pass category_id as a strong parameter in the blogs controller.

def blog_params
    params.require(:blog).permit(:title, :content, :category_id)
end

Now, let's create a few categories from the browser.

creating categories from the browser

You could also add some validation while creating category. For that, you can update the category.rb file with the following code:

```ruby class Category < ApplicationRecord validates :name, presence: true, uniqueness: true has_many :blogs end

This will add few validations as shown in the GIF below:

adding validations while creating categories

How to display categories as a dropdown in the new blogs page

Now that you can create both blogs and categories, you'll need to display all categories as a dropdown when someone visits the new blog page.

The code for that is shown below:

```ruby

The select tag creates the dropdown selection box. The options_for_select takes a few arguments.

First, it maps through all categories and returns an array of [c.category, c.id]. The category name gets displayed as a dropdown and the category id of any category the user selects gets passed to the controller. The controller then performs the database insertion for blogs.

You can go to the new blogs URL and create blogs with categories.

creating blogs with categories

Listing each category's blogs

The next part of this tutorial will show you how to list all categories and all blogs associated with each category. We will be displaying this on the categories index page.

For that, you need to add some code in the categories index view.

```ruby

<%= notice %>

Categories

<%= link_to 'New Category', new_category_path %>

Here, it's iterating through all categories in order to display each category's name. After we are done with displaying the category name, the next part is to display all blogs associated with each category. So, you can iterate through category.blogs from which you can get the blog records.

If you visit the /category route, you can see all categories with their blogs as displayed in the GIF below.

listing each category with blogs

Conclusion

In this tutorial, you learned how you can add categories in your Ruby on Rails applications using one-to-many associations.

If you liked this article, please consider buying me a coffee ☕.

You can find me on Twitter for various content related to Web Development.

Thanks for reading.

Happy Coding.

Polymorphic association in Ruby on Rails refers to the type of active record association. From the Rails Guide, it allows a single model to belong to more than one other model on a single association.

This tutorial assumes that you have some knowledge of a few associations in Rails like the belongs_to, has_one, and has_many associations.

It is a slightly more advanced type of association but it's perfect when you want to connect a model to multiple other models.

The Problem with Not Using Polymorphic Associations

Suppose you want to create an app with features like posts, a forum, and event functionality.

In the initial stage of your app, you might plan to add a comment feature to just the posts model. But as your app grows, you might want to add a similar comment feature to the forum and event models as well (maybe for other models, too, along the line).

Let's see how this would look in the picture below:

Passing comments to posts, event, and forum models

Every time you want to add something that has comments in the app, you have to add a foreign key to the comments table. You would end up writing lots of repetitive code in this process.

This might not be a problem for small applications, but as your app grows this can be a huge issue. And this is where polymorphic associations come in super handy.

How Polymorphic Associations Helps Solve This Problem

The solution to the above problem is to use polymorphic associations in Rails. This lets you define a single model which can belong to other different models without having to write repeated code.

Considering the above example, you do not have to add the foreign key to the comments table every time you have to add comments to other models.

With polymorphic associations, you can add just two columns in the comments table, which is very straightforward. Let's see how it works in the next section of this article.

How to Implement Polymorphic Associations

To create the new PolyComment model, we will be using the following command:

rails g model PolyComment content:text commentable:references{polymorphic}

Let's check the PolyComment model now:

``` ruby class PolyComment < ApplicationRecord belongs_to :commentable, polymorphic: true end

The migration file will look like this:

```ruby class CreatePolyComments < ActiveRecord::Migration[6.1] def change create_table :poly_comments do |t| t.text :content t.references :commentable, polymorphic: true, null: false

t.timestamps end end end

Now, let's run the migration using the rails db:migrate command to update the schema which will have two additional interesting columns.

```ruby create_table "poly_comments", force: :cascade do |t| t.text "content" t.string "commentable_type", null: false t.integer "commentable_id", null: false t.datetime "created_at", precision: 6, null: false t.datetime "updated_at", precision: 6, null: false t.index ["commentable_type", "commentable_id"], name: "index_poly_comments_on_commentable" end

The columns commentable_type and commentable_id help setup the polymorphic associations.

commentable_type stores the name of models like Event, Post, or Forum in this case. And commentable_id stores the id that corresponds to that model.

Now, let's generate the three models with the following commands:

rails g model Post title

rails g model Event title

rails g model Forum title

Now, we need to add has_many relationships in these three models:

Post.rb ```ruby class Post < ApplicationRecord has_many :poly_comments, as: :commentable end

Event.rb ```ruby class Event < ApplicationRecord has_many :poly_comments, as: :commentable end

Forum.rb ```ruby class Forum < ApplicationRecord has_many :poly_comments, as: :commentable end

You can add comments to as many models as you want based on the above logic.

How to test it in the console

Now, let's play around with the console to test the results:

Creating new post

Here, we have created a new Post.

Adding Comment to Post

Here, you can see that the value of commentable_type is Post (in the form of a string) since it is associated with the Post model. Also, the value of commentable_id is 1 since it matches the id of the respective object.

This is how you can add comments for any models you want.

Conclusion

Polymorphic associations make your code DRY (Don't repeat yourself) and bug-free. If you want to connect a model with multiple other models then the polymorphic associations will be a great choice. Using this approach, you do not have to define a separate association for each model.

If you liked this article, please consider buying me a coffee ☕.

You can find me on Twitter for various content related to Web Development.

Happy Coding!

Nowadays, most web applications have a search feature. Users can use the search feature in order to navigate websites more easily.

Implementing a search feature in Ruby on Rails is very easy. By using only a few lines of code you can set it up.

This tutorial assumes that you have basic knowledge of Ruby on Rails. If you need an introduction to the framework, check out this course.

What Will We Be Creating

By the end of this article, we'll have a web app with a search feature that looks like this:

Demo of the app

How to Generate the Post Scaffold

Here we're using Ruby version 3.0 and Rails version 6.1.7.

Rails scaffold refers to the automatic generation of files that forms the basic structure of the rails project. These files include controllers, views, models, routes, and migration.

Now, let's scaffold the post using the following command:

rails g scaffold post title description:text

Now, you need to run the migration in order to update the schema using the rails db:migrate command.

If you run the server now, you can perform all the CRUD operations in the project.

How to Add Haml to the Project

You will be using haml in views instead of erb. You can do this by simply adding gem 'haml', '~> 6.1', '>= 6.1.1' in the gemfile. You can get all gems from the https://rubygems.org/ website.

Haml uses indentation and its main purpose is to make the markup look beautiful.

Now, you can use the haml extension in views instead of erb. So, you can rename application.html.erb to application.html.haml. You can also use html to haml tools for converting erb to haml files.

How to Build the Search Form

Once that's done, you're at the main part of the tutorial. So, let's add the form in the application.html.haml file.

```ruby %body %form{action: "/search"} %input{placeholder: "Search",name: "key",type: "text"} %button{type: "submit"} Search = yield

This code will generate a form in the whole application.

Here, you are passing the action attribute which will redirect to the search page when the form is submitted. Also, you are passing the key as the name attribute for the input element.

If you submit the form now you will get the following routing error:

Screen recording showing the routing error.

How to Add Root and Search Routes

Let's add a few routes in the routes.rb file.

```ruby root "posts#index"

get '/search', to: "posts#search"

The first route makes the index view the root page.

The second route adds the search route as a get method. So, you need to create a search action with some SQL queries in the posts controller.

How to Add the Search Action in the Controller

In the above route, the search route is looking for search actions in the posts controller. So, let's create it.

```ruby def search key = "%#{params[:key]}%" @posts = Post.where("name LIKE ?", key) end

Here, in the search action, the key variable holds the value of params[:key]. You get the value of params[:key] after the form submission.

The % symbol matches zero, one, or multiple characters. The above code uses two % symbols before and after params[:key] to match the value of params[:key] present in any position with the name column records in the database.

It is using the LIKE operator with a where clause in order to perform a search. ? is a placeholder value in queries and gets replaced with whatever arguments get passed – for example, key in this case.

Additionally, you can also use the or operator for searching multiple columns in the database.

@posts = Post.where("name LIKE ? or description LIKE ?", key, key)

You can search for both the name and description records using the above code.

How to Add the Necessary Views

Next, you need to add a search.html.haml file. But before that, let's create a new partial called _post.html.haml file in order to reuse the code. The post partial will look like this:

```ruby

%tbody -@posts.each do |post| %tr %td= post.name %td= post.description %td= link_to 'Show', post %td= link_to 'Edit', edit_post_path(post) %td= link_to 'Destroy', post, method: :delete, data: { confirm: 'Are you sure?' } %br/ = link_to 'New Post', new_post_path

This is how the search.html.haml file will look:

```ruby

%h1 Search Results %p#notice= notice %h1 Posts %table %thead %tr %th Name %th Description %th{colspan: "3"} =render "post"

And, you need to update the index.html.haml file as well.

```ruby

%p#notice= notice %h1 Posts %table %thead %tr %th Name %th Description %th{colspan: "3"} = render "post"

By doing this, you are using the post partial in both index and search view.

Finally, the search feature works as expected.

You can find the full source code of this project in this GitHub repository.

Conclusion

This is how you can create a search feature in a Rails application.

If you liked this article, please consider buying me a coffee ☕.

You can find me on Twitter for various content related to Web Development.

Thanks for reading.

We've released a full course on the freeCodeCamp.org YouTube channel that will help you learn Ruby on Rails by building a friends list app.

The course was created by John Elder from Codemy.com. John has written two best-selling Ruby on Rails books and has created many video courses.

In this course you will build an app that keeps track of your friends' contact information. You will learn how to implement CRUD functionality. CRUD stands for Create, Read, Update, and Destroy and is used in almost all web apps.

Here are the topics covered in this course:

• Introduction and Installation
• First Webpage and MVC Overview
• Application Partial Links and New Pages
• CRUD Scaffold
• Style App with Bootstrap
• Style Devise Views
• Associations
• Style Modifications
• Fun With the Controller
• Git, GitHub, and Heroku

Watch the full course on the freeCodeCamp.org YouTube channel (4-hour watch).

In this article, I'll share some of the plugins that I use to make development with Ruby on Rails easier and more fun.

Why use these tools?

Development tools play a significant role in a developer's life. If you are a junior developer and are just getting started working on projects, then knowing about the appropriate tools is a must.

These tools can save you a lot of time and they allow you to code more efficiently and thus increase your productivity.

If you are Ruby on Rails developer who's looking for free development tools, I would recommend Visual Studio. It has a ton of plugins, like the ones mentioned below, and they have helped me increase my productivity a lot.

Note: All visual studio plugins are available on the Visual Studio Marketplace for free.

So let's dive in.

Ruby

With ~1.3M downloads, this is one of the most popular plugins for Ruby. It provides enhanced Ruby language and debugging support.

With enhanced debugging support, developers can set breakpoints and inspect the local and global variables in debug mode. This helps to debug any issues easily and in quick time.

This plugin also supports code formatting via rubocop which is very much needed when you are working with team of developers to maintain consistent code format.

Ruby plugin has the following features:

• Automatic Ruby environment detection with support for rvm, rbenv, chruby, and asdf

• Lint support via RuboCop, Standard, and Reek

• Format support via RuboCop, Standard, Rufo, and RubyFMT

• Basic Intellisense support

• Ruby debugging support

Source: Ruby

Rails

This is another popular plugin for Rails which provides enhanced Rails support.

ERB HTML templating is widely used in Rails ecosystem as views to render HTML pages for websites. The Rails plugin has support for the .erb syntax and also provides auto-completion for popular HTML tags like stylesheet, meta tags, asset tags, and so on.

This plugin also helps to switch between Rails views (*.erb files) easily. It also helps you see online documentation of any methods or commands easily side by side.

Here are some of the features this plugin supports:

• Ruby on Rails “Asset Helpers” and “Tag Helpers” snippets.

• .erb syntax highlights.

• Navigation between related files through command.

• Go to Definition.

• View path suggestion, Model’s static method suggestion, and Model’s field suggestion.

• Open the online document to the side through command.

Source: Rails

Image from VSCode Rails

Ruby Solargraph

Ruby Solargraph is one of the most helpful plugins on this list, and provides IntelliSense, code completion, and inline documentation for Ruby.

Inline documentation helps you view all the allowed methods of the class/object, and also helps you easily understand the definition of each method and its arguments.

This is one of the plugins I have personally used many times to refer to a Ruby method's documentation, arguments for a method, and so on.

Image from VSCode Solargraph

Vscode Endwise

This is my favorite extension that can save you a lot of time and headaches. This extension automatically adds end to all your Ruby code blocks.

Image from VSCode Endwise

Rails Db Schema

This plugin helps you define a DB schema and also enables auto-completion for Rails DB schemas.

While defining schemas or creating tables for any Entity, this plugin enables and autocompletes syntax for all your DDLs (Database definition language) like create_table, create_index, delete_table, update_table, and so on.

Image from VSCode DB Schema

It helps in autocomplete of all attributes of any database entity. For example, if User has email, name, and date_of_birth attributes, this plugin will automatically detect the definition of entity and autocompletes its attributes when you type User.

Image from VSCode DB Schema

Why use Visual Studio?

There are many other IDE options for Ruby on Rails developers like RubyMine (the enterprise version), Sublime, Vim, and so on.

But my personal favorite is Visual Studio as it has extensive plugin support for multiple languages like Golang, PHP, Node.js, and more. So it's the default IDE, especially for polyglot developers.

Even though visual studio lacks few features compared to RubyMine like getting support for the latest Rails version updates, it covers the majority of the features required for development via community plugins.

If this article was useful, please share it with your network. Also, follow me on Twitter to know when I publish my next article.

Ruby on Rails is an opinionated framework, and emphasizes the use of convention over configuration (CoC), and don't repeat yourself (DRY) practices. Rails can best be described as a model-view-controller (MVC) framework, and provides sensible defaults and structures for rapid application development. Lately, Rails has integrated an API module to make the creation of web-services faster and easier.

Ruby on Rails was created by David Heinemeir Hansson and is currently on it’s 6th version.

How to install Rails

Rails is downloaded in the same way as any other Ruby gem: with the gem install command. Before we download it, we’ll need to download Ruby. Afterwards we’re only 3 words away from starting with Ruby on Rails:

$ gem install rails

Rails ships with sqlite3 as the default database, which is a simple file on disk. You need to install MySQL or PostgreSQL if you want to use something more robust.

How to create a Rails application

1. After you install Ruby on Rails, it’s very simple to create a brand new application, we’ll just need 3 more words:

$ rails new your_application_name

2. If you want to use MySQL:

$ rails new <application_name> -d mysql

3. If you want to use Postgres:

$ rails new <application_name> -d postgresql

4. This command will create a folder with the _your_applicationname you informed in the last command. Next step is to go to the new directory you’ve just created:

$ cd your_application_name

5. Get the necessary gems and software packages before running your application:

$ bundle install

6. To run the rails server and see if everything went accordingly is also fast:

$ rails server

It couldn’t be anymore simple! Well, this isn’t actually 100% true, we could make it even smaller by reducing the rails server command to:

$ rails s

7. Now with your preferred browser, go to http://localhost:3000 and you’ll see: “Yay! You’re on Rails!”

Alternative method for creating a Rails application

1. Create a new directory:

$ mkdir <application_name>

2. Go into the new directory:

$ cd <application_name>

3. Create the Rails application using the Unix dot notation. This results in assigning the name of the directory to the new application:

$ rails new .

4. Start exploring the framework of the application you just created. To see a useful table of the folder structure, check out Getting Started with Rails.

Convention over Configuration

Convention over Configuration means a developer only needs to specify unconventional aspects of the application. For example, if there is a class Sale in the model, the corresponding table in the database is called sales by default. It is only if one deviates from this convention, such as calling the table “products sold”, that the developer needs to write code regarding these names. Generally, Ruby on Rails conventions lead to less code and less repetition.

What is MVC?

Model (Active record) contains the business logic and interacts with the database. Views (Action views) all of the HTML files and structure. Controller (Action controller) interacts with the views and model to direct the actions of the application.

DRY - Don’t Repeat Yourself

Don’t repeat yourself means that information is located in a single, unambiguous place. For example, using the ActiveRecord module of Rails, the developer does not need to specify database column names in class definitions. Instead, Ruby on Rails can retrieve this information from the database based on the class name.

Ruby on Rails is open source

Not only is it free to use, you can also help make it better. More than 4,500 people have already contributed code to Rails. It’s easier than you think to become one of them.

You've likely heard about Docker terms like containers, images, services, volumes, network, Dockerfile, docker-compose file, right? Or you've watched some videos about what it is, but you're not sure how can it apply to your daily life as a developer?

That's what I first thought after watching videos about Docker. Not only can Docker run web-apps, servers, and databases, but it can also be a local development environment! I wrote this article not only so you can learn how to do it, but also for me, so I won't forget it. Let's get started!

Table of Contents

• Why Docker?
• Installing docker and Ignorefiles
• Dockerfile and Docker-Compose
• Building and Running the Container
• Making new rails app and starting the server
• Cleaning up
• Conclusion and repo

Why Docker?

Why use docker? Why not just install it on your local machine, and install Ruby Version Manager (rvm) or Ruby Environment (rbenv)?

Setting up Ruby On Rails with with these tools is great. It took me over 3 hours of installing, troubleshooting, and searching the documentation to get it working. But recently, I got my mac reformatted. But I didn't list or take note of the websites I've visited to make it work on my machine. I forgot how to install it again and it's a pain to repeat the steps.

This is where Docker shines. Install docker, load your dockerfiles, run a few commands in your terminal, you're already setup! And also, what if you want to uninstall all that you did? It's hard to track what steps to undo. With Docker, it's just a few commands to cleanup.

When I was watching an online tutorial about docker, Dan Wahlin, the teacher, said that one of the benefits of docker is to accelerate developer on-boarding. Dan said in his tutorial:

"Docker can help there because we can make one or more images that can then be converted into running containers, and those containers can run on our different developer, and even designer machines."

Let's say you have a team of developers, designers, and testers, and have an app with a back-end server, database server, and caching server. You have 12 clean slate machines, with a combination of linux and mac computers. Do you really want to go install, troubleshoot, and follow varying installation instructions that depend on the machine? Then make the pieces work, one-by-one on every machine, without the assurance of they won't encounter any varying errors along the way?

This is why I took time to study Docker. With a few commands and a few lines of a configuration file, you're already setup. In the next section, we'll get our hands dirty with docker setup.

Installing Docker and including Ignorefiles

1. Install Docker

I'm not gonna talk much about installing docker, there are many videos out there. But usually, it's just download and open the installer, register an account on dockerhub, and you're good to go. Check out Docker installation docs.

2. Make a .dockerignore file

What is a dockerignore file? Dockerignore file just tells Docker which files to ignore in it's container. An example is when you have a minified assets, js, css files, that gets changed from time to time whenever you change the original code. This also applies to gitignore files. Usually, the list of recommended files to ignore are usually found in the internet. You can copy this gist on your own .dockerignore .

And if you use git, put this snippet of code in your .gitignore.

The look of your project folder will look similar to this.

The ignorefiles are a little bit lenghty that's why I just put links.

Dockerfile and docker-compose file

This is where most of the operation happens. Think of these two files as set of instructions Docker follows on how to setup your virtual container. Dockerfile and docker-compose file works hand in hand. You can have multiple Dockerfiles for different services, and one docker-compose file to tie them up together.

3. Make a file named Dockerfile

A Dockerfile is a file with set of rules you'll set that docker will follow. There are pre-built set of rules found on Docker hub. An example is pre-built installation instructions for MySQL, or PHP, or Node.js. After making your Dockerfile, put this code on your Dockerfile. And I'll go through a brief explanation on what does these lines do.

FROM ruby

WORKDIR /home/app

ENV PORT 3000

EXPOSE $PORT

RUN gem install rails bundler
RUN gem install rails
RUN apt-get update -qq && apt-get install -y nodejs

ENTRYPOINT [ "/bin/bash" ]

• FROM ruby - this means docker will pull a pre-built setup by ruby. You don't need to think about updating or installing on your machine the latest ruby version. You'll see the list of Docker's pre-built images on their Dockerhub. Think of it as like npm.
• WORKDIR /home/app - Work directory. Work directory means this is be your default folder location when you start your development environment. You can name it whatever you want.
• ENV PORT 3000 - Environment variable. This will set a variable named $PORT on your bash terminal to be '3000'.
• EXPOSE $PORT - expose port 3000 (that we've set earlier) of the virtual container to your local machine.
• RUN - Run commands are some setup instructions that you want the terminal to run before you use it. In our case, we installed ruby on rails, bundler, and node.js before we even use the development environment so it's all ready when we use it.
• ENTRYPOINT ["/bin/bash"]- this command tells docker what command to execute when we run the container. In our case, we need to run bash terminal so we can have access to rails.

Note that these explanations are only brief. You can see more explanations or you can do your deep-dive on Dockerfile reference docs.

Your Dockerfile will look like something like this.

You can do sorts of cool stuff with Dockerfile. In my case, I've tried to install zsh and oh-my-zsh on my container because it has some cool auto-completion features. But in our example we don't really need it, it will only increase our image size, so I didn't include it.

4. Make a file named docker-compose.yml

Docker compose file is a file that ties up different services together. A good example is when you're wiring up your rails app to different servers like MySQL database server, or redis caching server. You can easily make them work with this file. But for our case, we'll stick to the minimum setup for clarity purposes. A YAML file is a type of markdown file with different rules on how to format your file. Just think of it as a JSON file, without the braces. Put this in your docker-compose.yml file.

version: "3.7"

services:
  ruby_dev:
    build: .
    container_name: ruby_container
    ports:
      - "3000:3000"
    volumes:
      - ./:/home/app

As you can see, it kinda looks like the Dockerfile, but with a little bit of indentation. Let's go through the lines.

• version - Through time, docker-compose file went through changes. That's why in docker-compose files, they need to specify which version they are using. In our case we just use the latest version as of this time.
• services - Specify list of services. As I said earlier, you can have many services like a rails server, and a MySQL server on your project. You can name your services any name you want. I named it ruby_dev.
• build: . - The dot here means a file path where to find the Dockerfile, which is the build instructions.
• container_name - The name of the container.
• ports: - these are the ports to expose from the docker container to our host local machine. The pattern here is HOST:CONTAINER. In our case it's "3000:3000". Which means we are letting the default Rails server port (3000) be available in our local machine's "localhost:3000".
• volumes: - volume means even if we quit or delete Docker, we can specify which files we can keep in our local machine. We put ./:/home/app there because we named in our Dockerfile earlier the workdir to be /home/app.

You can see more explanations on Docker Compose reference docs.

Your docker-compose.yml will look like something like this.

Building and running the container

With all our config files setup, let's build and run the container! After the loads of terms we encountered, building and running the container is way simpler. It will only involve few commands.

5. In your terminal, run docker-compose build

Running this command will get Dockerfile and install all the necessary things to make a rails development environment. Note that the installation may take a while because docker will need to download the necessary packages.

6. In your terminal, run docker-compose run --rm --service-ports ruby_dev

This command will start a bash terminal that will be your rails development environment where the rails commands are available. With only these two commands, and two config files, you already have a rails environment without even going through a log of troubleshooting! Notice that our command has some flags, --rm means remove the container after using it, and --service-ports means use port 3000 in our container so we can see our rails server in action. The name ruby_dev also came from services found at our docker-compose.yml.

Your terminal might look like this after running the run command. Check if there's rails by running rails -v command. Versions might vary.

Test-run a rails app

Now that we've successfully made our rails development environment, we'll test a sample rails app.

1. Run rails new myapp && cd myapp

This command will create a new rails app in a folder named myapp. After that the terminal will go the folder. You can name it whatever you want.

2. Update and install gems. Run bundle update && bundle install

Just make sure you're in the right folder, in myapp, which contains the rails app files. This command will update and install your dependencies.

3. Test the server by running rails server -p $PORT -b 0.0.0.0

Remember the port we specified in our Dockerfile before? This is where we can use it. In our case, rails will use port 3000 to start the server. Don't forget to put -b 0.0.0.0 because you won't see the app on your local machine without this.

Hello rails splash screen. Yeah rails!!!

4. Stop the server by pressing ctrl-d on your keyboard.

Cleaning Up

After you're done with everything, you can exit on your container by running exit on your container's bash terminal. The --rm flag you typed before will remove the container, but will you get to keep your ruby on rails files.

Run docker-compose down to cleanup

Cleaning up is when you're done with the project, and you want to remove your dev environment so you can save space. If you're really done, you can use this command. Docker will remove all your setup, and the images you downloaded. This so powerful, because, imagine you followed a lot of steps and a lot of installation on your mac. The only way to remove that setup is to uninstall them one by one. With docker on our side, it's just one command. Aww yeah!

Conclusion

Glad you made this far! Let's look at the big picture. Setting up a dev environment in Docker can be broken down in 2 steps:

1. List the instructions you need on your Dockerfile and docker-compose file.
2. Start or stop or cleanup your dev environment with the docker-compose command.

This is a big win for us. You just need to keep the Dockerfile and compose file and whenever you switch machines, you just run two commands! Setup once, and forget.

Repository

You can see the repository on how the setup looks like, and additional commands that you need here by checking out the full github repo here.

If you find the article helpful, or if you have some additional questions, throw it in the comments. I'll be glad to help!

This article was written by Jonathan Cunanan on freeCodeCamp News.

? Twitter - ? freeCodeCamp - ? Portfolio - ⚛️ Github

The first time you open your terminal and write rails new the sheer number of files and folders that are created can be overwhelming. You may even work on numerous Rails projects without ever opening many of these folders - so what exactly are they? What are they doing behind the scenes?

Well, the truth is that you don’t need many of them and Rails has several flags built into the new command which will allow you to create a new project without some of the built-in defaults of Rails (to learn more just type out rails new —help). That said, for most projects you’ll be running rails new and creating a beastly project folder.

In this post I’m going to go through every single file and folder in a new Rails 6 project. Feel free to use this as a reference as you are working through your new Rails project to understand some of the more obscure folders. Bookmark this post and return to it anytime you find yourself in the weeds on a new Rails project.

So let's start:

rails new example-project

Wow, that’s a lot!

First, Rails is creating all the files and folders required by a new Rails app.
Then it’s fetching gems and bundling them; these are the dependencies that Rails needs in order to run your website in its simplest iteration. Seem like a lot? To some extent it is but these gems add the functionality that makes a Rails project so easy to get off the ground. Essentially all you need to do now is run rails server and you have a webapp running locally: that’s pretty powerful and not something you can get so easily /without/ all that boilerplate.

Let's get into all those folders:

  create README.md
   create Rakefile
   create .ruby-version
   create config.ru
   create .gitignore
   create Gemfile
     run git init from "."
Initialized empty Git repository in /Users/tfantina/Documents/Code/FileStructure/.git/
   create package.json
   create app
   create app/assets/config/manifest.js
   create app/assets/stylesheets/application.css
   create app/channels/application_cable/channel.rb
   create app/channels/application_cable/connection.rb
   create app/controllers/application_controller.rb
   create app/helpers/application_helper.rb
   create app/javascript/channels/consumer.js
   create app/javascript/channels/index.js
   create app/javascript/packs/application.js
   create app/jobs/application_job.rb
   create app/mailers/application_mailer.rb
   create app/models/application_record.rb
   create app/views/layouts/application.html.erb
   create app/views/layouts/mailer.html.erb
   create app/views/layouts/mailer.text.erb
   create app/assets/images/.keep
   create app/controllers/concerns/.keep
   create app/models/concerns/.keep
   create bin
   create bin/rails
   create bin/rake
   create bin/setup
   create bin/yarn
   create config
   create config/routes.rb
   create config/application.rb
   create config/environment.rb
   create config/cable.yml
   create config/puma.rb
   create config/spring.rb
   create config/storage.yml
   create config/environments
   create config/environments/development.rb
   create config/environments/production.rb
   create config/environments/test.rb
   create config/initializers
   create config/initializers/application_controller_renderer.rb
   create config/initializers/assets.rb
   create config/initializers/backtrace_silencers.rb
   create config/initializers/content_security_policy.rb
   create config/initializers/cookies_serializer.rb
   create config/initializers/cors.rb
   create config/initializers/filter_parameter_logging.rb
   create config/initializers/inflections.rb
   create config/initializers/mime_types.rb
   create config/initializers/new_framework_defaults_6_0.rb
   create config/initializers/wrap_parameters.rb
   create config/locales
   create config/locales/en.yml
   create config/master.key
   append .gitignore
   create config/boot.rb
   create config/database.yml
   create db
   create db/seeds.rb
   create lib
   create lib/tasks
   create lib/tasks/.keep
   create lib/assets
   create lib/assets/.keep
   create log
   create log/.keep
   create public
   create public/404.html
   create public/422.html
   create public/500.html
   create public/apple-touch-icon-precomposed.png
   create public/apple-touch-icon.png
   create public/favicon.ico
   create public/robots.txt
   create tmp
   create tmp/.keep
   create tmp/cache
   create tmp/cache/assets
   create vendor
   create vendor/.keep
   create test/fixtures
   create test/fixtures/.keep
   create test/fixtures/files
   create test/fixtures/files/.keep
   create test/controllers
   create test/controllers/.keep
   create test/mailers
   create test/mailers/.keep
   create test/models
   create test/models/.keep
   create test/helpers
   create test/helpers/.keep
   create test/integration
   create test/integration/.keep
   create test/channels/application_cable/connection_test.rb
   create test/test_helper.rb
   create test/system
   create test/system/.keep
   create test/application_system_test_case.rb
   create storage
   create storage/.keep
   create tmp/storage
   create tmp/storage/.keep

Let's jump in:

cd example-project
code .

In VSCode this is what we have

We will go in order as Rails organizes them, for the most part, I will be talking about every single folder and file, for repeated files (such as .keep) I will only mention it once. You will notice a lot of conventions in Rails such as “application_[framework]s” (application_controller.rb, application_helper.rb, application_job.rb etc). In such instances I will cover the folder in detail so you know what goes inside, just know that the existing file “application_[...].rb” is a parent class that other classes you create in the folder will inherit from.

The app folder

Is where the majority of your development work will take place /app contains the Models, Views, and Controllers that will be served to users when requested by the browser.

app/assets

Stores assets for the Rails Asset Pipeline. The Asset Pipeline brings together the assets (JavaScript, CSS, and images), in a project and serves them to the client in the most efficient way possible. It does this by concatenating and minifying assets. It also precompiles assets written in Sass and CoffeeScript.
More info: The Asset Pipeline — Ruby on Rails Guides

app/assets/config

See below

app/assets/config/manifest.js

The aforementioned Asset Pipeline is managed by a Ruby gem called “Sprockets-rails” which does all of the above. “Sprockets-rails” has some associated helper gems such as “sass-rails”, “uglifier” and “coffee-rails”. Coffee-rails and Sass-rails precompile your Sass and CoffeeScript into CSS and JavaScript while Uglifier minifies these assets. Manifest.js lets you specifically set what is going to get pre-compiled.
For more on this specific file see: eileen.codes | Rails 5: The Sprockets 4 Manifest

app/assets/images

Image assets, such as icons and SVGs for the Asset Pipeline can be placed here.

.keep

This is the first of many .keep files you will see throughout a new Rails project. These are not Rails files but files for Git which won’t normally track empty folders. The keep. file just says “someone’s in here”. Anything with a .keep file will be tracked by Git. You don’t need .keep if you put something else in the folder.

app/assets/stylesheets

The stylesheets folder is where you will place styles associated with your app. You can write stylesheets in CSS or SASS out of the box., the Asset Pipeline will precompile any and all stylesheets for you.

app/assets/stylesheets/application.css

Contains all styles that will be included in the Asset Pipeline. Global styles can be written in Application.css but you can also write Controller specific stylesheets (when you run the command rails g to create a new Controller it will create an associated stylesheet. =require_tree . is Rails way of including all associated folders inside a directory so any other CSS files inside this project will be included when compiled =require_self will include any CSS that you write inside the Application.css file itself, this is location specific so the CSS inside Application.css will be run /after/ the other folders that are pulled in by require_tree .

.app/channels

Rails has numerous smaller internal frameworks. ActionCable is a framework that lets you use WebSockets to create realtime features in your app like chats and auto-updating “subscriptions” to notifications and new content. If you are not going to implement any realtime features you don’t need to worry about any ActionCable folders. The channels folder holds the server-side Ruby files for creating these connections.
You can read all about ActionCable here: Action Cable Overview — Ruby on Rails Guides

app/channels/application_cable

Application_cable holds channel and connection files for creating new realtime features in your app.

app/channels/application_cable/channel.rb

Each individual realtime features of your app would be encapsulated into an individual channel channel. For example, a chat feature chat, could be one channel. A notification system for newly published content would be a separate channel. This folder contains all the channels of your application.

app/channels/application_cable/connection.rb

Connections are the authentication between the user and the server. They don’t deal with any logic (that’s what channels do), rather they just check to make sure the current user is authorized to subscribe to the various channels in your application. In most cases, this would be a simple verification that the user is logged in.

app/controllers

Part “C” of the “MVC” pattern in Model View Controllers. Controllers like a middleman between the model and the view. Based on the user’s request the Controller will grab any associated data from the Model and pass it to the view which the user is shown. For example, if a user is navigating to the localhost:3000/posts page the Controller will determine what View they are shown as well as any associated records from the Model.

app/controllers/concerns

Concerns are a way to shrink your Models down, rather than writing a huge amount of reusable methods in a single model you can throw those methods into concerns where they can be easily reused in your Controllers.

app/controllers/application_controller.rb

Controllers are just ruby classes that inherit from a class called ActionController. As you add more models to your project you will have more controllers to deal with. applicationcontroller.rb is required for any Rails project because it inherits from ActionController::Base and all future controllers intern inherit from it, giving them the functionality of Controllers.
You’ll see a lot of “application[insert relative title here].rb” files: application_controller.rb, application_helper.rb, application_record.rb. In most cases, these represent a global way of interacting with the app, an intermediary that inherits from a base class and then is inherited by future classes or both. I won’t discuss the functions of these files in all cases.

app/helpers

Helpers are a way to keep your views tidy. Views should be concerned simply with displaying information as html to the user. If you find your html.erb files are getting bogged down with lots of little calculations or logic you should move that code into helper methods.

app/helpers/application_helper.rb

Provides a place to write global helpers, as you create more Controllers you will have more helpers to work with specific Controllers and Views.

app/javascript

This folder is a handy place to put all the javascript you use in your application, the Rails Asset Pipeline will include them from this folder into any pages where they apply (the Asset Pipeline knows where the scripts belong because the files, normally, follow a naming convention of the Controller they apply too).

app/javascript/channels

We’ve already looked at ActionCable’s channels above but this folder contains client-side specific javascript for creating realtime WebSocket connections.

app/javascript/channels/consumer.js

Consumers are the clients of a WebSocket connection; the end-users who are subscribing to the channel. This script will connect those consumers to the channel on the client-side.

app/javascript/channels/index.js

An application can have multiple Channels (chat, alerts, new posts, etc). index.js is a client-side directory of all the channels in your application.

app/javascript/packs/application.js

Webpacker is a ruby gem which allows you to use Webpack, the JavaScript bundler in your Rails project. It works in conjunction with the Asset Pipeline and is intended for large JavaScript frameworks, not small scripts or other assets like CSS or images (which Webpack generally would handle in a Javascript project). Webpacker, however, is flexible and this is just the default. You can have Webpack handle images and smaller JavaScripts completely bypassing the Asset Pipeline if you’d like. You can specify that in this folder by requiring different assets. The default assets that get packed are:

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

app/jobs

Jobs are background tasks that you run while users continue to use your application Any time you have an operation that will involve a lot of processing, enough to slow the user’s experience down significantly and cause your application to “hang”, you should create a background job that will run the task behind the scenes allowing the user to continue using your site uninterrupted.
For more info on Jobs see: Rails Active Job Tutorial: How to Use activejob | Codeship | via @codeship

app/assets/jobs/application_job.rb

See above.

app/mailers

You can think of mailers as controllers for emails. You can create a new mailer with Rails generate mailer. This will give you the equivalent of a Model and a Controller for sending emails to your users.

app/mailers/application_mailer.rb

See above.

app/models

The “M” of MVC; a Model is a template for the data stored in your database. Generally, any table is considered a “Model”. Common models may be User , Post or Comment . Note that these things are singular rather than plural, this is a reference to the prototypical nature of a model. This is in contrast to Controllers why by convention are plural because Controllers are referencing multiple records.

app/models/concerns

Concerns are modules - little nuggets of reusable code generally extracted from Models when they get too fat. The Concerns folder is part of an internal Rails framework called ActiveSupport which makes modules a bit easier to manage.

For more info see the Rails guides on concerns.

app/models/application_record.rb

Application_record.rb inherits from ActiveRecord::Base all subsequent models in your app will inherit from ApplicationRecord , similar to how Application_controller makes the functionality of the ActionController available to all other Controllers.

app/views

The last piece of the MVC pattern is Views. The Views folder contains everything the user will see in their browser, mostly in the form of HTML with embedded Ruby (ERB) or .Haml which is a templating language for Ruby. New controllers will most likely have an associated view folder with the same name (unless you’re creating an API). Generally speaking, every method in the Controller will have an associated View.

app/views/layouts

Your new Rails app will have a Layouts folder with application.html.erb, mailer.html.erb and mailer.text.erb these set global layouts for the Rails app in various domains such as the browser and the inbox. You may wish to add other components of a layout into this folder, for example, a _header.html.erb but most of your views will be organized into View folders specific to their Controller. Application.html.erb is the main template for your app, this file creates the main HTML <head> and <body> tags for your application with the views themselves shown in <%= yield %> . Yield is just a bit of Ruby code that adds the appropriate view for the page the user is looking at. Having an Application.html.erb file keeps your code DRY since you don’t have to repeatedly declare a doctype, head elements or include scripts and stylesheets, for every page in the View. Rails and the Asset Pipeline take care of this for you. The three files in this folder as stated above are:

• app/views/layouts/application.html.erb
• app/views/layouts/mailer.html.erb
• app/views/layouts/mailer.text.erb

bin folder

The bin folder helps set up the Rails application so it and associated commands can run properly.

bin/bundle

Ensures that the Gem Bundler works properly.

bin/rails

Spring is a preloader which keeps Rails running in the background as you work (there are some cases where you need to restart the server but for the most part changes to the Views or Controllers will be loaded automatically and immediately into your app running in a development environment). This file loads spring when you start the Rails application.

bin/rake

Rake stands for Ruby Make and is used to run several commands that will both set up and update the server.

bin/setup

Lets you write commands that will run when your app is first started.

bin/spring

Allows Spring to run without using the Bundler to bundle all your gems, this lets spring quickly reload your pages in development whenever you make a change.

bin/webpack

As discussed above Rails uses Webpack for bundling some JavaScripts as opposed to the AssetPipeline, this file requires the necessary setup and then runs Webpack.

bin/webpack-dev-server

Allows you to customize the dev server of Webpack which you may wish to do if you don’t want some or all of your assets bundled in your development environment.

bin/yarn

Yarn is a JavaScript package manager similar to NPM. You can use either with Rails projects.

config

Config, much like the name implies contains files for setting up your Rails application in different environments; development and test.

config/environments

This folder lets you configure how your application will work in development, production and testing environments. For example, you may wish to ensure that your action_mail is configured to send emails through a mail service in production but not in development.

config/initializers

This folder allows you to set granular initializers to define how your Rails app will preform there is a good chance you won’t spend too much time in here especially when working on your first few Rails applications.

config/initializers/application_controller_renderer.rb

Allows controllers to render outside their scope. For more information see: Upgrading to Ruby on Rails 5.0 from Rails 4.2 - application use case - Running with Ruby

config/initializers/assets.rb

Relates to the Asset Pipeline; which, you’ll remember, serves pages in your Rails app with the specific assets (CSS, JS, etc) they need. Here, you can add assets to the load path such as node_modules.

config/initializers/ backtrace_silencers.rb

Backtraces are a debugging tool that allows you to see what’s going on in your Rails app, particularly useful when things blow up and you can pinpoint the specific area of failure. Configure what backtraces show by determining which libraries are allowed to show backtraces in this file.

config/initializers/content_security_policy.rb

From Mozilla: “The HTTP Content-Security-Policy response header allows web site administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints.“ Content-Security-Policy - HTTP | MDN. In essence, this controls the data that is allowed to flow into your app and from what external sources. For example linking to external scripts, fonts or images outside of your app.

config/initializers/cookies_serializer.rb

Determines the format for cookies, by default this is :json

config/initializers/filter_parameter_logging.rb

We’ll discuss logging below but there are some parameters (accepted user inputs) like passwords or sensitive user data that you don’t want to show up in your log, you can add them here. filter_paramiter_logging is sort of like .gitignore for parameters.

config/initializers/inflections.rb

As discussed in the Model explanation, Rails has naming conventions for what is singular and plural. Based on locales (language settings for your app see Locales folder below) you can update these inflections in this initializer although it’s probably not a good idea unless it’s absolutely necessary.

config/initializers/mime_types.rb

MIME types - Multipurpose Internet Mail Extensions specify the format of email attachments.
MIME - Wikipedia

config/initializers/wrap_parameters.rb

By default, Rails wraps all parameters into JSON but you can specify other formats using the wrap_parameters hash. ActionController::ParamsWrapper

config/locales

Will generally load with en.yml as the only file. If your application is going to have multiple language options you can include all the translations as YML files here.

config/webpack

Allows you to configure Webpack settings based on the environment.

config/webpack/development.js

config/webpack/environment.js

config/webpack/production.js

config/webpack/test.js

config/application.rb

Will run the boot.rb file if you are using Passenger. It pulls all gems you’ve required in the gem file into your project and creates a class Application that inherits from Rails::Application

config/boot.rb

Creates an environment variable BUNDLE_GEMFILE set to the location of your project’s gem file, this is how Rails will know where to pull in dependencies or Gems, of which there are about 2 dozen in an out-of-the-box Rails install.

config/cable.yml

Similar to database.yml (see below) cable.yml sets development, test and production adapters for ActionCable, which you will remember is Rails way of implementing realtime features into your application.

config/credentials.yml.enc

credentials.yml replaces secrets.yml as the location of secret keys. This file is encrypted so nobody can read your secret keys and is only decrypted by the master key (see below).

config/database.yml

You can set a default database (to make your code a little DRYer) as well as specific DBs for development, test, and production.

config/environment.rb

Initializing the Rails application on the server requires a lot of steps, depending on if you’re using rails server or Passenger these steps may be slightly different but once environment.rb loads the application is initialized and begins running.

config/master.key

Throw this into your .gitignore file right away (see below), this is the master key that decrypts credentials.yml.enc in Rails and nobody should have it. For more info you can read this brilliant article: Rails 5.2 credentials – cedarcode – Medium

config/puma.rb

Puma is a web server for Ruby and is the default web server for Rails’ development environment. You can configure Puma through this folder altering things like thread count and the default port that puma will listen for incoming requests on (default is 3000).

config/routes.rb

Routes are the road map around your Controllers. Routes take incoming requests to the server and direct them to the correct Controller. Unlike most other files in the config folder, you will spend a lot of time here setting up routes as you build your app.

config/spring.rb

As discussed in the bin folder Spring is a preloader this file actually tells Spring which files and folders should trigger a restart.

config/storage.yml

ActiveStorage is a framework introduced in Rails 5.2 for uploading and storing assets such as images. You need a place to put those things such as an AWS instance, you specify that location in this file.

config/webpacker.yml

Allows you to add additional environments too Webpacker.

db

db/seeds

Seeds let you fill a database with data. Let’s say you wanted to see your pagination feature in action; you could create 11 posts by hand or you could just use a gem such as Faker to create 11 random posts for you and insert them directly into your database.

lib

Lib is defined by Rails guides as “Extended modules for your application.” If this sounds vague you're not the only one who feels that way. What specifically goes in the lib folder is somewhat controversial: see What goes in Rails lib/ – Extreme Programming – Medium and What code goes in the lib/ directory? but the general consensus is that lib should be reserved for code that does not fit into the app folder, that could be easily extracted out for use in other applications. It has two subfolders assets and tasks

lib/assets

From Ruby on Rails Guides:

"lib/assets is for your own libraries’ code that doesn’t really fit into the scope of the application or those libraries which are shared across applications."

lib/tasks

You can write custom rake tasks and put them in this folder. It's not a very commonly used location.

log

Logging is an important way to see how your application is performing and for finding and troubleshooting issues. By default, this folder will be empty. You can initialize various loggers in the config/environments folder with a command like: config.log_level = :info from there as you’re run your application the Log file will be created. For more detailed info see this great article from Datadog: How to collect, customize, and manage Rails application logs

Included in the Log folder:

• log/development.log

node_modules

Any node packages you are using in your project (such as Webpack and Babel) will be dependant on dozens if not hundreds of other node packages. A package manager such as NPM or Yarn will manage these packages for you. You shouldn’t go into this folder or edit anything in it.

public

The public folder contains resources that are external and may be accessed outside the normal structure of your application, favicon, apple-touch-icons, robots.txt and of course error pages. Pages like: 404, 422 and 500. Should the application in production experience some kind of error these HTML pages will be served automatically bypassing routes, controllers or any specific views. These pages are not part of the Rails Asset Pipeline so you will need to write any styles inline.

public/robots.txt

Allows you to specify how search engines crawl your website.

storage

Rails 5.2 introduced ActiveStorage which replaced gems like PaperClip and allows Rails to directly interface with cloud services like AWS or Google

test

Rails has testing built-in from the ground up! The default test suite in Rails is MiniTest so you will find that all these folders are ready to go with MiniTest.
There are folders where you can test specific Controllers, Helpers, Models, Mailers as well as write Integration tests which work across multiple Controllers and recreate something akin to actual user experience. For more on what a constitutes a controller test vs an integration test I recommend this article from (Jason Swett)

test/channels

test/channels/application_cable/connection_test.rb

Tests for ActionCable connections like all ActionCable stuff you will only need this if you are using channels in your application.

test/controllers

You can test your controllers here, these tests are generally looking at how well your controller goes between the model and the view, they are larger in scope then Model tests but smaller in scope then Integration tests.

test/fixtures

Not a place for writing tests but generating dummy test data. Inside the fixtures folder you can add any number of YML files with predefined data. You can pull this data into your tests to make sure that your models are working correctly and interacting with the application as expected.

test/fixtures/files

Now that Rails has file handling built-in with ActiveStorage not only can you test data from models you can also test files.

test/helpers

You can write specific tests for the helpers you have in app/helpers. Testing helpers is not too common but you can do it if a helper is overly complex or seems brittle.

test/integration

Integration tests allow you to test interactions between controllers and provide a testing option closer to the actual user experience.

test/mailers

You can even write tests for your mailers, to ensure emails are being sent correctly and formatted properly.

test/models

One of the most granular tests; you can ensure that a record is saved properly, the database has updated, etc.

test/system

System tests are a way of testing your application in a real browser generating screenshots to show you how everything looks in action. System tests will also test the JavaScript, not that you should use MiniTest system tests as a replacement for a good JavaScript testing library like Jest. System tests; however, will allow you to see how your JavaScript is functioning in the browser.

test/application_system_test_case.rb

This file holds the defaults for your system tests, you can change browsers, drivers or screen resolution.

test/test_helper.rb

Test helper brings in external data and libraries that are required for tests. You will notice that right off the bat fixtures :all is imported. This gives your tests access to fixtures. You could set up a host of other test suites and frameworks from test_helper.rb to include their functions and DSLs such as Capybara, FactoryBot and Faker.

tmp

Temporary - this folder contains caches and sessions it may be cleared on occasion either manually or on deploy (depending on how you are deploying your app).

vendor

The vendor folder is a place for 3rd party code somewhat like Gems. Gems; however, are a bit more self-contained whereas the vendor folder may contain specific scripts not bundled as gems. For more on this as well as some of the benefits see How to Vendor Gem a Gem.

.browserslistrc

Browserslist is a tool to target specific browser versions for NPM tools such as Babel. Set to “defaults” by default, ensures that

.gitignore

As with any other project, your version control will ignore any files or folders you specify in here.

.ruby-version

Simply contains the version of Ruby the project is working under, RVM can read this file and set the correct version of ruby on your computer (if you have multiple versions of Ruby installed).

babel.config.js

Babel is a JavaScript compiler that lets you use the latest and greatest features of JavaScript and compiles them to be compatible with web browsers that may not yet have adopted those features. For more information on Babel configuration see their official docs.

config.ru

Rack (the popular Ruby server) uses this file to start the application.

gemfile

Inside the gemfile you store all your application’s dependencies, as you have seen the Rails New command installs a lot of gems but as you add more functionality to your application you’ll be hopping in and out of this file a lot.

gemfile.lock

Similar to package-lock.json for Node projects, this file is updated when you run bundle install or bundle update and resolves all gem dependencies above and beyond what you included manually in the gem file. Don’t mess with this file it’s updated automatically.

package.json

Establishes NPM dependencies for Javascript modules, these will be packed with Webpacker.

postscss.config.js

PostCSS gives you a lot of modern functionality with CSS, from automatically adding vendor prefixes to including CSS Modules. For more on this cool tool check it out.

rakefile

Again Rake stands for “Ruby Make”. Rails has several commands built in which require Rake such as rake routes (showing you all routes for your application) rake db:migrate to add new Models and columns to your db. Among others, you can add custom rake commands here.

README.md

This is the Readme for your project, it will be displayed on your projects Github page, include any information you believe would be useful for others investigating or working with your project.

yarn.lock

Much like package.json, Yarn is Webpacker default package manager. This is a lock file, so like Gemfile.lock it will be updated automatically and you should not change it manually.

You made it through! Congratulations!

via GIPHY

Additional Resources

Helpers(The Beginner’s Guide to Rails Helpers - Mix & Go)
Info on Keep Files (StackOverflow keep files)
Rails Initialization (The Rails Initialization Process — Ruby on Rails Guides)
Creating the Blog Application(Getting Started with Rails — Ruby on Rails Guides)

I realize that's pretty overwhelming but let me simplify it a bit. 99% of Rails is there to let you customize your project to the nth degree this is why Rails continues to work well for large enterprises and startups alike; you can easily adjust and tweak almost any part of your application with very little effort. That said, for most beginners, personal projects and even a decent amount of corporate projects you will use very little of this functionality.

Since Models, Views, and Controllers represent the core of a Rails application you will be spending most of your development time in the app folder. You will use the routes.rb file a fair amount in the config folder while you set up how users will step through your app and as you add new Controller actions. Be sure to always write proper test coverage for your applications. If you are, you will spend a lot of time in the test folder. The gemfile is one final place you will visit often adding and updating gems as needed.

Although there are a ton of files and folders created in every new rails new you shouldn’t be overwhelmed by it; if you ever get lost this post has your back.

#

Why uniqueness validation is not enough

Even with the uniqueness validation, unwanted data sometimes gets saved in the database. For clarity, let’s take a look at a user model shown below:

class User
    validates :username, presence: true, uniqueness: true
end

To validate the username column, rails queries the database using SELECT to see if the username already exists. If it does, it prints “Username already exists”. If it doesn’t, it runs an INSERT query to persist the new username in the database.

When two users are running the same process at the same time, the database can sometimes save the data regardless of the validation constraint and that is where the database constraints (unique index) comes in.

If user A and user B are both trying to persist the same username into the database at the same time, rails runs the SELECT query, if the username already exists, it informs both users. However, if the username doesn’t exist in the database, it runs the INSERT query for both users simultaneously as shown in the image below.

Now that you know why the database unique index (database constraint) is important, let’s get into how to set it. It’s quite easy to set database unique index(es) for any column or set of columns in rails. However, some database constraint in rails can be tricky.

A quick look at setting a unique index for one or more column

This is quite as simple as running a migration. Let’s assume we have a users table with column username and we want to ensure that each user has a unique username. You simply create a migration and input the following code:

add_index :users, :username, unique: true

Then you run the migration and that’s it. The database now ensures that no similar usernames are saved in the table.

For multiple associated columns, let’s assume we have a requests table with columns sender_id and receiver_id. Similarly, you simply create a migration and input the following code:

add_index :requests, [:sender_id, :receiver_id], unique: true

And that’s it? Uh oh, not so fast.

The problem with the multiple column migration above

The problem is that the ids, in this case, are interchangeable. This means that if you have a sender_id of 1 and receiver_id of 2, the request table can still save a sender_id of 2 and receiver_id of 1, even though they already have a pending request.

This problem often happens in a self-referential association. This means both the sender and receiver are users and sender_id or receiver_id is referenced from the user_id. A user with user_id(sender_id) of 1 sends a request to a user with user_id(receiver_id) of 2.

If the receiver sends another request again, and we allow it to save in the database, then we have two similar requests from the same two users(sender and receiver || receiver and sender) in the request table.

This is illustrated in the image below:

The common fix

This problem is often fixed with the pseudo-code below:

def force_record_conflict
    # 1. Return if there is an already existing request from the sender to receiver 
    # 2. If not then swap the sender and receiver
end

The problem with this solution is that the receiver_id and sender_id get swapped each time before saving to the database. Hence, the receiver_id column will have to save the sender_id and vice versa.

For example, if a user with sender_id of 1 sends a request to a user with receiver_id of 2, the request table will be as shown below:

This may not sound like an issue but it’s better if your columns are saving the exact data you want them to save. This has numerous advantages. For example, if you need to send a notification to the receiver through the receiver_id, then you’ll query the database for the exact id from the receiver_id column. This already became more confusing the moment you start switching the data saved in your request table.

The proper fix

This problem can be entirely resolved by talking to the database directly. In this case, I’ll explain using PostgreSQL. When running the migration, you must ensure that the unique constraint checks for both (1,2) and (2,1) in the request table before saving.

You can do that by running a migration with the code below:

class AddInterchangableUniqueIndexToRequests < ActiveRecord::Migration[5.2]
    def change
        reversible do |dir|
            dir.up do
                connection.execute(%q(
                    create unique index index_requests_on_interchangable_sender_id_and_receiver_id on requests(greatest(sender_id,receiver_id), least(sender_id,receiver_id));
                    create unique index index_requests_on_interchangable_receiver_id_and_sender_id on requests(least(sender_id,receiver_id), greatest(sender_id,receiver_id));
                ))
            end

            dir.down do
                connection.execute(%q(
                    drop index index_requests_on_interchangable_sender_id_and_receiver_id;
                    drop index index_requests_on_interchangable_receiver_id_and_sender_id;
                ))
            end    
        end
    end
end

Code explanation

After creating the migration file, the reversible is to ensure that we can revert our database whenever we must. The dir.up is the code to run when we migrate our database and dir.down will run when we migrate down or revert our database.

connection.execute(%q(...)) is to tell rails that our code is PostgreSQL. This helps rails to run our code as PostgreSQL.

Since our “ids” are integers, before saving into the database, we check if the greatest and least (2 and 1) are already in the database using the code below:

requests(greatest(sender_id,receiver_id), least(sender_id,receiver_id))

Then we also check if the least and greatest (1 and 2) are in the database using:

requests(least(sender_id,receiver_id), greatest(sender_id,receiver_id))

The request table will then be exactly how we intend as shown in the image below:

And that’s it. Happy coding!

References:

Edgeguides | Thoughtbot

I recently started working with Ruby (almost 2 months now) and Ruby on Rails (a little over 3 weeks). Working with Rails’ Active Record framework is one of my favorite things about Ruby on Rails. In this post, we will be looking at validations in Active Record, custom ones particularly. Here is a quick intro to Active Record before we move to the good stuff.

Active Record is one of the core gems that make up Ruby on Rails. It is the part of the framework that deals with databases.

It is an ORM (Object Relational Mapping) framework that lets you build a schema for a database using pure ruby and it is based on the Active Record design pattern described by Martin Fowler. So, with Active Records, you are creating your DB, creating tables, storing, retrieving and deleting data using ruby which translates to SQL under the hood.

Quick Intro

Suppose we have a student model with properties first name and last name. To use Active Record we just need to extend the ApplicationRecord and when we run rails db:migrate it gives us the SQL statement for it.

To interact with the database, we use methods inherited from the ApplicationRecord superclass.

It also supports associations and other database stuff.

For a detailed intro to Active Record, check out the official ruby on rails guide.

Validation

Because we write web applications for users other than ourselves, we cannot be sure that the users will always input valid data into the database. To enforce this, Active Record provides us a mini-validation framework that ensures the presence of data, uniqueness of certain fields, and so on.

Let’s look at our students table above. We wouldn’t want to create a user without a first name or last name which presently is possible. To mitigate this, we just need to modify our Student class like so:

With this modification, when you create a Student instance without the first name or last name attributes, it is an invalid student and active records will not persist it to the database.

Active record also provides us with methods to check if our data is valid or invalid:

With this, we do not even have to attempt to save the data.

Apart from just preventing the data from being persisted, Active Record also provides an error list that holds the attributes that failed validations and user-friendly messages to present to the users. These errors can be accessed as shown in the snippet below.

There is a lot more on validation but it’s not the topic of this article. For a deep dive, you can get an in-depth explanation from the ruby on rails guide chapter on Validation.

Custom Validation

Sometimes, we might want to use certain validations that are more than just ensuring the presence of an attribute, length, uniqueness, or any of the helpers provided by Active Record. Luckily, Active Record allows us to define our own custom validations, which is the point of this article.

So, let’s say for our Student model, we have a compulsory student registration number column. It has to be filled from the registration form (I know this can be auto-generated) which should always start with the registration year. Now, Active Record does not provide this kind of validation out of the box, but has made it possible for us to define it and use it.

There are mainly two ways to define your own validation logic:

• Custom Validator
• Custom Methods

Custom Validator

To validate using a custom validator, you just need to define your validation logic in a class that extends ActiveModel::Validator and implements the validate method, which takes the record to be validated as its argument.

If validation fails, it adds the attribute to the errors array along with its error message. So, in our case, we’ll have RegNumValidator as seen below:

To use this validator in the Student model, we use the validates_with method:

With this, when a user tries to create a student with the wrong registration number, the record creation fails and an error message can be shown.

Custom Methods

To use custom methods for validation, you just need to define a method to use for validation in your model class and call it like you would call any of the in-built validations — using validate. Using the same logic as what we had above, our model would look like this:

Conclusion

I hope this article has given you the necessary knowledge to begin to explore Active Records validation and custom validation especially. Whenever you have a validation rule that is not part of the existing active record validation API, you can write one yourself.

Active Record Validations — Ruby on Rails Guides
_Validations are used to ensure that only valid data is saved into your database. For example, it may be important to…_guides.rubyonrails.org

Rails 6.0 is almost here. The stable version will be released on April 30. The Rails 6.0 beta1 was released on January 15. As Rails releases always are, Rails 6.0 is also action-packed. There are two major frameworks newly introduced, Action Mailbox and Action Text. In this post, let's take a quick look at Action Text by using it in a small app.

courtesy:wikipedia

Action Text

Action Text allows us to bring rich text content and editing to Rails. This means we can perform operations like formatting text, embedding images, formatting links, adding lists and other editor-like feature to a text field.

This is done by including the Trix editor into the framework. The RichText content generated by the Trix editor is saved in its own RichText model that’s associated with any existing Active Record model in the application. All embedded images or other attachments are automatically stored using Active Storage.

Let us start building our Rails app which will be a blogger app. The app is created in Rails 6.0, so the ruby version must be >2.5.

In the terminal type

rails new blog --edge

The -- edge flag fetches the latest rails version or edge version of the rails.

Action Text expects web packer and ActiveStorage to be installed. The active storage is already present in the Rails app. So we need

gem “image_processing”, “~> 1.2” #uncomment from Gemfilegem ‘webpacker’

in the gem file.

Now run

bundle install.

Next, we need to create a config/webpacker.yml:

bundle exec rails webpacker:install

Now let us start our Rails Server.

Great, let’s quickly build our app. The app will have only one model Article.

Let us create a controller for articles:

rails g controller Articles index new create show edit update destroy — no-helper — no-test-frameworks

And then configure our routes:

Rails.application.routes.draw do resources :articlesend

Next, we need to create our model. Our Articles model will have two fields: they are title and text. text must be the field that accepts Rich Text Format. So in the migration, we need to add only the title field. The text field will be handled by ActionText.

Let’s generate the model

rails g model Articles title:string — no-test-framework

and run the migrations:

rails db:migrate

Now let us add ActionText part. For that first run

rails action_text:install

This will add all the dependencies required by Action Text. Most notably, this will add a new file javascript/packs/application.js and two action-storage migrations.

Run the migrations again using

rails db:migrate

Now we can add the text part of our model. Go to app/models/article.rb and add the following line

has_rich_text **:text**

text is the field name we are providing. It can be anything like body or content etc.

Now our model becomes

class Article < ApplicationRecord has_rich_text :textend

Before we build our form, let’s create our controller logic for the creation of articles:

class ArticlesController < ApplicationController  def create   @article = Article.new(article_params)   @article.save   redirect_to @article end

 private def article_params   params.require(:article).permit(:title, :text) end

end

We can now create the form for the blog. In app/views/articles/new.rb add the following form code:

<%= form_with scope: :article, url: articles_path, local: true do |form| %>

<p>    <%= form.label :title %><br>    <%= form.text_field :title %>  </p>   <p>    <%= form.label :text %><br>    <%= form.rich_text_area :text %>  </p>   <p>    <%= form.submit %>  </p><% end %>

Notice that for text field we are using form.rich_text_area which is provided by Action Text.

Let us render our page:

Awesome!!

We now have an awesome text editor for creating our article.

Before we start playing with the editor, let’s quickly implement the show functionality of the blog, so that we can see the articles we have created.

In app/controllers/articles_controller.rb add the following function:

 def show   @article = Article.find(params[:id]) end

Also, we need to create a view for this.

Create the file app/views/articles/show.html.erb and add the following code:

<p>Article Title:<strong><%= @article.title %></strong></p><p>Article Text:<strong><%= @article.text %></strong></p>

<%= link_to ‘Create new’,new_article_path %>

That's it. Our app is done. Now let's check the various features available in the text editor provided by ActionText.

We can see that ActionText provides almost all the functionalities of a normal rich text-editor like formatting the text as bold, italic, adding strike-throughs, quotes, links, dragging and dropping images, etc.

After saving this, we can see the saved post from the show page.

Great!

This is a very small example that displays the potential of ActionText. Hope it was helpful. Do give it a try.

A vast majority of web apps deal with rich content in some way. So I believe this new feature of Rails can make the lives of many developers easier.

Kudos to DHH and all the awesome people behind this.

https://github.com/amkurian/Rails-6.0_action_text_demo

Some Useful Links:

Action Text Overview - Ruby on Rails Guides
_Action Text OverviewThis guide provides you with all you need to get started in handling rich text content.After…_edgeguides.rubyonrails.org

Gems are located in the Gemfile inside your project folder. Let’s have a look at some you’ll want to have.

will_paginate

Adds pagination to your app

Installation

Add to Gemfile

gem 'will_paginate'

Install

bundle install

Usage

In a .html.erb file, render page links in the view:

<%= will_paginate @places %>
  <% @places.each do |place| %>
    <h1><%= place.name %></h1>
    <br />
  <% end %>
<%= will_paginate @places %>

In your controller, you can define how many entries per page you want to display. In the example below, it will list 3 entries per page.

def index
  @places = Place.all.paginate(page: params[:page], per_page: 3)
end

Source: https://github.com/mislav/will_paginate

simple_form

Forms made easy!

Installation

Add to Gemfile

gem 'simple_form'

Install

bundle install

Run the generator

rails generate simple_form:install

Usage

In a .html.erb file:

<%= simple_form_for @place do |f| %>
  <%= f.input :name %>
  <%= f.input :address %>
  <%= f.input :description %>
  <br />
  <%= f.submit 'Create', class: 'btn btn-primary' %>
<% end %>

Source: https://github.com/plataformatec/simple_form

devise

Adds user management

Installation

Add to Gemfile

gem 'devise'

Install

bundle install

Run the generator

rails generate devise:install

Configure device at config/environments/development.rb

Add this line:

config.action_mailer.default_url_options = { host: 'localhost', port: 3000 }

Edit code in app/views/layouts/application.html.erb

Add this line:

<% if notice %>
  <p class="alert alert-success"><%= notice %></p>
<% end %>
<% if alert %>
  <p class="alert alert-danger"><%= alert %></p>
<% end %>

Add sign-up and login links in app/views/layouts/application.html.erb

<p class="navbar-text pull-right">
<% if user_signed_in? %>
  Logged in as <strong><%= current_user.email %></strong>.
  <%= link_to 'Edit profile', edit_user_registration_path, :class => 'navbar-link' %> |
  <%= link_to "Logout", destroy_user_session_path, method: :delete, :class => 'navbar-link'  %>
<% else %>
  <%= link_to "Sign up", new_user_registration_path, :class => 'navbar-link'  %> |
  <%= link_to "Login", new_user_session_path, :class => 'navbar-link'  %>
<% end %>
</p>

Force user to be redirected to login page if not logged in.

Edit in _app/controllers/applicationcontroller.rb

before_action :authenticate_user!

Source: https://guides.railsgirls.com/devise

geocoder

Adds geocoding from Google API

Installation

Add to Gemfile

gem 'geocoder'

Install

bundle install

Create a migration file, run this in your terminal:

rails generate migration AddLatitudeAndLongitudeToModel latitude:float longitude:float

rake db:migrate

Example of a migration file adding latitude and longitude columns for existing Places table:

class AlterPlacesAddLatAndLng < ActiveRecord::Migration[5.0]
  def change
    add_column :places, :latitude, :float
    add_column :places, :longitude, :float
  end
end

Add these lines in your app/model/place.rb

geocoded_by :address
after_validation :geocode

Add this script in show.html.erb

<script>
<% if @place.latitude.present? && @place.longitude.present? %>
  function initMap() {
  var myLatLng = {lat: <%= @place.latitude %>, lng: <%= @place.longitude %>};
  var map = new google.maps.Map(document.getElementById('map'), {
    zoom: 15,
    center: myLatLng
  });
  var marker = new google.maps.Marker({
    position: myLatLng,
    map: map,
    title: 'Hello World!'
  });
}
</script>

Source: https://www.rubydoc.info/gems/geocoder/1.3.7

figaro

Easily configure your APIs in Heroku deployment

Installation

Add to Gemfile

gem 'figaro'

Install and create a commented config/application.yml file and add it to your .gitignore

bundle exec figaro install

Update your API keys in config/application.yml

For updating API keys in heroku, go to your terminal:

figaro heroku:set -e productionheroku restart

Source: https://github.com/laserlemon/figaro

carrierwave

image uploader

Installation

Add to Gemfile

gem 'carrierwave'

Install

bundle install

In your terminal

rails generate uploader Image

It will generate this:

app/uploaders/image_uploader.rb

Create a migration file

rails g migration add_image_to_courses image:string

Run the migration file

rake db:migrate

In your model

class User < ApplicationRecord  mount_uploader :image, ImageUploaderend

Add to a html.erb i.e. app/views/instructor/courses/new.html.erb

<%= f.input :image %>

Add to controller app/controllers/instructor/courses_controller.rb

params.require(:course).permit(:title, :description, :cost, :image)

Add to show.html.erb i.e. app/views/instructor/courses/show.html.erb

<%= image_tag @course.image, class: 'img-fluid' %>

Also update the following:

• app/views/courses/show.html.erb
• app/views/courses/index.html.erb
• app/views/instructor/courses/show.html.erb

Image Resolution with ImageMagick, more on carrierwave

Carrierwave in shows that MiniMagick and RMagick can be used

It shows here app/uploaders/image_uploader.rb

class ImageUploader < CarrierWave::Uploader::Base
  # Include RMagick or MiniMagick support:
  # include CarrierWave::RMagick
  # include CarrierWave::MiniMagick

Installing ImageMagick

We need to update our development environment’s database of programs to make sure when we install a program we’re getting the latest version.

$ sudo apt-get update

Install ImageMagick

$ sudo apt-get install imagemagick

Installation MiniMagick

Add to Gemfile

gem 'mini_magick'

Install

bundle install

Uncomment MiniMagick in app/uploaders/image_uploader.rb

class ImageUploader < CarrierWave::Uploader::Base
  # Include RMagick or MiniMagick support:
  # include CarrierWave::RMagick
  include CarrierWave::MiniMagick

That line gives CarrierWave the ability to reach out to the ImageMagick program we installed on our program, through the MiniMagick gem. This will allow us to resize the image.

Unlocks image-resizing abilities such as resize_to_fill, resize_to_fit, resize_and_pad, and resize_to_limit.

Add this in app/uploaders/image_uploader.rb

# Process files as they are uploaded:
process resize_to_fill: [800, 350]

Integrating Amazon S3 for Video Uploads

Installation

Add this line to your application’s Gemfile:

gem 'carrierwave-aws'

Run the bundle command from your shell to install it:

bundle install

Step 1: Configuring the Initializer

Normally we would install our gem first, however to prevent bugs when switching from fog to AWS we need to update our initializer first.

You can read the details of how to configure the carrierwave-aws gem in the Usage Section of the Documentation. Following the pattern they specify, we should update config/initializers/carrierwave.rb to look like this:

# config/initializers/carrierwave.rb
CarrierWave.configure do |config|
  config.storage    = :aws
  config.aws_bucket = ENV["AWS_BUCKET"]
  config.aws_acl    = "public-read"
  config.aws_credentials = {
      access_key_id:     ENV["AWS_ACCESS_KEY"],
      secret_access_key: ENV["AWS_SECRET_KEY"],
      region:            ENV["AWS_REGION"]
  }
end

Now save the file.

Step 2: Updating our Gemfile

Add the carrierwave-aws gem as described by the documentation. Edit the Gemfile to look like this:

gem 'carrierwave'gem 'mini_magick'gem 'carrierwave-aws'

Save the file and run the command to install the gem.

$ bundle install

Then restart your server.

Step 3: Add Region to application.yml

We need to add a region to our application.yml file. Open up your config/application.yml and add this line to specify the region we want to use:

# config/application.yml
AWS_ACCESS_KEY: "Your-access-key"
AWS_SECRET_KEY: "Your-secret-key"
AWS_BUCKET:     "Your-bucket"
AWS_REGION:     "us-east-1"

Save the file.

Step 4: Updating the Uploader

If you remember from before, we specified inside the storage provider for the uploader to use :fog. Rather than that, we need to switch it to :aws.

# encoding: utf-8
class ImageUploader < CarrierWave::Uploader::Base
  # Include RMagick or MiniMagick support:
  # include CarrierWave::RMagick
  include CarrierWave::MiniMagick
  # Choose what kind of storage to use for this uploader:
  #storage :file
  storage :aws
  # A bunch more comments down here....
end

Save the file.

One more thing we will have to do is re-sync the localhost with heroku. To do this we need to run a simple command:

$ figaro heroku:set -e production

Make sure uploads continue to work by uploading an image for a course and make sure it goes through successfully.

VideoJS

Add css file before </head>

<link href="http://vjs.zencdn.net/5.12.6/video-js.css" rel="stylesheet">

Add JavaScript files before </body>

<script src="http://vjs.zencdn.net/5.12.6/video.js"></script>

<script src="http://vjs.zencdn.net/ie8/1.1.2/videojs-ie8.min.js"></script>

Note: You must place the videoJS script tags in the bottom of the body otherwise you will have issues loading the video player because of Turbolinks.

Thanks for reading! Hope this was helpful.

Every trend, technology, and even programming language has its peak in popularity that sooner or later will decrease slightly or by a considerable amount. If we lookup “state of ruby language” in Google we will most likely get many results concerning Ruby’s alleged death and decrease in popularity. Still, I believe the truth is, Ruby is doing great and still remains a good technology to choose in 2019.

Here is why:

1. Ruby is still among the top 10 programming languages

It is very unlikely that Ruby will die anytime soon as it is still featured among GitHub’s top programming languages of 2018. What’s more? Large enterprises like GitHub and Airbnb are continuously using Ruby on Rails. Just a couple days ago, cloud computing giant AWS added Ruby to its serverless computing solution — AWS Lambda right next to Java, C#, Python and Node.js, which proves the stable position of the language.

Ruby may have slowed down (no pun intended) but it is far from dying, especially due to the vast amount of existing projects that have to be maintained and extended.

2. The community is active and supportive

The Rails framework has over 3,500 contributors on GitHub. Frequent updates and new gems created by developers ensure that the applications created using the framework can be developed more easily and delivered more quickly.

The active community regularly shares experiences and troubleshooting problems. With over 300,000 questions on Stackoverflow it is unlikely that you will have a really hard time finding a solution for a problem you are experiencing. Not only Ruby, but also Ruby on Rails has become mature over the years and its documentation has gotten very detailed and extensive — a great starting point for newcomers.

Ruby is not only Rails. More lightweight solutions like Sinatra, frameworks offering different approaches like Hanami, and even frameworks for event sourcing are growing in popularity and improving on what Ruby can offer.

3. Ruby constantly evolves

With updates at least twice a year, Ruby creators make sure the language is not dying and constantly evolves. Despite the fact that the performance issues will not likely disappear any time soon due to some basic characteristics of Ruby (especially its dynamic nature), the release of Ruby 3 in 2020 is expected to introduce several improvements that can make Ruby significantly faster.

4. It’s really great for startups, internal tools, prototyping and whatnot

Thanks to its intuitive, simple, and readable syntax resulting in much higher productivity, Ruby has been a great fit for startups or any company that would like to deliver (and extend) software products as soon as possible. Faster development means better savings (quicker time-to-market), which is important for startups with a limited budget. This way, more money can be invested in the development of additional stuff like updating features and marketing.

On the other hand, large-scale projects can benefit from Ruby on Rails using it as a prototyping tool or an efficient way to deliver proof-of-concept solutions. Because it is relatively easy and cheap to build and extend applications with Ruby, it is also a great option for building internal/back-end tools, where the performance is not a top priority.

It is not uncommon to use Ruby even for large, high-performance applications. This usually requires engineers that know how to craft high-performance applications in Ruby though, as speed is not inherently bundled with this language. Also, it might require some horizontal scaling.

5. Ruby has a well-established code style recommendations

Ruby is a mature programming language and stable technology, bringing more to the picture than simply being ‘trendy’. It is still possible to write bad code in Ruby, and some say it is fairly easy as the language is very flexible — it allows achieving the same result in multiple ways (not always the prettiest ones).

On the other hand, the language itself allows writing beautiful and readable code — this is encouraged by a well-established set of best practices related to implementation and testing. Such code, if written properly, can be easily understood and maintained by fellow developers, further improving on the stability and maintainability of the whole solution.

6. Developer happiness

A vast amount of libraries and resources for learning, a helpful and active community, well established best practices and beautiful, readable syntax — all this makes Ruby a programming language that is a pleasure to work with. It’s a language oriented on developer happiness.

In most cases, happy developers deliver better value to their customers. While there are other languages that try to mimic best aspects of Ruby (like Crystal), those are still immature technologies that need to prove themselves in production environments.

But why is Ruby slowing down?

There is no easy answer to that question, but we can theorize about it. It is likely that Ruby has matured enough and has started to lose some momentum. Lots of solutions, libraries and techniques were already created or designed so the need for new ones is not as significant as it once was. We can also see a slight decrease when it comes to appearance of new learning materials — most likely due to same reason.

Furthermore, the appearance of new languages and frameworks better suited for particular applications/solutions forced Ruby to share its part of the cake with the new players. Languages that are much less resource intensive, languages providing efficient libraries for specialized solutions related to ML/AI or other new concepts, and finally, languages designed around parallel processing — Ruby cannot compete with them in those areas, at least not yet. It is best to always use the right tool for the right job and Ruby is not one-size-fits-all kind of tool.

Conclusions

Even in 2019 Ruby remains a great choice for your development needs. There is no doubt that it is still a relevant language and it still attracts new followers and developers.

Last but not least, what should be kept in mind that there are no ‘bad’ programming languages in and of themselves, there are only badly chosen languages for particular use cases. So if you feel Ruby seems to be a great fit for you, do not hesitate, it is still out there among the top most popular technologies.

Originally published at selleo.com.

I’m currently a developer for Blueprint, an organization at UC Berkeley. We develop software pro bono for non-profits and advance technology for social good. This past year, my team worked on building a solution for The Dream Project. The goal is to provide a better education for children in the Dominican Republic.

I am writing this post in hopes of sharing my experience of doing Salesforce integration using Heroku Connect for a Ruby on Rails/React Native app.

What is Heroku Connect?

“Heroku Connect makes it easy for you to build Heroku apps that share data with your Salesforce deployment. Using bi-directional synchronization between Salesforce and Heroku Postgres, Heroku Connect unifies the data in your Postgres database with the contacts, accounts and other custom objects in the Salesforce database.”

Another way to put it…

Heroku Connect assists with replacing your app’s Postgres database with a Salesforce database. Of course, since Rails apps connect natively to Postgres, you cannot do immediate calls and pushes to Salesforce without some API like the Restforce gem.

In reality, the Postgres database that our Rails app will interact with serves as a disguise for Salesforce. It is a working middleman. All data must go through it before reaching Salesforce, and vice versa. Heroku Connect is the bridge that combines the capabilities of Force.com and Heroku without the need for a gem.

You might ask… why even bother learning Salesforce integration?

Well, Salesforce integration streamlines the process of storing and retrieving data. Especially customer data for businesses.

You can provide your customers with modernized computer systems for an improved user experience and workflow. You’ll be accelerating app development. It also creates better tools for informing management and sales on business performance.

This helps businesses achieve efficient levels of operation for business-to-consumer apps. It does this through instantaneous and accurate updates.

A Sample Project for Inspiration

To give some background for the code snippets below in the tutorial, I will explain beforehand the project I was working on. This project got me introduced to Heroku Connect.

Previously, Dream recorded student information in a Salesforce database. This was not ideal for teachers to use. To make their lives easier, we created a user-friendly app. The app handled course creation, student enrollment, and attendance taking.

Due to the poor internet connection at Dream campuses, we turned to Heroku Connect for constant synchronization of updates. It synchronized updates on the Heroku Postgres database side and Salesforce database side.

All the code described in this demo is available in our project repo. You can also check out the React side of the application here.

Alright, let’s start the demo…

Overview

I’m going to tackle this demo in the following order:

1. Description of Tech
2. Setup (Heroku Postgres and Heroku Connect)
3. Heroku Connect Mappings + Notes
4. Changes to your local Rails app

Description of Tech

• Force.com (Salesforce Developer Account)
• Heroku Connect
• Rails app (my Rails version was 5.1.4)

Setting up: Deploying your app to Rails

After setting up your Rails app, you want to deploy your app on Heroku. Here is a quick run-through on deploying your app:

1. Login to your Heroku account, and you will be redirected to the dashboard on the top right. You will see a “New” button on a top right to create a new project. Type in your custom app name and create your app.
2. You will be redirected to the deploy page of your new app. Scroll down to the bottom to the section “Deploy using Heroku Git.” Follow the instructions on the page. (Note: after you add the Heroku Git remote you can alway update your Heroku app. You update by adding and commiting your changes and finally doing a git push heroku master.)

Most likely, if this is your first time, you will face an error: “Heroku deployment failed because of sqlite3 gem error.” This is because Heroku uses Postgres instead of sqlite3. To fix this, check out this Stack Overflow post.

Heroku Postgres

With your app deployed, your overview page should have the add-on Heroku Postgres. This is your usual database for deployed Heroku apps.

Add-ons like Heroku Postgres or Heroku Connect appear in the Overview tab or Resources tab.

Click on this add-on to check the URL database info in the settings tab. Be sure to add your Postgres database URL to your Rails app.

To add the database URL, you can either create an environment variable using the Figaro gem:

or just include a URL variable in your database.yml file:

Heroku Connect

Next, click on configure add-ons or the resources tab, and search for Heroku Connect. Click provision to add the add-on.

You will then be redirected to the screen below. Note that the schema name is “salesforce” for now (feel free to change it as well), and you’re good to continue.

Click setup connection. Enter your Salesforce user info to establish the connection with the appropriate details.

You’re now done with the setup! Now we can move on to mappings.

Mappings

I recorded a short video of creating a mapping for a Teacher object:

The video is a walkthrough for establishing mappings. There are a couple things I want to explain further that I personally got confused with. After reading these clarifications, I would recommend rewatching the video for a better understanding.

1. ‘__c’

You may be asking why there are so many ‘__c’s that are appended at the end of my teacher object and teacher fields. Well, Salesforce actually appends this to each custom class/field.

So, tying back to my Rails project, the table name is now Teacher__c instead of Teacher and the columns/fields have changed from names like First_name, Last_name to _Firstname__c, _Lastname__c. Some default fields like sfid or createddate are not custom, so they don’t require appending ‘__c’.

2. Custom Fields

So, how do you create custom fields? Well, there’s actually a small arrow on the right side of your screen for you to edit objects and fields.

Click on view object/fields to modify them respectively.

After each modification, remember to check if you also need to modify your Heroku Connect mappings.

3. Two Way Syncing

I wanted to point out two very cool features about Heroku Connect’s Two-Way Syncing. The first is poll frequency, which regulates how often you want your Postgres database to update with Salesforce updates. Checking the Accelerate Polling box makes most operations pretty much instantaneous.

The second is the section on pushing data from your Postgres database to sync with the Salesforce database. You must check the box in order to have this feature work at all. However, right afterward, you will most likely see a warning pop up:

“Warning: Read-write mappings require a unique identifier to be specified.”

This is a layer of protection to ensure that you don’t accidentally create duplicate objects. It’s great if you have a unique identifier (in the video, each teacher has a unique email, so I made that my identifier). Otherwise, you can skip it and still have a functional Heroku Connect mapping. However, you may want to program your app to double check for existing records before creating an object.

Changes to your local Rails app

Now that you have your Heroku Connect all nice and set up, it’s time for a quick local adjustment before you can interact with your Salesforce data.

In overview, you will see the name of your schema, in this case “salesforce”. If you had picked a different name during the provisioning phase, that name would show up here instead.

Because my Rails app’s table name is still Teacher, I need to change it to Teacher__c to correctly reference the Salesforce data. I must change the table name to the format _schemaname._objectname or salesforce.teacher__c to reflect the changes.

The other notable change applies if your model has validated statements, like my Teacher model. Following the validates keyword, we still have the old field names like first_name without ‘c’ and last_name without ‘c’. We need to change those names by either appending the ‘__c’ to the old field names or by creating separate methods:

Afterwards, create some objects in Salesforce and open up your Rails console to retrieve this info. (In the video, I called Teacher.all to display all Salesforce Teacher objects in my Rails console.) The information should also be reflected in the Heroku Connect explorer.

Reflection

I spent a good half of my semester trying to figure out Salesforce integration. I did lots of research, experimented with different solutions, and plenty of support. In the end, it was a very enlightening experience to work with the cool features of Salesforce/Heroku/Rails. I also learned how much I’ve grown as a developer and reflect on my strengths and weaknesses.

Usually people implement the first solutions they find. They do this without understanding why it is good or bad. I researched and planned out three separate solutions before discovering Heroku Connect. Through this, I realized how important it was to weigh the pros and cons of different solutions before settling, even if more time is spent researching instead of implementing.

By using this knowledge, my team and I built an app to help teachers provide quality education for students in the Dominican Republic schools that have a poor connection to the Internet. We learned to persevere when times were hard because we knew that despite every long work session, every bug fix, every line of code, we had a mission, and every step of the way was another step towards improving the world.

This experience helped me to really prioritize the goal and the importance of doing quality work instead of immediately using the fastest way to go. Every solution is worth researching its pros and cons. It’s all about resilience and tenacity.

So to all developers out there, no matter what situation you’re in, don’t give up. Don’t be afraid of trying new solutions and failing. Stay positive and Happy Deving!

Wilson Wang is a junior at UC Berkeley studying computer science and data science. He is interested in developing software for improving business-customer relationships. Besides technology, Wilson is passionate about martial arts, architectural design, and landscape photography.

Thanks for reading! To learn more about Blueprint, follow us on Facebook and Instagram, and visit our website!