Skip to search.

Breaking News Visit Yahoo! News for the latest.

×Close this window

growing-oo-software-guided-by-tests · Growing O-O Software, Guided by Tests

The Yahoo! Groups Product Blog

Check it out!

Group Information

  • Members: 127
  • Category: Development
  • Founded: Jul 16, 2008
  • Language: English
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Hear how Yahoo! Groups has changed the lives of others. Take me there.

Messages

Advanced
Messages Help
Messages 363 - 392 of 401   Oldest  |  < Older  |  Newer >  |  Newest
Messages: Show Message Summaries Sort by Date ^  
#363 From: Steve Freeman <steve@...>
Date: Tue Aug 4, 2009 2:11 pm
Subject: one last opinion.
smg_freeman
Send Email Send Email
 
Nat and I can't agree on some of the code highlighting, so we need
some other opinions. The question is whether class/method highlighting
(using bold) is useful or not.

I've uploaded three versions of the same file:

This emphasises both class and method names:
http://www.mockobjects.com/with-all-highlighting.pdf

This emphasises only class names:
http://www.mockobjects.com/with-class-highlighting.pdf

This emphasises neither:
http://www.mockobjects.com/with-no-highlighting.pdf

Some of the code is still bold, but that's plain old emphasis.

Thoughts soonest, please

S.

#364 From: David Peterson <david@...>
Date: Tue Aug 4, 2009 2:23 pm
Subject: Re: one last opinion.
dpeterson72
Send Email Send Email
 
I prefer the last one - emphasising only the important bits.

Having class and method names in bold is actually the opposite of the convention in Eclipse where keywords are in bold and method names are in normal text.

David


2009/8/4 Steve Freeman <steve@...>
 

Nat and I can't agree on some of the code highlighting, so we need
some other opinions. The question is whether class/method highlighting
(using bold) is useful or not.

I've uploaded three versions of the same file:

This emphasises both class and method names:
http://www.mockobjects.com/with-all-highlighting.pdf

This emphasises only class names:
http://www.mockobjects.com/with-class-highlighting.pdf

This emphasises neither:
http://www.mockobjects.com/with-no-highlighting.pdf

Some of the code is still bold, but that's plain old emphasis.

Thoughts soonest, please

S.



#365 From: "dchelimsky" <dchelimsky@...>
Date: Tue Aug 4, 2009 2:23 pm
Subject: Re: one last opinion.
dchelimsky
Send Email Send Email
 
--- In growing-oo-software-guided-by-tests@yahoogroups.com, Steve Freeman
<steve@...> wrote:
>
> Nat and I can't agree on some of the code highlighting, so we need
> some other opinions. The question is whether class/method highlighting
> (using bold) is useful or not.
>
> I've uploaded three versions of the same file:
>
> This emphasises both class and method names:
> http://www.mockobjects.com/with-all-highlighting.pdf
>
> This emphasises only class names:
> http://www.mockobjects.com/with-class-highlighting.pdf
>
> This emphasises neither:
> http://www.mockobjects.com/with-no-highlighting.pdf
>
> Some of the code is still bold, but that's plain old emphasis.
>
> Thoughts soonest, please

Given that bold text is the MO for emphasis, I find it easier to understand what
is what with no additional syntax highlighting.

HTH,
David

>
> S.
>

#366 From: Thomas James Malone <tom.malone@...>
Date: Tue Aug 4, 2009 2:15 pm
Subject: Re: one last opinion.
tomjmalone2001
Send Email Send Email
 
I think none looks the best

But that just me.

Tom
On 4 Aug 2009, at 15:11, Steve Freeman wrote:

Nat and I can't agree on some of the code highlighting, so we need 
some other opinions. The question is whether class/method highlighting 
(using bold) is useful or not.

I've uploaded three versions of the same file:

This emphasises both class and method names:
http://www.mockobjects.com/with-all-highlighting.pdf

This emphasises only class names:
http://www.mockobjects.com/with-class-highlighting.pdf

This emphasises neither:
http://www.mockobjects.com/with-no-highlighting.pdf

Some of the code is still bold, but that's plain old emphasis.

Thoughts soonest, please

S.



