Create your own scheduler within 10 minutes with Rails and dhtmlxScheduler

Today I am going to show you how to create a Google-like scheduler with your Rails application. Here we are going to  use dhtmlxScheduler. It is a Javascript event calendar. Intuitive drag-and-drop interface allows the end users to quickly manage events and appointments in different views: Day, Week, Month, Year, Agenda, Timeline, etc. For more info regarding dhtmlx click here.

Step- 1: Let’s first create a new Rails application for our scheduler

$ rails new my_scheduler

nishant@nishant26: ~_058

Step- 2: Create  a ‘Home’ controller

$ rails g controller home index


Step – 3 open config/routes.rb and replace as following

get ‘home/index’


root ‘home#index’

Step – 4 Start Rails server now and test it in your browser with http://localhost:3000

$ rails s


Step- 5 Now download the dhtmlxScheduler. Download open source from standard edition box. Now unzip the file

Add following files to vendor/assets/javascripts

and following files to vendor/assets/stylesheets


Then we need to create an assets folder in the public directory and copy following files there.


Now open config/initializers/assets.rb and add our newly added css and js to asset precompile settings:

Rails.application.config.assets.precompile += %w( dhtmlxscheduler.css )
Rails.application.config.assets.precompile += %w( dhtmlxscheduler.js )

Step – 6: Open views/layouts/application.html.erb and include include dhtmlxscheduler.js and dhtmlxscheduler.css

<%= stylesheet_link_tag ‘dhtmlxscheduler’, media: ‘all’, ‘data-turbolinks-track’ => true %>

<%= javascript_include_tag ‘dhtmlxscheduler’, ‘data-turbolinks-track’ => true %>

Step- 7: Now open your newly created home/index.html.erb.It will display our scheduler.

Now we add a container for our scheduler and initialize our event calendar

<div id=“scheduler_here” class=“dhx_cal_container” style=‘width:100%; height:800px;’>
<div class=“dhx_cal_navline”>
<div class=“dhx_cal_prev_button”>&nbsp;</div>
<div class=“dhx_cal_next_button”>&nbsp;</div>
<div class=“dhx_cal_today_button”></div>
<div class=“dhx_cal_date”></div>
<div class=“dhx_cal_tab” name=“day_tab” style=“right:204px;”></div>
<div class=“dhx_cal_tab” name=“week_tab” style=“right:140px;”></div>
<div class=“dhx_cal_tab” name=“month_tab” style=“right:76px;”></div>
<div class=“dhx_cal_header”>
<div class=“dhx_cal_data”>


Step- 8: Restart your server and check your browser at http://localhost:3000


Step- 9: So dhtmlxSheduler is initialized and we may proceed to further settings. Let’s create a model for an event.  Run the following command

$ rails g model Event start_date:datetime end_date:datetime text:string

Run database migration
$ rake db:migrate

Step- 10: Now open config/routes.rb and add another route for data loading

get “home/data”, to: “home#data”, as: :data

step : 11:
Open controllers/home_controller.rb and add ‘data’ action to it.

