As these updates come in thick and fast, it's quite hard to keep up
with you!

Could you quickly recap which chapters you'd most like feedback on, in
priority order?


On 17 Apr 2009, at 11:05, Steve Freeman wrote:

> as we approach the end-game...
>
> We've just uploaded some reworked material in Parts 3 and 4,
> particularly around ideas of Object-Oriented style, and dealing with
> persistence and threads.
>
> Comments, as always, welcome.
>
> S.
>
> 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
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Matt Wynne
http://blog.mattwynne.net
http://www.songkick.com

Some feedback on this as I read through it:

Example Scenario
* Paragraph #2: 'A customer has a contact address and, if they have a
credit card, card has a billing address'. Did you mean '*the* card has
a billing address'?
* There's a big diagram here with lots of entities on it, but are they
all actually relevant to the code being shown in the chapter?

Isolating Tests that Affect Persistent State
* paragraph #3: 'this knowledge' jars a bit - you didn't actually
mention the word 'knowledge in the preceding paragraph.

Testing an Object that Performs Persistence Operations
* paragraph #3: 'The unit tests for that behaviour can mock out the
CustomerBase.'. This is confusing to me - which behaviour are you
talking about unit testing here? I think you just described behaviour
that we're about to write (non mocking) tests for, so this doesn't
seem relevant.
* the example here is nice. I like how you've shown how to use test
cases on the boundary, and to use the customer's name as test
documentation.
* not sure you need to show me how to implement the matcher - there
must be hundreds of examples of doing this elsewhere - a footnote
explaining what's going on would be sufficient IMO, and keep the noise
down.
* when you showed the implementation of PersistentCustomerBase I was
surprised at first that you'd implemented addCustomer without writing
a test, then I realised you'd used that method in the test (which was
ostensibly a test for the customersWithExpiredCreditCardsAt method in
order to set up the data. Duh! Might be worth mentioning that, for
thickoes like me.

Round-Tripping Persistent Objects
* 'some of the builders involved perform database operations require
an active transaction.' => '... perform database *that* operations
require...'

Overall, I feel like this chapter is a bit heavy on technology (as
apologised for in the footnotes). I would probably just pull out that
stuff, as it will make the book date sooner, and detracts from more
important points of principle you're making. I'd also like you to
describe *when* you'd run these tests. Database-hitting tests are
notorious from slowing test suites down - have you given this point
any attention elsewhere maybe? If not I think it's worth a mention.
I'm working on a project right now where there's no separation between
fast mock-based unit tests and slow-arse database-hitting tests, and
it hurts.

On 17 Apr 2009, at 11:05, Steve Freeman wrote:

> as we approach the end-game...
>
> We've just uploaded some reworked material in Parts 3 and 4,
> particularly around ideas of Object-Oriented style, and dealing with
> persistence and threads.
>
> Comments, as always, welcome.
>
> S.
>
> 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
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Matt Wynne
http://blog.mattwynne.net
http://www.songkick.com

Hmmm. I try to but I'm not sure I can remember :)

That last update was mostly around Parts III and IV

S.

On 19 Apr 2009, at 23:12, Matt Wynne wrote:
> As these updates come in thick and fast, it's quite hard to keep up
> with you!
>
> Could you quickly recap which chapters you'd most like feedback on, in
> priority order?
>

Thanks Matt.  I've just pushed a new version of the persistence
chapter that addresses those points.

--Nat