#367 From: aman kohli <akohli@...>
Date: Tue Aug 4, 2009 2:31 pm
Subject: Re: one last opinion.
akohli
Send Email Send Email
 
I think that only highlighting the pertinent portions is more useful and not
just highlighting things like classnames and methods.

-- ak

--- On Tue, 8/4/09, Steve Freeman <steve@...> wrote:

> From: Steve Freeman <steve@...>
> Subject: [growing-oo-software-guided-by-tests] one last opinion.
> To: growing-oo-software-guided-by-tests@yahoogroups.com
> Date: Tuesday, August 4, 2009, 3:11 PM
> Nat and I can't agree on some of the
> code highlighting, so we need 
> some other opinions. The question is whether class/method
> highlighting 
> (using bold) is useful or not.
>
> I've uploaded three versions of the same file:
>
> This emphasises both class and method names:
> http://www.mockobjects.com/with-all-highlighting.pdf
>
> This emphasises only class names:
> http://www.mockobjects.com/with-class-highlighting.pdf
>
> This emphasises neither:
> http://www.mockobjects.com/with-no-highlighting.pdf
>
> Some of the code is still bold, but that's plain old
> emphasis.
>
> Thoughts soonest, please
>
> S.
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>     mailto:growing-oo-software-guided-by-tests-fullfeatured@yahoogroups.com
>
>
>

#368 From: Llewellyn Falco <isidore@...>
Date: Tue Aug 4, 2009 2:41 pm
Subject: Re: one last opinion.
isidore_us
Send Email Send Email
 
I prefer option D) other :-)

We are all use to syntax highlighting. I can not think of an editor that does not offer it.
The reason this exists across the board is because it makes code easier to read.

but your examples don't do that. The highlighting you are using isn't what you would use for in an editor. granted you can't use color, but you still have font/bold/italics even grayscale. I don't have the perfect syntax highlighting in greyscale yet, but attached is  my current recommendation.

also, I like line numbers. makes it easier to communicate. I find they are something I turn on early when pairing.

reading code is one of the harder parts of code books. please make it as easy as possible.

I would also suggest a light grey highlighter for selected lines instead of all bold.


llewellyn falco





1 of 1 Photo(s)


#369 From: Steve Freeman <steve@...>
Date: Tue Aug 4, 2009 3:17 pm
Subject: Re: one last opinion.
smg_freeman
Send Email Send Email
 
> Having class and method names in bold is actually the opposite of the
> convention in Eclipse where keywords are in bold and method names
> are in
> normal text.

That's why I set up my eclipse differently...

S

#370 From: Russ Rufer <russ@...>
Date: Tue Aug 4, 2009 3:50 pm
Subject: Re: one last opinion.
russrufer
Send Email Send Email
 
Another vote for "emphasises neither". Slight preference.

My second choice would be "emphasises only class names." It looks nice, but I wonder how to highlight that a class name has changed? The class names are easy enough to find without highlighting.  But it wouldn't really detract from the experience if you choose this option.

I think using bold for all method names obscures the changes you're trying to call attention to.

- Russ
 

On Tue, Aug 4, 2009 at 8:17 AM, Steve Freeman <steve@...> wrote:
 

> Having class and method names in bold is actually the opposite of the
> convention in Eclipse where keywords are in bold and method names
> are in
> normal text.

That's why I set up my eclipse differently...

S



#371 From: aman kohli <akohli@...>
Date: Tue Aug 4, 2009 4:11 pm
Subject: Re: one last opinion.
akohli
Send Email Send Email
 
> That's why I set up my eclipse differently...

what looks good on the screen, does not necessarily look good on the page.

-- ak


>
> S
>

#372 From: Pietro Di Bello <pierodibello@...>
Date: Wed Aug 5, 2009 12:07 pm
Subject: Typos in Chapter 1
pierodibello
Send Email Send Email
 
Hi all, 
I think I've found two typos in chapter 1.

In the Testing End-to-End paragraph, the last statement is:
The result is a more difficult release cycle than we would like, so we have to be understand our whole technical and organisational environment. 

to *be* understand sound strange to me...

In the Levels of Testing paragraph:
The distinction is that these the Integration Tests are there

