[Wtr-development] ruby cheat sheet

[aidy lewis]

Hi Bret,

2008/6/15 Bret Pettichord <bret at pettichord.com>:
> On Sun, Jun 15, 2008 at 3:44 PM, aidy lewis <aidy.lewis at googlemail.com>
> wrote:
>>
>> On the Ruby cheat sheet Marick (I think) writes this
>>
>> > (In fact everything in Ruby is an object.)
>>
>> Not true. The 'if' expression is not an object.
>>
>> Anyway, I think it indicates to new users that whatever they write in
>> Ruby will be OOP. And it is not the case
>
> Well since it is a cheat sheet, it is meant to be a summary of ideas, not a
> completely accurate one.
>
> I've been reading Kathy Sierra lately and she talks about how beginners need
> basic ideas, and that a problem with a lot of technical writing is that
> people are more concerned with writing sentences that experts will agree are
> 100% accurate rather than that beginners will agree are 100% helpful.
>
Just because something is accessible doesn't mean that it can be
inaccurate. Orwell's '1984' is accessible (used to be on the school
curriculum) but it takes experience to fully understand it.

> Ruby is unlike almost any other computer language in that the only kind of
> data that it supports are objects. You can get into semantics about how to
> express this idea, but the important thing, first, is that you understand
> it. For example, in Java, integers are not objects, only some things are
> objects and other things are not. In Java, and if expression cannot return
> an object, only a boolean, which is not an object.
>
> But in Ruby and if expression really is an object. Both "true" and "false"
> in Ruby are objects and they have methods. This surprises many people
> because this is not true of almost any other language.

OK. How about keywords and blocks?
>
> You say that this implies that everything in Ruby will be OOP, but this is
> not the case. I need to understand more about what you are trying to say
> here. Ruby does allow you to write code that appears to be procedural, but
> even this really just amounts to methods on the Kernal class.

You can write procdeural code in Ruby (see my framework), it is only
till recently while I have been pairing with developers that I have
begun to realise how procedural my code was. Testers are likely to
write procedural code in Ruby as they are coming from QTP, VBA or
Rational Robot etc. It is not the most effecient or enjoyable way to
write code; as there is always that nagging thought - that it is not
right. I think Matz in his book says we can write procedural code in
Ruby - as we can do in Python.
>
> This fact has important consequences. E.g. it is the reason why "include"
> statements should not be placed at the top of a file, but rather should be
> placed in the class where they are needed.

And this is my point. From the Watir examples I was putting 'includes'
at the top of files and not mixing in. It was a bad way of doing
things.

Other bad examples are: using xUnit and FIT for workflow tests. I
spent months trying fit xUnit into into acceptance tests. Rspec
story-runner fits.
>
> Maybe you can say more about what your concern is and give an example of a
> misunderstanding that you are worried about?

My point is that we need accurate and good examples from the start.
That I believe is something I need to start off.
>
> One problem we may have is that this cheat sheet was designed to accompany a
> face-to-face class and maybe it doesn't work as well in other contexts?
>
> Bret
>
Aidy