Chronicles of a Ruby Developer

Using Interactors to organise business logic

Sun, 25 Jan 2015 14:34:25 +0000

What is an Interactor

My team has started using the Interactor gem to encapsulate complex business logic hence, freeing up the controllers. The Interactor gem presents us with a very nice way of representing one thing that the application does and allowing us to adhere to the Single Responsibility Principle. Also, if there is a series of action that are required by the business logic, we are able to organise a sequence of interactors using the Organizer method.

I believe that it would be easier to demonstrate the functionalities of the Interactor gem through code, of course. For a working app, pull from this github repo to view the working code. The app is built using the rails-api gem which is a lightweight rails app minus all the unnecessary view modules.

In this app, I would want to create a customer record and associate it to my user_id which is my sales_rep id. I would create an interactor that would FindSalesRep and the user_id would be extracted from the params in the JSON document.

Constructing an Interactor

A context contains everything that an Interactor needs to work with. The params from the controller sets the context when an Interactor is called. Creating an interactor is easy. Just create a class that includes Interactor and define an instance method call, whereby the context can be accessed within it.

class FindSalesRep
  include Interactor

  def call
    begin
      result = SalesRep.find(context.user_id)
      context.sales_rep_id = result.id
    rescue => e
      context.fail!(message: e)
    end
  end
end

Working with a Context

As an Interactor is run, you may add information to the context.

  context.sales_rep_id = result.id

The salesrepid can be accessed by the controller that runs the Interactor. ruby result = FindSalesRep.call(params) puts "Sales rep id #{result.sales_rep_id}" To set a failing context when an operation has failed, a context.fail! can be flagged. This can be accessed by the controller to render a flash message.

  result = FindSalesRep.call(params)
  unless result.success?
    flash.now[:message] = result.message
    render :error
  end

Organizing multiple Interactors

I find the organizer function, which is a variation of the basic Interactor, very helpful in explicitly defining the multiple responsibilities require by the controller when processing an action. The organizer is designed to run multiple Interactors in one Interactor and contents in the context is passed to every Interactor that the organizer organizes. Each Interactor may change the context by adding on more information into it to be passed on to the next Interactor. If one Interactor fails its context, the organizer would not call the subsequent Interactors.

The code will provide more clarity on this concept.

client_controller.rb

class ClientsController < ApplicationController

  def create
    res = AssociateSalesRepToClient.call(params)
    if res.success?
      render json: res.client
    else
      render json: res.message.to_s, status: 404
    end
  end
end

associate_sales_rep_to_client.rb

class AssociateSalesRepToClient
  include Interactor::Organizer

  organize FindSalesRep, CreateClient

end

find_sales_rep.rb

class FindSalesRep
  include Interactor

  def call
    begin
      result = SalesRep.find(context.user_id)
      context.sales_rep_id = result.id
    rescue => e
      context.fail!(message: e)
    end
  end
end

create_client.rb

class CreateClient
  include Interactor

  def call
    begin
      result = Client.create(sales_rep_id: context.sales_rep_id, name: context.name, abn: context.abn)
      context.client = result
    rescue => e
      context.fail!(message: e)
    end
  end
end

In the example above, the organizer AssociateSalesRepToClient defines the process of creating a Client. The task of creating a Client record requires a sales rep id to be retrieved and saved in a Client record. This example may be contrived, but it would be sufficient to demonstrate the concept of organizers.

The create will run AssociateSalesRepToClient Interactor whereby user_id is a key in the params. The FindSalesRep Interactor will run and that would set sales_rep_id into the context to be passed onto CreateClient Interactor. The Client would then be created and save if all runs well. If FindSalesRep runs into an error(user id not found), CreateClient Interactor will not be run and the context will be failed. The controller will receive a false context.success? which would proceed to render the error message.

Conclusion

Interactors are a nice way to reuse operations and explicitly specifying a sequence of actions in order to execute business logic. It also provides a way to bubble back errors when they occur in any of the operation. If in any case the error needs to rollback an operation, a rollback method can be specified in the Interactor. This serves as an option (compared to service objects and use cases) to trim down the controllers by moving business logic out of it.

Inject,each_with_object,reduce - fun Ruby enumerables

Fri, 23 Jan 2015 14:34:25 +0000

