training – redpanthers.co

How to write maintainable routes in rails

coderhs — Sat, 17 Sep 2016 05:54:03 +0000

config/routes.rb is the gateway to your ruby on rails application. All request send by your users are directed to the appropriate code by the routes. Example:

match 'profiles', to: 'users#index', via: 'get'

When someone visits your-website.com/profiles then the request is taken to the Index action of the UsersController. Under that action you will get the index.html.erb. So using routes we have configured the UsersController to respond to the users request it is its responsibility to do it now. We can declare routes in various ways:

match 'profiles', to: 'users#index', via: 'get'
get 'profiles', to: 'users#index', via: 'get'
resources :users
resource :users, path: 'profiles'

Since there are multiple ways to declare routes (as all forms are right), its best to stick with a single method for the code to be more readable. routes.rb is going to be one of the most heavily edited file in your project as when ever you add a new page or create a new form, you need to add a route to access the page or an end-point to accept the request. So it is most likely that your routes.rb file will start to grow ugly:

  resources :saved_filters
  match "/404" => "errors#error404", via: [ :get, :post, :patch, :delete ], as: 'error404'
  devise_for :saas_admins
  mount RailsAdmin::Engine => '/saas_admin', :as => 'rails_admin'
  %w(about privacy benefits compliance onboarding payroll time_off terms contact aca-compliance).each do |page|
    get page => "content##{page.underscore}"
  end
  get "/not_authorized", to: 'errors#not_authorized'
  post '/broker_sign_in_path', to: 'application#broker_sign_in_domain', as: 'broker_sign_in_domain'
  post '/employer_sign_in_path', to: 'application#employer_sign_in_domain', as: 'employer_sign_in_domain'
  post '/messages/reply_from_external_user',to: 'messages#reply_from_external_user',as: '/messages/reply_from_external_user'
  # Routes for the public site

So here we will share some tips to write proper, maintainable routes: First important point to note is that, its best to write routes as resources eg:

resources :users

declaring resources will create the following 7 routes. if you don’t want some of these routes, then pass that as options while declaring

resource :users, only: [:create, :update, :show, :destroy]

Use nested routes, if you find yourself referring to a child model from parent.

resources :posts do
  resources :comments
end

If you want to declare custom routes, within the resources, the they should only be declared within the resource block. Note: Difference between Member and Collection Member: is used when the routes is meant to work on a single object (eg: DeActivate single user) Collection: is used when the route is meant as an action over a collection of object (eg: search for a user)

resources :users do
  member do
    match 'de_activate', to: 'user#de_activate', via: 'get'
  end
  collection do
    match 'search', to: 'user#search', via: 'post'
  end
end

Always write routes through match rather than defining as post/get, because in future you might have to add multiple HTTP verb for the same route and using match would eleminate multiple lines of the same route.]]>

Optimising PostgreSQL database query using indexes

coderhs — Thu, 11 Aug 2016 10:59:22 +0000

