Passed GSoC Mid-Term Evaluation

I am really happy. I passed the Google Summer of Code 2008 mid-term evaluation! This means that I get to finish my project patch management portal. I want to thank Dave, my mentor for give me the opportunity to continue working on the project.

This is a quick report of all the work made until this point.

May 26 – June 1: Tables used on the project were created and integrated into the OSVDB schema. Use cases were defined.

June 1-18:

I created an MVC to manage patches. So the base_patches_controller.rb allow us to manage all the actions related to patch submission. I was testing the code and submitting my first patches and all their relevant information and things are going quite well.

So, principal functions were created. You can submit general information about a patch, also associate it with a vendor/product/version, associate it with an author, vulnerability and add a patch rating.

These are the principal actions (methods). However, more actions will be created this week, specially for ratings and vulnerabilities.

General: create edit update destroy
Ratings: addpatchrating updatepatchrating
Products: addvendor showversions
Credits: adduthor update_author deleteauth
Vulnerabilities addvuln deletevuln

I also created and MVC for base_patch_rating_levels. So, it is possible to CRUD patch_rating_levels.

I just worked in models creating maping objects (Has many, belongs_to, has_and_belongs_to), but didn’t work on validations yet. I expect to work in views at the end of this week. (This is HTML and CSS work).

June 18-30: We have the core of Patch Management Portal written. Patches are linked to vulnerabilities and shown in the home page.

-Main views for patches were created.
-Optimization in the database tables.(indexes)
-Active and fragmet caching in some pages and methods.And a patch sweeper created.
-Moderator nav modified to submit a patch and to C,R,U,D rating levels with Active scaffold.
-Home page modified to show “Latest OSVDB Patches” (similar functionality to vulns) with Printer,normal and popup views.

-Validations added to models.

July 01-07: Working on file submission.

This is really important because users can submit a file for everybody to download. So, it is more easy for mostly users to apply the patch just by reading the short-technical description and downloading the file(code).
my my
July 13: File Submission finished. Users can add/delete files related to patches.

You can see my work in progress here in the project wiki and also take a look at my mid-term evaluation. Later on I will be publishing the source code.

I expect to finish the project successfully and be part of the development team.

Rdoc – Generating documentation for Ruby and Rails

Rdoc is a program for creating documentation for ruby source code. Rdoc generates HTML documentation, using syntactic information from the source and text in comment blocks.

You can check documentation about ruby libraries if you have ruby property installed by running the ri command. For example, if we want to know what the capitalize method does, just type in your terminal:

ri String.capitalize

str.capitalize    => new_str
Returns a copy of str with the first character converted to
uppercase and the remainder to lowercase
"hello".capitalize  #=> "Hello"
"HELLO".capitalize  #=> "Hello"
"123ABC".capitalize  #=> "123abc"

Rdoc is very useful to look for information about programs, methods and examples.

If you want to see the rails api documentation type in your terminal: gem server and then go to your browser at the url http://localhost:8808

You will get an HTML page “RubyGems Documentation Index” with a summary of all ruby gems installed on your system.

Click on the gem you want to see the documentation and you will see an HTML page with 3 columns: (Files, Classes, Methods) and everything documented in detail.

If you installed rails with rubygems you can access the rails API. Also the rake app:doc command creates the HTML documentation for your Rails project and stores this documentation in the doc/app directory.

Run the file  doc/app/index.html and you will see of the documentation of your rails project.
Thanks for your visit to the blog. You can follow me on Twitter:

Query analyzer for Rails

I found an interesting and very useful plugin for rails called Query analyzer that allows us check for tables not optimized in our database. It really helps a lot to optimize tables and queries and put indexes on our conditions columns and primary/foreign keys. Sometimes, we forget to do things so simple like this.  Here is a great explanation of what the plugin does.

How to use it? Just install the plugin with:

script/plugin install

Then check your logs. You can see your console as well. Once you have the plugin installed you will see all queries your application does and how they are currently managed.

For example:

I have a table called form_help_divs. It is a table to show some messages in forms around my application. I usually make a call to the database to get a form_help_div record. The query generated is like this:

SELECT * FROM `form_help_divs` WHERE (`form_help_divs`.`name` = 'patch_vuln') LIMIT 1

So in theory. The query should check for only one row, but that is not true because the name column doesn’t have an index. And how I realized that?. I just checked my log and saw this:

Analyzing FormHelpDiv Load

select_type | key_len | type | Extra       | id | possible_keys | rows | table          | ref | key
SIMPLE      |         | ALL  | Using where | 1  |               | 33   | form_help_divs |     |

As you see the query is looking for all records (in this case 33) in the database searching for the name ‘patch_vuln’. That is not good guys. Let us optimize our queries by adding and index to that table. We can add it by hand in our mysql interface, but is better to create migrations.

class AddFormHelpDivIndexes < ActiveRecord::Migration
    def self.up
        add_index :form_help_divs, :name

    def self.down
        remove_index :form_help_divs, :name

Type rake db:migrate in your console and your migration will be executed.Now run your application again and you will see the difference in your logs and console. This is the result:

FormHelpDiv Load (0.001585)   SELECT * FROM `form_help_divs` WHERE (`form_help_divs`.`name` = 'patch_vuln') LIMIT 1

Analyzing FormHelpDiv Load

select_type | key_len | type | Extra     | id | possible_keys | rows |table  | ref   | key
SIMPLE   |768|ref|Using where|1|name,index_form_help_divs_on_name|1|form_help_divs | const | name

¡What a big difference!. Now the query is looking just for one row in the database and that will increase the query speed significantly.

There are other ways to make our applications running faster with rails. Adding indexes is one of those ways and let us gain a lot of optimization specially if we are working with big applications and tables with so many records.
Thanks for your visit to the blog. You can follow me on Twitter: