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.

Deleviring mails from a Rails app to the local mbox and displaying in Evolution

A special thanks to one of my friends because of whom this was completed on time.

Recently I was integrating ActionMailer in a Rails application. I was using Cucumber to test the application. In the test environment the general idea is to ask the ActionMailer not to try to deliver the emails really but assume that those are delivered.

When the integration of the ActionMailer was done, I wished to see how the email actually looked like in a mail reader like Thunderbird or Evolution on my local machine before putting the email templates in the production mode. I did not use my production server for all this testing stuff because of the fear of being blacklisted. I actually wished to test how a email looked like after the delivery.

To accomplish this I asked ActionMailer to use Postfix to deliver those emails to my local GNU/Linux mbox. I then used Evolution mail reader to read my local mbox so that I could see how the actual mail looked like after delivery. I did following things to achieve this.

Install Postfix

I have Ubuntu on my development machine. So to install Postfix you could do just the following.

$ sudo aptitude install postfix

Above will install and configure the postfix on your machine. To check if the postfix was configured correctly on your system try sending a mail to yourself.


$ mail <your_login_name_to_machine>(e.g. waseem on my machine)
Subject: Test mail to local user.
Trying to send a mail to the local user.
.
Cc:
$

Now we test if the mail was actually delivered to the local mailbox.

$ mail
Mail version 8.1.2 01/15/2001. Type ? for help.
"/var/mail/waseem": 1 message 1 new
>N 1 waseem@goodlove Wed Oct 7 15:34 14/460 Test mail to local user.
&

Looks like the mail was delivered.

Configure Postfix to use virtual email addresses.

I am developing a Rails application which lets some user sign up using their email address. In my user model I have a validation which checks the format of the email address submitted by a user when she signs up. In my tests I used email with format of "user_name@webapp.test". To force Postfix to deliver all the mails send to the email of this format I used its virtual_alias_maps configuration option.

Postfix's virtual_alias_maps lets you create any number of 'virtual' email addresses, that would all end up in one email account. And for the testing purposes I wanted that account to be my local system user's account mailbox.

First we create a file called 'virtual' which will hold the mapping of the aliases of the email formats.

$ sudo vim /etc/postfix/virtual

Put the following lines in that file.

@webapp.test waseem
@test.local waseem


Above tells Postfix that all the mails send to the emails ending in @webapp.test and @test.local domains should be delivered to the mbox of user waseem. :)
Now we hash this file so that postfix can read this file faster.

$ sudo postmap /etc/postfix/virtual


A /etc/postfix/virtual.db file would be created after doing this.

Now we tell Postfix to use this file for virtual alias maps.


$ sudo postconf -e "virtual_alias_maps = hash:/etc/postfix/virtual"


Now we restart Postfix by doing $ sudo /etc/init.d/postfix restart.

Ask Rails to use Postfix for the mail delivery.

In your config/enviroments/test.rb replace config.action_mailer.delivery_method = :test with config.action_mailer.delivery_method = :smtp

Now we test the if the delivery of the mails is taking place by making some actions which cause execution of mail delivery method in the Rails app code. In my case it was just by executing feature definition which tried to signup a user to the application.

When I did the above, I faced following error.

OpenSSL::SSL::SSLError (hostname was not match with the server certificate):
/usr/lib/ruby/1.8/openssl/ssl.rb:123:in `post_connection_check'
/usr/lib/ruby/1.8/net/smtp.rb:582:in `tlsconnect'


I googled for the solution and found out two of them. First was to ask Postfix to not to do any SSL security checks. To do this you should edit the /etc/postfix/main.cf to have smtpd_tls_auth_only=no. Restart the Postfix and you are fine again.

Other solution is to generate good SSL files and force Postfix to use them. I prefered the first solution as it suited my needs.

Now when you tried sending emails with you Rails application to any email address ending in @webapp.test or @test.local, those were actually delivered to the local mbox of user waseem. You could test it by running the mail program in your terminal.

Using Evolution to read your local mailbox.

It is comparatively quite simple. You just create a new account in the Evolution program. Enter any email address and select "Standard mbox spool or directory". Now choose /var/mail/<your_login_name_to_machine> for the path. Choose SMTP as your mail server type and localhost in the server configuration. You are done now.

Now when you check this account in the Evolution, you will find those emails sent by the Rails application in the test environment.

Enjoy!!

Enabling 'choice_node' in XMLMapping gem

XML-Mapping is a great ruby gem. It lets you make ruby objects from XML and vice versa. It is a very useful gem but it seems that it is not maintained from it's project page. The last release was done on December 2005. Looks like it is no longer being maintained by it's author.

I am using XML-Mapping and Cucumber to test a rails application which generates XML feeds. Recently I had a need to use 'choice_node' method. But it gave me a 'undefined method choice_node' every time I tried to use it. The funny part is the method is very well documented like any other methods.

I had installed it from the source as a gem at my local machine. When searched the code for definition on ChoiceNode class I got nothing. It means the code which I downloaded did not have any choice_node method in it so how come I was going to get it in my application.

However following fixed the problem.

First remove or better rename the old gem.

gem_install_directory$ mv xml-mapping-0.8.1 xml-mapping-0.8.1-old


Then checkout the latest source of the gem from it's CVS repository.


gem_install_directory$ cvs -d :pserver:anonymous@rubyforge.org:/var/cvs/xml-mapping login
gem_install_directory$ cvs -d :pserver:anonymous@rubyforge.org:/var/cvs/xml-mapping checkout .


Now you can use the XML-Mapping gem with it's full power.

Skype: Problem with audio playback on Jaunty

I recently bought a Dell Inspiron and installed Ubuntu Jaunty Jackalope on it. I was having a hard time making skype work on this. Every time I started skype, it gave me a "Problem with audio playback" error. I googled a lot and on Ubuntu forums found following solution to this.

First go to Skype->Options->Sound Devices and set "Sound In", "Sound Out" and "Ringing" all to pulse. Uncheck the "Allow Skype to automatically adjust my mixer levels".

Now go to the volume settings by double by clicking on the speaker icon on top panel. Here in the preferences, check the capture option. Now in the recording tab unmute the mic.

Go to Skype and make a test call. Everything should be working by now.

This solution was found here.

Resolve Conflicts in Git

I am going to tell you something very basic here. These basics are really important though.

Today when I tried to merge one of my branch say phuddu to my master, I got some weired messages from git.

...
ERROR: Merge conflict in app/models/activity.rb
Auto-merging app/models/death_report.rb
...
fatal: merge program failed
Automatic merge failed; fix conflicts and then commit the result.

Looks like I crashed into a merge conflict today.

My app/models/activities.rb file looked like following.

<<<<<<< .merge_file_sdfPaP
# == Schema Info
=======
# == Schema Information
>>>>>>> .merge_file_LT3vRO
# Schema version: 20090530092020
#
# Table name: activities
#
<<<<<<< .merge_file_sdfPaP
#  id         :integer(4)      not null, primary key
#  item_id    :integer(4)      not null
#  user_id    :integer(4)      not null
#  item_type  :string(255)     not null, default("")
#  created_at :datetime
#  updated_at :datetime
#
=======
#  id         :integer(11)     not null, primary key
#  user_id    :integer(11)     not null
#  item_id    :integer(11)     not null
#  item_type  :string(255)     not null
#  created_at :datetime #  updated_at :datetime
#
>>>>>>> .merge_file_LT3vRO

Every chunk of code above within the

 <<<<<<< 

and

 ======= 

reflects the modifications made by other commiter (Oh! why!! why did you do this?) whereas the code within the

 ======= 

and

 >>>>>>> 

reflects the changes made by me. Now to resolve above conflicts we will edit our files according to the need and do the following.

git update-index <filename>

It actually tells the git that conflicts have been resolved in the files. Now just do a commit and you are done.

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.

* and \*

I was coding from past 25 minutes in my favorite language C (that's because this is the only language I know :-).

Any ways I was writing a program which could evaluate reverse Polish expressions taking input from command line (yeah yeah you must be thinking pretty simple, what's so special). The logic of the program is very simple. You just push any incoming operand in the argument list to a stack and whenever any operator comes you just pop last two operands and push the result back to the stack after operating them with the operator.

Well I wrote the code and started testing it.

$./a.out 2 3 4 + *
$0

I was surprised and thought a bug might have been crept in and checked the code for logical errors. But hey I guess my logic ain't bad. Then I threw the dice another way.

$./a.out 2 3 +
$5
which is the correct output.

Now comes the funny part. I had faith only in GDB. So I ran a GDB session.

$gcc -g expr.c
$gdb ./a.out
(gdb)run 2 3 4 + *

Yes, to pass arguments when you are debugging your code using GDB, you have to specify the arguments on the (gdb) prompt when you are going to run it using run or r. I checked the values of different variables. The first culprit was argc or argument count it's value was 19 it was supposed to be 6. I just checked the first few starting lines. Everything was going on fine. Push and Pop operations to the stack, conversion of strings i.e. "2" to integer 2 everything was cool. Then suddenly when i checked the value of *argv it showed itoa.c which is another C source file in my current directory. I was surprised what the hell was going on. After scratching my head for another five minutes I typed following on the command line.

$./a.out 2 3 4 + \*
$14

It's the right output.

The problem I was facing is that the gnulinux shell considers * as wild card character meaning any number of character. So when I passed * to the program I was actually passing all the files currently present in my current directory so the result was erroneous and when I passed \* I was actually telling the shell that it was '*' not the name of all the files present in my current directory. So GDB saved the day.

Moral of the *experience*..

1. Avoid hand-hacking. Had I tried solving the problem without using GDB, I would have wasted my precious hours.

2. When passing wild cards to a program on the Shell escape them using \ unless you really mean them to be wild cards.

3. Free Software is great.