It’s been too hard to deal with file uploads in Rails. There’s been a lot of fine plugins available, but it was overdue that we incorporated something right into the framework. Finally, we have one, in the form of Active Storage. This release includes Active Storage, a new framework provided by Rails to make it easier to upload and process files. With this new framework, we’ve solved for the modern approach of uploading files straight to the cloud. Out of the box, there’s support for Amazon’s S3, Google’s Cloud Storage, and Microsoft Azure Cloud File Storage. If you’re dealing with images, you can create variants on the fly. If you’re dealing with videos or PDFs, you can create previews on the fly. And regardless of the type, you can analyze uploads for metadata extraction asynchronously. This framework is not only used in production, but it is born for production.

There’s a sparkling new Redis Cache Storage that incorporates general partial, fragment, and other Rails caching jobs into a cohesive unit that anyone can use.

Rails 5.2.0 has Added support for PostgreSQL operator classes to add_index. The operator classes identify database operators to be used by the index for the columns. You can assign the same operator to all columns, or not. It currently only supports PostgreSQL.

Added ability to create PostgreSQL foreign keys without validation. Normally, PostgreSQL verifies that all rows in a table satisfy its foreign keys constraints. With this option, you can create these constraints without the overhead of checking if they are valid.

Rails 5.2.0 also has embraced the cherry of HTTP/2 with early hints. This means we can automatically instruct the web server to send required style sheet and JavaScript assets early. This means a faster page delivery.

On the topic of performance, Rails now ships with Bootsnap in the default Gemfile. This generally reduces application boot times by over 50%.

 CSRF and XSS have enhanced that further in Rails 5.2 with the addition of a new DSL that allows you to configure a Content Security Policy for your application. We can configure a global default policy and then override it on a per-resource basis and even use lambdas to inject per-request values into the header such as account subdomains in a multi-tenant application.

In Rails 5.2, we’ve rectified the mess by deprecating the two different kinds of secrets and introduced a new shared concept called Credentials. Credentials, like AWS access keys and other forms of logins and passwords, were the dominant use case for secrets. Credentials are always encrypted. This means they’re safe to check into revision control, as long as you keep the key out of it. This means atomic deploys and there is no need to mess with environment variables.

Since Rails 5.1, we’ve also made great strides with Webpacker. So Rails 5.2 is meant to pair beautifully with the new Webpacker 3.0 release. Rails have fully embraced modern JavaScript with a pre-configured build pipeline run by Webpack. We keep strengthening that relationship.

Thanks again to everyone who continue to pour their love and support into Ruby on Rails! Happy Coding.

Including MongoDB in CI build system

services:
- mongo:latest

Add the MONGODB_URI variable

variables:
MONGODB_URI: mongodb://mongo:27017/test_db

Add config/mongoid.yml ile

test:
  clients:
    default:
      uri: <%= ENV['MONGODB_URI'] %>

Override config/mongoid.yml with config/mongoid.yml.gitlab

before_script:
  - cp config/database.yml.gitlab config/database.yml

Summary

image: starefossen/ruby-node:latest
services:
  - mongo:latest
variables:
  MONGODB_URI: mongodb://mongo:27017/test_db
before_script:
  - RAILS_ENV=test bundle install --jobs $(nproc) "${FLAGS[@]}"
  - cp config/mongoid.yml.gitlab config/mongoid.yml
  - RAILS_ENV=test bundle exec rake db:create db:migrate
test:
  script:
    - bundle exec rspec

development:
  clients:
    default:
      database: dev_db
      hosts:
        - localhost:27017
      options:
        read:
          mode: :primary
        max_pool_size: 10
production:
  clients:
    default:
      uri: <%= ENV['MONGODB_URI'] %>
      pool_size: <%= ENV['DB_POOL_SIZE'] %>
test:
  clients:
    default:
      database: test_db
      hosts:
        - localhost:27017
      options:
        read:
          mode: :primary
        max_pool_size: 1

test:
  clients:
    default:
      uri: <%= ENV['MONGODB_URI'] %>

Multi-tenancy

Advantages

• Shared infrastructure lead to lower costs by sharing same power resources and software across its clients.
• In single-tenant applications, you have to manage different sets for each client while in multitenant applications you have to monitor and provide administration for a single platform only.
• Entire system becomes more scalable
• Upgrading the software version and installation becomes easier for multitenant applications.
• Easier to add new clients.
• Configuration can be changed without touching codebase.
• Easy maintenance

