Sunday, November 8, 2009

Love the Code

Recently I went to the New Delhi Ruby Meetup. This is a great place to meet some very good Ruby and Rails developers from New Delhi and NCR. If you are interested in Ruby or Rails or any other technology any way related to web development, you should give it a try.

In the past meetup we had a short brain storming session on "How to be a good Rails developer?".

Apart from making your Ruby programming better, using proper idioms while coding, having some standard variable names throughout different applications, writing more secure code(XSS and SQL injection etc free), one thing which popped up was to make yourself familiar with the code which you use in your application from external sources. These external sources of the code are mainly gems or plugins used by your application.

Rails is a very adaptive community. It adapts new changes very rapidly and humbly. One of the reasons for this is that it is very easy to create gems and plugins to be used by Rails. You can find a gem to do almost any job you want. This easiness sometimes results in a buggy gem. And sometimes these bugs are quite critical for your application and cause some very critical security problems.

One solution to solve this problem which we came up with was to read the source code of the gem. Reading the source code of a gem does not make any sense if the code base of the gem is quite huge. Some gems are really veryhuge. Reading all this code may also not be very productive given you have to complete your application by the deadline. So you come with the idea of reading only that part of the code which is critical to your application. One other thing which makes this code reading painful is the quality of the code in that gem. If the code is not organised well and is also not written well, reading it and understanding it will also take a lot of your precious development time.

The funny thing is that the whole gem is critical to your system. How do you know which part of the code does what unless you read all the parts.

A few solutions(I doubt) which I thought are following.

1. Read the documentation thoroughly


You should try to read the whole documentation of the gem which you are going to use carefully. If you doubt some particular behaviour, you should check out the code implementing that behaviour and other related methods.

2. See all the bug list


If that gem has a bug tracker, you should see all the open bugs and current situation of the bugs in that list. Some bug might be critical to your application. You should also try to solve some bug and submit a patch to the gem.

3. Faith in the community for that gem


If the gem is really very useful and good enough, you will be suggested to use it on IRC or blogs of other Rails developers. You should also check if any of your friends has use it and try to find out if they faced any problems using this gem.
I think there should be some Rating and/or download/installation count indicator for each gem on the gem hosting web site(s). These ratings given by the people and the download count give a very good indication of how much the community trusts a particular gem. This is not a new idea. Vim has been doing from ages.

4. Read the mailing list


You should also try to read the old message threads in the mailing list of that gem. It could be quite tedious. To make it a little bit easier, you should try to search the messages for some 'security' or 'bug'.

One thing we should also expect from the gem maintainers is that they should explicitly state all the critical issues using this particular gem in the documentation.

No comments: