SelfdotCode

Many functional languages, such as elixir, use recursion on a regular basis. Ruby, however, takes advantage of explicit recursion far less often, instead favoring iterators. In this post, we’ll explore some situations in which recursion is actually the better choice in Ruby. 

RECURSION VS. LOOP:

To lay the groundwork, let’s illustrate how iterators in Ruby look vs recursion in a typical situation.   Say I have an array and I want to square each value in it. The recursive solution in Ruby might be: 

Here we set a base case where the method returns once the array is empty. Then we split the array into a head and tail, call the block on the head (this returns the square of the head) and call the method again with the tail as its argument, simultaneously pushing the return of the block into acc. Once the original array is empty, we return the value of the acc, which will be an array of the squared numbers. 

  The equivalent by using iteration would be the much simpler, easier, and more optimized: 

[1, 2, 3].collect {|x| x * x} => [1, 4, 9] 

In fact, Ruby uses iteration and loops to do a whole host of tasks, including .each, .collect/.map, .filter/.select, .find, .until, .while, etc. 

WHEN TO USE RECURSION:

A good question, then, is when to use recursion in Ruby over an iterator. In most cases, a loop of some sort will be the most simplest, optimized solution for finding or changing items in an array. That being said, there are cases where recursion will be far more readable and elegant, which is something all coders should value. 

We should consider favoring recursion when trying to accomplish a loop in which the result of the first loop produces the second item/array to loop over, which produces the third, etc. Using a while/until loop in that situation requires us to set up all sorts of variables to track changes which becomes progressively messier as the number of variables increase. Recursion, however, as we’ll see, allows us to keep the entire process self contained and elegant, as no new variables need to be created. Rather, the method is called and called again as soon as new items to loop over are produced. 

EXAMPLE: To illustrate, let’s build the beginnings of binary search tree. The way it will work is that we’ll have a root number value with a left and right node. Say my root number is 8. If the next number I want to add is lower than 8, I will attach it to the left node. If it is higher than 8, I’ll attach it to the right node. Each number I attach will itself have two nodes, which will behave in the same manner. Thus, a built binary search tree might be depicted as:

The way the program adds a value to this binary search tree is by hopping from node to node, doing a less-than-or-more-than conditional on each (to tell whether it should go left or right) and following the nodes until it comes to an empty one, whereupon it will insert the new value as a node there. 

THE LOOP BST: 

Here’s where we get to loop vs. recursion. If I want to do this inserting process using a loop, then I'll need to set an instance variable for my BST (binary search tree) to keep track of the current node being looked at to determine whether to go left or right down the tree. It might look like this (messy) code: 

Which, when used, might return the tree below:

Before we go over why the insert method above is not the best solution, let’s understand how it operates. The key is that it keeps track of the ‘@movement’ instance variable, which is a copy of the BST that is winnowed down as the loop progresses. Every time the method loops, it sets potential_movement to the @left or @right of the @movement variable (depending on the number at the current position).  

If the number being inserted, for example, is lower than the current BST number, then potential_movement is set to whatever is at @left. If @left itself is a BST (i.e. it hasn’t gotten to the bottom of the tree yet), it sets @movement to @left (i.e. the remaining part of the tree) and repeats the process. This process happens until the loop comes to an @right or @left that is equal to nil. Then, it creates a new BST with the number we want to insert as its argument and sets that @right or @left equal to it. 

PROBLEMS WITH THE LOOP VERSION:

There’s nothing wrong with the above method in that it, at least, works, but boy is it ugly and difficult to follow! Also, by the end, the @movement instance variable for each BST includes, for the most part, an unnecessary copy of the search tree below it.   

The reason this method is so ungainly is that it needs to change which BST node to call self.left or self.right upon. In other words, as opposed to keeping track of a simple piece of data, such as a counter or a boolean, the loop keeps needing to be called upon different objects, in this case BSTs, to check the @right and @left values of the current BST. 

THE RECURSIVE BST:

This is a great case where recursion will be helpful because recursion is precisely the process of calling the same method again and again on different objects or pieces of data, eventually using the results of those repeated calls to return the correct value. 

