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.

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.

Cheers.

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.

Wednesday, October 7, 2015

Disable sorting of a column when using Datatables

Hello,

I recently wrote a post(in the company blog that I currently work for - Cybrilla) on how to use a specific aspect of Datatables. The blog also has some insights on when using Datatables would be a good option. 

Sunday, September 27, 2015

Building the Hangman game as part of a distributed team

Hello,

I was recently involved in building a Hangman game(as a side project) to improve my Javascript skills. What was unique about this experience was that the work on this project was done in collaboration with folks from different parts of the world. I had a good experience overall and one can read more about my experience from the original article that was published on the Code Newbie site.

Sunday, July 26, 2015

Sublime Text 3 shortcuts used as part of my daily workflow


Hello there,

Shortcuts are an integral part of my daily workflow as programmer. Apart from the shortcuts that I use via my oh my zsh dotfile(the ones that come via oh my zsh plugins and the custom ones that I've added on top of those), below are the day to day programming shortcuts that I use wrt Sublime Text 3 for Mac OSX.

I'd be happy to know if you find any of them useful.

Tuesday, July 14, 2015

Crossed 10k blog views - a blog about how to make your blog better(reflecting back on my blogging experiences - part 3).


Greetings everyone,

This is my last post(part 3) as part of the series - "Crossed 10k blog views - reflecting back on the experiences of being a blogger". You can read the blogs on part 1 - Why you should consider blogging and part 2 - a blog on how to blog of the series as well. I've been wanting to talk about the third part for a while now and I'm happy that I finally was able to roll it out. I know this post was expected to be published sometime earlier but somehow it just got postponed, I'm sorry for the delay from my end. Below are my two cents on how could one make their blogpost better and thereby be a better blogger.

In no particular order, here goes nothing -

1. The title of your post matters. Choose wisely here as this is the first thing that any reader would see when they visit your blog. Also, please note this is the first thing your blog subscribers would see in the subject wrt the new mails they receive(this is for those readers who've subscribed to your blogs via email updates), Keeping it concise is great and when you find that doing so is hard, try to see if you can choose alternate words to help keep your blogpost title short.

2. Read others blog and see what you find nice about their blog and the way they've gone about writing it. Next time around you might want to embrace that one nice thing you saw in somebody else's blog to give your blog a unique flavor. Talking about flavor reminds me of food :). People make Yummy food by trying different combinations ;) . Just make sure you make an informed decision on this and don't simply go out the way when experimenting new things as part of a new blog. Take in the new ideas one at a time and see how each new addition is responded to by your valuable readers.

3. Break things down

In the body section of your blog it'd be nice if you'd break each of the things you want to talk about in smaller paragraphs instead of talking about all of them in one huge para. A body can easily form 3-5 small paras(or more, just quoting an e.g., here) and that would look any day more neater than say 2 huge paras.

4. Label(or in other words tag) your blog appropriately so that people could search(if the blogging platform that you use supports that feature) for the blog post via keywords they'd enter in the search bar once they visit your blog site.

5. Choose a blogging platform wisely where you think you'd like to regularly blog from. Personally for me, Blogger as a platform serves many of my needs very well. Below are some reasons why I think so -
a. It allows me label my posts and folks can easily search from the posts that I've written so far by using appropriate labels in the search bar.
b. Through their stats feature that they provide I get a better idea of which posts people like and it also helps me better understand what was good about this post when compared to say a previous one and that way I can learn by filling in some missing gaps(helping me overcome some of the mistakes I've been making in my earlier posts) instead of simply repeating the same mistake again.
c. It allows me to easily integrate certain built in widgets as well some custom widgets. An e.g., widget that I use is 'Follow by Email'.

6. Highlight things in bold wherever you think it's important. This really helps to give your readers a quick summary of important takeaways from your post.

7. Less is more - yes and no

As a blogger, for quite a while I wasn't sure if my blog should be of a specific length. IMHO there's no fixed rule to this, may be it just depends on what's the topic of your post. Some posts might need more information and thereby might call for them to be longer, whereas in other cases a shorter post could be just right.

I'll just give you an e.g., of how I went about deciding this for two blogposts that I've written a while ago.

Blog 1(The longer blog) - Newspaper Collection Drive at Cognizant for a Cause - An Experience till the Journey's End

Blog 2(The shorter one) - What are the employability skills required for an entry level engineer in an IT Industry(atleast in India)?

8. A picture is worth a thousand words - use them. I recently was listening to an audiobook on 'Your Brain at Work' by David Rock and there he very nicely throws light on how a picture talks not only about the multiple entities that come as part of the capture, but also about the relationships among those entities. For e.g., take a picture of somebody's graduation pic you could see a lot of things like - the graduating student, happiness, the university, other folks in the pic(like the parents or a partner etc.,). Now think about this, do you see how wonderfully these entities are connected by just one picture :). Personally, this came as a wonderful insight to me from the book.



9. Use appropriate widgets in the blog to let readers get to know more about you(like the LinkedIn widget, Stackoverflow widget etc.,) and contact you(I've provided my email in the 'About' section of my blog) as a follow up on your blogpost, if they might want to. One thing about being a blogger is that you need to stay connected with your viewers, the folks who comment on your blog etc., These folks are your readers so it's a good thing if you provide them your contact in case they'd want to reach out to you urgently(This can really help if your blog has technical articles too). In the past I've contacted some bloggers through their email wherever I had a follow up question on their original post and wanted a prompt response.

I would like to also add, most recently I've added this widget called 'Pocket' and my readers can very easily save a link to each of my blog posts through this cool widget. It really helps when one say for e.g., has figured out a post towards EOD and has say a bus to catch for the journey back home. That person can simply save a link to my blog via this handy widget and revisit the post anytime in the future. These days, even Twitter has added this to help save a link to each of the tweets that one might find handy. Convenient, isn't it :) .

10. The Learning goes on, ask people and read books on how to blog better if you have may be detailed questions on how to blog better about specific topics. If you're techie, this book on Technical Blogging might be of interest to you.

11. Spreading the word.

Yes, you heard it right, you should spread the word about your post and trust me there is isn't any shame whatsoever in doing it. It's your wall on Facebook or your account on Twitter, you're free to talk about anything appropriate, so simply do it(reminds me of Nike's slogan - 'Just Do It' :)).

