Comments on: Rubyize this : 2nd edition

By: canadacubeyo

canadacubeyo — Wed, 24 Sep 2008 15:59:09 +0000

canada ugly vacant frog green look head white vacant we america girl

By: usaglobalstu

usaglobalstu — Wed, 24 Sep 2008 15:52:50 +0000

canada vacant australia england joke free apple mail busy cube england green black kitchen

By: Refactor my Code « Marc-André Cournoyer’s blog

Refactor my Code « Marc-André Cournoyer’s blog — Wed, 26 Sep 2007 22:24:26 +0000

[...] have you seen on blogs the author asking to replace > and < with something else. Oh! and forget about indentation HTML eats those, Wordpress replace " with some weird character, etc, etc and etc! [...]

By: RSL

RSL — Wed, 01 Aug 2007 13:47:08 +0000

@ Eric: All the Ruby tutorials use Array#each [because they're teaching Ruby] but the Rails tutorials [and even the books, shame shame!] use for/in to attract programmers from other languages. It’s one of my pet peeves as it conditions the new Rails/Ruby programmer to keep thinking in his/her old programming language. This neglect to understand Ruby and Rails trickles usually ends up creating what I “lovingly” refer to as FrankenModels, with code and structures that use Ruby but look more like a PHP program.

As far as do..end or braces, they’re both very Ruby. The difference tends to be mostly stylistic, with braces being used more for short, one-line code blocks and do..end for blocks that take more code. Don’t let this fool you into thinking they’re the same though. When using variable assignment and the return value from a block, do…end will sometimes raise an error as it doesn’t bind as tightly as braces do and the assignment can’t properly determine what’s going on. This doesn’t happen a lot but when it does, you’ll be glad you learned that braces bind tighter.

By: Eric

Eric — Wed, 01 Aug 2007 07:13:44 +0000

Thanks to RSL for pointing this out.

It actually was the first time I ever used “for … in ….” instead of @songs.each{|song| }
I just saw it in previous code, and gave it a try!
But in every Ruby tutorial I saw, .each has been used.

I didn’t know “for … in …” was syntactic sugar for Array#each though…

Do you have any other examples of “Rubyer” code?

do..end vs {}
“a”

By: RSL

RSL — Tue, 31 Jul 2007 21:11:39 +0000

@ Alex: Neither link_to nor to_proc are Ruby methods themselves but Railsisms. I stand by my statement that a preference for the for/in methodology usually belies a programmer who hasn’t come to fully understand Ruby. For/in is syntactic sugar for Array#each, put there for programmers who can”t or won’t let go of programming habits they learned in other languages. Array#each is not only marginally faster but more importantly… it’s more _Ruby_. And by learning to think in Ruby [instead of translating your old programming languages' idioms to Ruby] one will no doubt see a marked increase in the efficiency of his/her code.

By: Alex

Alex — Mon, 30 Jul 2007 21:48:06 +0000

I don’t really think its really an issue of not knowing Ruby. I just think the syntax of for x in y is nicer than y.each do |x|. While I take the point about it being marginally slower, this is true (often to a larger extent) of a large number of other widely used, convenient methods, like link_to or to_proc. It’s just one of the downsides of Ruby I’m afraid.

By: RSL

RSL — Mon, 30 Jul 2007 21:33:30 +0000

Wow. I find it kinda disheartening that only one out of thirteen solutions broke away from the PHP/JS for/in mindset and went with the much more native Ruby Array#each. The Ruby compiler has to translate those “foreign” phrases into Ruby’s Array#each every time you use them. :( I really, really hate that so many “Rubyists” continue to baby-feed their students this ugly, clunky, fallback methodology. It’s usually a telltale sign [to me] that someone doesn’t really know their Ruby. :(

By: Scott

Scott — Mon, 30 Jul 2007 18:29:47 +0000

Fun! OK, here’s mine. Not much different from everyone else’s, but I thought I’d throw it in the ring.

First, in the controller:
@songs = Song.find(:all)

Second, in the migration that created songs, I’d set the default for rating to 1 and make rating an int. This gets rid of the need to check for nil in the rating. I’d think about validating for this in the model as well.

Here’s the view:

% @songs.each do |song| %
h2%= song.title.titleize %/h2
%= song.rating > 0 ? image_tag(’star.gif’) * rating : “This song hasn’t been rated yet” %
% end %

I tend to use the trinary operator a lot, so I find that readable. Others may differ :)

Scott

Oh yeah, if you use image tag like that, you need to have star.gif in the public/images directory. This seems more railsy to me. If you really want it in public, then I think that calling it like image_tag(‘/star.gif’) will do the trick.

By: macournoyer

macournoyer — Mon, 30 Jul 2007 17:41:32 +0000

# Controller def show @songs = Song.find(:all) end


# Helper

def song_rating(song)

  if song.rating.to_i > 0

    image_tag('star.gif') * song.rating.to_i

  else

    "This song hasn’t been rated yet"

  end

end
# View

>% @songs.each do |song| %<

  >h2<>%=h song.title.capitalize %<>/h2<

  >%= song_rating song %<

>% end %<

# Me self.drink! :coffey