rails on Andrés Álvarez

Easy Notification System in Rails Part 3

Tue, 12 Sep 2017 00:00:00 +0000

Read part 1 and part 2 of this series

In this post, we will be sending automatic e-emails every time notifications are created.

Creating the Mailer

We will work with one mailer that will send e-mails for every notification that is created. We can generate our mailer with this command:

rails g mailer NotificationsMailer

Our mailer will contain an action for each notifiable type that works with notifications in our application. In this series, we've been using comments and posts as examples.

Easy Notification System in Rails Part 2

Tue, 05 Sep 2017 00:00:00 +0000

Read Part 1 of this series here

In Part 1 we learned how to setup our models and controllers to create notifications using callbacks in our application. Then we displayed these notifications in a Bootstrap 3 navbar using JQuery written in CoffeeScript.

In this post we will be adding more functionality to our notification system.s

Mark as Read Feature

We will be adding a feature that allows the current user to mark a notification as read as well as all notifications, in the following manner:

For a single notification, it should be marked as read when it is clicked from the list of notifications.
For all notifications, they should be marked as read when a specific button is pressed.

Setting up the Routes

Let's begin adding the necessary routes. In part 1 we defined a notifications resource. We will add a collection POST route and a member POST route of the same name:

# config/routes.rb
Rails.application.routes.draw do
  # ...

  resources :notifications, only: [:index] do
    post :mark_as_read, on: :collection
    post :mark_as_read, on: :member
  end

end

Easy Notification System in Rails

Mon, 04 Sep 2017 00:00:00 +0000

Having a notification system is very common for a web application. In this post I will go over how to implement your own simple and easy notification system for your Rails application.

This post is heavily inspired by Chris Oliver's In-App Navbar Notifications tutorial, with a few personal changes and additions.

Read part 2 of this series.

Models and Routes

Before starting with the models, lets quickly define the application resources in our routes:

# config/routes.rb
Rails.application.routes.draw do

  devise_for :users

  resources :posts do
    resources :comments
  end

  resources :notifications, only: [:index]

end

The Notification Model

We will manually generate the notification model which will handle the storing of notifications in the database. We can generate a very basic model like this:

rails g model Notification recipient_id:integer actor_id:integer read_at:datetime action:string notifiable_id:integer notifiable_type:string

Here is an explanation for some of the fields for the above model:

recipient_id: Represents the user in your application which will receive the notification.
actor_id: Represents the user in your application which triggered the notification.
read_at: The time when the notification was read. A value of nil is used for unread notifications.
notifiable_id: The object that represents this notification (a post, comment, etc). This will be a polymorphic association.
notifiable_type: Type of the notifiable object. This is usually represented by a humanized (and optionally, internationalized) string form of the object's class.

Integrating Devise With Rolify in Rails

Thu, 24 Aug 2017 00:00:00 +0000

I have searched through tons of StackOverflow questions and blog posts on how to properly integrate Rolify with Devise when registering as a new user through the registration view provided by Devise. All proposed solutions and half-solutions seemed very messy to me, but I found a very simple way to achieve this.

Preparing the Roles

Assuming you already have initialized a Devise User model along with a Rolify Role model, a very common question I see is how should the roles be prepared so that the new users can have a list of already created roles to choose from when registering? In the Rolify documentation, most (if not all) examples involve implicitely creating roles by adding roles to user in the Rails console:

user = User.find(1)
user.add_role :admin

A new admin role will be created if it does not exist already. But in a fresh application, with no users, a list of existing roles should be available in order to register.

Answers to this dilemma involve different approaches. I personally prefer creating them when seeding the database:

# db/seeds.rb

Role.create!(name: 'admin')
Role.create!(name: 'doctor')
Role.create!(name: 'nurse')

Select2 With Simple Form in Rails

Mon, 14 Aug 2017 00:00:00 +0000

Select2 is a great JQuery plugin that customizes your select boxes to give a better user interface and experience.

Recently while working on a Rails project, I was experiencing some problems when using Select2 and Simple Form in my view.

In the view, I want to use Select2 to search for people in a Person table in the application's database. Select2 should use AJAX to hit a controller's action that performs the search. The user can then select one of the results found and it will be added to the field as a token (this is a multiple select field).

The controller action looks something like this:

def search
  @people = Person.all.where('name LIKE ? OR last_name LIKE ?',
    "%#{params[:q]}%", "%#{params[:q]}%")

  respond_to do |format|
    format.json { render json: @people.map { |p| { id: p.id, full_name: p.full_name } } }
  end
end

Testing JSON API Strong Parameters in Rails

Thu, 25 May 2017 00:00:00 +0000

Recently I was experiencing a problem with a Rails API where I would update a model with new attributes, and then proceeded to add the new attributes to the model's factory, and then add the corresponding model and request specs.

The problem was that I would forget to whitelist the new attributes in the controller. Then running the request specs would not detect the error since I only test against one updated attribute that was whitelisted long ago. This became really annoying since I had no way to know if the new attributes were being whitelisted or not, and my tests weren't saying anything about it. This problem becomes even more apparent when the list of whitelisted attributes starts becoming very long.

In an API following the JSON API specification, here is an example of how the strong parameters method would look like:

def thing_params
  params.require(:data).require(:attributes).permit(:color, :size, :age, :name,
      :owner, :origin, :location, :purpose, :price, :alive)
end

As you can see, the list of attributes is getting pretty long. And we do not want to explicitly keep adding more attributes to the test.

Testing Strong Parameters in Controller Specs

After the release of Rails 5 I started ditching controller specs in favor of request specs. I like this approach and I think it's great, but I think it would be too much unecessary work to test that all the necessary attributes are whitelisted, in the request spec. Therefore I proceeded to create very simple controller specs that would test that all attributes of importance are whitelisted in the controller.

Testing a Rails API With RSpec

Mon, 15 May 2017 00:00:00 +0000

As I continue to improve me API testing skills in Rails, I have come to point where I really feel comfortable with all the tools I need to correctly add useful tests to my API. This post explains how I usually test my Rails APIs using RSpec.

Setting Up the Necessary Tools

In addition to RSpec, there are a few tools that make my testing experience much easier. These are:

After Adding these gems to the Gemfile. I proceed to create a /support directory under the /spec directory. This directory will contain the additional configuration of the above tools, as well as some helper definitions that our specs will use.

/spec/support/shoulda.rb:

Shoulda::Matchers.configure do |config|
  config.integrate do |with|
    # Choose a test framework:
    with.test_framework :rspec

    # Or, choose the following (which implies all of the above):
    with.library :rails
  end
end

Rails API With Nested Resources

Mon, 08 May 2017 00:00:00 +0000

Cocoon is a very popular gem to add nested resources functionality in Rails. It allows you to add or remove “mini forms” of another model into a main model's form and create all objects at once when the form is saved.

I was recently finding myself trying to implement a similar functionality using only Rails 5 API and JSON API specification.

As an example, we will try to implement the commonly seen Work Experience and Educational Background features seen in sites such as LinkedIn, where the user can add many items for these categories. The user's profile and all items for those categories (which are separate models) should all be saved at once, once the form is submitted.

accepts_nested_attributes_for

accepts_nested_attributes_for allows us to save attributes on associated records (work experience, educational background) through a parent record (user). By default nested attribute updating is turned off and you can enable it using the #accepts_nested_attributes_for class method.

Using Rails With Webpack in Cloud 9

Mon, 03 Apr 2017 00:00:00 +0000

The rails/webpacker project allows integration of Webpack with a Rails application. However, setting this up in a Cloud 9 development environment needs a few tweaks to be able to work correctly. This post explains how to achieve this.

Creating the Application

We will first create a regular Rails application and then use the webpacker gem to install Webpack.

rails new webpack-app

Add the gem to Gemfile:

# Gemfile

gem 'webpacker', github: 'rails/webpacker'

Install Webpacker

rails webpacker:install

Using Objects and Ranges With Cases in Ruby

Wed, 29 Mar 2017 00:00:00 +0000

Ruby's case statement provides some nice functionality to be used with objects and ranges. I was recently developing a small application in Ruby on Rails using blood test data where I had to check if a certain test item (i.e. HDL Cholesterol) value belonged to a certain range. I did not want to use a bunch of if statements and I actually found a pretty neat way to implement using the Ruby case.

In my application I have a Rails model called Entry which represents a blood test result with a lot of field data such as blood glucose level, blood pressure level, etc. etc. I want to display this data in the view using Bootstrap 3's nice progress bars and I want the progress bar's contextual class to be changed and determined by the range in which this data point sits in.

If we take total cholesterol as an example, a quick Google search indicates that an ideal value would be less than 200 mg/dL, a high value (not good) would be between 200-239 mg/dL, and a very high value (definitely not good) would be above 240 mg/dL.

To implement this, I created a Recommendations module under the /models directory. All classes belonging to this module will have different ranges to represent what I explained above. This is what the model directory tree looks like:

app/models/
├── application_record.rb
├── concerns
├── entry.rb
├── recommendations
│   ├── blood_glucose.rb
│   ├── diastolic_pressure.rb
│   ├── hdl.rb
│   ├── ldl.rb
│   ├── systolic_pressure.rb
│   └── total_cholesterol.rb
└── user.rb

Integrating TravisCI With Rails and Heroku

Tue, 07 Mar 2017 00:00:00 +0000

Adding TravisCI to your application's deployment flow will enable you to spot any build fails or test fails during deployment without affecting your production environment.

In this post I go over on how to integrate TravisCI with a Rails 4 application that uses Postgresql, Rspec, and is later deployed to Heroku if the Travis build is successful.

Setting up TravisCI

Assuming you already have an account in TravisCI, look for the Github repository of the Rails application and enable it. Then we will want to add a .travis.yml file to the application's root directory with the following contents:

language: Ruby
rvm:
  - 2.3.0

The configuration above tells TravisCI that our application will use Ruby 2.3.0. Once you commit and push the change above to the master branch, Travis will begin creating the build, which might take a few minutes.

Configure Postgresql

Seems our Rails application uses Postgresql, we need to configure TravisCI to run our build with a Postgresql database. To do this we will add the following configuration to .travis.yml:

services:
  - postgresql

Then we will add another configuration that will make Travis create a Postgresql database with username postgres and blank password for the build:

before_script:
  - psql -c 'create database travis_ci_test;' -U postgres