Why do I take this Journey?

I have been using Solr the last two years for quite some projects. My work was always done using sunspot (via sunspot_rails when one has Rails application), a gem that is a client library for Solr.

You need to know few things about Solr, when using sunspot to access it and do most of the things. sunspot is a fantastic gem and relieves you from huge amounts of work when storing data in a Solr database.

However, there are times that I felt that I needed to know more. For example, when I was searching for University of Athens and I got no results, but I knew that my documents had all or any of the words “University”, “of”, “Athens” in their body, or, even worse, there were also documents that were having the whole phrase “University of Athens” in their body. Or I wanted to query with parts of words, or parts of e-mails, and still I was not getting any results. You can see how I ended up solving these problems reading these two: 1) Why Sunspot Solr does not bring results when I include “of” word in search query? 2) How can I set Sunspot to search for sequences of characters instead of words?

Hence, I decided to take a journey to Solr. And this will be a registration of my steps to this journey. Understanding how Solr works, will make me manage better what I can do and achieve with sunspot too.

And here we go

First steps

• I downloaded solr from here
• Followed the tutorial

Summary

One cannot be but extremely impressed of the features and capabilities of Solr. I believe that I will use to replace many of my MySQL stores that are only used for querying.

(Next steps will soon follow)

Did you know that you can execute migration commands from rails console? Assume that you want to change the column ‘name’ of the ‘Product’ model, to have a limit of 32 characters and set it to not null. Here is what you can do:

1
2
3
4
5
6

$ rails c
> ActiveRecord::Migration.change_column :products, :name, :string, :limit => 32, :null => false
-- change_column(:products, :name, :string, {:limit=>32})
(38.1ms)  ALTER TABLE `products` CHANGE `name` `name` varchar(32) NOT NULL
-> 0.0396s
=> nil

Capistrano is a great tool for deploying Ruby on Rails applications on remote server machines. If you have ever used it, you may already know that it creates new directory structures for each new release that it realizes and sets “current” to point to the latest one.

This is very fine, but there are cases in your application that you might want to share the same directory data among releases. You can declare in your “deploy.rb” file the directories that will be shared among your releases. By default, the directories “log”, “public/system” and “tmp/pids” are already shared. Hence, you do not have to do anything for them. But, if, for example, you want to share the “my_custom_data” directory that you have inside your application structure, you need to add the following line inside your “deploy.rb” file:

1

set :shared_children, fetch(:shared_children) + ["my_custom_data"]

This will create a link to “shared/my_custom_data” folder by executing the following command automatically:

1

ln   -s  /home/<my_app>/<deployment_dir>/shared/my_custom_data   /home/<my_app>/<deployment_dir>/current/my_custom_data

Please, note that my_custom_data should pre-exist while you are doing the deployment. But, bundle exec cap setup will create shared folders anyway for you the first time you setup your servers.

I consider testing one of the most important phase in application development and Rails does a very good job on that. However, testing documentation on Rails Guides is still work under development.

Here is a short tutorial on how you can test that a reponse has rendered the correct template and the correct layout.

If you want to make sure that the response rendered the correct template and layout, you can use the assert_template method:

1
2
3
4
5

test "index should render correct template and layout" do
  get :index
  assert_template :index
  assert_template :layout => "layouts/application"
end

Note that you cannot test for template and layout at the same time, with one call to assert_template method. Also, for the layout test, you can give a regular expression instead of a string, but using the string, makes things clearer. On the other hand, you have to include the “layouts” directory name even if you save your layout file in this standard layout directory. Hence,

1

assert_template :layout => "application"

will not work.

Gotcha: Watch out if your view renders any partial

If your view renders any partial, when asserting for the layout, you have to assert for the partial at the same time. Otherwise, assertion will fail.

Hence:

1
2
3
4

test "new should render correct layout" do
  get :new
  assert_template :layout => "layouts/application", :partial => "_form"
end

is the correct way to assert for the layout when the view renders a partial with name_form. Omitting the :partial key in your assert_template call will complain.

This is a very good guide on how one should style its Ruby code. I am following this since I started Ruby and I suggest that everybody does the same.

One extra on usage of {…} vs do…end blocks can be found here (Weirich Convention).

Read my new article on Site Point about MySQL Replication (Part I and Part II)

This is an implementation of a Maze algorithm to find the path from start to goal in between the walls of a maze.

Read the details here.

This week I have decided to use octopus, a fantastic gem for realizing replication or sharding. I have already implemented MySQL Replication (Master / Slave) and I wanted to have my Ruby on Rails application actually use it!

This is my github project: Octopus Replication Example

Your comments are welcome!

During the weekend I have discovered a bug on Rails activesupport gem. The truth is that it has already been reported to Rails. It is the issue https://github.com/rails/rails/pull/2472.

You can see my detailed answer here: http://stackoverflow.com/questions/7706487/rails-tests-showing-0-passed-when-all-pass/7939497#7939497

Use the gist that is referred there until the bug is fixed.

As always, your comments are welcome.

I believe that testing is the most important part of the software development lifecycle. Nothing is ready unless it passes successfully all tests.

Meanwhile, I am trying to test as much aspects of my Rails application as possible. One such are the validations that I have on my models. To help my task on testing validations, I have created a gem that helps me out there.

You can find more details here:

Validator Attachment

Your comments are welcome.