#brainopia

[gazay]

Install ruby-debug19 with new rvm architecture

Many months ago I started using in my projects ruby 1.9.3 and in the first day I get problem with ruby-debug19. It's described in @spastorino's team blog post ruby 1.9.3 and ruby-debug. All was ok when I tried it then, but now, when I loose my old macbook air because of indonesian rains (sad but true) and bought new one without any possibilities to get backup from old one, I have had again problem with installing ruby-debug19. I tried to use methods described in comments of Santiago's post, but it doesn't help. Now I can't find sources of ruby in rvm directories and after some time I asked @brainopia about this problem. He gave me this script:

#!/bin/sh rvm_current=`rvm current` echo "Installing ruby-debug with $rvm_current ..." curl -OL http://rubyforge.org/frs/download.php/75414/linecache19-0.5.13.gem curl -OL http://rubyforge.org/frs/download.php/75415/ruby-debug-base19-0.11.26.gem gem install linecache19-0.5.13.gem ruby-debug-base19-0.11.26.gem ruby-debug19 -- --with-ruby-include=$rvm_path/src/$rvm_current rm linecache19-0.5.13.gem ruby-debug-base19-0.11.26.gem echo "Done."

All installed without any problems! The problem was in new place for ruby sources in rvm directories, now they all stores in /Users/username/.rvm/src/ .

And before, in earlier versions of rvm, ruby sources were separately in their own directories: /Users/username/.rvm/rubies/ruby-1.9.3-p0/include/ruby-1.9.1/ruby-1.9.3-p0/

[gazay]

Something about code styles

Several months ago we with my brogrammer @brainopia talked about style of assignation, when expression very long and complex. So here some examples of what we thinking:

# Original example - method chain @authors = Author.alive.now_and_future.common_and_side.location(@location).all( :select => 'permalink as not_delegated_permalink', :group => :permalink, :having => 'count(*)=count(distinct placement)' + 'and bool_or(on_sale_from <= current_date)' )

This is how usually people write code. Conventions about 80 symbols, parameters each per line, and long and complex method chain.

So @brainopia proposed to me several variants how we can rewrite this code for more readability.

# Add more readability for methods @authors = Author. alive. now_and_future. common_and_side. location(@location). all( :select => 'permalink as not_delegated_permalink', :group => :permalink, :having => 'count(*)=count(distinct placement)' + 'and bool_or(on_sale_from <= current_date)' )

Now looks easier to understand for me. I have problem with reading long and many times related to other files one-liners. So this variant more acceptable for me then original one. But here I don't like two moments:

indentation of start object differs with methods which we call on it

round brackets around the attributes of method 'all'

And here we have two options. First thing is that we can use escaping character and besides everywhere where we feel bad:

# Using escaping character @authors = \ Author. alive. now_and_future. common_and_side. location(@location). all \ :select => 'permalink as not_delegated_permalink', :group => :permalink, :having => 'count(*)=count(distinct placement)' + 'and bool_or(on_sale_from <= current_date)'

Looks better? Yeah, but indentation still not good for object - just move lines below it for one more softtab.

And the second option - we can move lines until we feel good about indentations and round brackets:

# Using indentation @authors = Author. alive. now_and_future. common_and_side. location(@location). all( :select => 'permalink as not_delegated_permalink', :group => :permalink, :having => 'count(*)=count(distinct placement)' + 'and bool_or(on_sale_from <= current_date)' )

We discussed about this options a lot, but I think here each programmer choses what he prefers. Now I understand that I want to use mostly variant with escaping character, because for me it is now better then others by some points:

you don't have problem with long attributes and 80-symbols convention how could arise in last example with large indentations

you can look fast on all methods in chain separately and on all their attributes

it's just looks good for me ;)

But code style in product code for some projects I work don't support this notation and maybe it will be little uncomfortable problem for someone I work with to read it. So in most cases when I can't refactor this big method chain in some reasons - I use mostly notation like in original example.

P.s. Sorry about english. I don't care. Me you BORSCH. ಠ_ಠ