the words "Integration Tests" seem redundant here.

HTH


Pietro Di Bello
Sourcesense - making sense of Open Source http://www.sourcesense.com

#373 From: "Pietro Di Bello" <pierodibello@...>
Date: Wed Aug 5, 2009 12:15 pm
Subject: Re: Introductions
pierodibello
Send Email Send Email
 
Hi, I'm Pietro Di Bello, I'm a senior sw engineer, programming mainly in Java
(since 1999).
I follow and practice eXtreme Programming and Agile Methods since 2002.

Pietro


--- In growing-oo-software-guided-by-tests@yahoogroups.com, "nat_pryce"
<nat.pryce@...> wrote:
>
> Hi all.  There's now quite a few people in this group, some of whom we
> don't know (or we don't recognise your Yahoo IDs).  Time for
> introductions!
>
> Please reply, telling us who you are and what your background and
> experience is.
>
> Here's my bio to kick things off:
>
> I am Nat Pryce.  I develop software and provide consultancy and
> training in software design and development process and practices,
> mostly in the finance and telecoms industries. I'm also a part-time
> research fellow at Imperial College where I study privacy in mobile
> systems and do occasional teaching.
>
> I have about 15 years experience in the industry, in a variety of
> systems and languages, ranging from C for tiny mote devices to Java in
> global enterprise integration systems with all sorts of wierder
> languages in between.
>
> I'm one of the authors of the jMock unit-testing framework and the
> WindowLicker GUI testing framework.
>
> I (occasionally) blog at http://nat.truemesh.com.
>

#374 From: Pietro Di Bello <pierodibello@...>
Date: Wed Aug 5, 2009 12:28 pm
Subject: Minor typo in chapter 8 - Building on Third-Party Code
pierodibello
Send Email Send Email
 
Other minor typo in Chapter 8. Building on Third-Party Code, paragraph "Only Mock Types That You Own":

To develop against an third-party API...

Seems to me to be more correct to use "a third-party API"

Pietro Di Bello
Sourcesense - making sense of Open Source http://www.sourcesense.com

---------- Forwarded message ----------
From: Pietro Di Bello <pierodibello@...>
Date: Wed, Aug 5, 2009 at 14:07
Subject: Typos in Chapter 1
To: growing-oo-software-guided-by-tests@yahoogroups.com


Hi all, 
I think I've found two typos in chapter 1.

In the Testing End-to-End paragraph, the last statement is:
The result is a more difficult release cycle than we would like, so we have to be understand our whole technical and organisational environment. 

to *be* understand sound strange to me...

In the Levels of Testing paragraph:
The distinction is that these the Integration Tests are there

the words "Integration Tests" seem redundant here.

HTH


Pietro Di Bello
Sourcesense - making sense of Open Source http://www.sourcesense.com


#375 From: Steve Freeman <steve@...>
Date: Thu Aug 6, 2009 1:41 pm
Subject: Re: Minor typo in chapter 8 - Building on Third-Party Code
smg_freeman
Send Email Send Email
 
Thanks for helping out. I should point out that the on-line version is
rather out of date and we've nearly finished copy editing.

Sorry for not being clearer

S.

On 5 Aug 2009, at 13:28, Pietro Di Bello wrote:
> Other minor typo in Chapter 8. Building on Third-Party Code,
> paragraph "Only Mock Types That You Own":



Steve Freeman
Winner of the Agile Alliance Gordon Pask award 2006

http://www.m3p.co.uk

M3P Limited.
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
Company registered in England & Wales. Number 03689627

#376 From: "Pete Keller" <pete@...>
Date: Thu Aug 13, 2009 7:24 pm
Subject: What is the current status
pete_keller
Send Email Send Email
 
When will we see it in print?

Thanks
Pete

#377 From: "nat_pryce" <nat.pryce@...>
Date: Mon Aug 17, 2009 5:11 pm
Subject: Re: What is the current status
nat_pryce
Send Email Send Email
 
--- In growing-oo-software-guided-by-tests@yahoogroups.com, "Pete Keller"
<pete@...> wrote:
>
> When will we see it in print?

It will be out in November.

--Nat