def data
  events = Event.all

  render json: {|event| {
    start_date: event.start_date.to_formatted_s(:db),
    end_date: event.end_date.to_formatted_s(:db),
    text: event.text

step -11
Add another route to perform antoher db relate action

get “home/db_action”, to: “home#db_action”, as: :db_action

def db_action
  mode = params[“!nativeeditor_status”]
  id = params[“id”]
  start_date = params[“start_date”]
  end_date = params[“end_date”]
  text = params[“text”]

  case mode
  when “inserted”
    event = Event.create :start_date => start_date, :end_date => end_date,     :text => text
    tid =

  when “deleted”
    tid = id

  when “updated”
    event = Event.find(id)
    event.start_date = start_date
    event.end_date = end_date
    event.text = text
    id = id
  render :json => {
    :type => mode,
    :sid => id,
    :tid => tid,


Step – 12- To save the changes in scheduler we need to use DataProcessor. Open app/views/home/index.html.erb.

var dp = new dataProcessor(“<%= db_action_path %>”);
dp.setTransactionMode(“GET”, false);

Now add following lines to your index.html.erb script tags:

scheduler.config.xml_date=”%Y-%m-%d %H:%i”;
scheduler.load(“<%= data_path %>”, “json”);
var dp = new dataProcessor(“<%= db_action_path %>”);
dp.setTransactionMode(“GET”, false);

If you want to use a post request for changing the data in your database, then you need to specify Transaction Mode dataProcessor = POST. Moreover, you need to change the corresponding route to:

post “home/db_action”, to: “home#db_action”, as: :db_action

And you need to add following line in your controllers/application_controller.rb

protect_from_forgery with: :null_session

instead of

protect_from_forgery with: :exception

Step- 15: Finally we are ready to see the result: run your server

$ rails s


The whole source code is availabe at my git repository.

All set! Now, go to your browser and start scheduling your day!!

Have a happy coding!!


Introduction to some Interesting gems!

Hi Guys, Yesterday I was reading an open source project code(errbit). Reading an open source project code improve your coding capabilities. It enhances your technical knowledge and code vocabulary. You may found some new coding patterns as well.

Today I am going to share some interesting gems which I found in that project. I have also created a demo app using some of those gems.

Here I listed out some of those gems:

1. actionmailer_inline_css :

Gmail doesn’t support <style> or <link> tags for HTML emails. Other webmail clients also have problems with <link> tags.
This means that CSS must be inlined on each element, otherwise the email will not be displayed correctly in every client.

Inlining CSS is a pain to do by hand, and that’s where the premailer gem comes in.

This actionmailer_inline_css gem is a tiny integration between ActionMailer and premailer.

2. decent_exposure :

Rails controllers are the sweaty armpit of every rails app. This is due, in large part, to the fact that they expose their instance variables directly to their views. This means that your instance variables are your interface… and that you’ve broken encapsulation.

decent_exposure makes it easy to define named methods that are made available to your views and which memoize the resultant values. It also tucks away the details of the common fetching, initializing and updating of resources and their parameters.

I have created a demo app to understand the use of this gem. Please refer my demo for more brief introduction.

3. Htmlentities :

HTMLEntities is a simple library to facilitate encoding and decoding of named (&yacute; and so on) or numerical ({ or Ī) entities in HTML and XHTML documents.

4. Hipchat :

HipChat is a group and private chat, file sharing and integration application. Here is the HipChat HTTP API Wrapper in Ruby with Capistrano hooks. You can find API documentation for HipChat here.

5. Flowdock :

Flowdock is a team collaboration app for desktop, mobile and web. Here is the Ruby gem for Flowdock.  You can refer API for Flowdock here.

6. Quiet_assets :

Most of the time while debugging in console we get frustrated with unnecessary logging statements of assets. This gem helps to mute assets pipeline log messages. Quite useful!

Importance of writing Test cases in an existing Rails Application

Hey guys!!

In my first article, I going to introduce you the importance of writing test cases(either with Rspec or minitest) with existing Rails Application and why one should write it?

Once you have created your Rails application and now you are quite excited with your bunch of code, files and directories. The only thing that you are missing now is Test cases??

Actually It’s not TDD(Test Driven Development) but It’s the way to learn TDD.

There are three important benefits by writing test cases:

1. You practice about thinking all cases and all possible conditions.
After writing enough tests, you will become aware of where is the possibility of breaking of methods, And as soon as you start TDD you can use this skill  to write robust tests to handle all possible cases of your application.

2. You get habituated with well structured tests.
Once you have done enough practice for writing tests, now you can apply different design patterns for structuring those tests.

3. You find the tests which are hard to  test.
As soon as you get more familiar, you will understand that which part of application is very hard to test and which part of the application is very easy to test. This will provide you the strength of analysis for future estimation of any project.

4. Tests are also very important while migration.
If your rails application has been written all possible test scenarios, then you can upgrade your rails application easily. You can upgrade it to any latest stable version.

Ease into TDD

Whenever you are testing your application,instead of clicking around in the browser to reproduce it, it better two write some cases.

Here is the flow of writing test cases:
a. Write a failing test
b. Run the test,
c. Fix the bug
d. Run the tests
e. Refactor tests

TDD is always preferable to write new rails application.(if you have enough time)

In my next post I will show you how to write tests? and how to pass them.

Have A Happy Coding!!!