Database Indexes: Indexes are a special lookup table that the database search engine can use to speed up data retrieval. An Index is similar to a pointer to a particular row of a table. As a real world example, consider a Britannica Encyclopedia with 22 volumes of books, and an extra book listing the index,with which you can find out the item you are searching for in those 22 books. PostgreSQL 9.5, provides several index algorithms like B-tree, Hash, GiST, SP-GiST and GIN. When you create an index using Ruby on Rails migration, by default it would be using the B-Tree migration. Whereas, as we move on to the indexing algorithms, we need to check into the general classification of an index and the data to be indexed. Primary Keys In rails, when we generate a model , by default an ID column would be added to the table. It would have integers values and they would be unique as well. By default, when you set a column as a primary key, the database would build a unique index on it. So we don’t need to add migration for it. Foreign Keys When you build a relationship between two tables you add a foreign_key in the child table to point to parent, eg: user_id, group_id. We need to query through this relationship a lot in rails, for example to load all the comments of post or all members of a group. So we need to index that for speed.. If you are using some non id value to reference a table, lets say in your application ,you give all your users a unique URL which has the username. (Eg: http://csnipp.com/coderhs), in that case we would be using the username to query the data, so we need to have it indexed. In fact you should index all the columns you might be using in your where queries. Like if you are searching for users of a particular age or income frequents in your reports, then you should create an index for them as well. Note: What we explained above are single column indexes and multi column indexes. So if you are indexing just a single column in a table, its single column indexes.

CREATE INDEX index_name
ON prices (user_id);

Rails code:

add_index :prices, :user_id

When we index multiple columns, they are called multi column index.

CREATE INDEX index_name
ON user_views (user_id, article_id);

Rails code:

add_index :user_views, [:user_id, :article_id]

If you are joining two tables, using a column (which is not the already indexed foreign key) then you should index that as well. State column & Boolean column State and Boolean column are columns that should be indexed as there would be a lot of rows but only limited number of values in those columns. Boolean column would have only true or false (two values)and state columns will have more than two like eg: draft, published, pending. The speed of load would be faster for these columns as they are only limited keys that can be placed in the index, and on a single lookup we can load them. Partial indexes can be used in the above case, as the name suggests it’s an index over a subset of your table. The index would be building if it satisfies certain conditions. They can be most useful while writing scopes in rails. Lets say that you have a scope that picks up all the articles which are marked as SPAM. In your model you will write a scope like below

scope :articles, where(:spam => 'true')

So internally it’s a where query, one can add a partial index migration as follows:

CREATE INDEX index_name
on articles (spam is true);

Rails:

add_index :articles, :spam, name: "index_articles_on_spam", where: "(spam IS true)"

When not to use indexes Using indexes speeds up the SELECT and WHERE command, but it does slows down the execution of INSERT. So avoid indexing when we have table that has a lot of insert and update So we should avoid using Indexes when we have a table that holds a huge number of raw data, where we do a lot of batch updates and insert. For example, in an IoT application we would pipe all the data from multiple devices to a single table , summarize and insert it into its proper tables. And by a lot of data, I am referring to at least 10+ MB of data per minute. In most cases, we would just truncate that table after processing, hence it would slow us down if we were to index it. If the table is too small and you know it will always be small If you have a setting table which just stores the application settings, that can be modified by an admin panel. Then it doesn’t seem to be worth having an index there. When you are manipulating the values of a column a lot Lets say the particular value of a column gets changes extremely a lot, like the website view count. Then indexing it is not highly recommended. Finally to complete this article. If you want to drop an index: SQL

DROP INDEX index_name;

Rails

remove_index :books, :created_at

Summary:

Index Primary key
Index Foreign key
Index all columns you would be passing into where clause
Index the keys used to Join tables
Index the date column (if you are going to call it frequent, like rankings of a particular date)
Index the type column in an STI or polymorphism.
Add partial index to scopes
Do not index tables with a lot of read, write
Do not index tables you know that will remain small, all through out its life time
Do not index columns where you will be manipulating lot of its values.

Keep visiting here to know more about the PostgreSQL indexing algorithms in part 2 of this article. References: https://www.postgresql.org/docs/9.2/static/indexes-types.html http://dev.mysql.com/doc/refman/5.7/en/mysql-indexes.html http://www.tutorialspoint.com/postgresql/postgresql_indexes.htm]]>

Skip unnecessary files while running Rails Generate

coderhs — Wed, 27 Jul 2016 04:27:04 +0000

rails generate controller Home Index new create, would create the following set of files: As one knows from experience, the helper; javascript and stylesheet files are not always used. In fact, most of the time, we would have a single stye.scss, and main.coffee that would take care of 95% of the total behaviour of our application. So, if we do not delete those files after generation, we would just end up with a lot of files in our system which would have no code throughout the life cycle of the program. Fortunately, rails gives us the ability to customize its own generators so that we can disable these files from being generated. Once we place the below code in the application.rb, it will stop the generation of these extra files.

config.generators do |g|
  g.helper false
  g.stylesheets false
  g.javascripts false
  g.view_specs false
end

Now, when you run rails generate controller Home Index new create, you will get less files. ]]>

Counter Cache: How to get started

coderhs — Tue, 26 Jul 2016 10:40:48 +0000

number of tasks under a project or the number of comments in a post or the number of users in an organization or anything similar is a common requirement in most rails applications. The code for doing it is also simple- @project.tasks.count; but the problem with this code is that every time you run it, you are counting the number of tasks of that project one by one. So, the speed of execution decreases with more number of rows. This code will slow down your page load, if you are displaying the details of more than one project in your page as shown below. To speed this up, rails gives you an in-build mechanism called “Counter Cache“. As the name suggests, it literally means to cache the number of referenced rows it has (number of tasks a project has). Example code definition

class Projects < ActiveRecord::Base
  has_many :tasks
end
class Task < ActiveRecord::Base
  belongs_to :project
end

To implement counter_cache, you need to pass in the counter_cache: true option along with the belongs_to relationship. You also need to add a migration to add an extra column called tasks_count to store the count. This needs to be added to the other model, which has the has_many reference.

class Task < ActiveRecord::Base
  belongs_to :project, counter_cache: true
end

Migration

class AddTasksCounterCacheToProjects < ActiveRecord::Migration[5.0]
  def change
    add_column :projects, :tasks_count, :integer
  end
end

If you are adding counter cache to an existing system, you need to update your tasks_count with the existing counts. To do that, one can use the code given below. Either place the code along with the migration or run it in console in both production/development environments.

Project.find_each { |project| Project.reset_counters(project.id, :tasks) }

Also note that the tasks_count is just the default column name; if you wish to change it with another name, just pass that name along with the :counter_cache option as below.

class Task < ActiveRecord::Base
  belongs_to :project, counter_cache: :not_the_default_column_name
end

Now, to use the counter cache in your calculations, you should use the method “size” instead of “count”. The method “size” will use the counter_cache if its present, where as using “.count” itself would do the actual sql count.

<% Project.all.each do |project| %>
  <%= project.name %> (<%= project.tasks.size %>)
<% end %>

Points to Remember

:counter_cache is the optional attribute of a belongs_to relationship
It requires the creation of an extra column (tasks_count) in the table which has the has_many relationship
One can use another column name by passing the name along with :counter_cache option
To use the counter_cache, one must use the “.size” method

Speed Improvements ]]>