Here’s the BST class with recursion: 

Which, when used, might return:

Here, both the code and returned result are cleaner. We don’t need an @movement or potential_movment variable to keep track of which object to check @right or @left upon because that object will always be the one that insert is being called upon! 

   In the Rails MVC framework, Active Record handles the model aspect by granting all sorts of convenient wrapper methods to interact with and present our database. It's an amazing tool that gives rubyists, among other things, an ultra convenient way to access our database data and relationships.

   But to optimize any Rails app, it can be critical to combine the convenience of Active Record with the power and flexibility of explicit SQL code. Doing so optimizes the speed of the user experience, makes the code more readable, and makes we, the coders, more knowledgable and flexible in our craft.  

   To illustrate the advantages of SQL, let’s start with a simple example that favors using pure Active Record and then build up toward a few more complex cases where we can put explicit SQL code to good use.

  Say I have an app with events and guests. An event can have many different guests, while a guest can be going to many different events. Let’s say I want to select all the recipients attending my first event. The SQL sentence might look something like this:

SELECT * FROM recipients INNER JOIN event_recipients ON recipients.id = event_recipients.recipient_id WHERE event_recipients.event_id = 1

   Here we have a join table for recipients and events called event_recipients, with an inner join to connect them.

   Compare that to the Rails Active Record equivalent.

event.find(1).recipients

  Easy peasy.

  We just find the event with the id of 1 and call .recipients on it. In this basic case, as in a huge variety of others, Active Record is more than enough to get the data that we need.

  Even in slightly more complex cases, adding just a bit of ruby logic on top of the Active Record wrapper is enough to get the job done without resorting to SQL on top of it. For example, if we wanted to get all the names of the recipients at our first event, we might do something like:

event.find(1).recipients.collect{|recipient| recipient.name}

 This finds the first event (i.e. the event with the id of 1), gets its recipients, and iterates over them using the Ruby collect method, extracting the name for each and returning an array of the names. Note, however, that we are now trying to extract data outside of the database using a plain Ruby collect method. This will already cost us some speed optimization. 

   Indeed, using pure Active Record wrapper methods is not always appealing in more complex cases, and this is where speaking the database's language becomes helpful.

  Let’s take a new example.

  Say I have a dog tracking app for a pet adoption center. In this app, I want to find out which breed is most common in our adoption facility, as well as the number of dogs with that breed. One option is to access the database using pure Active Record and then adding logic using non-Active Record Ruby methods, such as by doing:

counter = Hash.new(0)

Dog.all.each {|dog| counter[dog.breed] += 1}

counter.max_by {|breed, count| count}

  Here we iterate through each dog and create a key-value pair for each breed, with a value starting at 0 and incrementing by 1 for each breed’s occurrence. Then we take the resulting hash and do a max_by method, returning an array with the key as the first item and the value as the second. For example: [“Golden Retriever”, 87]

   The above approach works, but is inefficient for several reasons. First, as we’ll see, the code could be shorter and more explicit. Second and more importantly, it’s time inefficient. Databases are optimized for searches. But the above snippet only hits the database and does one action: load each and every record in the Dog table with all of its columns. On top of that, it then uses plain old Ruby to iterate through each and every one of the records to extract the breed. This would be much quicker and more efficient if we could get the exact data we needed purely through using the database.

  Fortunately, we can! The key is to understand not JUST Active Record, but also SQL code and structure. Here’s, for example, a short alternative using pure SQL:

SELECT breed, COUNT (breed) FROM dogs GROUP BY breed ORDER BY breed DESC LIMIT 1;

  This will in theory be far quicker than our pure ActiveRecord/Ruby option because the entire data search is happening inside of the database.

   So what’s the best combination for both Rails usability/workability and database efficiency? Here’s one option that combines Active Record with SQL structure and a bit of SQL code:

Dog.group(:breed).order('count_id DESC').limit(1).count(:id)

   This returns a super useful hash that contains the exact data that we need. For example: {“Golden Retriever” => 87}

   The above example showed a simple case where a little bit of SQL code and structure went a good way toward creating a better solution for our app. But even more SQL knowledge can go even further, especially when it comes to even more complex queries.  

   Take the example we started with in this post: We have events and guests (and users, who are the people that use our app). Let’s say, also, that our app is a gift tracking app, and our user wants to get gifts for the guests. So a gift belongs to an event and a guest. A guest can attend many different events. An event can have many different guests. Additionally, a recipient belongs to a user’s account and an event belongs to a user’s account.

  Now I want to let my user see a list of all the gifts that he plans on giving to his guests at his events. The initial thought might be simply to do something similar to our early event-recipients example, where we combined Active Record with plain Ruby: Gift.all.collect {|gift| gift.name}

  There’s an issue, though. We don’t want to show ALL the recipients and gifts in our database. Rather, we want to show the recipients and gifts that belong only to the current user of the app! If YOU use the app, for example, you shouldn’t be able to see the recipients and gifts that belong to MY account!

There are several solutions to the problem that get our app working, but let’s cut right to one of the most efficient. Here is where we can illustrate the power of speaking the database’s language. Instead of doing a complicated Ruby sort, we can instead liberally use SQL with only a skeleton support from our Active Record wrapper methods:

Gift.joins('INNER JOIN recipients ON gifts.recipient_id=recipients.id INNER JOIN users ON recipients.user_id = users.id').where('users.id = ?', current_user.id).order('gifts.name')

  Here, we inner join our gifts to recipients and then use another inner join for recipient’s to the user where the user is the current_user, meaning user id of whoever is using the app at the time  (note that for this last part we have sanitized our input into the database, which can be important for avoiding SQL injection hacks).  We then sort the gifts by name for good measure.

   Ember has gone through a ton of version releases. When Ember 1.13 was upgraded 2.0 in late 2015, it had already gone through thirteen point releases in just two years. With all these releases, the documentation for Ember has gone through constant updates. Solutions from staple resources, such as Stack Overflow, become deprecated with alarming speed. Hence this blog post. 

    In this post, we’ll build a nested iteration with conditionals. 

    What does this mean? Here’s an example:

THE SETUP: 

    I have an app that keeps track of events, such as a birthday, along with the gifts that I want to give for those events, and the recipients to whom I want to give the gifts. 

    In our setup: A gift belongs to an event and to a recipient. An event has many gifts and has many recipients (let’s say it’s a birthday for twins!). A recipient has many events she could be attending, and has many gifts she could receive at any given event.

   Thus, a recipient going to a birthday event can have many gifts at that birthday event and also many gifts she could be getting at other events, such as the New Year’s party. 

   The goal in this app is for a user to be able to go to his event's show page, see the event with all of its recipients and, under each recipient, see all the gifts the recipient will be receiving at that particular event. 

THE GOAL: 

    To make the above goal a reality, we need to iterate through all of an event’s recipients, for each recipient iterate through their gifts, and conditionally show only the gifts that have the event’s eventId out of all the recipient’s possible events (i.e. only the gifts for that particular event). Selecting the correct gifts to show for each user requires conditional logic within the iteration. Let’s figure out how to do that. 

   THE BEGINNING: 

    First, here’s our event.js in the routes directory, where we pass in our event object. Note that an event has the attributes of a title, description, and date. It also has many recipients and has many gifts.

app/routes/events/event.js

    Now for our event.hbs:

   app/templates/events/event.hbs  (note that HTML is left out for clarity purposes)

Getting the recipient and its name, as above, is the simple part.

    THE CHALLENGE:

    The issue is showing only the proper gifts for the recipient (i.e. the gifts with the proper eventId) as opposed to all of the gifts for all of the recipient’s events. 

