Dojo @ FWD on Monday

[Tom Hall]

Sorry for the late notice, I am away in Paris, Christian will be there
from forward to look after you though.

http://april-fwd-cljdojo.eventbrite.com/

I have deleted the recurring event as a few of you mentioned you like
to know who is coming and you cant see that info on the recurring
events for some reason.

Thanks and see you all soon,
Tom

[Christian Blunden]

I am open to suggestions for food.. do we want to do something besides pizza?

--
You received this message because you are subscribed to the Google Groups "London Clojurians" group.
To unsubscribe from this group and stop receiving emails from it, send an email to london-clojuri...@googlegroups.com.
To post to this group, send email to london-c...@googlegroups.com.
Visit this group at http://groups.google.com/group/london-clojurians?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Bruce Durling]

Tommy,

Thanks for announcing.

Christian,

Thanks for picking up the hosting. Sandwiches are good or perhaps pasta?

cheers,
Bruce

--
@otfrom | CTO & co-founder @MastodonC | mastodonc.com
See recent coverage of us in the Economist http://econ.st/WeTd2i and
the Financial Times http://on.ft.com/T154BA

[Christian Blunden]

We've got 4 sign ups so far.. anyone else thinking of attending?

Also, still open to suggestions for food.. happy to go with Bruce's options

Just to get an idea

- Sandwiches.. like subway? like Pret?

pasta might be a bit messy/difficult? Can't guarantee plates/cutlery will be clean...

C>

[Bruce Durling]

Sandwiches like Subway. I should be there tomorrow. I'll go sign up now.

cheers,
Bruce

On Sun, Apr 7, 2013 at 6:09 PM, Christian Blunden

[Mathieu Gauthron]

I've just signed up. I'll be coming as well.

Cheers,

Mathieu

Regards,

Mathieu Gauthron

Director

Matlux Ltd

+447728407050

[David James Humphreys]

I re-signed up too. Subway / Prêt etc is ok for me too.

[Robert]

I'll try and make it. Pret sandwich platter is always a winner with me.

[Jennifer Smith]

Sorry cannot make it this time chaps - hope it's a good one

jen

[Christian Blunden]

Ok so I have some good news and bad news..

The bad news is that due to some unfortunate administrative red tape.. there shall be pizza _again_ tonight

The good news is that due to some unfortunate administrative red tape.. there shall be pizza tonight ;)

see you all here..

Forward

Level 2, Centro 3

19 Mandela St, Camden

pizza arrives at 6:30 

Christian

On 7 April 2013 19:47, Robert <shudd...@gmail.com> wrote:

[Daniel Barlow]

Oh no, not pizza again.  Yay, pizza

Just registered, see you there ...

d...@telent.net
http://ww.telent.net

[Mathieu Gauthron]

Its fine with me. I prefer pizza over sandwiches.. ;-)

event if i know sandwiches would be better for my waistline. Nevermind...

[Robert Claeson MBCS, Cert Acc]

It's bread and cheese either way.

[Christian Blunden]

bread and cheese *heaven*

[david h]

First of all: thanks to Christian and Forward for hosting the dojo.

On team 2 we tried to use TDD from the start to build an inflate/deflate library. We spent a lot of time discussing how useful the tests would be.

We looked at Clojure test.generative. We decided to avoid using it as we didn’t fully understand.

We used the red, green, refactor approach; make a test that fails (red), do enough to make it pass (green), then refactor to cover other cases.

This approach was rather slow and seemed to focus more on moving along than really thinking about our problem. There was a lot of “fake it ’til you make it” to stub a method to get green.

We also discussed how the outside-in testing approach may not be a really good fit for Clojure. We can’t be sure it’s our own fault.

We all got back together for show-and-tell, it seemed as though the other teams had a similar issue with using tests.

There was a lot of really insightful commentary on different aspects of testing with a focus on it’s application to Clojure.

We had some arguments for and against using the REPL for exploration during the test phase. Overall, it was a really helpful dojo – even though we didn’t write too much code we managed to think about the testing.

[Bruce Durling]

Fellow Clojurians,

I had a lot of fun too. It was great to be able to talk about testing,
writing 2nd(3rd4th) versions and think about how program design may be
different in a functional language.