I have learnt to love Enumerables and it is imperative to understand how it works because nobody would want to write nested for loops all the time. Solving problems in Exercism has taught me the joy of using enumerables and how it can effeciently solve problems in a succint manner.

Take for example this problem from the Difference of Squares exercise from Exercism.

The sum of the squares of the first ten natural numbers is,

1**2 + 2**2 + ... + 10**2 = 385

The square of the sum of the first ten natural numbers is,

(1 + 2 + ... + 10)**2 = 55**2 = 3025

To calculate the sum of squares, I initially chose to use the each_with_object and inject methods.

  def sum_of_squares
    (1..num).each_with_object([]) { |n,sq| sq << n*n }.inject(0,:+)
  end

eachwithobject(obj) { |(*args), memo_obj| ... } definition

Iterates the given block for each element with an arbitrary object given, and returns the initially given object.

The first iteration goes through the given collection, (1..num) and returns an array, which is the object given to each_with_object([]). You can pass in an empty hash object, each_with_object({}) to return a hash result. In the block, sq becomes the accumulator value(memo value) that will accumulate an array of squares by iterating through every element, n. And because an array is returned, I could method chain the result with an inject method to sum every element in the array.

The #inject method is really lovely in the sense that it allows you to apply an operation on a collection by specifying a block or symbol.

inject(initial, sym) → obj definition

Combines all elements of enum by applying a binary operation, specified by a block or a symbol that names a method or operator.

If you specify a block, then for each element in enum the block is passed an accumulator value (memo) and the element. If you specify a symbol instead, then each element in the collection will be passed to the named method of memo. In either case, the result becomes the new value for memo. At the end of the iteration, the final value of memo is the return value for the method.

According to the definition on Ruby Doc, inject expects an initial value and a symbol whereby each element in the collection will be passed to the name of the method, in this case a :+ which would sum every element in the collection.

In the above example I would have ruby [1,4,9,16,25,36,49,64,81,100].inject(0,:+) This is just a looong way to arrive at the desired result and I think I can do better. With just a bit of refactoring of the first iteration of my solution and it should look good. So, I have decided to use the enumerator reduce, which essentially is an alias for inject. I think reduce gives a better meaning to this example as it is collapsing all the elements into one.

def sum_of_squares
  (1..num).reduce { |sum,n| sum + (n ** 2) }
end

As per the definition for inject, I am able to specify a block in reduce, and an accumulator value, in this case sum. Because there isn't an initial value specified in this block, sum is going to assume the value of the first element as the initial value(in this case 1) and n will be set to the 2nd element.

If num was set to 2, we would have the code with values as such:

def sum_of_squares
  (1..2).reduce { |sum,n| sum + (n ** 2) }
end

sum initial value in this case would be 1 and n would be set to 2, hence the returning the value 5.

Conclusion

If you are coming from a language like C++, you would find these methods delightful to use (hence creating happy Rubyists). I would use it to build hash or an array by applying a method onto every element in the collection. each_with_object may be an overkill for the problem above but it is definitely useful when transforming values that we have queried from the database.

Raindrops exercise in Exercism

Fri, 16 Jan 2015 14:34:25 +0000

So this is how I spent my Friday night before bedtime, solving a problem on Exercism.

This is the problem

Raindrops

Write a program that converts a number to a string, the contents of which depends on the number's prime factors.

If the number contains 3 as a prime factor, output 'Pling'.
If the number contains 5 as a prime factor, output 'Plang'.
If the number contains 7 as a prime factor, output 'Plong'.
If the number does not contain 3, 5, or 7 as a prime factor, just pass the number's digits straight through.

Examples

28's prime-factorization is 2, 2, 7.
- In raindrop-speak, this would be a simple "Plong".
1755 prime-factorization is 3, 3, 3, 5, 13.
- In raindrop-speak, this would be a "PlingPlang".
The prime factors of 34 are 2 and 17.
- Raindrop-speak doesn't know what to make of that, so it just goes with the straightforward "34".

My solution (not the best but will go through another iteration)

  class Raindrops
    RAINDROPS = {
        '3' => 'Pling',
        '5' => 'Plang',
        '7' => 'Plong'
    }
    def self.convert(prime_num)
      if prime_num == 1
        return prime_num.to_s
        else
          primes = find_prime_factors(prime_num)
        end
      drops = primes.map { |p| RAINDROPS[p.to_s] }.join
      drops.empty? ? prime_num.to_s : drops
    end

    def self.find_prime_factors(num)
      primes = []
      (2..num).each do |n|
        if(num % n == 0)
          primes << n if is_prime?(n)
        end
      end
      primes
    end

    def self.is_prime?(num)
      (2..(Math.sqrt(num).ceil)).each do |n|
        return false if (num % n == 0)
      end
    end
  end

