«

On 24/05/05, pat eyler <> wrote:
> Sorry for posting about my own article, but I'm interested in feedback,
> recommendations for future topics, etc. IBM has just published an
> article I wrote about doing test first development with Ruby:
>=20
> http://www.ibm.com/developerworks/ed...s-ruby1-i.html
>=20
> (sorry, you need to sign in (free account) to read it).
>=20
> I've got an opportunity to do some more writing for them (how much
> more depends on how well received/popular the articles are), and I'd
> love to get some feedback from the community about what kinds of
> Ruby things I should be sending their way.
>=20
> --
> thanks,
> -pate
> -------------------------
> We are often unable to tell people what they need to know, because
> they want to know something else, and would therefore only
> misunderstand what we said
> - the Raven (George MacDonald, Lilith)
>=20
>=20

Just started with your article, and I wonder why you build a
constructor that tests for object classes, why not simply call .to_s
on the argument?

class T
attr_reader :key

def initialize(key)
@key =3D key.to_s
end
en

[T.new(1).key, T.new("1").key, T.new([1]).key] =3D> ["1", "1", "1"]

best regards,

Brian

--=20
http://ruby.brian-schroeder.de/

Stringed instrument chords: http://chordlist.brian-schroeder.de/

On 5/24/05, Brian Schr=F6der <> wrote:
> Just started with your article, and I wonder why you build a
> constructor that tests for object classes, why not simply call .to_s
> on the argument?

I wrote it that way to create some (artificial, but easy to see)=20
boundary conditions for the article, this test doesn't actually=20
show up in the released versions of r43. It would have been
better to be able to verify the format of the id strings, but I
wasn't able to find that kind of information about them.

Actually testing it the way I did was a bit of a stretch. In the case=20
of the test key '1234' you could have a Numeric, but the real keys=20
all seem to be alphanumeric. It's certainly possible to create an
Array that would be stringified into a valid key as well, e.g.
["1", "2", "3", "4"]. =20

>=20
> class T
> attr_reader :key
>=20
> def initialize(key)
> @key =3D key.to_s
> end
> en
>=20
> [T.new(1).key, T.new("1").key, T.new([1]).key] =3D> ["1", "1", "1"]
>=20
> best regards,
>=20
> Brian
>=20
> --
> http://ruby.brian-schroeder.de/
>=20
> Stringed instrument chords: http://chordlist.brian-schroeder.de/
>=20
>=20


--=20
thanks,
-pate
-------------------------
We are often unable to tell people what they need to know, because
they want to know something else, and would therefore only
misunderstand what we said
- the Raven (George MacDonald, Lilith)

On 24/05/05, pat eyler <> wrote:
> On 5/24/05, Brian Schr=F6der <> wrote:
> > Just started with your article, and I wonder why you build a
> > constructor that tests for object classes, why not simply call .to_s
> > on the argument?
>=20
> I wrote it that way to create some (artificial, but easy to see)
> boundary conditions for the article, this test doesn't actually
> show up in the released versions of r43. It would have been
> better to be able to verify the format of the id strings, but I
> wasn't able to find that kind of information about them.
>=20
> Actually testing it the way I did was a bit of a stretch. In the case
> of the test key '1234' you could have a Numeric, but the real keys
> all seem to be alphanumeric. It's certainly possible to create an
> Array that would be stringified into a valid key as well, e.g.
> ["1", "2", "3", "4"].
>=20

I understand your motivation, but I think it is showing something that
I would rate as ugly ruby code to the world. If you really want a
string, you could have used to_str.

Please don't feel offended. I'm not even maintaining a library and
have until now never managed to really develop something test first,
let alone write an article and get it published. I feel that ugly
maybe is a bit too strong a word, but I can't find anything more
subtle.

I think it is important to show good ruby style in articles, and
ducktyping is one part of good style.

best regards,

Brian Schr=F6der

--=20
http://ruby.brian-schroeder.de/

Stringed instrument chords: http://chordlist.brian-schroeder.de/

pat eyler wrote:
> On 5/24/05, Brian Schröder <> wrote:
>
>>Just started with your article, and I wonder why you build a
>>constructor that tests for object classes, why not simply call .to_s
>>on the argument?
>
>
> I wrote it that way to create some (artificial, but easy to see)
> boundary conditions for the article, this test doesn't actually
> show up in the released versions of r43. It would have been
> better to be able to verify the format of the id strings, but I
> wasn't able to find that kind of information about them.


My own experience in writing abut Ruby, especially in the common case
where the audience is largely unfamiliar with Ruby, is that practices
and procedures tend to get a bit skewed for reason of discourse.

Code is often not as compact is a it might otherwise be because that
tends to require more background explanation. It's also hard to create
good demo cases, to find the balance between a compelling problem and a
7-page discussion limit.

Has anybody collected tips and guidelines for writing about Ruby? It
would be good to see more Ruby articles in high profile places (i.e.
sites outside the Ruby community circle, or in widely-circulated
magazines such as Linux Journal), but I wonder if people with good ideas
and useful knowledge hold off because they don't know where to start or
how to construct a well-organized, (reasonably) self-contained article.

James Britt

On 5/24/05, Brian Schr=F6der <> wrote:
> On 24/05/05, pat eyler <> wrote:
> I understand your motivation, but I think it is showing something that
> I would rate as ugly ruby code to the world. If you really want a
> string, you could have used to_str.
>=20
> Please don't feel offended.=20

No worries. I have thick skin.

> I'm not even maintaining a library and
> have until now never managed to really develop something test first,
> let alone write an article and get it published. I feel that ugly
> maybe is a bit too strong a word, but I can't find anything more
> subtle.

Inelegant? It's a valid point, but as James Britt points out in a
new (related) thread, it's an fine line between trying to make a=20
point and striving for elegant code. I'll tell you what, I'd be happy
to take on reviewers for upcoming articles. Contact me offline
if you have an interest in helping refine code or prose.

>=20
> I think it is important to show good ruby style in articles, and
> ducktyping is one part of good style.
>=20
> best regards,
>=20
> Brian Schr=F6der
>=20
> --
> http://ruby.brian-schroeder.de/
>=20
> Stringed instrument chords: http://chordlist.brian-schroeder.de/
>=20
>=20


--=20
thanks,
-pate
-------------------------
We are often unable to tell people what they need to know, because
they want to know something else, and would therefore only
misunderstand what we said
- the Raven (George MacDonald, Lilith)

On 5/24/05, James Britt <> wrote:
> My own experience in writing abut Ruby, especially in the common case
> where the audience is largely unfamiliar with Ruby, is that practices
> and procedures tend to get a bit skewed for reason of discourse.
>=20
> Code is often not as compact is a it might otherwise be because that
> tends to require more background explanation. It's also hard to create
> good demo cases, to find the balance between a compelling problem and a
> 7-page discussion limit.
>=20
> Has anybody collected tips and guidelines for writing about Ruby? It
> would be good to see more Ruby articles in high profile places (i.e.
> sites outside the Ruby community circle, or in widely-circulated
> magazines such as Linux Journal), but I wonder if people with good ideas
> and useful knowledge hold off because they don't know where to start or
> how to construct a well-organized, (reasonably) self-contained article.

I'm also very interested in this, as (I think) are several other people. I=
=20
don't want to bore the rest of the list though. Would there be any interes=
t
starting a list for Ruby related 'riting where we could collect tips and=20
guidelines, pass along leads/prospects, etc.?

>=20
> James Britt
>=20
>=20


--=20
thanks,
-pate
-------------------------
We are often unable to tell people what they need to know, because
they want to know something else, and would therefore only
misunderstand what we said
- the Raven (George MacDonald, Lilith)

pat eyler ha scritto:

>
> I'm also very interested in this, as (I think) are several other people. I
> don't want to bore the rest of the list though. Would there be any interest
> starting a list for Ruby related 'riting where we could collect tips and
> guidelines, pass along leads/prospects, etc.?

is'nt this the maybe this is something that should go into the "Why
Ruby" stuff[1]?

[1]http://rubyforge.org/projects/whyruby/

pat eyler wrote:
> On 5/24/05, James Britt <> wrote:

>>Has anybody collected tips and guidelines for writing about Ruby? It
>>would be good to see more Ruby articles in high profile places (i.e.
>>sites outside the Ruby community circle, or in widely-circulated
>>magazines such as Linux Journal), but I wonder if people with good ideas
>>and useful knowledge hold off because they don't know where to start or
>>how to construct a well-organized, (reasonably) self-contained article.
>
>
> I'm also very interested in this, as (I think) are several other people. I
> don't want to bore the rest of the list though. Would there be any interest
> starting a list for Ruby related 'riting where we could collect tips and
> guidelines, pass along leads/prospects, etc.?

I've started a page on RubyGarden:

http://www.rubygarden.com/ruby?WritingAboutRuby



James
--

http://www.ruby-doc.org - The Ruby Documentation Site
http://www.rubyxml.com - News, Articles, and Listings for Ruby & XML
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys

Hi,

pat eyler a écrit :
> Sorry for posting about my own article, but I'm interested in feedback,
> recommendations for future topics, etc. IBM has just published an
> article I wrote about doing test first development with Ruby:
>
> http://www.ibm.com/developerworks/ed...s-ruby1-i.html
>
> (sorry, you need to sign in (free account) to read it).
>
>
> I've got an opportunity to do some more writing for them (how much
> more depends on how well received/popular the articles are), and I'd
> love to get some feedback from the community about what kinds of
> Ruby things I should be sending their way.
>

Sorry for the late reply but I didn't have the time to read this article
before today.

First, I'd like to say that I found this article very interesting and
well written (easily understable by a newbie I think).

But I have a question. The article is entitled 'Test-first programming
with Ruby' but when talking about ZenTest you tell that it "can also
work in reverse, loading a test suite and writing code stubs for every
test" which corresponds to what this is all about. However the examples
you are showing after that are examples to go from code to tests. Why
didn't you show how to go from tests to code using ZenTest?

Ghislain

On 6/7/05, Ghislain Mary <> wrote:
> Hi,
>=20
> Sorry for the late reply but I didn't have the time to read this article
> before today.

No problems, feedback is always good.

>=20
> First, I'd like to say that I found this article very interesting and
> well written (easily understable by a newbie I think).
>=20

Good, that's my target.

> But I have a question. The article is entitled 'Test-first programming
> with Ruby' but when talking about ZenTest you tell that it "can also
> work in reverse, loading a test suite and writing code stubs for every
> test" which corresponds to what this is all about. However the examples
> you are showing after that are examples to go from code to tests. Why
> didn't you show how to go from tests to code using ZenTest?
>=20

I did, perhaps it didn't show up very well:



Letting ZenTest write code stubs for you works the same way. If you=20
were to run the tool against your existing ts_r43.rb like=20
'ZenTest.rb ts_r43.rb', it would generate the output shown here:

1 class R43

2 def key
3 raise NotImplementedError, 'Need to write key'
4 end

5 def echo
6 raise NotImplementedError, 'Need to write echo'
7 end

8 end
=20
Since all that ZenTest is writing for you are code stubs (which look
a *lot* like test stubs) I probably need to be more explicit about what's
going on.=20

> Ghislain
>=20
>=20


--=20
thanks,
-pate
-------------------------
We are often unable to tell people what they need to know, because=20
they want to know something else, and would therefore only=20
misunderstand what we said
- the Raven (George MacDonald, Lilith)