cheers,
Bruce

[Jennifer Smith]

Wow sounds like an insightful dojo - sorry I could not make it.

It's intersting that you think that outside-in style testing may not be a good fit for clojure... if you mean what i think you mean by that. The few times I have ever written tests in clojure I used midge and I found that the outside-in approach worked well. I was able to think through the whole top level design of how I wanted the parts of my program to fit together, without worrying about the implementation details.

My thoughts are that clojure is neither a good or a bad fit for writing tests first but it depends on what your goals are - repl experimentation covers a lot of what I use unit tests for in other languages. 

[Joel Gluth]

This may be a trite observation, but: the outside-in testing approach
is married to the top-down, decompositional model of traditional
languages (be they OO or otherwise).

The LISPy bottom-up way of doing program design lends itself to a
different style of "think-first" test writing, I think.

Now we are really in the realm of personal opinion, but: this is a
very good thing. The red-green-refactor approach never sat very well
with me, though at times I have done it a lot.

[what were the skies like when you were young?]

[Steve Freeman]

sorry to have missed this one, I wish I'd know that would be the topic...

Having passed through both, I'm not sure that outside-in is quite the same as top-down. Abelson and Sussman talk in terms of "programming by wishful thinking", so there is a respectable lisp history for some of the concepts.

My brief experience of working with Bruce (mostly consisting of not getting my environment to run), was that test-first is still useful for forcing out concepts. Every time I've done it, including with bash, I've found it's helped to break things into more smaller pieces.

S

[Bruce Durling]

Steve,

On Tue, Apr 9, 2013 at 2:40 PM, Steve Freeman <st...@m3p.co.uk> wrote:
> sorry to have missed this one, I wish I'd know that would be the topic...

I was quite surprised the voting went that way. Who would have thought
that testing would be so popular. Someone should write a book...

> Having passed through both, I'm not sure that outside-in is quite the same as top-down. Abelson and Sussman talk in terms of "programming by wishful thinking", so there is a respectable lisp history for some of the concepts.
>
> My brief experience of working with Bruce (mostly consisting of not getting my environment to run), was that test-first is still useful for forcing out concepts. Every time I've done it, including with bash, I've found it's helped to break things into more smaller pieces.

I think this goes back to some of what I was talking about with you
around paying attention to the data structure first and then
pipelining that through a number of transformational functions rather
than thinking about the interface first and then implementing in from
there.

I *really* enjoyed working on that code with you, but I'm not happy
with how the code turned out in the end. I am completely willing to
believe that this is down to my lack of ability rather than any
failings on an outside in approach. I felt that the code we came up
with by working in from the interface was more coupled than I would
have liked and it has made it more difficult to add or remove
functions to change the data structures. Again, I'd like to stress
that I think this is all due to my head being filled with rocks and
custard and might have nothing to do with outside in testing. I did
love the way you were always trying to reduce redundancy in the tests
and still ask myself WWSFD when testing. :-D

What I did talk about yesterday was how I tend to iterate from writing
something with a let on the repl, looking at those results, rewriting
it as a defn with a test (if I feel it is complicated enough or a
large enough chunk) that I am now doing with midje. This gets in a
rewrite of the function (which goes to Malcolm comment on version n+1
being better than version n).

It isn't test *driven* development, but it is repl driven development
assisted by tests (RDDABT), which feels a bit like spike and
stabilise.

Is it good, bad or indifferent? I don't really know yet. It does let
me implement the bits that I do understand, test the bits I find
complicated or write tests for bits where I'm unsure about what the
requirement is and I want to capture my thinking.

Robert suggested that the reason I'm pursuing this is that I'm
thinking through the requirements as I'm writing the code as I don't
have a customer or product owner to tell me what things should be
doing. I think there may be some truth to this.

However, I have often found that domain experts often aren't as expert
as they sometimes appear and occasionally give answers because you've
asked them a question, rather than because it is right (if that makes
sense). Having an expert say "I don't know" is more than some are
willing to admit. Because of this I've found that when I can it is
handy to do something very quick around a corner case and then present
examples for verification, but this could be because I've mostly done
ETL and it is already a pretty remote thing for most business experts
to think about.