#378 From: "Pete Keller" <pete@...>
Date: Mon Aug 17, 2009 6:32 pm
Subject: Re: Re: What is the current status
pete_keller
Send Email Send Email
 
On Mon, August 17, 2009 13:11, nat_pryce wrote:
> --- In growing-oo-software-guided-by-tests@yahoogroups.com, "Pete Keller"
> <pete@...> wrote:
>>
>> When will we see it in print?
>
> It will be out in November.
>
> --Nat
>

Sounds like a Christmas present to me.    8)  <cue Snoopy Dance Music here>

Thanks
Pete

#379 From: George Dinwiddie <lists@...>
Date: Tue Sep 1, 2009 4:20 pm
Subject: state machine diagram (was: [TDD] incomplete vs broken)
gdinwiddie
Send Email Send Email
 
Dave Smith wrote:
>>>>>> I would once again humbly suggest that you might be starting with the
>>>>>> wrong test. If you are doing TDD you should be starting with a unit
>>>>>> test for the thing you are about to write, not with a functional test
>>>>>> that requires you to integrate pieces that don't yet exist.
>>>>> Starting with a functional test as a statement of where you're heading
>>>>> is
>>>> a
>>>>> perfectly fine way to do TDD.
>>>>>
>>>> Provided you can make that functional test pass with a simple
>>>> implementation that can be written in under a minute I agree.
>>>> Otherwise, it may work for you, but it isn't TDD.
>>>>
>> In other words: TDD is, "Write a test, see it fail, get it to pass,
>> refactor, repeat." If you skip (or delay) the "get it to pass" part
>> you are doing something, but it isn't TDD.
>>
>>> Citation?
>>>
>> http://c2.com/cgi/wiki?TestDrivenDevelopment
>>
>
> That's one school of thought. Here's another:
> http://www.mockobjects.com/book/ongoing.html

Irrespective of the quibbling on the TDD list, I saw the diagram
http://www.mockobjects.com/book/figures/listening-to-tests.png and found
it a little troubling.  To me, it seems to suggest writing a failing
test and then refactoring, without making the test pass first.

I forget whether this is a mealy or moore state machine diagram, but one
   of them represents steady state as the nodes, and actions as the arcs.
   Would that make for a less misinterpreted diagram?

   - George
     [Apologizing again for not keeping up with the book and this list]


--
   ----------------------------------------------------------------------
    * George Dinwiddie *                      http://blog.gdinwiddie.com
    Software Development                    http://www.idiacomputing.com
    Consultant and Coach                    http://www.agilemaryland.org
   ----------------------------------------------------------------------

#380 From: Steve Freeman <steve@...>
Date: Wed Sep 2, 2009 9:08 am
Subject: Re: state machine diagram (was: [TDD] incomplete vs broken)
smg_freeman
Send Email Send Email
 
the intention is that sometimes you have to refactor a broken test to
make the error messages meaningful before making it pass.
Unfortunately, I think it's too late to change the figure now.

Thanks

S.

On 1 Sep 2009, at 17:20, George Dinwiddie wrote:
> Irrespective of the quibbling on the TDD list, I saw the diagram
> http://www.mockobjects.com/book/figures/listening-to-tests.png and
> found
> it a little troubling.  To me, it seems to suggest writing a failing
> test and then refactoring, without making the test pass first.
>
> I forget whether this is a mealy or moore state machine diagram, but
> one
>  of them represents steady state as the nodes, and actions as the
> arcs.
>  Would that make for a less misinterpreted diagram?
>
>  - George
>    [Apologizing again for not keeping up with the book and this list]
>

#381 From: Nat Pryce <nat.pryce@...>
Date: Wed Sep 2, 2009 6:16 pm
Subject: Re: state machine diagram (was: [TDD] incomplete vs broken)
nat_pryce
Send Email Send Email
 
Actually the intention is that while trying to write a test you sometimes have to go back and refactor (on green -- hence the green arc) to get the code into a state that lets  you easily write the test (which is then red).


On 2 Sep 2009, at 10:08, Steve Freeman <steve@...> wrote:

 

the intention is that sometimes you have to refactor a broken test to
make the error messages meaningful before making it pass.
Unfortunately, I think it's too late to change the figure now.

