Building things that matter
blake-connally-373084.jpg

Code Challenges

Compare the Triplets (Ruby)

Came across HackerRank the other day so decided to give their coding challenges a whirl.  The third or fourth one I did was interesting in that I decided to play with some hashes as part of my solution. Again, nothing complicated, but I wanted to play with hashes as part of the solution. 

The Challenge

My Solution (Brute Force)

First attempt was a straight up brute force approach.  Conditional statements for comparing each score that then added to the scores of the individuals being compared, and chucking all that into an empty array to return.  It cleared all the initial tests and scored the max points of 10 on final submission, but it wasn't really DRY enough and well, I wanted to play with hashes.  So Enter solution two

Solution two was born from the idea that we are comparing two coders, each of whom have multiple values associated to them, we have their overall score that we are calculating and then we have the triplet values for each user that we use to calculate that overall score. The thought process here was simply, to gather the information for each coder in a such a way that is was easy to understand, reason about and access.  

Solve Method

So first thing we did was create the score param based on the values provided to the solve method.  The assumption based on the directions is that the first three elements of the array belong to the first coder and the second three belong to the second.  So we parsed that into a hash that looked like this:

score_params = {
  coder_one: {
    score: 0,
    set_zero: a0,
    set_one: a1,
    set_two: a2 },
  coder_two: {
    score: 0,
    set_zero: b0,
    set_one: b1,
    set_two: b2 }
}

This allows us to capture and calculate the total score for each coder and have their respective set scores under their own hash and makes it every easy to reason about and understand where scores are coming from without having to do any manipulation of the array other than just parse it into our score_params hash at the start of the method.  This allows the array to stand as it is, and we work with a hash to do our remaining calculations.

The other thing we did was extract the logic for comparing these values into a separate method, maintaining single responsibility and taking a more component approach to our method.  The compare method takes the score_param we parse at the beginning and does the comparisons of those within that method.  That method does look familiar in that it uses the similar conditional logic we used in the first iteration, but it is extracted away so as to not clutter up the main solve method.  I think of this as pushing the logic down the stack, where the solve would be our controller and compare would likely live in the model where we would ask the model to do the work of calculating and the controller would return the info back to the view. 

Compare Method

Finally we stick with our results array and we pass the calculated score for each coder  into that array.  That calculated score is held in the score param as well so everything is neat and clean in terms of our data structure and we don't have additional variables like we had in the brute force approach (individual_one, individual_two) that only are used for calculating the combined score for each coder.  Holding that score in the param is clean and keeps us at two variables for the whole method. 

I think there may be a cleaner way to do the compare method, but I'm not unhappy with it because you can look at it and very easily reason about what it is doing.  Additional steps on this would be to work in logic for handling the option of comparing more than one coder's scores.  Though that is outside the scope of the challenge as written.  

Robert Cornell