2009/4/19 Matt Wynne <matt@...>:
>
>
> Some feedback on this as I read through it:
>
> Example Scenario
> * Paragraph #2: 'A customer has a contact address and, if they have a
> credit card, card has a billing address'. Did you mean '*the* card has
> a billing address'?
> * There's a big diagram here with lots of entities on it, but are they
> all actually relevant to the code being shown in the chapter?
>
> Isolating Tests that Affect Persistent State
> * paragraph #3: 'this knowledge' jars a bit - you didn't actually
> mention the word 'knowledge in the preceding paragraph.
>
> Testing an Object that Performs Persistence Operations
> * paragraph #3: 'The unit tests for that behaviour can mock out the
> CustomerBase.'. This is confusing to me - which behaviour are you
> talking about unit testing here? I think you just described behaviour
> that we're about to write (non mocking) tests for, so this doesn't
> seem relevant.
> * the example here is nice. I like how you've shown how to use test
> cases on the boundary, and to use the customer's name as test
> documentation.
> * not sure you need to show me how to implement the matcher - there
> must be hundreds of examples of doing this elsewhere - a footnote
> explaining what's going on would be sufficient IMO, and keep the noise
> down.
> * when you showed the implementation of PersistentCustomerBase I was
> surprised at first that you'd implemented addCustomer without writing
> a test, then I realised you'd used that method in the test (which was
> ostensibly a test for the customersWithExpiredCreditCardsAt method in
> order to set up the data. Duh! Might be worth mentioning that, for
> thickoes like me.
>
> Round-Tripping Persistent Objects
> * 'some of the builders involved perform database operations require
> an active transaction.' => '... perform database *that* operations
> require...'
>
> Overall, I feel like this chapter is a bit heavy on technology (as
> apologised for in the footnotes). I would probably just pull out that
> stuff, as it will make the book date sooner, and detracts from more
> important points of principle you're making. I'd also like you to
> describe *when* you'd run these tests. Database-hitting tests are
> notorious from slowing test suites down - have you given this point
> any attention elsewhere maybe? If not I think it's worth a mention.
> I'm working on a project right now where there's no separation between
> fast mock-based unit tests and slow-arse database-hitting tests, and
> it hurts.
>
> On 17 Apr 2009, at 11:05, Steve Freeman wrote:
>
>> as we approach the end-game...
>>
>> We've just uploaded some reworked material in Parts 3 and 4,
>> particularly around ideas of Object-Oriented style, and dealing with
>> persistence and threads.
>>
>> Comments, as always, welcome.
>>
>> S.
>>
>> 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
>>
>>
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>
> Matt Wynne
> http://blog.mattwynne.net
> http://www.songkick.com
>
>



--
http://www.natpryce.com

Hi all.  I've just pushed a new version of the chapter on Testing
Asynchronous Code that, I hope, explains things much more clearly.
For a start, it now has pictures and example code!

As always, your feedback is most welcome.

Cheers,
--Nat

--
http://www.natpryce.com

Sorry that my first comment is negative, but I find this an innapproriate,
unnecessary and generalisation likely to cause offense. I'd suggest removing it,
or at least changing it to "speaker of the house" ;)

--- In growing-oo-software-guided-by-tests@yahoogroups.com,
"stephen.cresswell@..." <stephen.cresswell@...> wrote:
>
> Sorry that my first comment is negative, but I find this an innapproriate,
unnecessary and generalisation likely to cause offense. I'd suggest removing it,
or at least changing it to "speaker of the house" ;)
>

All feedback is useful.  Thanks for letting us know.

--Nat

OK. It's gone.

On 19 May 2009, at 08:55, stephen.cresswell@... wrote:
> Sorry that my first comment is negative, but I find this an
> innapproriate, unnecessary and generalisation likely to cause
> offense. I'd suggest removing it, or at least changing it to
> "speaker of the house" ;)


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

Just republished to the website.

We've been doing a lot of work in Parts III and IV, and some rework in
the example. Unfortunately, the diagrams seem to have got larger.
We'll get back to that.

S.

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

"There are different opinions about whether test values should be literals..."

I'd like to see more of these types of discussions, weighing up the pros & cons,
making suggestions of which approach is best in which scenario, etc.

One candidate is targeted mocking / explicit verification (as advocated by
Mockito) vs the catch all approach that highlighted an unexpected method
invocation (page 95).

"but that includes j ust catching and printing" should be
"but that includes just catching and printing"

On Page 95 the bullet points are numbered 1, 2, 1, 2, 3, 4. It would be clearer
if they didn't restart.

I haven't read much further yet, so apologies if the following is covered later
on...

When to mock a 3rd party library would be an interesting side discussion. In the
past when I've used 3rd party libraries like apache's httpclient, I've tested my
code by starting an embedded instance of jetty and controlling it's responses.
There are equivalent libraries for FTP servers (apache), SMTP servers (wiser)
too. In concept it's no difference from testing persistence code using HSQLDB.

You obviously still need an end-to-end test that runs in a realistic
environment, since there's no guarantee that the embedded server will behave
like the real one.

2009/5/29 stephen.cresswell@... <stephen.cresswell@...>:
> I haven't read much further yet, so apologies if the following is covered
> later on...
>
> When to mock a 3rd party library would be an interesting side discussion.

We do discuss working with third party code in more detail later on,
in part 3 and 4.

--Nat.

Hi. My name is Chris Tucker.  I'm a (new) member of the Silicon Valley Patterns
group, and am covering/discussing the book in the current track there.  Most of
my career has been spent thus far on web-based software development in a variety
of different environments, with an interlude for a couple of years doing JEE
work for a medication delivery/verification company.  I've been interested in
TDD for some time, though have never previously quite executed on the "Driven"
part of the acronym; my hope for this book is that it can show me how and why I
can and should fix that.