cheers,
Bruce

[Jennifer Smith]

 

It isn't test *driven* development, but it is repl driven development
assisted by tests (RDDABT), which feels a bit like spike and
stabilise.

I am happy with what you are saying *being* test-driven development. Usually, when we test-drive it we tend to have a picture in our heads of how it's supposed to go, even if it is the tests we are writing first. You are just replacing the picture in your head with noodling in the repl.

I think that repl-copy-paste-test-rewrite-moretests-rewrite-driven-development is kind of awesome. 

In the end TDD is just an acronym - if your workflow proves out and all the reasons why we use tests to shape our development are met then it's no bad thing. 

Re inside out and outside in and left to right and bottom to top, that's still an interesting debate. Given as everyone has a different interpretation, some demonstrations of what people mean could be useful.

Is it good, bad or indifferent? I don't really know yet. It does let
me implement the bits that I do understand, test the bits I find
complicated or write tests for bits where I'm unsure about what the
requirement is and I want to capture my thinking.

Robert suggested that the reason I'm pursuing this is that I'm
thinking through the requirements as I'm writing the code as I don't
have a customer or product owner to tell me what things should be
doing. I think there may be some truth to this.

However, I have often found that domain experts often aren't as expert
as they sometimes appear and occasionally give answers because you've
asked them a question, rather than because it is right (if that makes
sense). Having an expert say "I don't know" is more than some are
willing to admit. Because of this I've found that when I can it is
handy to do something very quick around a corner case and then present
examples for verification, but this could be because I've mostly done
ETL and it is already a pretty remote thing for most business experts
to think about.

cheers,
Bruce

[Bruce Durling]

Jen,

On Tue, Apr 9, 2013 at 4:24 PM, Jennifer Smith
<jennifer....@gmail.com> wrote:
>> It isn't test *driven* development, but it is repl driven development
>> assisted by tests (RDDABT), which feels a bit like spike and
>> stabilise.
>
>
> I am happy with what you are saying *being* test-driven development.
> Usually, when we test-drive it we tend to have a picture in our heads of how
> it's supposed to go, even if it is the tests we are writing first. You are
> just replacing the picture in your head with noodling in the repl.
>
> I think that
> repl-copy-paste-test-rewrite-moretests-rewrite-driven-development is kind of
> awesome.
>
> In the end TDD is just an acronym - if your workflow proves out and all the
> reasons why we use tests to shape our development are met then it's no bad
> thing.

I think the middle D of TDD (the Driven bit) is the important bit. I
don't feel like I'm *driven* by tests when I do repl noodling and I
usually write the function first and then write the test based on what
was in the repl (which is also often copy and paste). I think I need
to add some test.generative to this as well, as my testing usually
only does happy path stuff at the moment unless I'm feeling very
disciplined (which, in truth, I never do - have any of you known me to
be disciplined on anything?)

I think the big difference here is having such a good repl. Having a
repl affords noodling in way that I was never able to do in Java,
certainly, and never found worked as well even in things with a good
shell like python. I'm not sure what it is about lisps that drive me
to a repl.

> Re inside out and outside in and left to right and bottom to top, that's
> still an interesting debate. Given as everyone has a different
> interpretation, some demonstrations of what people mean could be useful.

For me inside out is when you start with the interface and work your
way down to where you have data or other systems. Bottom up is when
you start with the layer above the data and work your way up to the
interface from there. I tend to like to go from the data or service up
in strips (data -> interface/ui for one feature, rinse and repeat).

cheers,
Bruce

[Bruce Durling]

Jen,

On Tue, Apr 9, 2013 at 4:24 PM, Jennifer Smith
<jennifer....@gmail.com> wrote:
> Re inside out and outside in and left to right and bottom to top, that's
> still an interesting debate. Given as everyone has a different
> interpretation, some demonstrations of what people mean could be useful.

This from Mr Marick seems appropos:

from: https://github.com/marick/Midje/wiki/A-tutorial-introduction#top-down-development-and-the-logical-structure-of-programs

<quote>
Top-down development and the logical structure of programs

