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.

My Emacs Encounter

An old vim user: This is the trap of the Catholics.
A somewhat-old vim user trying emacs: Now *sigh* I want to be a Protestant again.

Whenever I visit a website or read a book which says something about any editor, its mostly about emacs or vim and most of them talk about emacs only.

I have been reading a lot about emacs so I thought why don't give it a shot. I want to tell you that I have been using vim from quite long, almost two years now, since I started writing code. I wrote the first "hello world" of my life in vim, and it was really a very good experience.

So lets try emacs. I typed emacs on my terminal and what I got was a separate window of the powerful rhino with a very neat look and a lot of options to manipulate text on its Toolbar a lot like GVim. I played with it for a while and then tried to know more about it. I started its tutorial to know it's basics.

First thing its tutorial teaches you is the movement of the cursors on the screen. Its straight C-p, C-n, C-f, C-b are used to move the cursor to the previous line, next line, one character forward on the same line and one character backwards respectively. The same movement of the cursor in Vim is achieved using k, j, l, h. You can also use the arrow keys to move the cursor but it is recommended to use the other key combinations so that while editing you won't have to move your fingers away from the touch-typing position of the keyboard. These key combinations, both of Vim and emacs, let you move the cursor very fast throughout your text.

But truly, I don't like the C-p, C-n, C-f, C-b of emacs because you have to hold the C or the Ctrl key of the keyboard for all the time. My little finger started aching after a while. Moreover the characters p, n, f and b are scattered on the typing pad far-far away from each other. You can't really use these key combinations unless You really have long fingers (thank god my fingers are long enough). You actually have to wrestle with the keyboard while using these key combinations.

With a lot of pain in my fingers I was still going through *the mighty* emacs Tutorial. There a are several jobs in emacs which can be done in the Vim in fewer key strokes. Two to tell you are C-L (Ctrl-Shift-l) these are three keys to put the current line under the cursor in the middle of the window in Vim you have to use zz and to view the next and previous screen full of text in emacs you have C-v and M-v (M is your Meta or Alt or Esc key) the same thing in Vim is done using PageUp and PageDown keys.

I really don't want to talk about which editor is superior. You use what You have been using and what suits Your needs more. There is no point in learning to use a new editor when you already know a lot about the other one. Moreover there a lot of features in both Vim and emacs both which We won't use in our entire coding career.

/*Why*/ You Should Blog

Do me a favor, please blog.

Even if nobody reads, you should blog. You must be thinking "This guy is nuts. Why should I waste my time, get my fingers pressing all the buttons on the keyboard, end up with severe pain and in the end nobody reads it."

Well, I'll say, you should write blogs not for anybody else but for your own self. Blog is a way of achieving innovation and clarity in your own ideas. Blogs make you stand right out from the crowd, heck, every now and then born a new blogger. Tell me which guy will get the notice of the people, who keeps mum or who speaks. What the guy is speaking and why people notice him is another matter.If you really do something innovative and find out to be useful to other people, including me, it's worth sharing and blog, in my ways, is the best way to do this.

You say that you don't have time, nobody will read your blog, you have nothing worth saying. Hell no!! Why? Let me explain..

Oh come on I'm also too busy to press these tiny black buttons with white alphabets. However, you must be certainly doing some amount of writing, "No!", you're kidding. You must be writing emails, "not even in a month?" You must be writing some document, "not even in a year?" You must be taking some notes, the subject you like studying most, "never?" You must be highlighting lines in the book which you are currently going through (don't tell me you don't read books), there you go start a blog then. You just keep an eye on your writings or saying that might be worth publishing. Now it's never time consuming to dump some document into a blog. Who asks you to submit a blog before 3:00 pm of every Friday. It's not like an *ass*ingment your teacher gave and you've to submit it before the deadline. You write a blog in a week, in a month, who cares, in a year, but make sure you do write one. So now you both have something to say and time to say. Remember there is a draft button just below.

Nobody will read. I say this is the best thing which can happen to your blog. Because every time you come to know that this good guy read your blog, you'll try to make this guy happy and here goes originality. Comments are good they really tell you where you lack and what you should improve in. Some might also contain praise of your work, it really makes feel happy. Criticism is *good*, but redirect all the comments to /dev/null in your root(read brain), making you change what you really want to say.

To be successful in writing, you should pick one person and write just for that person. Forget for the moment that other people will be reading what you write, and just write as if you a re talking to that one person.
--Kurt Vonnegut Jr.

It seems good advice.

Blogging is weired, you are writing something you already know, or some person has already written about. Something you really take for granted is "common knowledge". You never know the guy who's Bill Gates in the field of having most A+s in your class might not know a simple thing and the guy who is nothing but a road-side punk might know method to create a new rocket engine. The Bill Gates guy can help the punk to get some As or B+s and the punk can teach the guy one or two about rocket science. There's too much to learn in this world and I hope we are still learning. The point behind the blogging is sharing. Get what we can from other smart *asses* and give away the knowledge we have. Don't poke fun at people who seem to be behind us, because they might have something which we'll never understand for years, if ever.

One more sincere advice, please make sure you don't write the blogs with the length of giraffes neck.

Consider me as one of those guys who are behind you and please re-read the first line of this blog.

same article can be found here