The example is giving me problems.  It's a long read, and requires careful
parsing of the source code to really get a good handle on it.  There seem to be
some real golden nuggets of information in there, but I fear they'll be buried
under the details.  I got to page 100 and got too impatient...so, I skipped
ahead to Part III.  I really liked what I saw there.

Part III feels like what I wanted front and center, smacking me in the face when
I opened the book.  Take Chapter 16, for example.  I'm told clearly and
succinctly why it's useful (nay, essential) to build a good end-to-end test
early.  I'm told how to break the problem down to make it tractable.  I'm told
exactly what is meant by a Walking Skeleton, and how I might go about building
one for my own project.  I learn about what I might expect to be scary when I
start out with TDD (early uncertainty, potentially slow initial progress) and
what's going to be great when I get into the swing of things (stability, safe
and consistent progress through the project life-cycle).  Within 6 pages, you've
totally sold me on the idea, and I haven't had to think for one second about
Swing, XMPP, Hamcrest, JMock, WindowLicker, or the myriad other things I had to
keep in my head to understand the Walking Skeleton in Chapter 6 and the first
test in Chapter 7.

Having read a couple of chapters from Part III I tried turning back around and
re-reading the first two chapters of the example, and they made a whole lot more
sense.  The example felt, as it should, like a concrete demonstration of the key
principles of developing "guided by tests", rather than an amorphous description
of "this is how we'd tackle this specific problem".  Too often the first time
through the example it felt like "magic" was happening: the decision process was
logical, but I couldn't gain any insight into how to get myself into that
decision process.  While it's certainly valuable to see what you choose to do
and when I needed the information from later in the book to have any idea of how
to teach myself to get into a situation where I might make similar decisions
(modulo rather more experience with the approach).

My general feeling is that the book is somehow backwards, or at least not in
optimal order.  I'd like to see Part III pulled forward, and either the example
pushed back behind it or, perhaps better, have the example interwoven with it.

As a final note, I also jumped into Part IV and had a dig through a couple of
the more "patterns" style chapters, particularly Chapter 25 and 26, and again
really liked what I saw.  I do a lot of development that happens close to the
database, and both of those chapters had valuable information in them that I'm
already applying in my work.  The more of that stuff the better, in my opinion.

Cheers,
Chris

/Now/ you tell me? :)

Part of our intention was to avoid some of the hand-wavy writing we
see that gives people general principles but says nothing about what
to do in practice. Anyway, looking at the outline, options include:

- swapping parts 3 and 4
- moving the first 4 chapters of part 4 (up to Achieving OO design)
before part 3. They're the "manifesto" chapters. The second  4 are the
"style" chapters and could maybe come afterwards.
- breaking things up in some way.

S.


On 1 Jun 2009, at 08:44, David Peterson wrote:

> I know it's possibly too late in the day to make such a big change,
> but I do
> think this is a good idea. I didn't recognise it at the time but,
> looking
> back, I felt similarly. It took a lot effort to work through the
> code and
> examples and I didn't fully understand the "why" until I'd read the
> later
> sections.
> David
>
> 2009/6/1 cjtucker_80 <c.j.tucker@...>
>
>>
>>
>> The example is giving me problems. It's a long read, and requires
>> careful
>> parsing of the source code to really get a good handle on it. There
>> seem to
>> be some real golden nuggets of information in there, but I fear
>> they'll be
>> buried under the details. I got to page 100 and got too
>> impatient...so, I
>> skipped ahead to Part III. I really liked what I saw there.
>>

Sorry, I meant 2 and 3.

So, now I'm thinking Parts:
1) Introduction
2) The process of TDD (1st four chapters of part III)
3) Example
4) Sustainable TDD (2nd four chapters of part III)
5) Tricky topics

An alternative might be to merge 1) + 2), and 4) + 5)

S.

On 1 Jun 2009, at 10:35, David Peterson wrote:
> I'm sorry! I was too caught up in the trees!
>
> For me, it's not really parts 3 and 4 that are the problem, but
> section 2
> (the worked example). I think the book would have been easier to
> follow if
> the example was moved to later in the book.
> When the worked example was introduced, I didn't have enough
> understanding
> of the bigger picture of TDD or what good OO code looks like to
> understand
> how or why you were doing it like that. The code seemed right, but I
> felt
> exactly as Chris said: how you achieved it seemed like magic to me.
> At the
> time, I just thought it was 'cos I'm a bit thick, but after I'd read
> the
> other sections I came back to the example it was a lot clearer. It's
> possible others would find it easier to start with something concrete,
> though.
>
> David

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