Yes, I do realise there is a Prime class that I could use, but I didn't want to. If you haven't checkout Exercism already, you're still not too late to the party.

Why you should give technical talks

Mon, 12 Jan 2015 14:34:25 +0000

A Newbie month at my local Ruby meetup had spurred me to give a talk for the first time. It was definitely nerve-racking considering I've only been coding in Ruby for a little over a year now. After submitting the topic of my talk, there was no turning back and I have to give my best shot.

Coincidentally, I came across a blogpost regarding giving technical talks by reInteractive which I found really encouraging and gave me a further boost of confidence. This has been really helpful to me and I would like to add my thoughts and experiences on why every developer should attempt to give technical talks and how to minimize the fear and trepidation.

How does giving talks benefit me

We love challenges and public speaking is a big challenge for the majority of the society. By overcoming a challenge, you build character and a certain amount of immunity towards fear, in this case, fear of public speaking. The ability to speak in front of a small crowd gives you the confidence when communicating with team mates and clients on a day to day basis. Being a good communicator is a very valuable skill as a developer and should be developed. We have also probably heard about this time and again that, speaking forces you to research on a subject matter thoroughly and as a result, you would understand it intimately.

Coming up with a topic to speak on makes you think

As developers, I know we do a lot of thinking and probably do it all day and even in our sleep (certain problems do get solved in our sleep). However, coming up with a topic to speak makes you think in an entirely different perspective. It takes a bit of work to identify an area of interest, a problem that you have endeavour to solve, or just general experience, to compose a talk out of it. To help ease the process, writing your ideas in Trello at the end of your working day is a start. You can then narrow down on what might interest you (and your potential audience) to warrant further research. Of course, it will be more adventurous to give a talk on a subject you don't really know about but would like to understand it more. For starters, it would be best to talk about something you are working on or have worked with, for example the usage of certain gems.

But my topic is too trivial and everyone knows about the subject matter

If you think that your topic might be suited for entry level, try talking during a Beginner/Newbie/RailsGirls night at the meetup. Understand that beginner nights are meant for speakers who are beginners as well. It doesn't matter if you think that everyone might have a great deal of understanding on what you will talk about because there will always be a handful of people who would find your topic very informational.

You will be surprised to find that there are a lot of people who really appreciate entry level talks rather than something that they might not have heard of before. Just keep in mind that it is always refreshing to have at least one entry level talk among the heavy weight topics. As a community who encourages and nurtures beginners, we should show more empathy towards the audience.

What if I can't answer every question by the audience

Ask for help. You're not going to be punished for not knowing an answer to a question. In fact, you will remember the answer for life and that is very valuable. Of course you should always try your best to present your opinion but you could get feedback on that from the audience as well. After all, we meet up to learn from each other and not judge on intelligence level.

You don't need x amount of years of experience to be able to give talks

You can always talk about your experience as well and by articulating your learning experience in a talk, you will be able to fine tune your learning strategy as well as inspire others. Lightning talk is a great way to talk about something relatively small but technical. A topic as small as how to use form_for is great for a 5 minute talk.

I get nervous doing public speaking

The proverbial phrase, practice makes perfect holds very true in gaining confidence when speaking. I have found that, people who nod in agreement of what you have to say, gives a boost of confidence which calms the nerves. Try looking for that one person in that audience who nods and try to focus your attention at that person. If you are absolutely anal about everything going as planned, gather some friends to be in the audience and stress that it is imperative that they nod when you are speaking.

As you can deduce from all the aforementioned points, it is mostly about a change in perception that would allay any fears in giving talks. Many a time, our fears inhibit us from doing anything. Once all these fears are alleviated, we are able to conquer anything that seemed challenging in the beginning. I hope that this would inspire you to have a crack at giving a talk at your local meetup group.

New Year!

Fri, 02 Jan 2015 14:34:25 +0000

Happy 2015! First task on my 2015 list is to get a blog with jekyll.

CodeSchool 4th and 5th week

Fri, 21 Jun 2013 07:36:58 +0000