One approach might be to somehow put this logic in the events/event.js route file. It’s not apparent that this is the correct approach, though, because the route wouldn’t be able to know which recipient our template is iterating through at any given time and, therefore, couldn’t operate on its gifts. For example, we might try to set up a template action that operates on the recipient being iterated through, and place the javascript for the actions in the event.js. There’s nothing obvious, however, such as a click event, to use to actually trigger the action. The challenge remains, then, to somehow isolate the recipient to operate on its gifts.

    THE SOLUTION: 

    That’s what our component is for!

   app/templates/events/event.hbs

    The beauty of a component is that it’s an elegant way to isolate a particular state of a template and operate on it. Here, into the ’ show-gifts’ component, we pass in the model (which is the event), setting it to a variable called ‘event.' More excitingly, we pass in the current recipient for that iteration and set it to a variable ‘recipient'! 

    We’ve now isolated the recipient!

USING THE COMPONENT:

    What we want to do is take the event and recipient we passed into the component and use the show-gift component’s show-gift.js file to insert a variable, let’s call it ‘gifts’, into the component’s template. This variable will be equal to an array of all the recipient’s gifts filtered for the particular event.

   app/components/show-gifts.js

   The way we set ‘gifts’ is through an Ember computed property, which allows us to declare properties, set them equal to functions, and have them accessible templates (kind of like passing in instance variables from a Rails controller to a view).

    Simply put, we take the event, we take the recipient, and do a filter on the recipients gifts, returning only those gifts whose eventId is equal to the event’s id (i.e. the gifts for that particular event). 

   Now the component’s template is a piece of cake:

app/templates/components/show-gift.hbs  (note: HTML is left out for clarity purposes)

    Here we simply iterate through our ‘gifts’ computed-property and display the name of each gift (name is an attribute of the gift model). 

    Success!

    We’ve now done the conditional logic we needed on each and every recipient. Using components, we’ve successfully and, relatively elegantly, accomplished our goal!

    Now, with a little bit of HTML, handlebar actions and helpers, etc., we get the result below: First, an event page for Linus’s birthday, where both Linus and Schroeder will be getting presents (not sure why Schroeder should be getting a gift, but good for him!). For Linus and Schroeder, we’re only showing the presents they’re getting for that particular event. We can see the proof of that by looking at Linus’s personal page, which lists all the gifts we’re keeping in mind for him, which includes several that aren’t for his birthday.

That’s it for iteration with conditionals inside of Ember components.

   The highlight of rails 5, still in beta, is the introduction of ActionCable, which allows browsers across multiple users to communicate information nearly instantly. Imagine, for example, a board game where each users sees the board pieces respond as soon as the other player makes a move, or a group order that updates whenever a user adds an item, or a message room where users can see chats in real time.  When one user does an action, the browsers for all users will show it without  the page refresh. 

    Before Rails 5, this critical functionality could not be achieved natively within the Rails framework. It had to be forced in using third party code. With Rails 5, however, ActionCable will be merged in to work as elegantly as any other natural Rails capability. 

      How is ActionCable implemented? It uses a WebSocket protocol that, on initialization with a client, creates a connection between the client and the server, constantly updating all users whenever a change is communicated to the server. We developers enact these connections by creating ‘channels’ that carry out the tasks we want the WebSocket to accomplish. Thus, to take the examples from earlier, we might have a messaging channel, an item adding channel, and a game move channel. 

    But, using a switch statement, we can also create a single channel that can handle many different types of requests. 

      In my food ordering app, we wanted to create a single channel in a restaurant order show page where users could add and delete items to an order as well as chat with other users about the order. Other users would see items added to or deleted from the order and messages added to the chat as soon as they happened. 

    To get this dual functionality, we decided to create a single channel that could handle both tasks. By doing so, we also avoided some Rails 5′s bugs that can occur when multiple different channels are enacted, freezing the server. Rails 5, after all, is still in beta!

    Take a look at controller for items and the controller for messages. Note that each time we broadcast to the server, one of the data params we pass in has a key of :action and a string as its value that describes the action of the broadcast. 

app/assets/controllers/messages_controller.rb 

app/assets/controllers/items_controller.rb 

Saw the :action strings on lines 9 and 12, 30 respectively? They aren’t magic. Rather, they help operate a javascript switch statement that determines the response from our channel.   

See below for the javascript: 