Multi-tenancy on the database layer or model layer

• apartment tenancy on database layer: https://github.com/influitive/apartment.
• actsastenant tenancy on model layer: https://github.com/ErwinM/actsastenant.

Using Apartment gem

Let’s create a new Rails app

rails new blog-post -d postgresql

cd blog-post

bundle exec rake db:create

Adding the Apartment gem to your Gemfile

Now open up the Gemfile in your rails app and add,

gem 'apartment'

Now generate the apartment config file,

bundle exec rails g apartment:install

This will create a config/initializers/apartment.rb file as the configuration file for us. There is a bunch of configuration stuff to use.

Create the model

For example usage, we will be creating models author and post.

bundle exec rails g model user name

bundle exec rails g model article content

class CreateUsers < ActiveRecord::Migration[5.1]
  def change
    create_table :users do |t|
      t.string :name, null: false
    end
    add_index :users, :name, unique: true
  end
end

validates :name, presence: true, uniqueness: true

bundle exec rails db:migrate

class User < ApplicationRecord
  validates :name, presence: true, uniqueness: true
  after_create do |user|
    Apartment::Tenant.create(user.name)
  end
  after_destroy do |user|
    Apartment::Tenant.drop(user.name)
  end
end

Specify common models

--------------------------
Apartment.configure do |config|
# Add any models that you do not want to be multi-tenanted, but remain in the global (public) namespace.
# A typical example would be a Customer or Tenant model that stores each Tenant's information.
config.excluded_models = %w{ User }
--------------------------

Specify tenant names

config.tenant_names = lambda { User.pluck(:name) }

Specify a middleware

Rails.application.config.middleware.use Apartment::Elevators::Subdomain

See it works

User.create (name: 'Angel')
User.create (name: 'Sam')

Apartment::Tenant.switch!('Angel')

Article.create(content: "Angel’s article")
Article.all
=> #<ActiveRecord::Relation [#<Article id: 1, content: "Angel’s article",
created_at: "2018-01-09 09:30:15", updated_at: "2018-01-09 09:30:15">]>

Apartment::Tenant.switch!('Sam')
Article.all
=> #<ActiveRecord::Relation []>

User.all
=> #<ActiveRecord::Relation [#<User id: 1, name: "Angel">, #<User id: 2, name: "Sam">]>

References

• https://github.com/influitive/apartment

Client libraries are developed by API developer or the community.

There are several HTTP client libraries in Ruby such as:

• HTTParty

• Faraday

• Built-in Net::HTTP

• Rest-Client

• HTTPClient

Among them, the favorite of mine is Faraday gem. Faraday has adapters for popular libraries like Net::HTTP. It is simple, flexible and supports multiple backends and embraces the concept of Rack middleware when processing the request/response cycle. Also, it’s possible to customize its behavior with middleware. We will use a connection object to start with Faraday as it’s more flexible way than a simple getrequest.

conn = Faraday.new
response = conn.get 'http://localhost:3000/tasks'

Using this connection object, we make HTTP requests.

params = {:title => 'Faraday gem', :created_by => 'blog'}
conn.post('http://localhost:3000/tasks',params)

This will POST  title = ‘Faraday gem’  and created by = ‘blog’ to http://localhost:3000/tasks. All HTTP verb methods can take an optional block that will yield aFaraday::Request object.

 conn.post do |req|
   req.url '/tasks'
   req.headers['Content-Type'] = 'application/json'
   req.body = '{"some": "content"}'
 end

Authentication

Basic and Token authentication are handled by Faraday::Request::BasicAuthentication and Faraday::Request::TokenAuthentication respectively. These can be added as middleware manually or through the helper methods.

conn.basic_auth('username', 'password')
conn.token_auth('token')

Proxies

To specify an HTTP proxy:

Faraday.new(:proxy => 'http://proxy.example.com:80/')

Using a different HTTP Adapter

Faraday provides an interface between our code and adapter. Sometimes we may want to use features that are not covered in Faraday’s interface. In such cases, we can have access to features specific to any of the adapters supported by Faraday, by passing a block when specifying the adapter to customize it. For example, you can switch to the HTTPClient adapter as below

 conn = Faraday.new do |builder|
   builder.adapter :httpclient do |client| # yields HTTPClient
     client.keep_alive_timeout = 20
   end
 end

