Sunday, November 23, 2014

Refactoring code along the lines of the DRY principle by leveraging the power of Ruby blocks and lambdas

In my early days as a ruby programmer, I used to always look for good examples through which I could understand Blocks and lambdas in Ruby. I did understand them after some research but I guess the connectivity of a real life e.g., was somewhere missing to help me remember how can one use them always. That's how I relate to this post and here's an attempt to help drive home the concept of Ruby lambdas and blocks for beginners at least to some extent. This has been tried and tested on Ruby-1.9.3p484

Here we'll try to explore how one could leverage the power of Blocks and Lambdas to make your code look more clean by refactoring one's code along the lines of better adhering to the Don't Repeat Yourself(DRY) principle.

The original code -


Refactoring 1 - 

Problem Context - Methods list_count(returns the number of linked list elements)  and list_elements(list the linked list elements) basically traverse through the entire linked list including the last node and both have a duplicated linked list traversal condition @current_pointer != nil .

To do - Remove the above duplication

Solution - Blocks to the Rescue! 

Adding blocks - If you have a look at the list_elements and the list_count methods they have duplicated for the lines 35-39(excepting line 37) and 45-49(excepting line 48). This doesn't adhere to the DRY principle and hence requires further refactoring. 

Below is a screen shot of what gets changed. You can have a look at this commit which shows the full modified version of the code as part of the first refactoring.


End Result - Lesser lines of code.

Refactoring 2 -

Problem Context - If you observe carefully, you'd find the other traverse_list method has the linked list traversal condition @current_pointer,next_node != nil and they are used to add a new node to the linked list at the end through the add_in_end method and the same is used in the get_tail method to get the last node. With the above condition, the current pointer stops at the last node but on the other hand with the condition @current_pointer != nil used by the list_count and list_elements method use the current pointer goes past the last node to satisfy the specific method requirement. The question now is, can we still remove any further duplication? The answer is yes.

Solution - Introducing Lambdas because we can't use past multiple blocks to methods in Ruby 1.9 . Read this link for more info.

Below is a screen shot of what gets changed. You can have a look at this commit which shows the full modified version of the code as part of this refactoring.


End Result - More concise solution adhering to the DRY principle.

Credits to the Pickaxe book by Dave Thomas for the learnings and to Avinasha for recommending this book.

P.S: This code has scope for further refactoring. I have just taken two sample use cases in an attempt to try and explain Blocks and Lambdas in Ruby.

Saturday, November 22, 2014

Think simple and Look within as a way to solve problems

There are so many times in life that we think we look outside for the solution of certain challenges we come across or certain things that we may encounter in day to day life. Looking outside helps, but not always.

Solution of many problems is within. Recently, I came across two experiences that makes me echo this thought and which make realize how much I got to improve on this way of doing things as well.

Experience 1 -

Problem/Concern - I always found it difficult to keep track of so many tweets from the different folks I follow on twitter on a day to day basis, I was wondering how to get around this.

What I used to do -
1) To some extent after some amount of exploration, I figured out the way of doing this is using the 'lists' feature in Twitter. That helped to some extent.
2) Not satisfied, I still was experiencing the problem so I used to keep thinking 'outside' for a better way of doing this.

A better solution - Although I don't have a complete solution yet, but the below point has helped me tackle this problem better at least to some extent.
1) Often one might be tempted to follow new folks on twitter, it's also equally important to regularly 'unfollow' those tweeple whom you think aren't adding that much value. I know this might be 'common sense' as one would call it, but it's just the way I at least thought of it initially was - may be I need to use some external service(some third party website) or similar stuff on those lines to manage my tweets better. 

Moral - The solution was within Twitter itself. Think Simple :). Think Within..

Experience 2 -

Problem/Concern -  To set a context, I'm a web developer who uses Ruby on Rails, a framework that's used to make websites. I find it sometimes difficult to keep a track the development log in the terminal for any new action I perform as a end user through the web interface of the application whenever there is a background process running within the application which may be for instance is constantly polling something for real time updates that would eventually be displayed on the UI(User Interface) .

What I used to do -
1) So I use an editor called Sublime Text for day to day development. Their search functionality is pretty powerful, so I used to go into the development log and find may through the log to find the things executed as part of the most recent action executed on my part from the UI.
2) I used to do a 'rake log:clear' to clear the log often so that my search can retrieve faster results.
3) Sometimes, in the past I used to even comment out that piece of code that runs a command which triggers the functionality to regularly check for updates. I was doing this in the local box so  I took this approach. I do realize now, it's not the ideal way of doing things especially when you have automated tests in place which might probably link your background process related functionality with what you'd be newly implementing.

A better solution -
1) Simply do a 'Ctrl + C' to stop tailing the dev log soon after you've executed your action from the UI and you'll have the most recent set of actions to explore from the terminal itself. This prevents you from digging out the solution from elsewhere. Isn't that a faster way of doing things? I didn't think of it at least.

Moral - Don't look for something outside(looking into the editor) which involves more effort(searching, cleaning up) when things can be simply achieved within the same terminal itself.

Overall Moral - Think Simple. The solution is within, not without :). 

Credits for the better solutions go to suggestions by Avinasha Shastry.

P.S:- Pardon me for the technical jargon if you don't understand much from this feel free to give me a shout or use google to help you understand the problem 2 better. I've made an attempt to make problem 2 to be understandable by any lay man.

Also, I'd be really happy to hear from folks who have been able to find a better solution to Problem 1, if any better solution exists.

Cheers.



Tuesday, October 14, 2014

Ten Questions you'd want to consider asking when interviewed for a Ruby on Rails position