app/assets/javascripts/channels/orders.js

    There are three types of actions on the order show page that we want done by the channel. The first is to make a message appear in the chat column when a user creates a message (lines 4-7). The second is for an item to appear and the cost of an order to update when a user adds an item (lines 8-12). The third is for an item to disappear and the cost of an order to update if a user deletes the item (lines 13-17).   

    Take a look at the switch statement on line 3. We call .action on the data sent by the channel, which gives back one of the strings we sent through as the value of the action key (either add-message, add-item, or delete-item). Based on that string, different code is run. Though not all of the code for the different cases are included in the screenshot above, you can get a general sense of what the code does from the names of the functions. 

   POOF. By using a switch statement and passing through a string as part of data, we’ve efficiently added multiple capabilities to our order show page through the use of a single ActionCable channel. 

Using Travis CI, we previously explored how to check that our project passes our test suite every time we push it up to Github. As importantly, we discussed how to add the dynamic tag to our github README , such as the green one right below, that indicates to the world that the tests on our active, public build are passing, so they can feel safe in using our code.

One big pitfall with the Travis CI tag, though, is that it doesn’t indicate whether the test suite actually thoroughly tests the code. In other words, if I had a test suite that merely asserted that we should expected true to be equal to true, then not only would the tests pass, but Travis CI would give us its great green tag to show the world that our tests our passing. Since the true = true test is absolutely useless in actually testing whether our code base works, this is obviously a problem. 

How do we check not only whether our build passes our tests a’la Travis CI, but also that our tests cover as many lines of our code as possible? Coveralls! 

Coveralls is a service that can build off of testing programs such as Travis CI. We will use it in conjunction with Travis to add a second tag tour README, which will show the thoroughness of our tests. Note that Coveralls can be set up without Travis CI, though it then becomes a bit more complex to configure.    After signing in using our github account, we navigate to the repo page below. Note that, if we use a free account we have access to all of our public repositories but none of our private ones. 

Simply click add repo, and we’ll be taken to a page that looks remarkably similar to the one on Travis, where we have options to add repos by clicking on-off buttons. 

Once we’ve selected the repo we want to use, in this case the Alphabet Soup gem, we must add a file to the repos, just as with Travis CI. Assuming that Travis CI is already set up for our repo (see my previous post (LINK) if this does not apply to your project yet), we will simply add a new file to our repo’s root called .coveralls.yml and add information about the testing service we are using as in the snapshot below.

Then, we go to the top of our spec_helper page and add the two top lines as shown below. 

Note that for a rails app, we’d add Coveralls.wear!(‘rails’) Then, in your gem file (or for a ruby gem, the .gemspec), make sure to add something along the lines of the picture below or, in a gem file, put:

In the case of a gem file, put the code below: 

gem 'coveralls', require: false Then, once our tests are written, we simply git commit and push to our remote repo. Now we go to the coveralls page. It might take a minute or two but when we refresh, we can see it works! It is telling us the coverage our code is giving for our test! We can now access a ton of information about our tests. Coveralls will show us line by line which line of our code are covered, it will breakdown the percentage covered for each individual file in our code. It’s a remarkable amount of information that we can use to improve our code coverage!

Plus, we get a shiny new green coverage badge! As shown below, for a README.md, we simply select the markdown code snippet and paste it into our README.

Then we push up to our repo and BOOM!!!

Quickly, let’s see what the badge looks like if we replace our tests with a nonsensical one that simply asserts that truth = true (i.e. it doesn’t actually test our code). All of a sudden, I’m down from 100% coverage to 50%! We still are testing a few things, such as whether certain files and class names exist, but we’re definitely not being very thorough!

Thus, we can see the usefulness of Coveralls. Even though our tests pass, anyone who takes a serious look at our repo (including ourselves), will know something is off. By the same token, if we have a high coverage, they’ll have a strong indication that our code works and is trustworthy. 

When putting code on github, especially code we want to share, it’s important not only to have tests, but have tests that our code passes. If the code doesn’t pass our tests then, at least according to our tests, the code is broken.

But if we are downloading code from github, say a ruby gem, how can we know if the code works? Well, one great way is to look at the build-passing tags, such as the one on the bottom far left here for Nokogiri:

And here on the bottom far left for Pry

They, like a huge number of other repositories, use a program called Travis CI, and here we’ll explore how to use it and set it up. I’m assuming here that you are familiar with github, have an account, and know basic git commands. First, go to the travis ci website and press sign up. If you’re signed in to github when you press that, then it literally signs you up automatically and syncs your github account

  If we go to our profile page, we can see a list of all our public repositories (private ones can only be seen with a paid account, I believe), and switches which default to off, signaled grey X’s.

To active the one we want, click the sliding button, which will turn green and indicate that our repository will be tracked by travis.

How linked is this with github? If you press on the repository name, it opens the repository on github just like that!

The first step in making a repository respond to travis ci is to add a file to the root directory of the project called .travis.yml and push it up to github. For the repository we will test this on, I added a primitive test to a gem repo called alphabet_soup.

Inside of the .travis.yml file, you have to put a few lines of code. See here for full detailed documentation. For most users of ruby, however, it’s enough to put in a few lines of code, such as: language: ruby #the language we’re using rvm:     - 2.2.3  # the version of ruby we’re using

Once this file is all set up and our tests are written in our spec or other testing directories, we can push up to github.

Then, on the travis website, we should see the repository we added come up on the left sidebar. When we click on it, it now shows a record for each time we pushed to the repository, with a green light for when we passed the tests in the spec folder and red for when the tests failed.  

Not only that, but it shows a screenshot of the tests being passed or failed!

Then on the top right of that same page, we finally see our goal, the option to add the build pass button to our github repository. Note: In the screenshot above, taken right after I had linked to travis and pushed to github (with passing tests) for the first time, the icon has not yet updated and turned green. It will take a few minutes.

If we are using a readme.md, then select the markdown option and copy paste the resulting url to the top line of the readme file. Push that to github, and we’re done. The tag is added!

If my next build fails, then the gem will turn red and announce it to the world so that no one downloads the broken code. It’s a great way to tell the world that they should stay away from our broken code, or that it’s passing all the tests we set it and, hopefully, works!

As coders, we like to minimize repetition. Code we don’t have to repeat is code that doesn’t use up brain space. 

In Sublime Text 2 (ST2), as with most text editors, we can help minimize repetition and typing errors using snippets.. 

Snippets are basically lines of code that our text editor will output once a trigger word is used. For example, typing  def + tab in ST2 will output

This process, however, only creates one snippet. What if I want to output methods like the one above several times in a row?

We can make a snippet for that using snippet chaining!

The trick is to make the last words in our snippet the tabTrigger for other snippets. 

To see how this works, let’s look at the snippet code for the default, normal def ... end snippet. 

This snippet, like all ST2 snippets, can be found by, from ST2 on the browser, navigating from Sublime Text 2 > Preferences > Browse Packages then from the resulting finder window, click the directory named Ruby. BAM, you can see all the ruby snippets in sublime text 2. Simply click on def-end.sublime-snippet to select the snippet shown in the picture above!

How to understand what you’re looking at?

Use ST2′s short Documentation 

The important thing to understand is the tabTrigger, which activates the snippet, and the function of $ signs, which determine where the user’s cursor goes. Note that $0 is the default last place the cursor goes. Generally, however, the cursor goes to the lower number first. Thus, $1 comes before $2 and so on. To toggle from one $ sign to the next, the user simply hits tab. 

Now for building our super snippet: 

Notice that this snippet looks very similar to the def ... end one. The big difference? It ends by placing the user’s cursor on the word ‘method’, which is the tabTrigger for itself! The beauty of this is that if I want to make another method, I can simply hit tab again to move the cursor to the end of the word, and tab again to activate it! This, in turn, will end with another tabTrigger, and so on until I’ve finished writing all my methods. 

As seen in the video above, we can easily add arguments and give some context to our methods before moving to the next one. 

But wait, there’s more!!

We can link even different snippets together using this method. Here’s an example that combines an initialize method for ruby classes with the methods snippet we explored above:

 By using the build snippet’s tabTrigger I make an initialize method for my class and add the option to chain create class/instance methods for it.