The idea is pretty simple, the folks who know what you are as an individual(although the extent they know can vary from person to person) would visit your post and some might like/retweet/favorite your post and the rule is simple, anything with more likes/retweets/favorites automatically draws the attention to other viewers of your twitter feed/ facebook wall.

Do this even on professional platforms like LinkedIn. I think this is very handy especially when you talk about blogposts related to your area of work. In my case for e.g., I sometimes go to the the extent of not only posting my technical blog on Linkedin but also post them in relevant technical groups within the Linkedin platform, narrowing down to what I may believe would be the ideal audience of my post.

12. What should I blog about? Many folks have this question. I've had this question in the past too. From somebody I learnt that one way to figure out what to write about is by simply thinking about something that you wish you could easily find out in the internet but wasn't that easily available unless you actually searched by spending more time than what you'd usually do in general.

13.  Add some humor to your posts. Variety is the spice of life, adding some genuine humor in the way you interact with your audience through your post is just a nice way to connect with your audience and it makes writing even more joyful as you can may be live the thought that yeah, my post actually could get someone to smile :). I also see that speakers do this in the conference talks and audiences enjoy such talks with an element of light humor.

14. Timing of your blog is crucial as well. I kinda relate more to this point from the perspective of the profession I'm in and you might thus find this point subjective in a way. I'm basically a developer and in the software world the technology that I use for development gets updated from time to time and as a result any tech blog that might be applicable now, might just not be that applicable if you delay posting the same blog a month later in case there is some enhancement/new feature added to that technology that helps one get the job done in a better way. Trying to push yourself to roll out tech blogs as early as you could before they lose it's relevance is really worth the effort.

15. Give credits to others where appropriate. If a part of your blog uses something that isn't originally yours, giving credit to the original owner of that specific asset which makes your blog even more complete is probably the least you could do to appreciate their effort especially since it's adding more value to your blog.

Lastly, I believe I still have more things to learn(as mentioned in one of the points above) along the journey of how to be a better blogger. I hope to update this blog as and when I learn more ways to be a better blogger along the way.

Hope the above points help you become a better blogger. In case they did, I'd be happy to hear from you :)

Thanks.

Photo credits - 

1. http://shadowxomega5.deviantart.com/art/A-Picture-Is-Worth-A-Thousand-Words-303482041

Monday, June 22, 2015

How to figure out Runtime Dependencies when using Bower via Rails Assets

Hi there,

The original post of this article was made in the company blog that I'm currently working for(Cybrilla). Please refer to this link for the complete blogpost.

Going forward, there might be quite a few posts which I might directly be posting on the company blog that I work for and I'm planning to share links to those posts on my personal blog. I just wanted to bring this to the kind notice of the readers/subscribers of this blog.

Thank you.

Sunday, June 7, 2015

ReactJS Bangalore June 2015 meetup experience


Hello,

Recently, I attended my first ReactJS meetup in Bangalore. The meetup was hosted at Codemancers .