Like this, we can switch to any of the supported adapters. The block parameters will change based on the adapters we are using.

Faraday::Connection object middlewares

A Faraday::Connection object has a list of middlewares, just like a Rack app. Faraday middlewares are passed as an env hash. It has request and response information.

conn = Faraday.new
conn.builder
=> #<Faraday::RackBuilder:0x0000000155d1f0 @handlers=[Faraday::Request::UrlEncoded,
   #Faraday::Adapter::NetHttp]>

Faraday::Builder is similar to Rack::Builder. A new Faraday::Connectionobject is initialized. It has middlewares Faraday::Request::UrlEncoded in front of an adapter Faraday::Adapter::NetHttp.  Like a Rack application, the adapter at the end of the builder chain is what actually executes the request. Middlewares are grouped into request middlewares, response middlewares, and adapters.

Faraday.new do |builder|
  builder.request :retry
  builder.request :basic_authentication, 'login', 'pass'
  builder.response :logger
  builder.adapter :net_http
end

Advanced Middleware Usage

The order in which middleware is stacked in Faraday is like in Rack. The first middleware on the list wraps all others, while the last middleware is the innermost one, so that’s usually the adapter.

conn = Faraday.new(:url => 'https://redpanthers.co/') do |builder|
  # POST/PUT params encoders:
  builder.request :multipart
  builder.request :url_encoded
  builder.adapter :net_http
end

Middlewares stack is manipulated by the Faraday::Builder instance. Each Faraday::Connection instance has a Faraday::Builder instance.

conn = Faraday.new
conn.builder.swap(1, Faraday::Adapter::HTTPClient)
# replace adapter
conn.builder.insert(0, MyCustomMiddleware)
# add middleware to beginning
conn.builder.delete(MyCustomMiddleware)

Writing middleware

Middlewares are classes that respond to call. When middleware is executing, it’s passed as an env hash that has request and response information. Middleware wrap the request/response cycle. The general interface for a middleware is:

class CustomizedMiddleware
  def call(env)
    # do something with the request
    @app.call(env).on_complete do |env|
    # do something with the response
    end
  end
end

All processing of the response should be done in the on-complete block. This enables middleware to work in parallel mode when many requests are occurring at the same time. After the on_complete block, env[:response] is filled in. Faraday::Response instance will be available only after `on_complete`.
faraday-middleware  is a collection of various Faraday middlewares for Faraday-based API wrappers.
For testing middleware, Faraday::Adapter::Test is an HTTP adapter middleware that lets you to fake responses.

References

• https://github.com/lostisland/faraday

]]>

file = File.new("file.txt", "w")

Opening Existing Files

file = File.open("temp.txt")

file.close

Reading and Writing Files

sysread Method:

file = File.new("input.txt", "r")
if file
   content = file.sysread(10)
   puts content
else
  puts "cannot open the file"
end

syswrite Method:

file = File.new("input.txt", "r+")
if file
   file.syswrite("Hello")
else
   puts "Unable to open file!"
end

each_byte Method:

file = File.new("input.txt", "r+")
if file
   file.syswrite("ABCDEF")
   file.each_byte {|ch| putc ch }
else
   puts "Unable to open file!"
end

IO.readlines Method:

arr = IO.readlines("input.txt")
puts arr[0]
puts arr[1]

IO.foreach Method:

IO.foreach("input.txt"){|block| puts block}

Renaming and Deleting Files

File.new("tempfile.txt", "w")
=> #<File:tempfile.txt>
File.rename("tempfile.txt", "newfile.txt")
=> 0
File.delete("newfile.txt")
=> 1

References

• https://www.tutorialspoint.com/ruby/ruby_input_output.html
• http://www.techotopia.com/index.php/Working_with_Files_in_Ruby
• https://ruby-doc.org/core-2.2.2/File.html

When should we refactor?

class WebsitesController < ApplicationController
  def create
    create_website
    find_or_create_user
    fetch_rank
    redirect_to root_url
  end
  def destroy
    .........
  end
.............
  private
  def create_website
    @website = website.first_or_create
    CollectionWebsite.create(collection_id: collection_id, website_id: website.id)
    @website.fetch_meta_description
  end
  def find_or_create_user
    site_urls = user.websites.map(&:url)
    websites_count = user.websites.count
    user.update!(sites: site_urls, site_number: websites_count)
  end
  def fetch_rank
    return if website.alexaranks.any?
    FetchRankJob.perform_later(website)
  end
 end