Test-driven design can be done either bottom up (in a way reminiscent
of traditional Lisp repl-driven development) or top down (as described
inGrowing Object-Oriented Software, Guided by Tests, one of the strong
early inspirations for Midje). Since there are various paths through
this user documentation, I'll point you to this introduction if you're
interested in learning about how Midje views the top-down approach in
a functional language.
</quote>

and links from there to more discussion.

cheers,
Bruce

[Chris Jenkins]

<de-lurk/>

custard and might have nothing to do with outside in testing. I did
love the way you were always trying to reduce redundancy in the tests
and still ask myself WWSFD when testing. :-D

OK, I have to ask: What does WWSFD mean?

I'm gutted to have missed this this Dojo (the current nature of my job doesn't allow me to make it up to London on a school night) but reading this email thread has been very interesting.

Personally, I find that hacking Clojure tends to be very REPL-based for me (compared to Java where I write an awful lot of unit tests and then spend most of my time in the debugger stepping through them). I write far fewer unit tests when hacking Clojure compared to, say, Java. I feel kind of bad about that but I'm not sure whether this is a result of the REPL-based development or a result of the Clojure code that I write being more hobby projects and the Java code being stuff that needs to be supported for years. Certainly, I'm less likely to write tests up front in Clojure; I'm more likely to dive straight in and start playing around with stuff in the REPL.

Cheers,

Chris

[Simon Katz]

Steve Freeman wrote on 2013-04-09 14:40:
> Having passed through both, I'm not sure that outside-in is quite the same as top-down. Abelson and Sussman talk in terms of "programming by wishful thinking", so there is a respectable lisp history for some of the concepts.

I'd be interested to hear more. Is the difference that with outside-in you write tests that specify the expected behaviour of the lower-level objects/functions (using mock objects or mock functions), and that with top-down you just keep on implementing lower and lower level things until you are done, and hope that everything ends up working? If so, I'd say outside-in is a kind of top-down.

Simon

[Bruce Durling]

Chris

On Tue, Apr 9, 2013 at 5:49 PM, Chris Jenkins <cdpje...@gmail.com> wrote:
> OK, I have to ask: What does WWSFD mean?

(def WWSFD "What would Steve Freeman do")

cheers,
Bruce

[Steve Freeman]

Sorry not for me. Look what happened to the last person they used that phrase with...

S

[Steve Freeman]

To me, it's similar but with a different emphasis.

To me, Top-Down implies going progressively from domain to hardware, whereas Outside-In takes you to wherever you need to go to implement the next slice of functionality. I find that Outside-In is a better match for a "soup of collaborating objects" approach. It helps me find coherent areas of code *with a clearly specified context*, whereas Top-Down is more about breaking up functionality into coherent chunks.

Hmmm, a bit vague.

S

[Steve Freeman]

(sitting next to Marick at ACCU...)

further, perhaps REPL-based development isn't completely bottom-up.

An extremist bottom-up position might be to write everything building up from primitives, hoping that it all hangs together at the top level.

I suspect that REPL development is more on the lines of "Hmm, I need a foo". Then poke around in the REPL to sort out what it should look like, and then code it up. Which makes it a little bit top-down, with the top-down being in your head.

Does that feel right?

S.

On 9 Apr 2013, at 17:49, Chris Jenkins wrote:
> Personally, I find that hacking Clojure tends to be very REPL-based for me
> (compared to Java where I write an awful lot of unit tests and then spend
> most of my time in the debugger stepping through them).

Spending lots of time in the debugger with unit tests would make me nervous. Or are you following a different process?

[Daniel Barlow]

On 10 April 2013 09:04, Steve Freeman <st...@m3p.co.uk> wrote:

To me, it's similar but with a different emphasis.

To me, Top-Down implies going progressively from domain to hardware, whereas Outside-In takes you to wherever you need to go to implement the next slice of functionality.

I hadn't thought of it in those terms, but i really like that distinction.  "Top Down" traditionally gets you an architecture based on organisational lines - the Customer Module, the Marketing Module, the Reporting Module, the Management Module, the Finance Module, etc etc, then you do a bunch of further requirements analysis on each of those, which means that everyone with a special interest sticks their oar in and your scope doesn't just creep it balloons.  "Outside In" says "Bob needs to know what the relationship between widgets sold and days of the week is, work with whatever bits of code you need to make that happen".

