subscribe

theBjornIdentity / Bjorn

There are no people in theBjornIdentity’s collective.

Huffduffed (123)

  1. Disciple-Making in the Local Church (Speaker Panel)

    —Huffduffed by theBjornIdentity

  2. Making Many: The Paster/Elder as Disciple-Maker

    —Huffduffed by theBjornIdentity

  3. Being One: The Pastor/Elder as Disciple

    —Huffduffed by theBjornIdentity

  4. Sermon: Church Discipline and Life (1 Cor. 5:9-13) — CanonWired

    Sermon: Church Discipline and Life (1 Cor. 5:9-13) Pastor Doug Wilson Christ Church – Moscow, ID Sermon #1787 – A.D. August 3, 2014 Text: (1 Cor. 5:9-13)             CLICK HERE for Youtube version For the sermon notes click HERE. Related Posts Sermon: Wheat and Darnel | Parables II (Douglas Wilson) Father Hunger: Discipline in a Cheerful Home Sermon: The Little One in our Midst (Mt 18: 1-20)

    http://www.canonwired.com/featured/1787/

    —Huffduffed by theBjornIdentity

  5. Debug 39: Nitin Ganatra episode I: System 7 to Carbon | iMore

    Debug is a casual, conversational interview show featuring the best developers in the business talking about the amazing apps they make and why and how they make them. In part 1 of the Nitin Ganatra trilogy, the former Director of iOS apps at Apple talks to Guy and Rene about his early career in Developer Technical Support (DTS), working on System 7 in the Copland era, and the advent of Carbon.

    Support Debug: Go to squarespace.com/debug and use offer code DEBUG to save 10% on your new website! Go to peek.usertesting.com and use express pass DEBUG to get your results back faster on a free 5-minute video of a real person using your site or app.

    Subscribe in iTunes

    Subscribe in RSS

    Download directly

    Follow on Twitter

    http://www.imore.com/debug-39-nitin-ganatra-episode-i-system-7-carbon

    —Huffduffed by theBjornIdentity

  6. Iterate 69: WWDC 2014 designer roundtable | iMore

    Iterate brings together the best designers and app producers in the business to talk user interface, human interaction, icon design, and user experience from concept to implementation. On this episode Ged Maheux of the Iconfactory, Jared Sinclair of Unread, and Dave Wiskus of Vesper join Marc, Seth, and Rene to talk about WWDC 2014, OS X Yosemite’s new design language, Extensibility’s remote views, and more!

    Subscribe in iTunes

    Subscribe in RSS

    Download directly

    Follow on Twitter

    http://m.imore.com/iterate-69-wwdc-2014-designer-roundtable

    —Huffduffed by theBjornIdentity

  7. Debug 38: WWDC 2014 developer roundtable | iMore

    Debug is a casual, conversational interview show featuring the best developers in the business about the amazing apps they make and why and how they make them. On this episode Matt Drance of Bookhouse Software, Ryan Nielsen of Tumult, Daniel Jalkut of Red Sweater, and Jason Snell of Macworld join Guy and Rene to talk about Apple’s WWDC 2014 keynote — the Swift programming language, Extensibility, Cloud Kit, Metal, and more.

    http://www.imore.com/debug-38-wwdc-2014-developer-roundtable

    —Huffduffed by theBjornIdentity

  8. Talk Show: WWDC

    —Huffduffed by theBjornIdentity

  9. Is TDD Dead, part 5

    Summary

    David starts by saying "to talk about

    trade-offs, you really have to understand the drawbacks, because

    if there are no drawbacks there are no trade-offs." He continued by saying that TDD doesn’t force you to do

    things, but it does nudge you in certain directions.

    The first issue he wanted to raise was over-testing. It’s often said you shouldn’t

    write a line of code without a failing test, at first this seems

    reasonable but it can lead to over-testing, such as where there

    are four lines of test code for every line of production code.

    This means that when you need to change behavior, you have more

    code to change .

    Kent has said ‘you aren’t paid to write tests,

    you just write enough to be confident’ - so he asked if Kent and

    I wrote tests

    before every line of production code?

    Kent replied "it depends, and that’s going to be the beginning

    to all of my answers to any question that’s

    interesting". With JUnit they were very strict about test-first and were very

    happy with how it turned out - so he doesn’t think you always get

    over-testing when you use TDD. Herb Derby came up with the notion of delta coverage - what

    coverage does this test provide that’s unique? Tests with zero

    delta coverage should be deleted unless they provide some kind

    of communication purpose. He said he’d often write a system-y test, write some code to

    implement it, refactor a bit, and end up throwing away the

    initial test. Many people freak out at throwing away tests, but

    you should if they don’t buy you anything. If the same thing is tested multiple ways, that’s coupling,

    and coupling costs.

    I said that I’m sure there is over-tested code,

    indeed if anyone does it would be ThoughtWorks since we have a

    strong testing culture. It’s hard to get the amount just

    right, sometimes you’ll overshoot and sometimes undershoot. I

    would expect to overshoot from time to time and it’s not

    something to worry about unless it’s too large. On the test-every-line-of-code point I

    ask the question: "if I screw up this line of code is a test

    going to fail?" I sometimes deliberately comment a line out

    or reverse a conditional and run the tests to ensure one

    fails. My other mental test (from Kent) is only test things that can

    possibly break. I assume libraries work (unless they are really wonky). I ask

    if I can mess up my use of the library and how critical are the

    consequences of the mistake.

    Kent declared that the ratio of lines of test code to lines of

    production code was a bogus metric. A formative experience for him was watching Christopher Glaeser

    write a compiler, he had 4 lines of test code for every line

    of compiler code - but this is because compilers have lots of

    coupling. A simpler system would have a much smaller

    ratio. David said that that to detect commenting out a line of code

    implies 100% test coverage. Thinking about what can break is

    worth exploring, Rails’s declarative statements don’t lead to

    enough breakage to be worth testing, so he’s comfortable with

    significantly less than 100% coverage.

    I replied that "you don’t have enough tests (or good enough

    tests) if you can’t confidently change the code,"

    and

    "the

    sign of too much is whenever you change the code you think you

    expend more effort changing the tests than changing the

    code." You want to be in the Goldilocks zone, but that comes

    with experience of knowing what mistakes you and your team tend to make and

    which ones don’t cause a problem. I said I like the "can I comment out a line of code" approach

    when I’m unsure of my ground, it’s a starting place but as I

    work more in an environment I can come up with better heuristics. David felt that this tuning is different between product teams that

    are stable rather than consulting teams that are handing the

    code over

    to an unknown team and thus need more tests. Kent said that it’s good to learn the discipline of

    test-first, it’s like a 4WD-low gear for tricky parts of

    development.

    David introduced the next issue: many people used to think

    that documentation was more important than code. Now he’s

    concerned that people think tests are more important than

    functional code. Connected with this is an under-emphasis on

    the refactor part of the TDD cycle. All this leads to

    insufficient energy to refactoring and keeping the code

    clear. Kent described that he just went through an episode where he

    threw away some production code, but keeping the

    tests and reimplementing it. He really likes that approach as

    the tests tell him if the new code is working. This leads to

    an interesting question: would you rather throw away the code

    and keep the tests or vice-versa? In different situations you’d

    answer that question differently.

    I said I’d found situations where reading the tests helped me

    understand what the code was doing. I didn’t think one was

    more important than the other - the whole point is the double

    check where there is an error if they get a mismatch. I agreed with David that I’d sometimes sensed teams making the

    bad move of putting

    more energy into the testing environment than in supporting

    the user, tests should be means to the end. I find I get a dopamine shot when I clarify code, but my biggest

    thrill is when I have to add a feature, think it will be tricky,

    but it turns out easy. That happens due to clean code, but

    there is a distance between cleaning the code and getting the

    dopamine shot. Kent showed a metaphor for this from Jeff Eastman, that is too

    tricky to describe in text. He got his rush from big design

    simplifications. He feels that it’s easy to explain the value of a new test

    working, but hard to state the value of cleaning the design.

    David said we often focus on things we can quantify, but you

    can’t reduce design quality to a number - so people prioritize things

    that are low on the list like test speed, coverage,

    and ratios. These things are honey traps, and we need to be

    aware of their siren calls. Cucumber really gets his goat - glorification of a testing

    environment rather than production code. Only useful in the

    largely imaginary sweetspot of writing tests with

    non-technical stakeholders. It used to be important to sell TDD, but now

    it’s conquered all, we need to explore its drawbacks. I disagreed that TDD was dominant, hearing many places where

    it’s yet to gain traction.

    http://martinfowler.com/articles/is-tdd-dead/

    —Huffduffed by theBjornIdentity

  10. Debug 37: Simmons, Wiskus, Gruber, and Vesper Sync | iMore

    Debug features the best developers in the business talking about the amazing apps they make and why and how they make them. On this episode Brent Simmons, Dave Wiskus, and John Gruber join Guy and Rene to talk about Vesper 2.0, architecting sync, the decision making process, design choices, and why Vesper for Mac comes next.

    http://www.imore.com/debug-37-simmons-wiskus-gruber-and-vesper-sync

    —Huffduffed by theBjornIdentity

Page 1 of 13Older