These days you have way too many options, tools, gems, transpilers, compilers, modules and frameworks to make javascript work with your Rails application. I wanted a simple and useful way to keep my code clean and organized.

I use several concepts which I will be explaining in the following sections. I hope you will find it helpful for your projects.

First of all, some heads-ups, I still use Sprockets and the Assets Pipeline, I believe we will all be using Webpack in the near future but so far, my experience with it brought me more pain than gain.

I've dropped jQuery and embraced ES2015, Sprockets didn't play nice with ES2015 Modules so I keep on using the Revealing Module Pattern, which works pretty well for me.

In summary,

• No jQuery
• No Webpack
• Plain ECMAScript
• Sprockets-Asset Pipeline
• No ES Module syntaxes
• No ES classes

And these are the topics I tend to cover in the next posts

1. Namespacing
2. Revealing Module Pattern
3. Mutation Observer
4. Fetch
5. HTML & M10n
6. AJAX
7. Form submission

I've created these modules to be used in a Rails application but they can also be uses in a plain HTML/JS page.

[1] Namespacing

One of the issues you may have if you are not careful writing JavaScript is polluting the global space. As your app becomes bigger you may start suffering name collisions in your code.

In order to keep my code clean, I use namespaces and directories structure,

└─ myApp/
   └── assets/
       ├── javascripts/
       │  ├── myApp/
       │  │   ├── controllers/
       │  │   ├── core/
       │  │   └── dom/
       │  ├── myApp.init.js
       │  └── myApp.js
       └── application.js

Where myApp is the name of the Rails application. Inside /assets/javascripts/ you can use any name, I usually use the same application name. So far, I use three main directories controllers, core and dom, I will explain later how I use them.

Finally I use two initialization files myApp.js and myApp.init.js.

The application.js file is the standard sprockets manifesto file.

The Root File - myApp.js

The only responsibility of this file is to set all the namespaces. The convention is one namespace per directory.