Week 4- BrainTree integration

The whole week was focused on the payment workflow and integration with BrainTree. It was a complex process getting our app to integrate and ensuring all the proper fields are passed on to their servers. I'm not saying that it is complicated to integrate with BrainTree, in fact once you have all the right information and keys set up, it is a straightforward process if the app accepts payments and passes it onto BrainTree's servers.

We have chosen to use the Transparent Redirect transaction whereby all payments will be submitted directly to BrainTree's servers and no credit card information will be stored on the app server. Every merchant who signs up will be given a set of API keys to be included in the app.rb. Developers can sign up for a sandbox account to obtain the keys

To create transactions, a HTML form_for is set up to retrieve the Customer's Details and Credit Card Details. The form includes a hidden transaction data which contains the transaction type and URL to be directed to.

tr_data = Braintree::TransparentRedirect.transaction_data(
  :redirect_url => "http://example.com/url_to_redirect_to",
  :transaction => {
    :type => "sale",
    :amount => "10.00"
  }
)

All we needed to do in our controller is to verify if the attendee has received an invitation and to create the transaction details to be passed on to their servers. The app will then await for a URL confirmation from BrainTree's servers and notify the user if they payment has been successful or failed. Obtaining the URL confirmation is as simple as setting the API below:

result = Braintree::TransparentRedirect.confirm(request.query_string)

Week 5 - API design and Handlebars templates

I was really looking forward towards learning about writing our own APIs and how the APIs would be consumed in the front end of the app. Why did we need APIs in our app? The index page contains a dashboard with a live feed of the status of attendees. Visitors will be able to see the number of people who are Awaiting for Invitation, Received Invitation, Paid, Received Reminder, Confirmed and Declined. Visitors will be able to register to get an invitation and then go through the payment process for confirmation.

Abiding by API conventions, we use namespace to keep track of our versioning. The Api::V1::BaseController responds to a JSON string and authenticates the HTTP request with a token. The Api::V1::AttendeesController < Api::V1::BaseController responds with a serialized string of the statistics of attendees to be displayed on the dashboard. To serialized, we used Active-Model-Serializer again to construct a JSON string.

To consume the API, our front end is written in CoffeeScript to render the statistics to be displayed on the dashboard. I must say that it takes a bit of getting used to writing JavaScript without the {},; and var. Just like Ruby, all CoffeeScript syntaxes are terse and it compiles into JavaScript. One of the advantages of using CoffeeScript is that, variables are not global by default hence it would prevent confusion of having variables with the same names from different JS files. I think I'm sticking to CoffeeScript and would not touch JavaScript unless necessary.

The data from the API is passed into a function that will invoke the HandlebarsTemplates.

HandlebarsTemplates['attendee_statistics'](data.attendee_statistics);

This will run the Handlebars file stored in the asset pipeline and it will be compiled, compressed and cached like all the JavaScript files in the app.

Rails Girls Summer of Code

Mon, 03 Jun 2013 08:16:11 +0000

I've also been occupying my time in organizing a team to participate in the Rails Girls Summer of Code . I just chanced upon this in my Twitter feed and thought I would check it out to see what the buzz is all about. As I was reading through it, my eyes grew the widest it has ever did. I knew I could totally do this, all I needed was a female pair, a coach to support us, and a mentor to guide us in the right direction of the project.

Looking for a pair wouldn't be too hard because there are so many enthusiastic women from Rails Girls who would immediately jump into an opportunity like that. The actual uphill task was convincing an individual/company to coach us for the entire duration of this program which is 3 months and dedicating a couple of hours a day to coach us. Students are paid a stipend of $1,500 by Rails Girls organization and coaches would be doing this pro bono.

I knew I couldn't just sit and wait for Rails Girls to find us a coach in our city and that would mean going the extra mile to hunt down people in the Rails community who would be kind enough to dedicate themselves for a good cause. After randomly tweeting people, we are finally in the midst of talking to someone who could potentially dedicate his time to coach us! The next step is to put in our application as a team and cross our fingers in hopes of being selected as a successful applicant for this program.

To give you an idea, I have embedded the Rails Girls video. Gosh, I hope we get it!

Rails Girls Summer of Code

CodeSchool 3rd week - Tokens

Mon, 03 Jun 2013 08:10:47 +0000

