Hi I hope this is not OT. I''m training my replacement at work to do BDD Rails development. He''s done a CS/maths degree but has no professional programming experience, so he''s never NOT done a project without BDD. In a way I am jealous of his unspoilt situation :) I''ve gone about things this way: * first teach him some Ruby (he did mainly Java at uni) * then let him write a small program (to a rough description I came up with) in Ruby however he wants * then teach him how to do BDD-driven OO * then let him re-write the sample app in a BDD way. The app loads a YAML file that lists some URLs, fetches the pages off the interweb, extracts some data from the body of the spec, and outputs it to XML. He''s picking stuff up quick - he wrote it in about 1 1/2 days despite only learning Ruby last week. I''ve gone through a really simple BDD example with him that is quite similar to part of the bigger app - he seems to follow the syntax of RSpec and flexmock, understands the concepts of full and partial mocks, etc. But I''ve left him to rewrite his app along the same lines, and it''s like there is a void. Where before he just kept working at little bits until the output built up, now he''s got the ability to isolate simple bits of code and develop/test them (eg formatting a <page> tag from a URL), he''s taking longer. He seems to be struggling to pick isolated pieces of functionality out of the bigger problem. One thing I have done for him is write a functional test - one that runs the whole app "WebParse.run(infile, outfile)" black-box style, and compares the output in "outfile" to the output of his existing app (which we''ve decided between us is correct and suitable as a reference). I''m not sure if this has helped or confused the issue. Clearly there is something important I am not explaining, something I take for granted. Does anyone have any ideas what? I was hoping someone else here has been through the experience of teaching BDD (RSpec or otherwise) from scratch and may be able to point me in the right direction. Thanks for any advice Ashley PS I haven''t told him to subscribe to this list yet, so I''m safe to talk about him for a bit :o) -- blog @ http://aviewfromafar.net/ linked-in @ http://www.linkedin.com/in/ashleymoran currently @ work
On 10/17/07, Ashley Moran <work at ashleymoran.me.uk> wrote:> Hi > > I hope this is not OT. I''m training my replacement at work to do BDD > Rails development. He''s done a CS/maths degree but has no > professional programming experience, so he''s never NOT done a project > without BDD. In a way I am jealous of his unspoilt situation :) > > I''ve gone about things this way: > * first teach him some Ruby (he did mainly Java at uni) > * then let him write a small program (to a rough description I > came up with) in Ruby however he wants > * then teach him how to do BDD-driven OO > * then let him re-write the sample app in a BDD way. > > The app loads a YAML file that lists some URLs, fetches the pages off > the interweb, extracts some data from the body of the spec, and > outputs it to XML. He''s picking stuff up quick - he wrote it in > about 1 1/2 days despite only learning Ruby last week. > > I''ve gone through a really simple BDD example with him that is quite > similar to part of the bigger app - he seems to follow the syntax of > RSpec and flexmock, understands the concepts of full and partial > mocks, etc. But I''ve left him to rewrite his app along the same > lines, and it''s like there is a void. Where before he just kept > working at little bits until the output built up, now he''s got the > ability to isolate simple bits of code and develop/test them (eg > formatting a <page> tag from a URL), he''s taking longer. He seems to > be struggling to pick isolated pieces of functionality out of the > bigger problem. > > One thing I have done for him is write a functional test - one that > runs the whole app "WebParse.run(infile, outfile)" black-box style, > and compares the output in "outfile" to the output of his existing > app (which we''ve decided between us is correct and suitable as a > reference). I''m not sure if this has helped or confused the issue. > > Clearly there is something important I am not explaining, something I > take for granted. Does anyone have any ideas what? I was hoping > someone else here has been through the experience of teaching BDD > (RSpec or otherwise) from scratch and may be able to point me in the > right direction. > > Thanks for any advice > Ashley > > > PS I haven''t told him to subscribe to this list yet, so I''m safe to > talk about him for a bit :o) > > > -- > > blog @ http://aviewfromafar.net/ > linked-in @ http://www.linkedin.com/in/ashleymoran > currently @ work > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >Hey Ashley, First of all, fun situation to be in! I like installing BDD into impressionable minds - I create one more person who thinks I''m brilliant. I would say the best way to do this is to pair. Start off with a toy app, introducing him to the syntax and basics of RSpec. I would definitely start off with user stories, and then get into the nuts-and-bolts object spec''ing. Perhaps you could write one full scenario in story runner (as I''m sure that''s completely foreign to him), and then you two can bounce back and forth while implementing it. You start off doing 60% of the coding letting him take 40%. Gradually let him take over more as he gets the hang of it, then you can lean back and sip pina coladas, swacking him with a ruler whenever he missteps. After you''ve done a little toy app, I would go to a part of your real app. If you''ve got any areas that have weak/no coverage, write some specs for it together. You can help show him how to retrofit specs onto existing code, and you strengthen your coverage to boot! I think you''ll BOTH learn more and be far more efficient if you pair together rather than giving him a bit of theory/tips & tricks and then leaving him to his own devices. Pat
On 10/17/07, Pat Maddox <pergesu at gmail.com> wrote:> I think you''ll BOTH learn more and be far more efficient if you pair > together rather than giving him a bit of theory/tips & tricks and then > leaving him to his own devices.Hear, hear!!!!!!!
On 10/17/07, David Chelimsky <dchelimsky at gmail.com> wrote:> On 10/17/07, Pat Maddox <pergesu at gmail.com> wrote: > > I think you''ll BOTH learn more and be far more efficient if you pair > > together rather than giving him a bit of theory/tips & tricks and then > > leaving him to his own devices. > > Hear, hear!!!!!!! > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >I have to agree w/Pat here, wrt to pair programming. (And let me say that I am _so_ jealous!) If it were up to me, I would start with BDD, Probably, immediately right after hello_world.rb. Even before they learn any Ruby syntax at all. Your toy app sounds more like a real application to me. It has actual user stories, confirmable results, etc. Why not break the usual cycle of code a little, test, code a bit more, test, repeat, from the start? RSpec is a DSL, like Rails is a DSL. And you don''t need to know much ruby to get started in Rails. I say that holds true in RSpec as well. The only qualms I can see is the concept of Mocks. But you could introduce that in something he is familiar with like Java. I only wish my mentor had forced me to learn test first, back in the day. But that was before all you geniuses where on the scene to set us straight! Ed -- Ed Howland http://greenprogrammer.blogspot.com "The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, confidential and/or legally privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers."
On Oct 17, 2007, at 6:14 pm, Pat Maddox wrote:> First of all, fun situation to be in! I like installing BDD into > impressionable minds - I create one more person who thinks I''m > brilliant.Lol - true, this is one of the better problems I''ve had to deal with.> > I would say the best way to do this is to pair. Start off with a toy > app, introducing him to the syntax and basics of RSpec. I would > definitely start off with user stories, and then get into the > nuts-and-bolts object spec''ing. Perhaps you could write one full > scenario in story runner (as I''m sure that''s completely foreign to > him),It''s also foreign to me! [hangs head in shame] I''ve been too busy to keep up with the latest RSpec gadgets. I just googled and was about to ask if you had seen this link: <http://evang.eli.st/blog/ 2007/9/1/user-stories-with-rspec-s-story-runner> but on closer inspection I suspect the answer may be yes :) I was actually going to ask this as a separate post some time. I''m pretty good (I like to think) with unit specs and breaking behaviour down, but have not looked much at higher-level user-story based testing. (And broader agile concepts generally) What''s the best book on the subject for someone in my situation? I have not tried RSpec trunk - I''ll fetch it out tonight and see if I can get some stories up and running, and teach him everything I know tomorrow :) I''m not averse to learning stuff as I teach it - I taught him FlexMock before I''d used it myself. Gernally though, it''s nice to have an idea what you''re talking about.> and then you two can bounce back and forth while implementing > it. You start off doing 60% of the coding letting him take 40%. > Gradually let him take over more as he gets the hang of it, then you > can lean back and sip pina coladas, swacking him with a ruler whenever > he missteps.This may be the key step I''m missing. (Gradually letting him take over, not whacking him with a ruler.) I think I might be expecting too much too soon. Unfortunately I still keep getting bombarded with spontaneous "by the way we need this server farm re-installing tomorrow"-type requests so I needed something I could leave him to it.> After you''ve done a little toy app, I would go to a part of your real > app. If you''ve got any areas that have weak/no coverage, write some > specs for it together. You can help show him how to retrofit specs > onto existing code, and you strengthen your coverage to boot!Good idea, I have a couple of pretty cleanly-separated web service interfaces written by his predecessor. This other guy destroyed everything he touched, so there are plenty of things I can justify re- writing.> I think you''ll BOTH learn more and be far more efficient if you pair > together rather than giving him a bit of theory/tips & tricks and then > leaving him to his own devices.I suspect you are entirely right. Unfortunately, our corporate culture has historically been "why are you spending so much time learning when you could be coding", and it can get politically difficult to be seen to be doing nothing at times. My last question then is... since he has not done Rails before, would it be better to jump straight onto the main project he will be working on, or a dummy project first? Actually we have something he could possibly help out with - I found out the other day that the setup system for one of our web services involves posting potential customers paper forms and waiting for them to fax the completed ones over*. So perhaps I can twist my boss''s arm that we should do a more Web 0.9 solution to this as a combined learn/code effort. That would make the final sprint like this: * take over some more of the coding on the demo app he is rewriting, but let him grab the keyboard as soon as he sees what needs doing (I wanted it to be all his work, but I''m sure if it''s mostly his work that may be as good) * build a really basic monkey-see, monkey-do Rails app so he''s got an idea of MVC (like I say, it''s ALL new) * spec some behaviour for the online setup app (that I think I will christen Postfax, in tribute) possibly in the Story Runner that I learnt an hour from now * implement some really basic behaviour myself, get him to add some more basic behaviour * try some more advanced stuff and hopefully let him take over slowly * get the pina colada and ruler ready Sounds like a plan? Cheers! Ashley *No, I am not making this up. I couldn''t believe it either. -- blog @ http://aviewfromafar.net/ linked-in @ http://www.linkedin.com/in/ashleymoran currently @ home
On 10/17/07, Ashley Moran <work at ashleymoran.me.uk> wrote:> I was actually going to ask this as a separate post some time. I''m > pretty good (I like to think) with unit specs and breaking behaviour > down, but have not looked much at higher-level user-story based > testing. (And broader agile concepts generally) What''s the best > book on the subject for someone in my situation?Behaviour Driven Development in Ruby with RSpec by David Chelimsky and Aslak Hellesoy Sadly, not yet in print, but coming soon from the Pragmatic Bookshelf. In the mean time, you might want to give this one a peek: http://www.amazon.com/Software-Development-Principles-Patterns-Practices/dp/0135974445
On 18/10/2007, at 8:54 AM, David Chelimsky wrote:> Behaviour Driven Development in Ruby with RSpec > by David Chelimsky and Aslak Hellesoy > > Sadly, not yet in print, but coming soon from the Pragmatic Bookshelf. >Will it be released in PDF beta any sooner? Cheers Shane
On 10/17/07, Shane Mingins <smingins at elctech.com> wrote:> On 18/10/2007, at 8:54 AM, David Chelimsky wrote: > > > Behaviour Driven Development in Ruby with RSpec > > by David Chelimsky and Aslak Hellesoy > > > > Sadly, not yet in print, but coming soon from the Pragmatic Bookshelf. > > > > Will it be released in PDF beta any sooner?Definitely. We just don''t know when yet. Believe me, as soon as we have that nailed down this list will be among the first to know :) Cheers, David
On Oct 17, 2007, at 8:54 pm, David Chelimsky wrote:> Behaviour Driven Development in Ruby with RSpec > by David Chelimsky and Aslak Hellesoy > > Sadly, not yet in print, but coming soon from the Pragmatic Bookshelf.I forgot about that one :) Can''t we pre-order the beta yet?> In the mean time, you might want to give this one a peek: > > http://www.amazon.com/Software-Development-Principles-Patterns- > Practices/dp/0135974445You recommended that one once before, this is my cue to actually buy a copy -- blog @ http://aviewfromafar.net/ linked-in @ http://www.linkedin.com/in/ashleymoran currently @ home
On Oct 17, 2007, at 6:52 pm, Ed Howland wrote:> If it were up to me, I would start with BDD, Probably, immediately > right after hello_world.rb. Even before they learn any Ruby syntax at > all. Your toy app sounds more like a real application to me. It has > actual user stories, confirmable results, etc. > > Why not break the usual cycle of code a little, test, code a bit more, > test, repeat, from the start? RSpec is a DSL, like Rails is a DSL. And > you don''t need to know much ruby to get started in Rails. I say that > holds true in RSpec as well. The only qualms I can see is the concept > of Mocks. But you could introduce that in something he is familiar > with like Java.That''s an interesting approach. My only hesitation is that if he''s seen to be writing Rails apps it might be interpreted by management that he''s learnt everything there is to know about behaviour-driven object-oriented MVC web programming, and I wouldn''t get chance to show him the good stuff before I leave. I think it''s good to see something working, but I wanted to avoid instilling Rails = Ruby in him. That''s why I started writing specs for trivial things, then simple things like loading a YAML file. Interestingly, mocks were a tough one. It took a while to explain the difference between full and partial mocks, and the difference between mocking instances and stubbing on classes. I don''t think it was the concept of imaginary objects, more the idea of setting expectations on them and describing interactions, as opposed to seeing whether the final output of the program is right.> I only wish my mentor had forced me to learn test first, back in the > day. But that was before all you geniuses where on the scene to set us > straight!I feel spoilt too, I was lucky to stumble on RSpec (and more importantly, rspec-users) so soon after I started learning unit testing. And Jim is a lucky guy too, having someone like me around to tirelessly relay the replies of experts to him. Ashley -- blog @ http://aviewfromafar.net/ linked-in @ http://www.linkedin.com/in/ashleymoran currently @ home
On 10/17/07, Ashley Moran <work at ashleymoran.me.uk> wrote:> > I only wish my mentor had forced me to learn test first, back in the > > day. But that was before all you geniuses where on the scene to set us > > straight! > > I feel spoilt too, I was lucky to stumble on RSpec (and more > importantly, rspec-users) so soon after I started learning unit > testing. And Jim is a lucky guy too, having someone like me around > to tirelessly relay the replies of experts to him. >I agree, I have learned tons from this group, too. I missed out on Rails Edge this year, but some of our St Louis Ruby guys got meet David. I''d like to thank all of them for their hard work on RSpec. Ed - Ed Howland http://greenprogrammer.blogspot.com "The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, confidential and/or legally privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers."
On 17 Oct 2007, at 20:54, David Chelimsky wrote:> Behaviour Driven Development in Ruby with RSpec > by David Chelimsky and Aslak Hellesoy > > Sadly, not yet in print, but coming soon from the Pragmatic Bookshelf. > > In the mean time, you might want to give this one a peek:Hi David, I heard that this book was coming out, have you got a rough idea when it might either go into print or into a beta book? There''s no mention of it on the Pragmatic Programmers site yet. Cheers, Alastair ----- Alastair Moore Freelance web design, development and consultancy t. 07983 983945 e. alastair at kozmo.co.uk w. http://www.kozmo.co.uk skype. alastair_kozmo
On 17 Oct 2007, at 21:05, David Chelimsky wrote:> Definitely. We just don''t know when yet. Believe me, as soon as we > have that nailed down this list will be among the first to know :) > > Cheers, > DavidOh, you''ve already answered my question :) ----- Alastair Moore Freelance web design, development and consultancy t. 07983 983945 e. alastair at kozmo.co.uk w. http://www.kozmo.co.uk skype. alastair_kozmo
On 17 Oct 2007, at 17:27, Ashley Moran wrote:> Hi > > I hope this is not OT. I''m training my replacement at work to do BDD > Rails development. He''s done a CS/maths degree but has no > professional programming experience, so he''s never NOT done a project > without BDD. In a way I am jealous of his unspoilt situation :)Oh, incidently, I found a couple of useful links: http://video.google.com/videoplay?docid=8135690990081075324 http://www.oreilly.com/pub/a/ruby/2007/08/09/behavior-driven- development-using-ruby-part-1.html ----- Alastair Moore Freelance web design, development and consultancy t. 07983 983945 e. alastair at kozmo.co.uk w. http://www.kozmo.co.uk skype. alastair_kozmo
On Oct 18, 2007, at 11:42 am, Alastair Moore wrote:> Oh, incidently, I found a couple of useful links: > > http://video.google.com/videoplay?docid=8135690990081075324Watched that ages ago - it''s good but looks really old school compared to the new syntax!> http://www.oreilly.com/pub/a/ruby/2007/08/09/behavior-driven- > development-using-ruby-part-1.htmlNot seen that, thanks for the heads up Ashley -- blog @ http://aviewfromafar.net/ linked-in @ http://www.linkedin.com/in/ashleymoran currently @ home
On Oct 17, 2007, at 6:17 pm, David Chelimsky wrote:> On 10/17/07, Pat Maddox <pergesu at gmail.com> wrote: >> I think you''ll BOTH learn more and be far more efficient if you pair >> together rather than giving him a bit of theory/tips & tricks and >> then >> leaving him to his own devices. > > Hear, hear!!!!!!!Yep you were both right! Today I sat down with Jim, took over typing for a while and let him jump in as soon as he looked like he knew what was going on. Was about 10x as productive as before, and made me realise (a) you need a lot of experience to catch edge cases and spec obscure Ruby code (unfair to dump on someone just learning), and, more importantly (b) BDD is much more of an art than a science. I learnt something priceless too: I found I was trying to solve problems in my head in an attempt to avoid writing bad code, and tried to explain things on paper when really, I didn''t know what the solution was anyway. BAD IDEA! Eventually I said to him - I''m going to pretend you''re not here and just work like I normally would. It worked, and now I know that the secret to BDD is KEEP BASHING THE KEYBOARD! It''s amazing how quickly you can make useful, elegant code out of complete garbage. I''ve had to apologise several times for the shocking stuff I was writing, tell him "don''t worry, I don''t care it''s ugly, we''ll see to that when it''s working". Ashley -- blog @ http://aviewfromafar.net/ linked-in @ http://www.linkedin.com/in/ashleymoran currently @ home -- blog @ http://aviewfromafar.net/ linked-in @ http://www.linkedin.com/in/ashleymoran currently @ home