← Back to Upcase

Rejected? Weekly Iteration Episode


(Ben Orenstein) #1

Hi all,

Joe and I shot a Weekly Iteration episode the other day where we did some live-pairing.

3/4 of the way in, we hit an issue that tripped us up for while. My initial reaction on watching the episode was that watching us struggle for 5-10 minutes wasn’t great television, and we should re-shoot, but I thought I’d show it to you all to see if you agree.

If you’re game, would you please watch the episode and answer the following:

  • Was it beneficial to you in any way to watch us struggle through something, or would you have preferred to watch the same screencast but without the 6-ish minutes of being stuck?
  • Did the 41 minutes feel too long?
  • Do you miss seeing our faces, or is just the screen interesting enough?

Here’s the episode

Thanks!

-Ben

P.S. We actually recorded 3 episodes that day, so the next episode will still be released on schedule.


(David Barkley) #2

I enjoyed the screencast and found that the issue you guys had just added a bit of drama, it was definitely the part that held my attention the most. Sometimes screencasts can seem over rehearsed and you can sense in the presenters voice/attitude that they know exactly whats going to happen next, like an english teacher who’s teaching Macbeth for the twentieth year in a row and is just going through the motions.

The length was fine and I don’t really know what seeing your faces would have added (in the nicest possible way).

Thanks for showing that even with the combined experienced you guys have that things still trip you up, It’s heartening to the less experienced of us.

David


(Luís Ferreira) #3

Hi Ben,

I really love these screencasts where you build something on an existent and working system, since it feel a lot more like what I do everyday and the problems that I face.

I do think it is good to watch you guys go through the issues on an uncut version, it makes it more humane and realistic.

41 minutes is a breeze when the content is interesting. Uncle Bob’s clean coders videos go for and hour and a half, so you’re good. :wink:

In general I would like to see your faces mostly when you’re explaining something or reviewing/concluding a topic. In this particular screencast, I think it would also be helpful to better understand who’s typing and when you swap.

Thanks for a nice screencast.

PS: Avdi Grimm has a very nice expression for when to move down from integration tests, he says that he does it when he’s feeling nervous and he feels nervous when he’s not getting constant feedback from the tests. So when the test error does not help you move forward, go down a level. I think this goes well with the way Joe talks about it. Does it make sense?

Here’s the link to a video of Avdi saying it himself: http://www.rubytapas.com/episodes/120-Outside-In


(Matthew Sumner) #4

So the problem you struggled with tickled my interest so I dove into the ActiveSupport::Duration code to find the reasoning. It turns out the duration object will only calculate once you call .ago or .since. The + and - operators add to the value and/or parts instance variable.

.ago and .since then take an optional parameter to calculate from a certain date. This means that 1.month will always be the number of days in the current month. This means that during January this return 45 days while december will return 44.

> (1.months + 14.days).parts
 => [[:months, 1], [:days, 14]] 
> Date.today - (1.months + 14.days).ago.to_date
 => 45 
> (Date.today - 1.month) - (1.months + 14.days).ago(Date.today - 1.month).to_date
 => 44 

You could use the following in your tests:

...
    subscription = Subscription.new(created_at: 14.days.since(Date.today.end_of_month))
...

Pretty smart!

Anyway, loved the episode, really gives a taste of pairing. I think the floundering is awesome and needs to stay in as it showed how to logically approach your tests failing your expectations. I did miss your faces though… there’s a lot of communication that feels lost by just seeing the screen, however, I can see keeping up with the weekly releases being tough and I’d rather these keep coming out then you to be overwhelmed with production/editing.

Also 41 minutes didn’t feel too long. It seems like you wouldn’t want to make a habit of it though for your own sanity :grin:

Keep it up!


(Duncan Parkinson) #5

I thought it was a good episode! I think that seeing people dealing with problems as they come up like that can give good insights into helpful processes for getting unstuck. It makes it more like PeepCode Play-By-Play episodes than scripted screencasts on a defined topic, but both of those styles have their place and offer different insights.

I’d certainly be happy to see more episodes in that style, although I did miss the conversation shots a bit when it was only focusing on the screen.

Incidentally, what was it that caused the warning about a non-existent method being stubbed? Is that part of Mocha or is it something else?

Thanks,
Duncan


(Ben Orenstein) #6

Yes, Mocha has a setting that will warn you if you a stub a method that doesn’t actually exist. We like to keep it enabled–it can help you detect when you’ve changed an object’s interface but forgotten to update your stubs.


(Noah Hendrix) #7

So, a bit random, but the Timecop error you ran into is probably a bug in the pg gem. I was recently reading this article that mentioned all dates with a year < 0 must include “BC”. I imagine that the logic is <=, not just <.


(Brian) #8

I thought this episode was great. Watching the two of you struggle through the issue was very interesting, I prefer the real experience to a scripted / rehearsed one. The length was just fine for me, I would have liked to see you finish.

Thanks again for another great episode!