Thursday, January 26, 2017

Plan to blog on Medium going forward

Hi all,

Thank you very much for being readers of this blog so far. I also appreciate the comments that you've shared wrt my posts from time to time. Of late, I've been posting my blogs on Medium and I plan to use that as a primary platform through which I'll be sharing my two cents with the world.

If you'd like to continue to read my posts that have my experiences from different walks of life, please feel free to follow my posts on Medium.

Thank you once again for your support by reading and/or commenting on the different blogs that I've posted on the Blogger platform from time to time. I would also like to take this opportunity to thank Google(and the team behind the Blogger platform in particular) for providing me with a valuable platform through which I could share my thoughts with the world.

I look forward to having your continued support and encouragement for the posts that I make on Medium..

Cya around :)

Sunday, April 10, 2016

Learnings along the way of completing the Roman Numerals Kata via Exercism

  • Roman Numerals Kata
    • Things that I applied or learnt along the journey that led to the final solution -
    • Approach the problem in small steps. I was solving this kata for the first time, I didn't know of any pattern whatsoever initially, hence took this problem, one step at a time and it eventually helped me get to solution. Often times one worries about the end solution or just the destination, without traveling the journey bit by bit.
      • I know you may think this approach(solving for one test at a time as done in this commit and this one) wouldn't give you the desired solution that'll satisfy all cases, but trust me it will help you eventually get there. That's why this approach is worth it.
    • Used the older hash syntax in ruby so that I could leverage keys as strings. With this I could do away with the to_s that I was using here.
    • Learnt that I don’t have to use a more higher order class like the Numeric class. Instead, I could use Fixnum. I also learnt about the hierarchy of these classes. Numeric is the parent of Integer which in turn is the parent of Fixnum.
    • Learnt that reverse_each is much faster than using reverse.each and made the relevant refactoring here
    • Refactoring related learnings * When I was looking at other people's solution like that of rwz's, I realized I can define my ROMAN_NUMERALS related hash in the reverse order like what was done here and thereby I wouldn't even need to use the reverse_each method, saving me an additional computation. * I learnt that I could further simplify my solution after referring to rwz's solution. The if...else related branches that I had introduced to handle the subtractive notation related to roman numerals can be dealt without using that amount of branching. I made the relevant changes wrt this learning in this commit. * Learnt how we could use each_with_object to do away with a temp variable from henrik's solution. Appropriate change was made in this commit. Below is how the code looks before and after using each_with_object

Before

  def to_roman
    num = ''
    number_to_convert = self

    ROMAN_NUMERALS.each do |roman_numeral, numeric_equivalent|
      next if numeric_equivalent > number_to_convert

      quotient, remainder = number_to_convert.divmod(numeric_equivalent)
      number_to_convert = remainder
      num << roman_numeral * quotient
    end

    num
  end

After

  def to_roman
    number_to_convert = self

    ROMAN_NUMERALS.each_with_object("") do |(roman_numeral, numeric_equivalent), roman_equivalent|
      next if numeric_equivalent > number_to_convert

      quotient, remainder = number_to_convert.divmod(numeric_equivalent)
      number_to_convert = remainder
      roman_equivalent << roman_numeral * quotient
    end
  end
  

I don't want to write code for special cases until I understand the general case first.

 For me, this was something I wasn't doing very consciously all this while but I felt, it's definitely something              worth reflecting upon and further experimenting with.
  • Wrapping up, I would like to thank Jim for the above thought and for his work that has helped so many people. Also, my learnings here wouldn't have been possible without those who've contributed to exercism and to those whose solution I had an opportunity to refer to. I'm thankful to them as well.

Sunday, April 3, 2016

Learnings from solving the Hamming exercise on Exercism

Hamming Exercise

  • Learnt how to use count with each_with_index
    • This helped me do away with the temp variable distance that I had used as a counter.

Before - Uses a temp variable called distance as a counter

class Hamming
  VERSION = 1

  def self.compute(dna_strand_1, dna_strand_2)
    raise ArgumentError if dna_strand_1.length != dna_strand_2.length
    distance = 0
    dna_strand_1.chars.each_with_index do |strand_1_char, index|
      distance += 1 unless strand_1_char == dna_strand_2[index]
    end
    distance
  end
end

After - Uses count insead of distance . Taken from rwz's solution.

class Hamming
  VERSION = 1

  def self.compute(dna_strand_1, dna_strand_2)
    raise ArgumentError if dna_strand_1.length != dna_strand_2.length

    dna_strand_1.chars.each_with_index.count do |strand_1_char, index|
       strand_1_char != dna_strand_2[index]
    end
  end
end
  • Looking back at this new approach I could relate better to the Nitpick made in my solution by rikki - the friendly neighborhood code review robot, who said -

Whenever you are looping through a collection and find yourself writing a conditional (if or unless) nested inside of the loop, take a moment to look through the available enumerable methods. There are some very handy ones that might let you simplify.

Misc Learnings

  • Use chars to get an array of characters from a string
  • Use zip to merge corresponding elements of two or more arrays as used wrt henrik's solution. Sample usage -
