I have recently finished the book “The Clean Coder - A Code of Conduct for Professional Programmers - R. Martin (Pearson, 2011) BBS”. Here is my short review:

Overall: Fantastic. Worth reading for every developer that wants to become professional.

My Notes and Highlights

Chapter 1 - Professionalism

• Professionalism is a marker of responsibility and accountability.
• It is better to make your manager unhappy rather than your manager customers.

Twitter Bootstrap 2 has a bug while on modal dialogs. The page does not scroll as expected. So, if the browser window is not wide/tall enough to display the whole modal dialog content, the scroll bars do not make it appear.

The bug is described here:

• http://stackoverflow.com/q/7508576/658469

And the answer is given a little bit below that:

• http://stackoverflow.com/a/7787883/658469

This problem does not occur with jQuery modals neither with Twitter Bootstrap 3.

I am using Ruby on Rails and the less-rails-bootstrap gem.

In order to fix the problem for my current application, and instead of moving to Twitter Bootstrap 3 or to jQuery, I have decided to fix the problem in the gem

Here is the fix:

gem 'less-rails-bootstrap', :git => 'https://github.com/pmatsinopoulos/less-rails-bootstrap.git', :branch => 'bug-fix-modal-scrolling'

Important Note This bug influences your capybara/selenium tests, because elements that are normally visible, while the browser is maximized, they cannot be located by selenium and they are reported as non-visible and cannot be interacted with, if the window browser is not open enough to display the whole modal dialog.

I usually come across people asking what is the preferred way of laying out the properties of a model and, in fact, of an ActiveRecord model. Shall we put first the validations and then the associations? Or first the associations and then the validations? Or shall we put first the callbacks?

One can google for rails style guide. Will basically find only this:

• https://github.com/bbatsov/rails-style-guide#models

which is a good resource. But is not complete.

My Rails Model Style Guidelines

we are talking here about Rails 3

Here is the list of my styling guidelines and which I use whenever I am writing a Model.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

# Here, I am defining a "module" with name Ma. I also define two methods. One without "self."
# and one with. See, later on, what happens when I "include" and what happens when I "extend"
# the "module" within a "class".
#
module Ma
  # I will be able to make this method an instance or a class method of a class.
  # It depends whether I will "include" or "extend" the module in the class.
  # Note that this method, I cannot call it directly on Ma. In order for this method
  # to be useful, I have to include or extend this module within a class.
  #
  def ma_method1
    puts "ma_method1"
  end

  # This method, is not reusable, in the sense that I cannot make it be an instance or class
  # method of a class. But still, it is a method of module Ma and I can call it directly.
  #
  def self.ma_method2
    puts "ma_method2"
  end
end

puts "Ma responds to ma_method1? : #{Ma.respond_to?(:ma_method1)}" # it will print "false"
puts "Ma responds to ma_method2? : #{Ma.respond_to?(:ma_method2)}" # it will print "true"
puts "-------------"

class A
  # "include" sets the module methods as instance methods of the class
  include Ma
end

a = A.new
puts "a Responds to ma_method1?: #{a.respond_to?(:ma_method1)}" # it will print "true"
puts "A Responds to ma_method1?: #{A.respond_to?(:ma_method1)}" # it will print "false"
puts "a Responds to ma_method2?: #{a.respond_to?(:ma_method2)}" # it will print "false"
puts "A Responds to ma_method2?: #{A.respond_to?(:ma_method2)}" # it will print "false"
puts "-------------"

class B
  # "extend" sets the module methods as class methods of the class
  extend Ma
end

b = B.new
puts "b Responds to ma_method1? : #{b.respond_to?(:ma_method1)}" # it will print "false"
puts "B Responds to ma_method1? : #{B.respond_to?(:ma_method1)}" # it will print "true"
puts "b responds to ma_method2? : #{b.respond_to?(:ma_method2)}"  # it will print "false"
puts "B responds to ma_method2? : #{B.respond_to?(:ma_method2)}" # it will print "false"
puts "-------------------"

But you can also include or extend a module in another module too. Read this gist by pglombardo who has kindly appended to the above piece of code.

There are sometimes that you might want to use class-level variables in a reusable module. How will you do that? Here is a sample ruby program that does that:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

require 'set'

module Cacheable
  def self.included(base)
    base.send :extend, ClassMethods
  end

  module ClassMethods
    def cached_keys
      @cached_keys ||= Set.new
    end

    def add_cached_key(key_sym)
      @cached_keys ||= Set.new
      @cached_keys.add(key_sym)
    end
  end
end

class A
  include Cacheable
end

class B
  include Cacheable
end

puts "A cached keys: #{A.cached_keys.inspect}"
puts "B cached keys: #{B.cached_keys.inspect}"

A.add_cached_key(:a)
puts "A cached keys: #{A.cached_keys.inspect}"
puts "B cached keys: #{B.cached_keys.inspect}"

B.add_cached_key(:b)
puts "A cached keys: #{A.cached_keys.inspect}"
puts "B cached keys: #{B.cached_keys.inspect}"

A.add_cached_key(:aa)
puts "A cached keys: #{A.cached_keys.inspect}"
puts "B cached keys: #{B.cached_keys.inspect}"

B.add_cached_key(:bb)
puts "A cached keys: #{A.cached_keys.inspect}"
puts "B cached keys: #{B.cached_keys.inspect}"

If you run the above ruby script, you will get the following output:

1
2
3
4
5
6
7
8
9
10

A cached keys: #<Set: {}>
B cached keys: #<Set: {}>
A cached keys: #<Set: {:a}>
B cached keys: #<Set: {}>
A cached keys: #<Set: {:a}>
B cached keys: #<Set: {:b}>
A cached keys: #<Set: {:aa, :a}>
B cached keys: #<Set: {:b}>
A cached keys: #<Set: {:aa, :a}>
B cached keys: #<Set: {:bb, :b}>

In the above example, we keep a class level Set of symbols (@cached_keys). We want every class that mixes in Cacheable to have its own instance of that Set.

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).