Just want to note, as the author, that this post is almost 18 months old now and I don't necessarily stand by them all anymore ;-) (I'd need to go back and re-edit to make that assertion..)

It may be helpful to move the datestamps of Ruby Inside's entries up to the top, and more prominently style them (size, colour). I was this close to chastising you for not having datestamps at all :) until I noticed the one for this article in small, non-descript black text between the post and the comments.

This is one of those things where results outweigh logic and decency. This post would almost certainly not have seen renewed interest in the last few weeks if the date/time were easily noticeable. It's quite a common "trick" on blogs now. Some people just immediately leave if they're on a post that's over a year old.

I'm sceptical of that reasoning. A post can have enough merit to outweight the negative impression old age gives. I think the lack of a datestamp can often lead to confusion or mild bewilderment as the reader tries to guesstimate time context. "Current developments for project foobar include A, B, and C. On the roadmap are D, E and F." How current is that "current"?

I certainly won't leave such posts just because they are over a year old! The post was interesting for it's contents and the dates imho should have no effect.

please also add a year

Careful with one of those tips [* x] does return x if x is an array and [x] otherwise except in the case where x is a hash in which case it transforms the hash to an array. Eg:

x = {:a => 1, :b => 2}

[* x]

=> [[:a, 1], [:b, 2]]

Some of the other tips just make the code less readable

Although he does helpfully preface several with 'this is a bad example' and 'this is not really a good idea'.

I like how #1 is about 'taking the pain out of the process' where the 'pain' to be removed appears to be 'the method name that describes what your code is doing'.

I also learned that "Array#*, when supplied with a number, multiplies the size of the array by duplicate elements". I can only assume this is a very common and useful operation out there in GPU Vector Magic Land.

I was somewhat disappointed that #12 suggested using ranges for number comparison instead of the obviously more idiomatic solution of manipulating metaclasses so every number has a working 'decade' method.

I often do the %w{rubygems sinatra etc}.each{|lib| require lib} trick. If I were more motivated, I would submit a patch that would allow require to take an array.

I'd bet there's something like that in the Facets lib already.

A cursory look for in Facets turned up http://facets.rubyforge.org/apidoc/api/core/classes/Kernel.h...

It is certainly useful, albeit not exactly what I want. Then again, I said cursory.

  >> 3. Format decimals
  >> money = 9.5
  >> "%.2f" % money                       # => "9.50"

Seriously? IMHO These sorts of things are not nice. To read the code you have to know these special magic operators. It's not immediately obvious it's calling a function to do string formatting.

Readable code is so important :/

Really? This is just a standard printf-style format string, something which all programmers should be familiar with. Even the '%' syntax isn't unique to Ruby; Python uses it as well IIRC.

The formatting string itself, sure - fine. What I think is ugly is using an operator (%) to call a function like that :/ It's just non-obvious and quirky. If you don't know ruby you won't be able to guess what it's doing.

The best solution here is probably to learn Ruby. There are plenty of non-obvious things in various programming languages. The benchmark should be readability by people who know the language.

I guess that any seasoned programmer would be well-aware of the printf notation (%.2f) and would immediately guess that % must be a printf operator in this language.

I love using printf all the time in my programs and it is one of my litmus tests for a new language - does it have easy quick access to sprintf? (Java failed this test)