Tuesday, February 18, 2014

Enumerables in Ruby

Using Enumerables in Ruby - Source for the tutorial is Ruby Programming Language
by Yukihiro Matsumoto(creator of Ruby) and David Flanagan.

The blog below has a sample code with output. The sample code below with inline comments in a way summarizes the concept(refer blog title) covered as part of the book.



Loops in Ruby

Using Loops in Ruby - Source for the tutorial is Ruby Programming Language by Yukihiro Matsumoto(creator of Ruby) and David Flanagan.

The blog below has a sample code with output. The sample code below with inline comments in a way summarizes the concept(refer blog title) covered as part of the book.



Iterators in ruby

Using Iterators in Ruby - Source for the tutorial is Ruby Programming Language by Yukihiro Matsumoto(creator of Ruby) and David Flanagan.

The blog below has a sample code with output. The sample code below with inline comments in a way summarizes the concept(refer blog title) covered as part of the book.



Conditionals in Ruby

Using Conditionals in Ruby - Part 1 - Source for the tutorial is Ruby Programming Language by Yukihiro Matsumoto(creator of Ruby) and David Flanagan.

The blog below has a sample code with output. The sample code below with inline comments in a way summarizes the concept(refer blog title) covered as part of the book.



Operators in Ruby - Part 2

Using Operators in Ruby - Part 2 - Source for the tutorial is Ruby Programming Language
by Yukihiro Matsumoto(creator of Ruby) and David Flanagan.

The blog below has a sample code with output. The sample code below with inline comments in a way summarizes the concept(refer blog title) covered as part of the book.



Operators in Ruby - Part 1

Using Operators in Ruby - Part 1 - Source for the tutorial is Ruby Programming Language by Yukihiro Matsumoto(creator of Ruby) and David Flanagan.

The blog below has a sample code with output. The sample code below with inline comments in a way summarizes the concept(refer blog title) covered as part of the book.



User input in Ruby

This is a sample program which takes user input and prints the same in Ruby



Arrays in Ruby

Using Arrays in Ruby - Source for the tutorial is Ruby Programming Language
by Yukihiro Matsumoto(creator of Ruby) and David Flanagan.

The blog below has a sample code with output. The sample code below with inline comments in a way summarizes the concept(refer blog title) covered as part of the book.



Playing with Numbers in Ruby

Using Numbers in Ruby - Source for the tutorial is Ruby Programming Language
by Yukihiro Matsumoto(creator of Ruby) and David Flanagan.

The blog below has a sample code with output. The sample code below with inline comments in a way summarizes the concept(refer blog title) covered as part of the book.



Helloworld in Ruby

Hello world program in Ruby



Using Hashes in Ruby

Using Hashes in Ruby - Source for the tutorial is Ruby Programming Language
by Yukihiro Matsumoto(creator of Ruby) and David Flanagan.

The blog below has a sample code with output. The sample code below with inline comments in a way summarizes the concept(refer blog title) covered as part of the book.



Saturday, February 8, 2014

One plus One is eleven - Individual Ubuntu dev boxes vs Single Redhat dev server for a team of developers

Hi,

Below are certain points(based on my experience till date) on the basis which I've tried to put forth my two cents on the pros and cons of having an individual development setup(for each developer)(using Ubuntu) v/s using a single development box(in this case it is Red Hat Enterprise Linux OS on which each developer would have individual user account through which they would go about day to day development - this is a sample case study with no direct/indirect reference to any individual/organization) for a team of multiple developers who would be working on a Ruby on Rails application.

Also, I would like to clarify why this comparison is done is because we are assuming a hypothetical scenario where the production app server is deployed on RedHat OS and the debate is about having the right development server in place for day to day development - keeping in mind the specific goal on how can one achieve more(be more productive and kinda spend not more time than what's ideally reqd for day to day development) with less(for e.g., simply by being smart when one has to be and finding the shortest path - reminds me of Dijkstra's algorithm ;) )

An attempt to list down the differences one by one follows below -



SE NO
Point of discussion
Ubuntu
Non Ubuntu - RedHat
1
Development setup
Individual for each developer
Common for all developers(one server, multiple user accounts)
2
Internet required for development
No
Yes(because we connect via putty installed on Windows to dev server).
From Home – via some VPN
From Office – Office intranet
3
Chances of intermittent connection loss to dev server when moving laptop from one place to another say to attend meetings etc.,
No concept of connection being effected as internet not used for day to day development(Your development box is your local box – Cheers J )
0 – 15 %(approx.)
Impact – Need to again reconnect to the server and open multiple putty sessions again(this mean logging into each individual session multiple times).
1.       For starting the server
2.       For tracing the log
3.       Opening the rails console
4.       (optional) for accessing the mysql console
4
Need to commit to see if your code changes work properly on the application
No
Yes and No.
Yes in the case where -1. You are working from your local desktop
 2. You’re using an editor like Sublime Text
 3. Committing those changes via something like Tortoise SVN(an interface to ease you SVN committing process)
4. Doing an update from the server side to fetch latest code and only then checking if your changes work properly or not.
This approach is not recommended because the general rule of thumb to committing code is that you make changes, test them.. If all things work fine only then go about committing the same.

No in the case where
1 Directly code via putty
2. Don’t have an editor
3. Overhead of not having the editor –
a. copying the code is a challenge if same/similar functionality has to be used in different files within the same application
b. Copying the code from one place to other spoils the alignment and the entire copied code needs to be realigned(as a result development becomes more time consuming).

