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 without zone. Use instead.” - as mentioned in this comment

Learnings -

  1. From this SO answer - will use the applications time zone, while 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 and 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. on the contrary is provided by Rails and respects 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.


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.

Thursday, February 4, 2016

How to get Elixir syntax highlighting in github markdown files

Very recently I've started to try out the elixir programming language. As I go about exploring the language through different experiments, I was thinking of making notes of learnings along the way in markdown files. I knew how ruby syntax highlighting works(please see the screenshot below) but didn't know the exact way to do this in elixir.

I've subscribed to a beginners channel in the elixir-lang slack group(you can get your invite here) . Karmen Blake(kblake on the slack group) and Andrea Rossi(lucidstack on the slack group) from that group were quick to help me out with the right syntax for highlighting elixir code in a markdown file. Here's how you can get elixir syntax highlighting in your markdown file -

Here's a github gist of how it looks. You can look at the raw gist to see the exact syntax that you may need to use. Below is a screenshot of how the highlighted syntax looks in a markdown file.

I would like to thank Karmen Blake and Andrea Rossi for helping out from the elixir community :). I think you should definitely hangout in the beginners channel of their slack group if you're just getting started with elixir.


P.S: It's been a while since I've written my last post. I had been held up with a few things in the past but I hope to write more often going forward. Thanks for your patience.