TDD and/or REPL-driven programming are what you use to get loosely coupled (or better, uncoupled) objects at the micro level, "Outside In"/ATDD/BDD is what you use to get code that's going to solve an actual need for someone in the first place.  "Top Down" in its traditional sense is not guaranteed to do either.
 
Sorry, I know you know this, you wrote the book.  I really like that you subtitled it  "Guided by Tests", not "Driven by Tests"

-dan

--
d...@telent.net
http://ww.telent.net

[Bruce Durling]

Steve,

Capt Picard? He seems to have done pretty well. When I don't think about what you might do, Steve I always ask my self WWCPD.

cheers,

Bruce

[Steve Freeman]

I believe the original version is "what would jesus do"

S

On 10 Apr 2013, at 09:54, Bruce Durling wrote:
> Capt Picard? He seems to have done pretty well. When I don't think about
> what you might do, Steve I always ask my self WWCPD.
>

[Simon Katz]

This is a really interesting discussion; I wish I'd made it to the dojo.

I'm not really sure which message in this thread to reply to for this, but Steve mentions REPL development below, so it's probably as good as any other.

I think it's important to distinguish between two meanings of "REPL".  One is a window that you type forms into to have them immediately evaluated.  The other is the process that sits behind it and which you can interact with from other places (editor windows, debuggers, inspectors, ...).

I find using a REPL window most useful to explore what the language and libraries do.  For example, if I don't remember whether (- x y) means "x minus y" or "y minus x", I can type (- 10 5) into a REPL window and see what I get back.  For non-trivial things it's really useful to be able to explore in this way.

When I hear the phrase REPL-based development, I think in terms of building up a program bit by bit in editor windows, repeatedly sending new forms (function definitions, data definitions, test definitions, ...) and modified forms to the REPL process.  Oh, and maybe sometimes saving those editor windows to files.  Every now and then it's important re-start the REPL process and re-load everything from your source files, otherwise you get caught by definitions not making it to your source files or the order of evaluation of definitions breaking things.

When I first heard the phrase REPL-driven development, I didn't really think that it might be something other than REPL-based development, but some people here seem to be talking more about doing real development, rather than just exploring, in a REPL window.  (Perhaps it makes sense to think in terms of using the REPL for mini-spikes?)

For me, the "REPL" part is independent of bottom-up, top-down, inside-out, with or without TDD.  The distinguishing thing is how you interact with your code, not what order things happen in.

Simon

[Frank Shearar]

On 10 April 2013 09:24, Steve Freeman <st...@m3p.co.uk> wrote:
> (sitting next to Marick at ACCU...)
>
> further, perhaps REPL-based development isn't completely bottom-up.
>
> An extremist bottom-up position might be to write everything building up from primitives, hoping that it all hangs together at the top level.
>
> I suspect that REPL development is more on the lines of "Hmm, I need a foo". Then poke around in the REPL to sort out what it should look like, and then code it up. Which makes it a little bit top-down, with the top-down being in your head.
>
> Does that feel right?
>
> S.
>
> On 9 Apr 2013, at 17:49, Chris Jenkins wrote:
>> Personally, I find that hacking Clojure tends to be very REPL-based for me
>> (compared to Java where I write an awful lot of unit tests and then spend
>> most of my time in the debugger stepping through them).
>
> Spending lots of time in the debugger with unit tests would make me nervous. Or are you following a different process?

I think it heavily depends on your language and your tools. In
Smalltalk it's _usual_ to spend a large amount of your time in the
debugger with unit tests. It's a highly productive way to develop, in
Smalltalk at least: a good debugger that can roll back and forth on
the stack arbitrarily, fix-and-continue debugging and a dynamic
environment/language means that you can literally write your test
case, watch it fail, and implement the missing functionality entirely
in the debugger.

frank

>> I write far fewer unit tests when hacking Clojure compared to, say, Java. I feel kind of bad
>> about that but I'm not sure whether this is a result of the REPL-based
>> development or a result of the Clojure code that I write being more hobby
>> projects and the Java code being stuff that needs to be supported for
>> years. Certainly, I'm less likely to write tests up front in Clojure; I'm
>> more likely to dive straight in and start playing around with stuff in the
>> REPL.
>