Kiran, an organizer of this meetup gave a talk titled Introduction to React Native. You can find the slides used as part of his talk on this link. Below are some quick notes that were jotted down based on the discussions at the meetup around the talk and also around varying experiences of the other attendees who've tried React.

  1. Discussion around ReactJS -
    1. Treat the application as small components
    2. We can compose those components to build large components
    3. jQuery etc., is imperative whereas React is declarative
    4. React handles states differently
    5. React uses different features like composition etc.,
    6. Interestingly React web and native supports writing some basic CSS properties within the React JS file itself.
    7. In react whenever the state changes, we update the view via the Virtual DOM.
    8. React components are tiny and manageable, one has more control over data when using React
  2. Discussion around React Native
    1. React Native is mainly for iOS apps at the moment. Support for Android is something that they've planned for the future.
    2. Development using React native can be done only on Mac at the moment because it depends on things like xcode etc.,
      1. to use in other operating systems Ubuntu → use a mac virtual box..(not officially supported by Apple)
    3. Has a steeper learning curve when compared to reactjs
    4. Learn once and write everywhere principle
    5. React native is mainly for the mobile apps with native experience
    6. Debugging can be done via chrome dev tools
    7. React native implements Flexbox(flexbox is a new layout module for web)
    8. Components like div etc., have equivalent things like View etc.,
    9. They try running react with the iOS simulator
  3. General discussion
    1. People definitely find it better than Angular. One of them even said that react is not only easier for him as a developer, but also it’s useful for other developers on the same project who may not be working on building similar JS stuff
    2. React Native is better than Web in terms of the UI
    3. Check out todomvc.com to help decide which JS framework can be used to better suit your needs.
    4. There is something like even the react developer tools through which you can even change the state or something on those lines.
  4. To get started with react
    1. http://www.reactstarterkit.com/ - It will have all the build tools that we need.
    2. An open source project that Kiran is working on -
  5. Things to research further about in the context of React
    1. ReactJS style guide
      1. Around this topic there was a discussion that folks can use Flux as their application goes bigger in size.
    2. How to write tests in React

Photos taken at the meetup -





I would like to thank Codemancers for hosting us, Kiran for sharing his experiences of using React via his talk and all the attendees for the interesting discussions we had around React.

P.S:- 

Since these are quick notes, please feel free to correct me if there is a typo in something or if I've incorrectly mentioned something. Also, please feel free to add more points as comments that were discussed as part of the meetup in case I missed mentioning something, I'll update the post accordingly.

Sunday, May 24, 2015

Bangalore Ruby User Group May 2015 Meetup Experience

Hello,

The May 2015 BRUG meetup was at Amagi Media Labs. I just thought of summarizing some quick notes from the discussions that took place as part of the meetup hoping that it could serve as a reference for those who could and couldn't make it for the meetup.

To give you a background, some of these discussions were around some questions raised by a person who is running a site called Loan Meet using Ruby on Rails. What's unique was this person was doing Rails development on Windows! We had an interesting discussion around 'Rails on Windows' and the person using it admitted that he had to setup additional things for using certain gems in a Windows platform.

Things discussed were -

  1. Somebody from Amagi Labs was giving a presentation into what they're basically into, what problems their addressing and where does Ruby fit into their Tech Stack.
  2. Akash Manohar briefly spoke about asdf an Extendable Version Manager for Ruby, Node.js, Elixir and more
  3. There was a discussion around Elastic Search and Avinasha Shastry from SupportBee mentioned that they Cache Elastic Search setup for Circle CI instead of installing it as part of every build.
  4. People were discussing different deployment options and many of them were suggesting that the Digital Ocean $5 plan is good for starters.
  5. People were talking about Heroku Review apps
  6. For basic mailing options in RoR apps people were discussing the below -
    1. Don’t use mailgun - it's pretty costly
    2. Using Amazon instead is cheap
    3. For Transactional email on behalf of clients people can’t use amazon
  7. I had a question around ways to better manage our assets. Akash from Icicle and somebody else(sorry, I can't properly recall who) mentioned You can use multiple manifest files. That was something I didn't know about earlier.
  8. We were then discussing different ways to manage front end assets -
    1. People were talking about - bower, yeoman, grunt and something called brunch (This actually reminds me of something like breakfast + lunch :)?, jokes apart, this was something which even I hadn't heard of earlier!) .
  9. People were also talking about debugging in production via pry-remote, papertrail, logstash for production related logs. Many of them agreed that using a third party service like papertrail can save you from the responsibility of managing these things by yourself.
  10. Encoding issues, configure git config to better manage carriage returns
  11. We could use SMS services in our Rails apps via Twilio and solutionsinfini .
  12. People were also talking about Prometheus by SoundCloud.

I'd like to thank Amagi Media Labs for hosting us. They've come up with a new office there and I'm just sharing a few snaps(I had asked them if I could click a few snaps) taken there as they're office setup looked interesting :)














P.S:- 
Since these are quick notes, please feel free to correct me if there is a typo in something or if I've incorrectly mentioned something. Also, please feel free to add more points as comments that were discussed as part of the meetup in case I missed mentioning something, I'll update the post accordingly.