Moving a big controller’s action to service objects

class WebsitesController < ApplicationController
  def create
    Websites::Create.call(website_params, current_user)
    redirect_to root_url
  end
  ..........
  def destroy
    Websites::Delete.call(website_params, current_user)
    redirect_to root_url
  end
  ..........
  private
  def website_params
    params.require(:website).permit(:url, :collection_id)
  end
end

module Websites
  class Create
    # From the controller, use it like this:
    # Websites::Create.call(params, user)
    def self.call(params, user)
      new(params, user).call
    end
    def initialize(params, user)
      @params = params
      @user = user
      @website = Website.where(url: params[:website][:url])
    end
    def call
      create_website
      find_or_create_user
      fetch_rank
    end
    private
    attr_reader :params, :user, :website
    def create_website
      @website = website.first_or_create
      CollectionWebsite.create(collection_id: collection_id, website_id: website.id)
      @website.fetch_meta_description
    end
    def find_or_create_user
      site_urls = user.websites.map(&:url)
      websites_count = user.websites.count
      user.update!(sites: site_urls, site_number: websites_count)
    end
    def fetch_rank
      return if website.alexaranks.any?
      FetchRankJob.perform_later(website)
    end
  end
end

While refactoring, at each step we have to make sure that none of our tests failed.

Partials and helpers

<% if @user && @user.post.present? %>
  <%= @user.post %>
<% end %>

module SiteHelper
  def user_post(user)
    user.post if user && user.post.present?
  end
end

<%= user_post(@user) %>

References

• https://github.com/adamniedzielski/service-objects-example

$ rails generate
Usage: rails generate GENERATOR [args] [options]
...........
Rails:
assets
channel
controller
generator
helper
integration_test
jbuilder
job
mailer
migration
model
resource
responders_controller
scaffold
scaffold_controller
task
.............

• controller: The Rails controller coordinates the interaction between the user, the views, and the model.
• helper: Code in helpers is included in the corresponding view. We can move big loops, method calls or other logic into a method in the helper.
• mailer: It allows for sending and receiving emails from and to your application.
• migration: Rails Migration allows you to use Ruby to define changes to your database schema.
• model: It is Ruby class that talk to the database, store and validate data, perform the business logic.
• scaffold: It refers to the auto-generation of a simple set of a model, views and controller usually for a single table.

-h, [–help] # Print generator’s options and usage -p, [–pretend] # Run but do not make any changes -f, [–force] # Overwrite files that already exist -s, [–skip] # Skip files that already exist -q, [–quiet] # Suppress status output

Generators

• rails generate model ModellName

It generates the model and the associated database table. For example, we can add a new model to the app called User with fields name and age as,

Eg:  rails g model User name: string age: integer

• rails generate controller ListController show edit

It generates controller. It is used if you are creating static views or non-CRUD related features. Let’s create a user controller that will manage the data flow and view for each users.

Eg:  rails g controller users

• rails generate scaffold ModelName ControllerName

Generates Scaffold. Let’s create a scaffold User with edit and view actions.

Eg:  rails g scaffold User edit view

• rails generate migration AddNewTable

Generates Table to migrate. We can create migration for adding a table as

Eg:  rails g migration User

• rails generate plugin PluginName

Generates Plugin.

Eg:  rails g plugin rails_plugin

• rails generate integration_test TestName

Generates Integration Test.

Eg:  rails generate integration_test User

• rails generate session_migration

Generates Session Migration.

Creating Generators with Generators

$ rails generate generator initializer
 create lib/generators/initializer
 create lib/generators/initializer/initializer_generator.rb
 create lib/generators/initializer/USAGE
 create lib/generators/initializer/templates

class InitializerGenerator < Rails::Generators::NamedBase
  source_root File.expand_path("../templates", __FILE__)
end

First, notice that we are inheriting from Rails::Generators::NamedBase instead of Rails::Generators::Base. This means that our generator expects at least one argument, which will be the name of the initializer.

Customizing Rails generators

config.generators do |g|
  g.orm :active_record
  g.template_engine :erb
  g.test_framework :test_unit, fixture: false
  g.stylesheets false
  g.javascripts false
end

References