It's kinda everyone's wish to get the best of both world's isn't it :). There's a way through Samba by which you can actually map your local boxes network drive to point to one of the remote servers(provided you have access to the same) and you can specifically point it to the codebase on which you're currently working. Through this service your changes made using the editor which basically opens the code on the remote server will automatically reflect in the remote server. Sound's good isn't it :). Well yeah, I've heard sometimes people use Samba as means to deep dive into their application logs(for debugging etc.,). Hmm, but having this for day to day development would be an icing on the cake, isn't it :). The prerequisite for it to be allowed for day to day development might be that you need to have support for Samba(not sure about it in detail just sharing knowledge based on what I know or have come across till date).Things can actually get more challenging as mentioned above if you don't have Samba support.
This seems to take care of this point, but what about others... read on before you reach to any conclusion ;).

5
Do we have an independent platform where a developer is empowered to showcase Proof of Concepts(POC’s)?
Yes
No(because we are all using a shared server – we need to be very cautious when we experiment with things).
6
Will your application break if you develop in Ubuntu and deploy(for prod) on Redhat
It depends(can’t be taken for granted it will or it won’t). A best way to answer this is to see if equivalent packages/plugins that are used as part of the application are available for Ubuntu and Windows. Bottom line, if this breaks for one application it can’t be taken for granted it will break on all applications. Root cause analysis needs to be done to go into exact details and decisions need to be made based on the same.
7
Freedom of a developer to have his/her playground to demonstrate his potential
Can do more. Every user will have his/her own root access to install additional softwares which can be used for the benefit of the company. Sometimes when you want to install app specific packages also, it’s easier to do it without any approval process in the loop(provided you are confident of what you are DOING)

It’s more of show me the code first before you talk.(taken from the saying – “talk is cheap, show me the code” – mentioned by Linus Trovalds the creator of the Linux Kernel)
Can do very less – needs to take approval for every single installation as this server is used by multiple people. What happens in the bargain ? – More time consuming for a developer to show his/her potential. Every developer will not have the root credentials only sys admin will have it(in some cases it’s the linux support team).
8
Cost
Free – Open Source. Can development be cheaper J ?
Huge cost involved for every developer to have the individual Red Hat development Setup.
9
Support
Independent. Not required, as it’s an individual desktop. If one breaks only a developer is impacted not the entire team. To fix any issues we have Ubuntu forums like – AskUbuntu, UbuntuForum, Ubuntu Mailing List, IRC
Dependent on Linux support teams within the corporate organization(if such a team exists) or on the Red Hat support staff from whom we’ve originally bought the OS.
10
Security
Shouldn’t be a concern as we will be using Ubuntu VM’s on Windows platforms. There should already be company firewalls protecting our internal systems through firewalls etc., IMHO.
Already taken care in a way by the support from Red Hat, Linux support team within the company(if exists) + support from firewalls setup with respect to the company network.
11
Single Point of Failure
No. One machine goes down. Use the VDI and clone the setup. We can keep a master copy of the setup and distribute it among all team members. Any changes to the application should be reflected in one of the master setups(which nobody plays around with). Thereby if  one developer ends breaking things, he doesn’t have to do much to get back the latest setup reqd for the application to be up and running. Only he will have to rework his local changes(say wrt the POC’s which will be in WIP)
Yes. One machines goes berserk, several developers are impacted(that’s why nobody wants to take risks and sometimes you lose out in the competition just because we don’t take calculated risks to speed up things).


These are my own personal views and I'm open to any pointers in case I'm missing something with respect to the differences mentioned above or if you'd like to add more differences the ones already mentioned above.

I'd be happy to pass on the mantle to all readers who would like to discuss more on this topic through comments on this post. It's your playground from here, take it away :) .

Net-Net - I think the differences talk for themselves and IMHO one should be in a position to independently take a call on what works best for them as some things could vary on a case to case basis.

Cheers :)

P.S:- One plus + One equals eleven is a pun that I've used for two individual entities being combined together to give you a single result.. One of the entities is Windows and I leave it to you to figure out what the other entity stands for .. :);)


Debugging your Rails apps - how I go about it generally

Hi,

To debug your Rails apps the following cmds are what I generally use.

a. Rails.logger.info . They are many variants to using this based on different scenarios. One of them is -
1. To just get a better hang of the flow of how the call passes goes from one place to another-

Rails.logger.info " Your Message goes here"

An easy way of finding the same in your log could be

Case 1

Rails.logger.info "\n*********\n Your message goes here\n********\n"

2. To get the flow and also to see the values used/passed anywhere in the method(s) called as part of your action which triggered the functionality

Say if 

Case 2

a = "hi"
Rails.logger.info "\n*********\n Your message goes here - #{a}\n********\n"

The above statement will print your message with the value of a.

3. Another very useful thing that I use from time to time is making use of the 'inspect' option. With experience I can definitely say it's very helpful when you for e.g., want to see what all are passed as part of a click of a submit button, the entire list of params that are passed(with the exact format like for e.g., say your passing a hash with multiple key value pairs) or basically the object values can be clearly seen and printed via the Rails Logger.

Sample e.g.,

Case 3

Rails.logger.info "\n*********\n Your message goes here - #{a.inspect}\n********\n"

Hope you find them useful. In case you have better suggestions on can one better debug, please feel free to share your suggestions as comments to this post.

You can read more about how to better debug your Rails apps from the Rails Guides (I've taken a reference from Rails 2.3 guides just as an e.g.,).

Thank you.