On 29 May 2009, at 13:50, stephen.cresswell@... wrote:
> "There are different opinions about whether test values should be
> literals..."
>
> I'd like to see more of these types of discussions, weighing up the
> pros & cons, making suggestions of which approach is best in which
> scenario, etc.

OK. Sometimes it's hard for us to tell from the inside when to stop
and consider.

> One candidate is targeted mocking / explicit verification (as
> advocated by Mockito) vs the catch all approach that highlighted an
> unexpected method invocation (page 95).

The trouble is that I personally don't think there's a trade-off with
explicit verification, I just think it's a bad idea. We had it in the
original mockobjects library and it got us into trouble.
Unfortunately, it's not easy to have these discussions on the interweb
without it turning nasty, so my inclination is that we just state our
position--and then do consulting on cleaning up the mess...

S.


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

--- 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.
>

I would also agree that I got more out of section II after I had read
sections III and IV.

Pete

On Mon, June 1, 2009 03:44, David Peterson wrote:
> I know it's possibly too late in the day to make such a big change, but I
> do think this is a good idea. I didn't recognise it at the time but,
> looking back, I felt similarly. It took a lot effort to work through the
> code and examples and I didn't fully understand the "why" until I'd read
> the later sections.
> David
>
> 2009/6/1 cjtucker_80 <c.j.tucker@...>
>
>>
>>
>> The example is giving me problems. It's a long read, and requires
>> careful
>> parsing of the source code to really get a good handle on it. There seem
>> to
>> be some real golden nuggets of information in there, but I fear they'll
>> be
>> buried under the details. I got to page 100 and got too impatient...so,
>> I
>> skipped ahead to Part III. I really liked what I saw there.
>>
>> Part III feels like what I wanted front and center, smacking me in the
>> face
>> when I opened the book. Take Chapter 16, for example. I'm told clearly
>> and
>> succinctly why it's useful (nay, essential) to build a good end-to-end
>> test
>> early. I'm told how to break the problem down to make it tractable. I'm
>> told
>> exactly what is meant by a Walking Skeleton, and how I might go about
>> building one for my own project. I learn about what I might expect to be
>> scary when I start out with TDD (early uncertainty, potentially slow
>> initial
>> progress) and what's going to be great when I get into the swing of
>> things
>> (stability, safe and consistent progress through the project
>> life-cycle).
>> Within 6 pages, you've totally sold me on the idea, and I haven't had to
>> think for one second about Swing, XMPP, Hamcrest, JMock, WindowLicker,
>> or
>> the myriad other things I had to keep in my head to understand the
>> Walking
>> Skeleton in Chapter 6 and the first test in Chapter 7.
>>
>> Having read a couple of chapters from Part III I tried turning back
>> around
>> and re-reading the first two chapters of the example, and they made a
>> whole
>> lot more sense. The example felt, as it should, like a concrete
>> demonstration of the key principles of developing "guided by tests",
>> rather
>> than an amorphous description of "this is how we'd tackle this specific
>> problem". Too often the first time through the example it felt like
>> "magic"
>> was happening: the decision process was logical, but I couldn't gain any
>> insight into how to get myself into that decision process. While it's
>> certainly valuable to see what you choose to do and when I needed the
>> information from later in the book to have any idea of how to teach
>> myself
>> to get into a situation where I might make similar decisions (modulo
>> rather
>> more experience with the approach).
>>
>> My general feeling is that the book is somehow backwards, or at least
>> not
>> in optimal order. I'd like to see Part III pulled forward, and either
>> the
>> example pushed back behind it or, perhaps better, have the example
>> interwoven with it.
>>
>> As a final note, I also jumped into Part IV and had a dig through a
>> couple
>> of the more "patterns" style chapters, particularly Chapter 25 and 26,
>> and
>> again really liked what I saw. I do a lot of development that happens
>> close
>> to the database, and both of those chapters had valuable information in
>> them
>> that I'm already applying in my work. The more of that stuff the better,
>> in
>> my opinion.
>>
>> Cheers,
>> Chris
>>
>>
>>
>

> So, now I'm thinking Parts:
> 1) Introduction
> 2) The process of TDD (1st four chapters of part III)
> 3) Example
> 4) Sustainable TDD (2nd four chapters of part III)
> 5) Tricky topics
>