Thanks

S.

On 1 Sep 2009, at 17:20, George Dinwiddie wrote:
> Irrespective of the quibbling on the TDD list, I saw the diagram
> http://www.mockobjects.com/book/figures/listening-to-tests.png and
> found
> it a little troubling. To me, it seems to suggest writing a failing
> test and then refactoring, without making the test pass first.
>
> I forget whether this is a mealy or moore state machine diagram, but
> one
> of them represents steady state as the nodes, and actions as the
> arcs.
> Would that make for a less misinterpreted diagram?
>
> - George
> [Apologizing again for not keeping up with the book and this list]
>


#382 From: George Dinwiddie <lists@...>
Date: Wed Sep 2, 2009 7:34 pm
Subject: Re: state machine diagram
gdinwiddie
Send Email Send Email
 
Yes, the text makes that clear.  Perhaps the picture is not as confusing
to other people as it is to me.

   - George

Nat Pryce wrote:
>
>
> Actually the intention is that while trying to write a test you
> sometimes have to go back and refactor (on green -- hence the green arc)
> to get the code into a state that lets  you easily write the test (which
> is then red).
>
> --Nat
>
> www.natpryce.com <http://www.natpryce.com>
>
> On 2 Sep 2009, at 10:08, Steve Freeman <steve@...
> <mailto:steve@...>> wrote:
>
>>
>>
>> the intention is that sometimes you have to refactor a broken test to
>> make the error messages meaningful before making it pass.
>> Unfortunately, I think it's too late to change the figure now.
>>
>> Thanks
>>
>> S.
>>
>> On 1 Sep 2009, at 17:20, George Dinwiddie wrote:
>> > Irrespective of the quibbling on the TDD list, I saw the diagram
>> >
>>
<http://www.mockobjects.com/book/figures/listening-to-tests.png>http://www.mocko\
bjects.com/book/figures/listening-to-tests.png
>> and
>> > found
>> > it a little troubling. To me, it seems to suggest writing a failing
>> > test and then refactoring, without making the test pass first.
>> >
>> > I forget whether this is a mealy or moore state machine diagram, but
>> > one
>> > of them represents steady state as the nodes, and actions as the
>> > arcs.
>> > Would that make for a less misinterpreted diagram?
>> >
>> > - George
>> > [Apologizing again for not keeping up with the book and this list]
>> >
>>
>
>
>


--
   ----------------------------------------------------------------------
    * George Dinwiddie *                      http://blog.gdinwiddie.com
    Software Development                    http://www.idiacomputing.com
    Consultant and Coach                    http://www.agilemaryland.org
   ----------------------------------------------------------------------

#383 From: Nat Pryce <nat.pryce@...>
Date: Thu Sep 3, 2009 4:29 pm
Subject: Re: state machine diagram
nat_pryce
Send Email Send Email
 
Maybe the internal arc should loop from "refactor" back to "refactor", approaching but not quite reaching the "write a failing test" node. Although that is also misleading, because it is the act of writing a failing test that drives further refactoring.

The diagram may have to remain an imperfect depiction of reality! 

On 2 Sep 2009, at 20:34, George Dinwiddie <lists@...> wrote:

 

Yes, the text makes that clear. Perhaps the picture is not as confusing
to other people as it is to me.

- George

Nat Pryce wrote:
>
>
> Actually the intention is that while trying to write a test you
> sometimes have to go back and refactor (on green -- hence the green arc)
> to get the code into a state that lets you easily write the test (which
> is then red).
>
> --Nat
>
> www.natpryce.com <http://www.natpryce.com>
>
> On 2 Sep 2009, at 10:08, Steve Freeman <steve@....uk
> <mailto:steve@....uk>> wrote:
>
>>
>>
>> the intention is that sometimes you have to refactor a broken test to
>> make the error messages meaningful before making it pass.
>> Unfortunately, I think it's too late to change the figure now.
>>
>> Thanks
>>
>> S.
>>
>> On 1 Sep 2009, at 17:20, George Dinwiddie wrote:
>> > Irrespective of the quibbling on the TDD list, I saw the diagram
>> >
>> <http://www.mockobjects.com/book/figures/listening-to-tests.png>http://www.mockobjects.com/book/figures/listening-to-tests.png
>> and
>> > found
>> > it a little troubling. To me, it seems to suggest writing a failing
>> > test and then refactoring, without making the test pass first.
>> >
>> > I forget whether this is a mealy or moore state machine diagram, but
>> > one
>> > of them represents steady state as the nodes, and actions as the
>> > arcs.
>> > Would that make for a less misinterpreted diagram?
>> >
>> > - George
>> > [Apologizing again for not keeping up with the book and this list]
>> >
>>
>
>
>

