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 :)

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.