Taking a decision to move on from your current company or may be even joining a new company in itself as a fresher out of college is not a small decision. A lots of lives can be impacted directly/indirectly by the decision you'd take on which company you'd want to join. Everybody would want to make this as right as they possibly could. Below are just some pointers that I learnt from experience about the questions one should ideally ask before embarking on a journey of exploring newer pastures. Hope asking these questions would help you better decide which company would be most suitable for you going forward. Please be noted this list is not exhaustive and has no direct/indirect bearing on any company in particular whatsoever.

1. What is the version of Ruby and Rails currently being used in the project? If it is an old one, do they plan to upgrade sometime in the near future or this isn't currently on their road map?
2. What is the development environment like?. This question can prove to be quite important to ask because some enterprise companies don't use dev environments like Linux/Mac directly i.e., in other words for instance they might use a Virtual Machine or connect to a remote box(like connect to a linux box via putty) for various security related reasons which they might have.
3. One more question that I've learnt from experience that might be worth asking is does company allow access to blogs, social networking sites(like Twitter, Facebook etc.,) and video sharing sites like Youtube. Access to these sites can really prove handy as part of your day to day development when one is looking for some help through tutorials, guidance etc.,
4. Do you have download access? This is something that'll prove pretty handy whenever as a hacker you'd want to experiment with new stuff(and thereby install the related tools, packages etc.,) and whose true value you'd want to demonstrate through a proof of concept to any stake holder of the company for which you'd be working. Sometimes getting download access to install gems in big companies can also be a challenge in itself especially if they don't have any other teams within the company who are already working on projects that use Rails.
5. Can you please tell me more about the project and how much of it is rails based? Certain projects use rails but may be not completely, the core part of some projects might be some other framework or language. It's important to know how integral is rails as a part of the project as this can give you a direct or indirect idea to what extent does Rails actually bring value to the table which thereby can even give you a hint of how important could be your role or contribution to this project on an ongoing basis.
6. Do you do Test Drive Development or basically is your code driven by automated test cases. Do you use Continuous Integration(CI) tools like Jenkins etc.,
7. What source code management system do you use as part of day to day development(Git, SVN etc.,).
8. What software development models(agile, waterfall etc.,) do use for the projects? Go a step further sometimes, if they say agile for instance ask explicitly for what software development methods(like SCRUM, Extreme Programming etc.,) in Agile do they use for their day to day projects.
9. a. Are the working hours flexible?. Sometimes as a developer what you'd want most is the flexibility to work when you think you'd be most productive. Of course, in addition to this there might be a couple of times when you'd have to run some personal errands for which you'd not be able to login to office during normal working hours.
b. Is there a work from home option?(This can matter a lot if you'd really want to save the time you'd otherwise lose in traveling to office and your way back). Don't be hesitant to ask this as many startups already provide this option as they value your time. You can check if this can be provided on a periodical basis(from time to time) if not on a continuous basis.
10. What are my roles and responsibilities as part of this project and team? What would be the expectations from me once I join the team?

These are ten main questions I can think of that really mattered at least to me based on my experience of being interviewed thus far for a Ruby on Rails opening, I'm sure there are a lot of other questions that can be added on, but I hope answers to these questions help you better decide on where to join next.


P.S: Please feel free to add additional questions as comments to the blog post if you think asking these questions would prove really handy.

Thursday, October 9, 2014

Books - your next best mentor

For a long time I was of the opinion I have read a lot of books back in school and college days and I wouldn't probably ever have to read that much going forward, from thereon. With the advent of online tutorials(videos, blogs etc.,), sometimes, there used to be a feeling within me that one can learn faster through videos and similar media then why should I even consider reading books that much?. I thought reading books might be more time consuming compared to these alternate resources at my disposal. That's kinda true but doesn't really apply always. Below is an experience that I went through which may tell you why..

Recently, I had applied for a job to a company where their first round of interview was actually a coding assignment. The way this works is, you're given a problem statement and you have to solve it within two days(ideally this is taken up by a candidate during a weekend). After submitting the solution to the problem I had requested them for some feedback. The interviewer was kind enough to share the same and highlighted a couple of important pointers after reviewing the submitted code. Overall, out of all the points shared in the form of feedback by the interviewer, I was able to clearly comprehend only some of them.

Out of the points I couldn't really understand very clearly was that my logic to the solution was procedural. I did know what procedural programming is but I couldn't really get a succinct understanding of how I was writing procedural code using an object oriented language like Ruby as part of my solution. This might seem very technical, if you're a non techie who is reading this but the basic point that I'm trying to drive home here is I was for a while lost as to how can I improve further on the quality of my code or solutions that I'd submit going forward without guidance from a physical mentor.

As a work around, I took to reading this book by Sandi Metz called POODR. I had heard enough through people's reviews/recommendations about this book before I decided to give it a shot. It not only helped me better understand what I was missing with respect to my solution but also really opened my mind to looking at developing solutions differently at least from what I had learnt thus far.

This overall experience made me reflect that sometimes, when you don't have an actual physical mentor to guide you, you can with no second thoughts rely on books. After all, people who've written books also would have their experiences and them sharing it in the form of a collection of many articles is for us learn from their experiences and broaden our ways of thinking by looking at things from another's perspective.

One more thing when I look back from this experience, I realized I was actually reading some books even as part of my professional career, not that religiously but definitely I was picking up some important lessons that I could apply in my job here and there. It was just that I didn't realize the true value of those books back then.

From now on, I'm going to make it a point to read more books regularly as they can really help me not only when I need guidance but also to open my mind to new ways of thinking, sometimes making me think - "Hey!, why didn't I think about that :)". Just one thing, just make sure you choose your books wisely. So what book are you going to read next ?:).