2.3.0 :008 > b = [7, 9]
2.3.0 :009 > c = [4, 8]
2.3.0 :010 > a = [2, 3]
 => [2, 3]
2.3.0 :011 > a.zip(b)
 => [[2, 7], [3, 9]]
2.3.0 :012 > a.zip(b,c)
 => [[2, 7, 4], [3, 9, 8]]
2.3.0 :013 >
  • Learnt that one needn't have to use a class always(using a class was the first thing that came to my mind when solving this). A module could also be used to solve this. The reasoning behind this(mentioned below) is something I hadn't thought of earlier. It also kinda makes sense to me becuase with Modules one cannot create instances of it and if there isn't a need to create instances, then why not consider using a module. People may want to debate further on this(i.e., on using classes vs modules - that's beyond the scope of this post) but the below point in itself was something worth reflecting upon for me.

    Yeah, there's not much reason to use a class for this, since there are no instances involved over here.

  • Something similar was also mentioned in markijbema's solution.

Lastly, my learnings here wouldn't have been possible without those who've contributed to exercism and to those whose solution I had an opportunity to refer to. I'm thankful to them.

Friday, February 12, 2016

Learnings from using Hound and friends

A few months back I built a basic expenses web app from scratch using Rails, SCSS, Bootstrap and friends. Working single handedly on a project has it's own pros and cons. When I started work on this project, one thing that I really wished for was to get constant feedback on the code that I wrote as that would help me write better code. As a programmer, by yourself, one can identify a number of things that may be wrong with your code but sometimes that ‘AHA’ moment may only come from somebody else’s feedback on your code.

When I was working on this app, I didn’t explicitly have somebody out there to give me feedback but I was luckily in the company of tools like Hound to help me with some feedback. Hound is a tool that comments on style violations with respect to your Github pull requests, allowing oneself and their team to better review and maintain a clean codebase. This post basically highlights some of the ways through which Hound and it’s friends(rubocop etc., that hound uses internally) helped me learn new things that eventually helped me write better code .


My Learnings -


1. “Do not use Date.today without zone. Use Time.zone.today instead.” - as mentioned in this comment


Learnings -


  1. From this SO answer - Time.zone.now will use the applications time zone, while Date.today will use the servers time zone. So if the two lie on different dates then they will be different.
  2. And as mentioned in this post -
You might notice that DateTime.now and Time.now both give you the time in system time zone. And it definitely makes sense since these are Ruby standard library methods that know nothing about Rails time zone configuration. Time.zone.now on the contrary is provided by Rails and respects Time.zone value that we set in Rails.


2. “Color white should be written in hexadecimal form as #ffffff
Color literals like white should only be used in variable declarations; they should be referred to via variable everywhere else.” - as mentioned in this comment


Learnings -  


I learnt that one should more consciously make use of the variables feature provided by SCSS. Using variables promotes reusability.


3. "Extra empty line detected at block body end" - as mentioned in this comment.  


Learnings -


This helped me to remove extra empty lines from my code. There are times when you submit a PR and you may forget about removing such things and for any person who is new to your code might find it confusing to see the presence of extra empty lines in some parts of your code and their absence in other parts.


4. "Redundant curly braces around a hash parameter. Space inside { missing. Space inside } missing" - as mentioned in this comment .


Learnings -


This comment talks about removing unnecessary code in the context of better code readability. Also, adding additional spaces where appropriate is any day more soothing to the eye.


5. "Files should end with a trailing newline" - as mentioned in this comment


Learnings -
According to POSIX, every text file (including Ruby and JavaScript source files) should end with a \n, or “newline” (not “a new line”) character as mentioned in this thoughtbot blog.


One can read more about how this is useful by following this Stackoverflow thread as well.


6. "Keep a blank line before and after private" - as mentioned in this comment


Learnings -


This basically helps separating one thing from another. This way, one can explicitly showcase how a particular line of code is in a way different from another.


7. "Prefer double-quoted strings unless you need single quotes to avoid extra backslashes for escaping." - as mentioned in this comment


Learnings -


When I think about this comment. What basically comes to my mind is that I need to ensure there is consistency in different parts of my codebase whenever I consider using quotes. I would like to leave this at it as many people have more stronger opinions on the usage of quotes and I believe that's beyond the scope of what this post was intended for in the first place.


Takeaways


I made appropriate changes to my code based on whatever hound related suggestions were understandable to me at that given point in time. For all of those programmers out there, especially those who are code newbies, tools like these can offer you really good guidance for starters . Even if you’re a programmer with some experience, you may learn something new on the design and/or development side when you try using hound and this definitely ends up giving a person more confidence to write better code.

I’m thankful to Thoughtbot, all those who’ve contributed to Hound and also to those people who have contributed to tools/libraries similar to rubocop that have helped hound to give constant feedback on our pull requests. I’m also thankful to Michael Hartl for his Rails tutorial as that was the reference that I used when going about building the expenses app.