window.myApp = {};  
window.myApp.Core = {};  
window.myApp.DOM = {};  
window.myApp.Controllers = {};  `  

The Manifest - application.js

As said before, this is the standard Sprockets manifesto file. We don't have anything yet to include from within the directories, only the root files. myApp.init file will be explained in the next section, Revealing Module Pattern.

It is worth mentioning that the first required file is vendor.js. This is a manifest file I add in a vendor directory at the Rails app root. I find very usefull to keep all 3rd party scripts separated.

//= require vendor
//= require myApp/myApp
//= require myApp/myApp.init
//= require myApp/dom/...
//= require myApp/core/...
//= require myApp/controllers/...

If you are including the 3rd party scripts in this fashion, remember to add the path to the Assets paths in your assets.rb file

Rails.application.config.assets.paths << Rails.root.join("vendor", "assets")  

[2] Revealing Module Pattern

I won't be explaining this pattern here. You can find all you need to know at Todd Motto's blog - Mastering The Module Pattern.

In the scaffolding below, myApp is the name of your application (or the name of your choice) and myNS is the namespace where you want your module to be, don't forget to create the directory in the file tree and create the namespace in the root file.
I called the module with window.myApp so I have all the functionality available without polluting the global space.

window.myApp.myNS.myModule = ((myApp) => {  
  const settings = {
    settingName: settingValue
  };

  const actionName = () => {
    // do something
  };

  return {
    settings, publicActionName: actionName
  };
})(window.myApp);

If you need to use JQuery you can include jQuery as a parameter in the module and have its functionality available within the module. It would go like this,

window.myApp.myModule = ((myApp, $) => {   })(window.myApp, window.jQuery);

I always add a settings hash at the beginning of every module, I find it useful for configuring the module behaviour. Then come the actions, this is where the stuff is done.

Finally, the return section of the pattern, where the private is made public. You may want to change the name, if you wish to keep the same name just write it once, privateName: privateName is not necessary.

Initialization file - myApp.init.js

The initialization file allows you to run any required process before anything else.

Again, myApp is the current namespace and Init is the module name. The initialization file is one of the simplest modules. On its more basic form, it has only one goal, to kick off the Observer. This nice guy will enable us to do very useful stuff but, we will talk about it in the next section. Needless to say, I've added a method to be executed at the action start for illustrative purporses. Notice I kept the _welcomeMessage method private, it won't be available for the rest of the modules.

As mentioned before, this is your opportunity to add any action you wish to execute before anything else. This is the first piece of code to be executed and the only one I run by myself. The rest of the code will be triggered by events, this is not a limitation of the framework, you can run any module code at any time.

The last three lines of code is where I execute the start(); action.

window.myApp.Init = ((myApp) => {  
  const settings = {
    message: "Starting myApp..."
  };

  const _welcomeMessage = (msg) => {
    console.log(msg);
  };

  const start = () => {
    _welcomeMessage(settings.message);
    myApp.Core.Observer.start();
  };

  return {
    start, settings
  };
})(window.myApp);

(function(myApp) {
  myApp.Init.start();
}(window.myApp));

[3] Mutation Observer

As with the Revealing Module Pattern, I won't be explaining the Observer itself, but how to use it. You can find very good information at the Mozilla Developer Network - MutationObserver.

The observer allows to watch any changes in the DOM tree and I use it to create Event Listeners.

Observer.js

The Observer is part of the Core namespace. As every file, it follows the revealing module pattern.

Below the complete code of the module. I will go step by step.

window.myApp.Core.Observer = ((myApp) => {  
  const settings = {
    selector: 'controller',
    triggerSeparator: '->',
    controllerSeparator: '#',
    renderCustomEvent: 'render'
  };

  const start = (selector = settings.selector) => {
    const MutationObserver = window.MutationObserver || window.WebKitMutationObserver || window.MozMutationObserver;
    const target = document;
    const config = { childList: true, subtree: true };
    const observer = new MutationObserver((mutations) => {
      let traversedNodes = new Array();
      for (let currentMutation = 0; currentMutation < mutations.length; currentMutation++) {
        if (mutations[currentMutation].type === 'childList' && mutations[currentMutation].addedNodes.length) {
          for (let currentAddedNode = 0; currentAddedNode < mutations[currentMutation].addedNodes.length; currentAddedNode++) {
            if (mutations[currentMutation].addedNodes[currentAddedNode].nodeType === 1) {
              let traversedNodeFlag = false;
              for (let currentTraversedNode = 0; currentTraversedNode < traversedNodes.length; currentTraversedNode++) {
                if (traversedNodes[currentTraversedNode] === mutations[currentMutation].addedNodes[currentAddedNode].parentNode) {
                  traversedNodeFlag = true;
                  break;
                }
              }
              traversedNodes.push(mutations[currentMutation].addedNodes[currentAddedNode]);
              if (traversedNodeFlag !== true) {
                let behavioralNodeList = mutations[currentMutation].addedNodes[currentAddedNode].querySelectorAll(`[data-${selector}]`);
                for (let currentBehavioralNode = 0; currentBehavioralNode < behavioralNodeList.length; currentBehavioralNode++) {
                  let behaviors = behavioralNodeList[currentBehavioralNode].dataset[settings.selector].trim().split(/\s+/);
                  for (let currentBehavior = 0; currentBehavior < behaviors.length; currentBehavior++) {
                    let trigger = behaviors[currentBehavior].substring(0, behaviors[currentBehavior].lastIndexOf(settings.triggerSeparator)); // trigger->controller#action
                    let controller = behaviors[currentBehavior].substring(trigger.length + 2, behaviors[currentBehavior].lastIndexOf(settings.controllerSeparator));
                    let action = behaviors[currentBehavior].substring(trigger.length + controller.length + 3);
                    if (window.myApp.Controllers[controller] === undefined) throw new Error(`Controller 'window.myApp.Controllers.${controller}' is not defined`);
                    if (window.myApp.Controllers[controller][action] === undefined) throw new Error(`Action 'window.myApp.Controllers.${controller}.${action}' is not defined`);
                    behavioralNodeList[currentBehavioralNode].addEventListener(trigger, window.myApp.Controllers[controller][action], false);
                    if (trigger == settings.renderCustomEvent) behavioralNodeList[currentBehavioralNode].dispatchEvent(new CustomEvent(settings.renderCustomEvent));
                  }
                }
              }
            }
          }
        }
      }
    });
    observer.observe(target, config);
  };

  return {
    settings,
    start
  };
})(window.myApp);

It is a bit lengthy but it is actually very simple.
As every module, it has its settings hash which allows to customize a few options.

The module has only one action, start(selector) which is the one we call from the initialization file. This is how it starts. The selector parameter will be used to identify which DOM elements are candidates for event binding.

const start = (selector = settings.selector)  

The next lines are for setting up the Mutation Observer object.

First, I setup the right interface according to the browser the visitor is using. The target is the DOM node the Observer will be observing, in this case, I want to observe the whole document. At last, I set what kind of changes I want to observe. The observer allows to observer attributes and even content changes. I only need to observe changes in the DOM tree, the default values are already false, but I'd rather be explicit.

  const MutationObserver = window.MutationObserver || window.WebKitMutationObserver || window.MozMutationObserver;
  const target = document;
  const config = { childList: true, subtree: true, characterData: false, attributes: false };

Next, the observer is created. It uses a callback function with a parameter called mutations which registers the observed mutations. It follows an ugly bunch of nested loop-ifs, it traverses all the mutations in mutations, if the mutation is of the type childlist and the addedNodes is not empty, it means that a new node was created in the DOM tree. So I loop through all the added nodes. Then, I check the nodeType of the current added node is an ELEMENTNODE and avoid anything else (TEXT, CDATA, DOCUMENTTYPE, etc).

If the parentNode of the current node has already been examined, I skip the current node since it was already examined as a child node. This way I avoid duplicating event listeners on the same elements.
I push the value of the new traversed node to an array so it is considered in the next loop run.

If the node has not been traversed before, I examined it looking for [data-${selector}], this means if I keep the default setting, I look for elements with [data-controller] data attribute from the current node down to all its children nodes. That's why I can avoid this step when traversing the children.

const observer = new MutationObserver((mutations) => {  
  let traversedNodes = new Array();
  for (let currentMutation = 0; currentMutation < mutations.length; currentMutation++) {
    if (mutations[currentMutation].type === 'childList' && mutations[currentMutation].addedNodes.length) {
      for (let currentAddedNode = 0; currentAddedNode < mutations[currentMutation].addedNodes.length; currentAddedNode++) {
        if (mutations[currentMutation].addedNodes[currentAddedNode].nodeType === Node.ELEMENT_NODE) {
          let traversedNodeFlag = false;
          for (let currentTraversedNode = 0; currentTraversedNode < traversedNodes.length; currentTraversedNode++) {
            if (traversedNodes[currentTraversedNode] === mutations[currentMutation].addedNodes[currentAddedNode].parentNode) {
              traversedNodeFlag = true;
              break;
            }
          }
          traversedNodes.push(mutations[currentMutation].addedNodes[currentAddedNode]);

The next lines are pretty simple, I loop over the Node List from the querySelectorAll, then I split, trim and substring the attribute value. By default, set in settings, the naming convention is triggerName->controllerName#actionName, if the controller or action is not defined, it throws an error, if it is all OK, an event listener is added.

Finally, if the event is renderCustomEvent, the event is dispatch immediately after adding the listener. This allows to run your action after the DOM element is rendered.

if (traversedNodeFlag !== true) {  
  let behavioralNodeList = mutations[currentMutation].addedNodes[currentAddedNode].querySelectorAll(`[data-${selector}]`);
  for (let currentBehavioralNode = 0; currentBehavioralNode < behavioralNodeList.length; currentBehavioralNode++) {
    let behaviors = behavioralNodeList[currentBehavioralNode].dataset[settings.selector].trim().split(/\s+/);
    for (let currentBehavior = 0; currentBehavior < behaviors.length; currentBehavior++) {
      let trigger = behaviors[currentBehavior].substring(0, behaviors[currentBehavior].lastIndexOf(settings.triggerSeparator));
      let controller = behaviors[currentBehavior].substring(trigger.length + 2, behaviors[currentBehavior].lastIndexOf(settings.controllerSeparator));
      let action = behaviors[currentBehavior].substring(trigger.length + controller.length + 3);
      if (window.myApp.Controllers[controller] === undefined) throw new Error(`Controller 'window.myApp.Controllers.${controller}' is not defined`);
      if (window.myApp.Controllers[controller][action] === undefined) throw new Error(`Action 'window.myApp.Controllers.${controller}.${action}' is not defined`);
      behavioralNodeList[currentBehavioralNode].addEventListener(trigger, window.myApp.Controllers[controller][action], false);
      if (trigger == settings.renderCustomEvent) behavioralNodeList[currentBehavioralNode].dispatchEvent(new CustomEvent(settings.renderCustomEvent));
    }
  }
}

The module finishes with its return section, making public the action start and it settings.

return {  
  settings,
  start
};

[4] Fetch

Another Core module is the one which handles all AJAX calls. Since the development of Promises, Async/Await and Fetch, javascript provides very simple tools to create our own AJAX calls without the usage of any library.

As I did with the Observer, I show the whole module and then go into details.

window.myApp.Core.Ajax = ((myApp) => {  
  const settings ={
    method: 'GET',
    body: null,
    options: {
      mode: 'cors',
      cache: 'no-cache',
      credentials: 'include',
      headers: {"Accept": "application/json"},
      redirect: 'follow',
      referrer: 'about:client'
    },
    callbacks: {
      runBeforeSend: (event) => {
        // code to run always before the call
      },
      runOnFailure: (failure) => {
        console.log("myApp.Core.Ajax failed Fetch.", failure);
      },
      runOnError: (response) => {
        console.log('myApp AJAX Response Error: ', response);
      },
      runOnSuccess: (response) => {
        console.log('myApp AJAX Response Success: ', response);
      },
      runOnComplete: (event) => {
        // code to run always after the call
      }
    }
  };

  const fetch = async ({url, event, callbacks = settings.callbacks,
  method = settings.method, body = settings.body, options = settings.options}) => {
    let init = {
      method: method,
      body: body,
      mode: options.mode,
      cache: options.cache,
      credentials: options.credentials,
      headers: options.headers,
      redirect: options.redirect,
      referrer: options.referrer
    };
    event.preventDefault();
    callbacks.runBeforeSend(event);
    try {
      let response = await window.fetch(url, init);
      let data = await response.json();
      response.data = data;
      response.ok ? callbacks.runOnSuccess(response) : callbacks.runOnError(response);
    }
    catch (failure) {
      callbacks.runOnFailure(failure);
    }
    callbacks.runOnComplete(event);
  };

  return {
    settings, fetch
  };
})(window.myApp);

Again the now standard revealing module pattern is used. The settings hash includes values to be used by the fetch action which uses the ES fetch api. I've set 'GET' as the default method, null for body, and a series of options wich allow to work with json. You can review the options at MDN.

const settings ={  
  method: 'GET',
  body: null,
  options: {
    mode: 'cors',
    cache: 'no-cache',
    credentials: 'include',
    headers: {"Accept": "application/json"},
    redirect: 'follow',
    referrer: 'about:client'
  },
  ...
};

The next setting defines the callback. You have 5 stages to run your callbacks.

1. runBeforeSend
   This callback will be run before executing the fetch api call.
2. runOnFailure
   This callback will in case of failure. Most of the time, network or server problems. The fetch api call cannot be successfully completed.
3. runOnError
   The main difference with runOnFailure is that the call is completed but the response is not OK. This means the response HTTP code is not in the 200s.
4. runOnSuccess
   The call has been completed successfully. The response HTTP code is in the 200s.
5. runOnComplete
   This is always executed after the call.

callbacks: {  
  runBeforeSend: (event) => {
    // code to run always before the call
  },
  runOnFailure: (failure) => {
    console.log("myApp.Core.Ajax failed Fetch.", failure);
  },
  runOnError: (response) => {
    console.log('myApp AJAX Response Error: ', response);
  },
  runOnSuccess: (response) => {
    console.log('myApp AJAX Response Success: ', response);
  },
  runOnComplete: (event) => {
    // code to run always after the call
  }
}

Finally, the fetch action. This action is an asynchronous function with 6 parameters. I use named parameters when the functions has more than 3. It can get too verbose but it saves me time when reusing a function after a long time and it also avoids misplacing arguments.

I set the init hash used by the fetch api, for further details on this options, please review MDN.

I prevent the execution of the default for the event and execute the callback runBeforeSend.
Within the try block I catch any exception thrown by fetch and execute the runOnFailurecallback.

I call await window.fetch with the defined url and init. Await allows to wait for fetch to return a promise. This promise is converted to json to extract the data.
If the response HTTP code is in the 200s (response.ok?), runOnSuccess is executed, otherwise I execute runOnError.

Once the try block is completed, runOnComplete is executed.

const fetch = async ({url, event, callbacks = settings.callbacks,  
  method = settings.method, body = settings.body, options = settings.options}) => {
    let init = {
      method: method,
      body: body,
      mode: options.mode,
      cache: options.cache,
      credentials: options.credentials,
      headers: options.headers,
      redirect: options.redirect,
      referrer: options.referrer
    };
    event.preventDefault();
    callbacks.runBeforeSend(event);
    try {
      let response = await window.fetch(url, init);
      let data = await response.json();
      response.data = data;
      response.ok ? callbacks.runOnSuccess(response) : callbacks.runOnError(response);
    }
    catch (failure) {
      callbacks.runOnFailure(failure);
    }
    callbacks.runOnComplete(event);
  };

The return section of the module includes settings and fetch action.

The usage of the action Core.Ajax.fecth is really simple and will be shown in the next chapters.

[5] HTML & M10n

A few comments about how I organize my html code.

First, I use HAML in my Rails applications, I find it much more readable and quicker to write than HTML and, they are equivalent.

Based on the Atomic Design Methodology, I used a much simpler approach. All my html files are consisted of one of two types, Containers and Block. They all have an id with a prefix, c- and b-, respectively.

Any container and block can include others containers and blocks, there are no restrictions on that. The only simple rule I follow is that you can only change the contents of a container while blocks are replaced as a whole.

This is how it looks like,

<div id="c-document">  
  <div id="c-header">
    <div id="b-title">
      Welcome
     </div>
    <div id="b-subtitle">
      Containers and Blocks
     </div>
  </div>
  <div id="c-body">
    <div id="b-content">
      Lorem Ipsum Dolor Sit Amet Lorem Ipsum Dolor Sit Amet
    </div>
  </div>
  <div id="c-footer">
    Thanks for reading
   </div>
</div>  

In Rails every container and block is actually a partial which are updated asynchronously.

M10n and how to update your content

I created a new module within the DOM namespace. I called it M10n (Manipulation) and in its basic form it only includes two actions updateContainer and replaceBlock.

The code is really simple, I use the settings to remove the prefixes from the id and change the innerHTML for containers and outerHTML for blocks. If the prefix is missing/wrong, I throw an exception.

window.myApp.DOM.M10n = ((myApp) => {  
  const settings = {
    containerPrefix:'c-',
    blockPrefix: 'b-'
  };

  const updateContainer = (id, contentHTML) => {
    if (id.substring(0, settings.containerPrefix.length) === settings.containerPrefix) {
      document.getElementById(id).innerHTML = contentHTML;
    }
    else {
      throw `Error: Container ID must begin with '${settings.containerPrefix}'`;
    }
  };

  const replaceBlock = (id, newBlockHTML) => {
    if (id.substring(0,settings.blockPrefix.length) === settings.blockPrefix) {
      document.getElementById(id).outerHTML = newBlockHTML;
    }
    else {
      throw `Error: Block ID must begin with '${settings.blockPrefix}'`;
    }
  };

  return {
    settings, updateContainer, replaceBlock
  };
})(window.myApp);

[6] AJAX

I have been explaining different modules in the previous posts and now it is time to show how I use all this functionality on a Rails app. The example is extremely simple, the user clicks on a button and a HTML container is updated.

main.html

This file is the template. You can set a Rails Controller Action to render it as root in your routes.rb file.
The button has a data-controller attribute, click->Sample#changeContainer. It means, the Observer will add a listener to this element for the event click which will execute the Action changeContainer of the Sample Controller.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">  
<html>  
  <head>
    <title>
      Javascript in Ruby on Rails
    </title>
    <%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track' => true %>
    <%= javascript_include_tag 'application', 'data-turbolinks-track' => true %>
    <%= csrf_meta_tags %>
    <body>
      <div id="c-root">
        <div id="c-top">
          <button data-controller="click->Sample#changeContainer">
            Button
          </button>
        </div>
      </div>
      <div id="c-bottom">
        <div id="c-output">
          This is the Output container
          No output yet.
        </div>
      </div>
    </body>
  </head>
</html>  

_b-output.html

This is the partial we are going to render from the RoR Controller to update de template.

<div id="b-output">  
  Content has been modified.
</div>  

sample.js

This is the javascript Controller. It has one Action, changeController. I use the url '/show' which needs to be added to the Rails routes.rb file to redirect the call to the proper Rails Controller#Action.
It takes the default callbacks and modifies the runOnSuccess so it can update the container with the html_content generated by the Rails Controller. Then, I call the fetch action from the Core.Ajax module.

window.myApp.Controllers.Sample = ((myApp) => {  
 const changeContainer = (event) => {
    let url = '/show'; 
    let callbacks = myApp.Core.Ajax.settings.callbacks;
    callbacks.runOnSuccess = (response) => {
      Jrm.DOM.M10n.updateContainer('c-output', response.data.html_content);
    };
    myApp.Core.Ajax.fetch({url: url, event: event, callbacks:callbacks});
  };

 return {
    changeContainer
 };
})(window.myApp);

sample_controller.rb

The Rails Controller has a show action. [Side note: I always try to keep the Rails Controllers with only REST actions: index, show, new, create, edit, update, destroy. If I need a different action, it always means that a new controller is required]

The show action just renders the partial in json format and sets the HTTP code as 200 (:accepted). This json is the response the fetch method will get and use to update the container contents.

class SampleController < ApplicationController  
  def show
    respond_to do |format|
      format.json do
        render(
          json: {
            html_content: render_to_string(
              formats: [:html],
              partial: 'b-output',
              layout: false,
              locals: {}
            )
          },
          status: :accepted
        )
      end
    end
  end
end  

I haven't included the manifesto root and initialization files, these files are required to make all this work.

[7] Forms

In the previous section, I showed you how I handle AJAX requests with a simple example. The example was a Get request to update the contents of a DIV. In this last section I will show how I process forms submissions with AJAX.

Core.Form

The Core.Form module includes only one action, submit. Its code is pretty simple. It has one condition, the DOM element (buttons most of the times) that launches the event must be within the form.

The Core.Form.submit action uses the Core.Ajax.fetch action define in the previous posts. The only difference is how I set the parameters for fetch.

URL, method and body, are set from the form which is identified from the event's currentTarget. This is why the currentTarget has to be within the form. It is possible to change this and identify the form with other mechanisms but I find this way very userful.

window.myApp.Core.Form = ((myApp) => {  
  const settings ={
  };

  const submit = (event, callbacks) => {
    let form = event.currentTarget.form;
    let url = form.attributes.action.value;
    let method = form.attributes.method.value;
    let body = new FormData(form);
    myApp.Core.Ajax.fetch({url: url, event: event, callbacks: callbacks, method: method, body: body});
  };

  return {
    settings, submit
  };
})(window.Jrm);

The controller calling this action should setup the callbacks and pass them over to Core.Form.submit.

Conclusions

All these basic patterns and modules gives you the foundations to start creating on top of it all your Controllers to manage and manipulate your Rails templates. As you start using them, you will be able to identify and add more base functionality to the core modules and keep your controllers DRY.

You will be increasing the separation of your JS code from your templates codes and keep them logically organized in Controller and Actions.

I hope you find this approach helpful for your next initiatives.

Feel free to share your comments or questions.

The last couple of weeks I been trying to understand the basic concepts of Classification, Clustering and Image Recognition but somehow all the sources immediately redirected me to Python and R; however I was wondering why there are almost zero references for Ruby or Rails in Artificial Intelligence and Machine Learning.

Where I can find...

After searching and refining for a while, I encountered this this excellent blog: practicalai.io
It seems it isn't being updated for a while, but it has some good articles to dig into Machine Learning and it is well explained.

Setting a Good Example

I did the examples of Q-learning and clustering and it was really mind-blowing. I recommend those because they are easy and fun.

Currently I'm playing with Tensorflow for Ruby (here in Github) and training my models with ImageNet in which you can download links of ~15 million photos in a snap. When you are trying to do Machine Learning, getting a lot of reliable data is as equal important as writing good code.

Last Recomendation

Check out this video: Is It Food? from the 2017 RailsConf, which explains a case in which the app has to recognize photos and reject the ones that are not food. I always love when something theoretical and abstract as Machine Learning can be applied in a simple and understandable way.

After playing for a while I think Ruby is more than capable to handle Artificial Intelligence, first of all I shifted my focus more into doing than understanding every little detail. There are a bunch of mathematical gibberish in between something doable and something perfect and as days go by, I becoming more practical about this stuff, sandboxing good already proven libraries to accomplish my goals.

More thoughts and code on this are coming soon!

For years we had been bugged about BPM and process modeling, what the heck is process modeling?

According to Wikipedia definition:

Business Process Modeling is the activity of representing processes of an enterprise, so that the current process may be analyzed or improved. BPM is typically performed by business analysts, who provide expertise in the modeling discipline; by subject matter experts, who have specialized knowledge of the processes being modeled; or more commonly by a team comprising both.

First of all, a process is a consecutive chain of enumerable tasks. When we say task, we mean any repeatable unit of work, which has a beginning and an end.

These tasks are connected in defined sequences and may contain business logic such as rules that defines the task outcome or result.

The Monolithic Approach

Programming paradigms aim to problem solving, hence when a programmer tackle one problem, his mind is set to write code in order to solve all possible scenarios with that domain in mind. What if the problem changes in the future, or the scenarios multiply in time?

The natural response is doing constant maintenance of the written programs and multiply/refactor the lines of code to solve all new possible scenarios. That's what we call the Monolithic Approach: one problem at the time, one program at the time.

Consider this new "mobile app world" for an instant; Say you have to wake up early, then you have the Alarm app! Now say you like to cook and want all recipes in one place, then you have the Notes app, and so on, ad infinitum ad nauseam.

Now imagine applying this approach in a thousand-people company, settled in several countries with operations around the planet. That's madness and simply a poor strategy.

Enter the Power of the Process

Processes are designed to communicate and connect monolithic software between each other, applying horizontal rules beyond the programs' domain. Processes are meant to interconnect limitless black boxes, managing their input and output, recording time stamps between each other's execution and signaling them in predefined states.

One of the most popular notations for process modeling is BPMN2, defined as follows:

The Business Process Modeling Notation (BPMN) is a graphical notation that depicts the steps in a business process. BPMN depicts the end to end flow of a business process. The notation has been specifically designed to coordinate the sequence of processes and the messages that flow between different process participants in a related set of activities.

To give you a more precise idea about it, let me show you what a sample Process looks like:

What Can You Do With a Process?

You can do a lot of things, for instance:

• Connect Legacy Apps
• Call Services (REST, WebServices, etc.)
• Process Batch
• Control Flows and Human Tasks
• Compute SLAs for Tasks and Processes
• Create Digital Trail for Tasks
• Standardize UI between multiple Apps
• Execute Rules (logical, decision tables, etc.)
• ...

This list could be as long as your imagination. Basically you can do it all. Every activity is a sequence of tasks which can be described as a process.

It's a Commercial World

There are several world class BPM managers; I'm going to mention the most relevant (according to me): IBM BPM inherited from Lombardi, the Oracle BPM and the Red Hat BPM Suite.

These solutions are in the $80K to $350K price range, far from being a petty cash investment and all are hard to configure and expensive. Here is where Red Hat stands out. They released their solution under an open source license via the KIE group, so you can download the developer version and write your own code to customize it. You can also access their Github repo here.

One more for the road: you can create a cloud virtual machine with the BPM Suite in Red Hat OpenShift to try it for free.

2020 UPDATE: These days we have the new kid on the block, the german company Camunda, which offers the best BPM Engine of the market! We recommend you to try it out, it is free and offers a very good REST Api as well.

If you still feel a little frustrated like me, circling around AJAX and Rails views, I think you might like this.

Some Use Cases

I faced this problem when I had to tackle these scenarios:

• Wizards partial saving
• Pure HTML Table editing/refresh
• Messaging/Notification refresh
• Infinite Scrolling

Let me dive into the first case; saving each step of a wizard gets a little bit complicated if you have to refresh the whole page every time you hit Continue. That is a known bad practice and to do it the right way, you might consider these strategies:

1. Keep all the data in memory and send it to the server when you finish the Wizard
2. Do partial step-by-step validation and saving

The second option handles the errors better and is more intuitive for the user. Personally, I think that's the way all the Wizards should be designed.

Let's Spice Up The Example:

Consider that you have to present the Wizard for the first time as a rendered (empty) HTML, directly from your controller action:

def new_wizard  
  @step_one = StepOne.new
  render 'new_wizard_view'
end  

You're loading the empty Wizard for the first time and it looks somewhat like this:

What happens when you hit Continue?

1. The button calls a JavaScript function that executes an AJAX call:

function saveFirstStep(form){  
  $.ajax{
    url: '/save/first/step',
    method: 'POST', // This also could be PUT or PATCH
    dataType: 'JSON',
    data: { step_one: { val_1: form.input_1.val(), ...} },
    ...
  }
}

1. The save Action is triggered in the Rails server:

def save_first_step  
  # Use a before_action to filter params and skip this line
  @step_one = StepOne.new(params[:step_one])

  respond_to do |format| 
    if @step_one.save
      format.js { render 'second_step' }
    else
      format.js { render 'first_step' }
    end
  end
end  

1. The JS view first_step.js will look roughly like this:

$('#first_step_container').html("<%= escape_javascript(render 'first_step_partial') %>");

1. Finally, to make it work you have to have a second partial ERB view first_step_partial.html.erb with all the HTML and model's errors from validations:

<div class="form-group">  
  <div class="row">
    <div class="col-md-offset-1 col-md-3">
      <%= f.input :id, :as => :hidden %>
      <%= f.input :icon, :collection => survey_icons %>
      <%= f.input :title %>
      <!-- the rest of the form goes on -->
      ...

The rendered result will look like this:

Time for Plan B:

I personally don't like having two different views (JS + ERB partial) per step because when you have a +3 steps Wizard, there will be too many views and it becomes a big problem for future maintenance.

Also, if you work with multiple models in the same Wizard, it becomes messy to store all the views in the directory hierarchy.

Instead of using the JS first_step.js view, you can attempt to return a JSON object from your action:

respond_to do |format|  
  if @step_one.save
    format.json { render :json => { 
      # Returns an empty object without errors
      :html => {} },
      # Returns the status to AJAX
      :status => :ok }
  else
    format.json { render :json => { 
      # Renders the ERB partial to a string
      :html => render_to_string(
        :template => 'first_step_partial.html.erb', # The ERB partial
        :formats => :html,                   # The string format
        :layout => false,                    # Skip the application layout
        :locals => {:step_one => @step_one}) # Pass the model object with errors
      },
      # Returns the status to AJAX
      :status => :unprocessable_entity) }
  end
end  

And re-write your AJAX call like this:

function saveFirstStep(form){  
  $.ajax{
    url: '/save/first/step',
    method: 'POST', // This also could be PUT or PATCH
    dataType: 'JSON',
    data: { step_one: { val_1: form.input_1.val(), ...} },

    success: function(response){
      // Moves to the next step
      $('#wizard').move_next;
    },

    error: function(jqXHR, textStatus, errorThrown){
      // Rewrites the DOM object with the updated first step
      $('#first_step_container').html(jqXHR.responseJSON.html);
    }
    ...
  }
}

With this workaround you certainly get rid of all the JS intermediate views and also keep all your HTML error handling in the ERBs. If you are fond of SimpleForm (or a similar gem), this solution helps handling DOM classes to show all input errors in the form.

Final Note and Coding Disclaimer:

This solution is a hack, and it is not considered the best way to handle AJAX calls in Rails, but is neat and it WORKS like a charm. If you know what you're doing, it's completely SAFE to use it.

Before you start posting or writing comments you have to consider this blog's etiquette.

Main Guidelines:

• Honesty comes first
• Always be kind and respect other's opinions
• Be aware of copyright laws
• Be mindful about spam
• Avoid being an over-sensitive reader

We encourage you to:

• Be yourself
• Post from your own wisdom and/or experience
• Double check your links and references
• Always consider writing to a greater audience
• Respect confidentiality and/or privacy
• Less is more

Also keep it casual and direct. If you are unsure about something, please feel free to contact the moderators via blog@versiondos.com