Category: Fedena

We covered some fundamental changes in environments of Fedena, Uzity and Flux covering CLI commands, Plugins, Gems, Asset pipeline, Bundler, Turbolinks, CoffeeScript and SASS in the  the first part. In this part, we will be covering about the changes seen in some other aspects of development and deployment, like ActiveRecord, Tags, ActionMailer etc.

Action Callbacks

Action callbacks are used mainly to prevent repetition of code in controllers by calling identical codes repeatedly. Rails  offers several action callbacks in controllers like before_filter, after_filter etc across all the three RoR environments we use. New alias methods have been added to action callbacks in rails 4, which enables us to use before_action, after_action etc. instead of before_filter, after_filter etc. However no sign of deprecation of these methods are shown.

ActionMailer

ActionMailer is used to send emails from a rails application. In rails 2.3, i.e in Fedena, ActionMailer is present as a Model. With the release of rails 3, ActionMailer was changed from model to a class and relocated to ‘app/mailers’ from ‘app/models’. This system remained unchanged in Rails 4. Also in Fedena, method prefixed with ‘deliver_’ was used  to send a mail. Calling method name as such is sufficient in Rails 3 and above. Uzity follows this method. ActionMailer has not been used in Flux.

Delayed_job

Delayed Job does not come by default in Rails. Delayed Job is a gem added manually. This was extracted from Shopify. Delayed Job can be used to execute time consuming process like preparing complex reports, sending emails etc. Delayed Job is used as a plugin in Fedena with some customizations. In Fedena delayed job is used to compile some reports, send emails etc. In Uzity, ‘delayed_job_active_record’ is used. This gives more control over queuing and priorities for jobs by naming queues and assigning priority in integer values. Delayed::Job.enqueue is used to append a Job to the delayed job in Fedena. In Uzity it can be done either by Delayed::Job.enqueue or by defining handling method in Models. ‘handle_asynchronously’ can be used to make a method execute as a Delayed Job. Delayed Job is not used in Flux so far.

PATCH Method

‘PATCH’ has been used as a primary method for ‘update’ in Rails 4. Both ‘PATCH’ and PUT are routed to ‘update’. PATCH is ideal for partial updation and for APIs. PATCH is a relatively new standard and what it does is that it applies a delta rather than entire resource updation.

Form Tags

Form in Fedena, used to have form written in a non-output syntax, like

<% form_for ...

This changed to syntax with output(with ‘=’ sign) from Rails 3 onwards like

<%= form_for ...

ActiveRecord Changes

ActiveRecord is responsible for mapping persistent data to ruby classes in a Rails application. It represents the ‘M’, i.e the Model in MVC Architecture. ActiveRecord usually goes through significant changes throughout every major and minor version updates of Rails. Some of such changes we see regularly between the operating environments of our applications are discussed here.

Query Engine

Querying mechanism has changed in Rails 3, increasing the flexibility of code in the controller. Several new methods like where, order, select etc were added. ‘where’ method was introduced, which can replace ‘find’ in queries. where returns an ActiveRecord::Relation. It is a collection of method objects unlike find which returns a single record or find_all which returns an array.

Throughout Fedena we use find and find_all for querying, with conditions specified either in the ‘Rails way’ or in SQL format, and returning data in arrays . In Uzity we got the new, ‘where’ and several other related methods in addition to find. In Uzity we use ‘find’ at some places where we expect the results to be in array format and with less data manipulations. In complex actions, we use the ‘where’ method so that we get an ActiveRecord Relation which we can keep on chaining till the expected result with lesser database calls. With Rails 4 several ‘find’ related methods saw deprecations by introduction of new methods and emphasis on ‘where’. So to avoid deprecation warnings and to be safe with future versions of rails we use the new finder methods in Flux.

Scopes

‘named_scope’ has been deprecated and changed to just ‘scope’ with Rails 3. The ‘conditions’ like we use in named_scopes also have to be changed to relation methods such as where, order etc. as mentioned previously. We use named_scopes and dynamic_scopes in all three applications, but tend to use it in very high frequencies in Uzity and Flux.

Query Chaining

Thanks to the ActiveRecord::Relation returned by latest methods starting from Rails 3, queries can now be chained with ease. The ActiveRecord relations returned by relational methods can be further queried many times. As a result, we tend to use more scopes in the models of both Uzity and Flux for pretty code and simpler and optimized queries. For example, if we add the scope ‘active’ and ‘open’ to the Task model, it is enough to use

Task.active.open.where(:id=>objective_id)

instead of

Task.find(:id=>objective_id,:is_deleted=>false,:status=>’open’)

or further longer

Task.find(:all,:conditions=>{:id=>objective_id,:is_deleted=>false,:status=>’open’})

ActiveRecord Store

ActiveRecord store was introduced in Rails 3.2. It is a simple key/value store. It stores a Hash as text, which is serialized upon load and save. It can be flexibly used to addition fields for a record. ActiveRecord Store is used to maintain notification count in Uzity.

Mass Assignment Controls

Along with the other security fixes, Rails also introduces several methods to prevent end user data. ‘attr_accessible’ and ‘attr_protected’, defined in Rails models were introduced in rails 3 to serve this purpose. These are basically blacklisting(attr_protected) and whitelisting(attr_accessible). This was made very strict by default in  Rails 3.2

With rails 4, a new method called ‘strong-parameters’ was introduced. The attributes are now protected from the controller part rather than from the model part, restricting the flow of parameters to the model. Only whitelisted parameters are permitted the flow. This however caused a lot of troubles dealing with nested forms and uploads in Flux at initial times until we got used to.

Migration Changes

Migrations remains more or less same throughout Rails 2.3 to Rails 4 with less number of deprecations. In Rails 2.3, i.e in Fedena, we had to write separate up and down migrations for each migration. In rails 3, writing ‘change’ migration was enough, but had trouble dealing with ‘change_tables’ and ‘drop_tables’. The change method was preserved in Rails 4 with fixes to ‘change_table’ and ‘drop_table’.

In general, while switching between projects in different versions of Ruby on Rails, it is very obvious that the application development is becoming easier with every new major versions of Rails. Rails 2.3 is like the essence of Rails among the three versions used. If we have experience developing in that environment, we can easily handle the newer versions without much problems apart from the initial lags.

This article is written by:

Sooraj T P
A hard core coder. A gadget freak. An unsung designer. There is hardly anything which Sooraj doesn’t talk about, be it tech, gadget, design, automobile or more. Sooraj is the “Tech Saint in making”.