I like this approach.  The example is still long so I wonder if it might be
possible to break it up into a couple of pieces, but having not finished reading
the book I'm really not in a great position to suggest how that might end up
looking.  I feel like so far the book could stand alone without the example, so
I might favour some comment suggesting that the example can be skipped and
revisited out-of-order without fear of losing anything.  For the same reason I
would be tempted to push the example all the way to the back as an extended
case-study/appendix....but I think that's probably a rather more draconian
change than might be acceptable at this stage in the book's development.

Cheers,
Chris

Hi,

apologies for joining the fun a bit late.

I'm Mauro Talevi.  I provide development and methodology consultancy, primarily
on enterprise server-based applications.  I come from a probability and
computational physics background, but after a few years of research moved into
commercial development, almost all in Java in the past 10 or so years, leaving
my days of Fortran and C in the drawer.

Got into Agile several years ago when I met Paul Hammant at the XTC as I was
trying to get a better understanding of Avalon Phoenix microkernel, and have
since been collaborating to several OS projects: PicoContainer, JBehave,
XStream, Waffle, Maven ... although not all at the same time :-)

My small contribution to JMock is to provide the Maven packaging.

I'm still resisting the blog virus, but eventually I will capitulate.

Cheers

I'm not keen to demote the example (having spent so much time on it),
not least because it's the one thing that the other books don't do --
show you how to make it work in practice.

S.

On 2 Jun 2009, at 00:19, cjtucker_80 wrote:
> I like this approach.  The example is still long so I wonder if it
> might be possible to break it up into a couple of pieces, but having
> not finished reading the book I'm really not in a great position to
> suggest how that might end up looking.  I feel like so far the book
> could stand alone without the example, so I might favour some
> comment suggesting that the example can be skipped and revisited out-
> of-order without fear of losing anything.  For the same reason I
> would be tempted to push the example all the way to the back as an
> extended case-study/appendix....but I think that's probably a rather
> more draconian change than might be acceptable at this stage in the
> book's development.

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

Hi Steve,

I haven't had opportunity to read the full material, but I agree on
the value of the example. I haven't seen an explicit, detailed
description of someone building distributed systems in an incremental
manner, and there are challenges, to be sure.

- Kim

On Wed, Jun 3, 2009 at 11:33, Steve Freeman <steve@...> wrote:
> I'm not keen to demote the example (having spent so much time on it),
> not least because it's the one thing that the other books don't do --
> show you how to make it work in practice.
>
> S.
>
> On 2 Jun 2009, at 00:19, cjtucker_80 wrote:
>> I like this approach.  The example is still long so I wonder if it
>> might be possible to break it up into a couple of pieces, but having
>> not finished reading the book I'm really not in a great position to
>> suggest how that might end up looking.  I feel like so far the book
>> could stand alone without the example, so I might favour some
>> comment suggesting that the example can be skipped and revisited out-
>> of-order without fear of losing anything.  For the same reason I
>> would be tempted to push the example all the way to the back as an
>> extended case-study/appendix....but I think that's probably a rather
>> more draconian change than might be acceptable at this stage in the
>> book's development.

On 3 Jun 2009, at 10:33, Steve Freeman wrote:

> I'm not keen to demote the example (having spent so much time on it),
> not least because it's the one thing that the other books don't do --
> show you how to make it work in practice.

Have you thought about accompanying it with a (free) online screencast
of you working through it? It would be really cool to have a worked
example with you guys pairing on it online, and it might help the
youngsters with a short attention span to digest it.

Just a thought :)

>
> On 2 Jun 2009, at 00:19, cjtucker_80 wrote:
>> I like this approach.  The example is still long so I wonder if it
>> might be possible to break it up into a couple of pieces, but having
>> not finished reading the book I'm really not in a great position to
>> suggest how that might end up looking.  I feel like so far the book
>> could stand alone without the example, so I might favour some
>> comment suggesting that the example can be skipped and revisited out-
>> of-order without fear of losing anything.  For the same reason I
>> would be tempted to push the example all the way to the back as an
>> extended case-study/appendix....but I think that's probably a rather
>> more draconian change than might be acceptable at this stage in the
>> book's development.
>
> 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
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Matt Wynne
http://blog.mattwynne.net
http://www.songkick.com

On 3 Jun 2009, at 13:38, Matt Wynne wrote:
> Have you thought about accompanying it with a (free) online screencast
> of you working through it? It would be really cool to have a worked
> example with you guys pairing on it online, and it might help the
> youngsters with a short attention span to digest it.

Actually, yes, but just not now :)

S.