• https://learn.co/lessons/rails-generators-readme
• https://www.tutorialspoint.com/ruby-on-rails/rails-generators.htm
• http://www.agmprojects.com/blog/building-a-rails-generator-and-packing-it-into-a-gem

1. Database independent tests

class Student < ActiveRecord::Base
  .
  .
  def name
    first_name +" "+ last_name
  end
end

describe Student do
  let (:student) {create(:student, first_name: 'Red', last_name: 'Panther')}
  it 'should return name' do
    student.name.should == 'Red Panther'
  end
end

let(:student) {create(:student, first_name: 'Red', last_name: 'panther')}

let(:student) {build_stubbed(:student, first_name: 'Red', last_name: 'Panther')

group: production do
  gem 'activemerchent'
end
group :test, : development do
  gem 'capybara'
  gem 'rspec-rails'
  gem 'byebug'
end

before(:each) do
  @article = create(:article)
  @author = create(:author)
end

before(:all) do
  @article = create(:article)
  @author = create(:author)
end

FactoryGirl.build_stubbed(:student)

RSpec.configure do |config|
 
  config.before(:suite) do
    DatabaseCleaner.clean_with(:truncation)
  end
 
  config.before(:each) do
    DatabaseCleaner.strategy = :transaction
  end
 
  config.before(:each) do
    DatabaseCleaner.start
  end
 
  config.after(:each) do
    DatabaseCleaner.clean
  end
 
end

References

• https://github.com/grosser/parallel_tests
• https://github.com/thoughtbot/factory_girl
• https://circleci.com/
• https://github.com/DatabaseCleaner/database_cleaner

Concurrency Abstractions

• Async (Concurrent::Async): A mixin module that provides simple asynchronous behavior to a class, turning it into a simple actor.
• Future (Concurrent::Future): An asynchronous operation that produces a value. It represents a promise to complete an action at some time in the future.
  • Dataflow: Built on Futures, Dataflow allows you to create a task that will be scheduled when all of its data dependencies are available.
• Promise (Concurrent::Promise): Similar to Futures, with more features. It represents the eventual value returned from the single completion of an operation.
• ScheduledTask (Concurrent::ScheduledTask): Like a Future scheduled for a specific future time.
• TimerTask (Concurrent::TimerTask): A Thread that periodically wakes up to perform work at regular intervals.

Installation

gem install concurrent-ruby

gem 'concurrent-ruby', require: 'concurrent'

Edge Gem Installation

gem install concurrent-ruby-edge

gem 'concurrent-ruby-edge', require: 'concurrent-edge'

Usage

require 'concurrent'

require 'concurrent-edge'

require 'concurrent-edge'
class Hello
  def greet
    sleep 3
    "Hello, #{Time.now}"
  end
end
all_promises = Concurrent::Promises.zip(
  Concurrent::Promises.future { Hello.new.greet },
  Concurrent::Promises.future { Hello.new.greet }
)
all_promises.then { |*values| puts values.inspect }.value

Hello, 2016-12-09 08:56:51 +0530
Hello, 2016-12-09 08:56:54 +0530

References

• https://github.com/ruby-concurrency/concurrent-ruby
• https://blog.engineyard.com/2013/ruby-concurrency
• https://github.com/ruby-concurrency/concurrent-ruby/blob/master/doc/thread_pools.md

CREATE YOUR CUSTOM LOGGER

# lib/custom_logger.rb
class CustomLogger < Logger
  def format_message(severity, timestamp, progname, msg)
    "#{msg}\n"
  end
end
logfile = File.open(RAILS_ROOT + '/log/custom.log', 'a') #create log file
logfile.sync = true #automatically flushes data to file
CUSTOM_LOGGER = CustomLogger.new(logfile) #constant accessible anywhere

• Severity of the log message
• Time instance representing when the message was logged
• progname configured or passed to the logger method
• Object the user passed to the log message.

LOAD CUSTOMLOGGER FROM ENVIRONMENT

#in any controller, view or model like,
CUSTOM_LOGGER.info("info from custom logger")
CUSTOM_LOGGER.add(Logger::FATAL) { 'Fatal error!' }
CUSTOM_LOGGER.fatal("Some arguments are not given.")
CUSTOM_LOGGER.error ("Argument #{@name} mismatch." )
CUSTOM_LOGGER.debug("This is a " + potentially + " expensive operation")

References

• https://ruby-doc.org/stdlib-2.1.0/libdoc/logger/rdoc/Logger.html