That was all we did in week 3, creating email tokens and testing it. It doesn't sound like a lot for 6 hours of lesson but we sure did a lot of discovering when dealing with BCrypt in creating tokens and the output of encoding the hash using urlsafe_encode64.

At the moment, every attendee will have a 3 unique tokens generated for the actions confirm, pay and decline. These tokens are generated using the BCrypt::Password create function with a hash.

BCrypt is the most recommended hash function compared to MD5,SHA1,SHA256 etc. From my understanding, BCrypt uses a variant of the Blowfish encryption algorithm that introduces a work factor which determines how expensive the hash function will be. BCrypt is really slow as the work factor increases compared to other hash functions. This would only mean it would take much longer to crack passwords with massive amounts of resources.

With every email sent out, there will be a link for the attendee to click on to notify of his/her decision be it confirm, pay or decline in one step. Dependent on their decision, the attendee object will be moved into a different state and forwarded to the appropriate link.

This is where BrainTree payment gateway comes into play in the app. All credit card transactions and information storage is handled by BrainTree. The integration to their APIs will be in the next few lessons.

Of course we took a lot of time writing the RSpec tests on the tokens and the links and refactoring our code to ensure there are no unnecessary repetition. At the moment we have not done anything to the view hence I can't provide any screenshots of our progress. However, this is the project link https://github.com/net-engine/tedx-brisbane in case you want to have a look around.

CodeSchool 2nd week - Creating background workers to be passed on to an EmailDelivery service

Sun, 26 May 2013 12:14:31 +0000

So, we have finally arrived at the heart of the app which is sending invitations and confirmations through email using Mandrill. Mandrill is an email service with SMTP setup and API integration. There is even a Mandrill course on Codecademy (yipee!) if going through the documentation is not your thing at the moment.

We actually spent a lot of time constructing the email background worker model using Sidekiq, and an email deliverer model using HTTParty gem to serialize the content of the email to be sent to Madrill's API. The body of the email is serialized using the ActiveModel::Serializer class which basically allows the user to customize the JSON output; beats passing hashes around.

With a big part of the backend constructed, we needed a front end for the administrator to be able to control the invitations and with that, we were introduced to the ActiveAdmin framework which eliminates the need to build an interface and the basic admin processes.

ActiveAdmin interface making it easy for developers to customize

Here's the most interesting part of the course by far, Capybara testing on the interface! What Capybara does is, it allows the developer to test the application by simulating how a user would interact with it. Capybara comes with a bunch of DSLs that emulates the language a user would use ie: page.should have_content("New User"), Attendee.count.should == 1. Language that is so similar to the English language that I struggled a bit understanding how it should work at a low level (this stems from my C++ background). I soon got a hang of it and stopped converting it to C++ constantly in order to understand the DSLs used.

Finally, our app has a front end and in the next few lessons, we will be integrating all the parts together. And now ,back to my revision and preparation for the upcoming lesson.

p/s: My opinions are based on a beginner's understanding of RoR. Please do correct me if I've made any mistake in terms of terminology and concept.

First week of code school

Sun, 19 May 2013 05:36:40 +0000

And so it began, my experience in building a Rails app with the guidance of a professional. The class is definitely not for the ultimate beginner as attendees are expected to have completed the Michael Hartl's Ruby on Rails tutorial. Don't give up on this tutorial if you think the first chapter , which is setting up the environment and familiarizing with GitHub, is too tedious and you just can't wait to start coding. You just need to push through the setting up stage (which is unfortunately a lengthy process) before seeing the fruits of your labor. Also, I would recommend diving straight into this tutorial rather than going through TryRuby because it is easy to lose the plot halfway through TryRuby. I got lost through the stories in poems in TryRuby. Michael Hartl has an entire chapter on Ruby itself and that would be sufficient to understand what is going on in Rails.

Lots of RSpec on the first day of the 3 hour lesson using FactoryGirl of course and setting up state machines for the app. I like the idea of using state machines to define the behavior of a class rather than toggling boolean variables which will end up really messy as it gets complex.

Our next task was to design the flow of how an email is supposed to be delivered using thread workers and integrating with a 3rd party email delivery API. It was helpful to decide how the controller should call the methods before actually writing the RSpec tests and the functions in the model. We were introduced to RSpec method stubbing which I'm still trying to get used to it.

All in all , it was a good first week of learning and I'm definitely better than I was a month ago.