--
----------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------


#384 From: "hrvojep" <hrvojep@...>
Date: Wed Nov 4, 2009 7:59 am
Subject: Source code for the book
hrvojep
Send Email Send Email
 
Hi,
I bought the book and want to work on the examples from the Sniper Auction,
where is the source code for the book?
Cheers
h.

#385 From: Steve Freeman <steve@...>
Date: Wed Nov 11, 2009 10:31 am
Subject: Re: Source code for the book
smg_freeman
Send Email Send Email
 
> I bought the book and want to work on the examples from the Sniper Auction,
where is the source code for the book?

I've just uploaded the final example code onto GitHub. There's a link from:

http://www.growing-object-oriented-software.com/

S


Steve Freeman

Winner of the Agile Alliance Gordon Pask award 2006
Book: http://www.growing-object-oriented-software.com

+44 (0) 797 179 4105
M3P Limited.  http://www.m3p.co.uk
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
Company registered in England & Wales. Number 03689627

#386 From: "hotjycoolguy" <hotjycoolguy@...>
Date: Tue Jan 26, 2010 3:10 am
Subject: Cool HarleyBoyz wants to add you as a friend :)
hotjycoolguy
Send Email Send Email
 
I want to add you as a friend so you can see my profile with my pictures.Here is
the link:
http://www.ourlivespace.com/hotcoolguy/addme.htm

#387 From: "carlisedfriends" <carlisedfriends@...>
Date: Wed Jan 27, 2010 4:56 am
Subject: [Private Photo Share] Cali Girl- Has sent you private photos.
carlisedfriends
Send Email Send Email
 
I do not want the entire group seeing these photos.Because some may recognize
me.
Here's the link:
http://www.ourlivespace.com/hotgirl/photos.htm

Enjoy babe :)

#388 From: "carlisedfriends" <carlisedfriends@...>
Date: Fri Feb 5, 2010 2:30 am
Subject: Message Alert - You Have 1 Important Unread Message!
carlisedfriends
Send Email Send Email
 
Message Alert - You Have 1 Important Unread Message!
http://www.ourlivespace.com/HotGirl/photos.htm

#389 From: "carlisedfriends" <carlisedfriends@...>
Date: Sun Feb 28, 2010 10:06 am
Subject: Sexy biker babes are waiting to meet you!
carlisedfriends
Send Email Send Email
 
Sexy biker babes are waiting to meet you! Check their HOT profiles here:
http://ozzadia.zoomshare.com/files/chicks.htm

#390 From: Robi Yagel <robi.robi.y@...>
Date: Wed Mar 3, 2010 5:20 pm
Subject: Slide set
robi.yagel
Send Email Send Email
 
Hello,
Are there some slides following the book content, or at least major parts, or even from one of the courses you provides.
Thanks, Rob

#391 From: "hotvhcoolguy" <hotvhcoolguy@...>
Date: Thu Mar 25, 2010 3:31 am
Subject: plz add me as your friend!
hotvhcoolguy
Send Email Send Email
 
Hi, I am Rosana. plz add me as your friend:

#392 From: "hotjycoolguy" <hotjycoolguy@...>
Date: Sat Mar 27, 2010 6:17 am
Subject: Looking for SEX partner!
hotjycoolguy
Send Email Send Email
 
Looking for SEX partner! Check my H.O.T photos here:
http://skinnymi.zoomshare.com/files/intimate.htm

Messages 363 - 392 of 401   Oldest  |  < Older  |  Newer >  |  Newest
Add to My Yahoo!      XML What's This?

Copyright © 2010 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines NEW - Help