[Steve Freeman]

As a wrote to Bruce offline, I'm certainly feeling my way here and haven't done enough production clojure to feel authoritative. All I can say is that it took quite some time for my crowd to really figure out how to TDD well, and that applying it in new situations often produces interesting results.

One of the big lessons from TDD in the large is that working with examples flushes out all sorts of detail that people forget. If you're in a situation where you can just lean over to users and show them something, that might be less necessary.

There's another bit about regression prevention as you scale up. Given that no-one in history has written a comprehensive test suite after the fact (except perhaps in safety critical), it's just easier to write the tests as you go along. Of course, maybe clojure makes all programs so compact that they can just be read in a page...

S

On 9 Apr 2013, at 16:06, Bruce Durling wrote:
> I think this goes back to some of what I was talking about with you
> around paying attention to the data structure first and then
> pipelining that through a number of transformational functions rather
> than thinking about the interface first and then implementing in from
> there.

[Steve Freeman]

Ah, you didn't say Smalltalk. That makes sense.

It's interesting to remember that TDD has its origins in a REPL environment of the kind that Simon mentioned.

S.

[Chris Jenkins]

I think it heavily depends on your language and your tools. In
Smalltalk it's _usual_ to spend a large amount of your time in the
debugger with unit tests. It's a highly productive way to develop, in
Smalltalk at least: a good debugger that can roll back and forth on
the stack arbitrarily, fix-and-continue debugging and a dynamic
environment/language means that you can literally write your test
case, watch it fail, and implement the missing functionality entirely
in the debugger.

That's actually exactly how I work with Java in Eclipse (single step through until something goes wrong, then fix the code and let the Eclipse debugger restart the method) but the Smalltalk tools that you describe sound a bit better :-)

The thing is, Java kind of makes it necessary to work like that because of the large amount of icky global state that needs to be set up before a particular method can run. In Clojure, I really like the way that the preconditions of a (pure) function are contained within the arguments to that function which makes it a lot easier to just call it from the REPL.

Cheers,

Chris

[Steve Freeman]

On 10 Apr 2013, at 11:24, Chris Jenkins wrote:
> That's actually exactly how I work with Java in Eclipse (single step
> through until something goes wrong, then fix the code and let the Eclipse
> debugger restart the method) but the Smalltalk tools that you describe
> sound a bit better :-)

when it comes to language wars, I really don't care because I'm not using Smalltalk any more...

> The thing is, Java kind of makes it necessary to work like that because of
> the large amount of icky global state that needs to be set up before a
> particular method can run. In Clojure, I really like the way that the
> preconditions of a (pure) function are contained within the arguments to
> that function which makes it a lot easier to just call it from the REPL.

That kind of structure is a design choice rather than a language requirement. Many of us have been writing "functional" Java for some years, and of course, clojure runs on the JVM

S

[Frank Shearar]

On 10 April 2013 11:27, Steve Freeman <st...@m3p.co.uk> wrote:
> On 10 Apr 2013, at 11:24, Chris Jenkins wrote:
>> That's actually exactly how I work with Java in Eclipse (single step
>> through until something goes wrong, then fix the code and let the Eclipse
>> debugger restart the method) but the Smalltalk tools that you describe
>> sound a bit better :-)
>
> when it comes to language wars, I really don't care because I'm not using Smalltalk any more...

I didn't mention Smalltalk to start a language war :) I just find it
interesting the way design decisions in the languages and tools - and
the availability of certain tools - makes certain things (like living
in the debugger) seem natural that to others would seem highly
_un_natural.

frank

[Julian Birch]

> Given that no-one in history has written a comprehensive test suite after the fact

I've come close.  I inherited a large, badly performing and fragile system with no tests.  Built an integration test harness and built a test every time something broke.  In fact, I'd say it was pretty much the only thing I could do with it.

About a year and 350 tests later, I was sufficiently confident I could actually respond to "I think there's something wrong with the system." with "Unlikely, but I'll investigate.".

Architecture was still a complete mess, though.

J

[Steve Freeman]

OK, almost no one...

S.