6 ms·

DHH Keynote from Confreaks

48 points by johnjlocke 12y ago

pmh 12y ago
DHH starts at ~11:30 mark.
deleted 12y ago
[deleted]
trebor 12y ago
Subject of the talk?
- steveklabnik 12y ago
  I am not at RailsConf and haven't watched the talk yet, but: "In many ways, the prism of computer science is harmful for the development of information systems" - https://twitter.com/wycats/status/458616115451527168 https://twitter.com/wycats/status/458616115451527168 "DHH is essentially talking about how getting overly concerned with testing millions of isolated pieces is more trouble than it's worth." - https://twitter.com/wycats/status/458620203711344640 https://twitter.com/wycats/status/458620203711344640 "A good TLDR of this talk is that pseudo-CS exploits your desire for "science" but does more harm than good." - https://twitter.com/wycats/status/458622138099183616 https://twitter.com/wycats/status/458622138099183616 EDIT: I'm most of the way through the talk now, I agree with wycats' summary.
  - stephenhuey 12y ago
    His finale after all that was clarity. He suggested it'd be better to aim for being a software writer more than a software engineer, and to focus on writing software well. As others have pointed out, he did argue that unit testing is sometimes a waste of energy when taking to the extreme. However, along with that he pointed out that he believes system tests are in fact important, and his take is that they're much more important than 100% code coverage in testing. Does your whole system work?
pothibo 12y ago
One thing I want to add about TDD that always made it impossible for me to build is how pointless (to me) it is to do TDD in the functional/integration areas. I tweak shit loads of forms, but as soon as a form get a little bit complex, it's impossible, for me, to apprehend the parameter's structure. Same goes with views. Your first view implementation is likely to be very different than the one you end up using. TDD is built on the assumption that you know everything from the get go which has never be the case for me. I write tests when things are settle down and ready to go live as a mean for me to say: "Ok, I think this is good enough, let's go live with this, but beforehand, let's make sure it works as expected". Then bugs appears, and I add tests to cover those cases so I don't introduce regressions in the future.
- gregmolnar 12y ago
  Same with me. I use "test first" with unit/model tests only. For the rest I first write the code, test in the browser and when I am happy I write a test to make sure I won't break the feature with future code changes.
- benjiweber 12y ago
  This shouldn't need to be the case with TDD. TDD is a tool for evolving the design & functionality. The whole reason for using it is that you don't know what you want beforehand. With TDD you write a failing test, write the smallest amount of code necessary to make it pass, then refactor. After that you add another test and go round again. You can use this to drive your design for low level unit/model tests. When writing higher level acceptance tests I like to write the tests in using the language you share with the customer [1]. If you do this then they should remain valid unless the requirements change, they should not be dependent on your understanding of the requirement. To achieve this you can have your tests manipulate a domain model. If you are not testing your model then you need a model for your tests. e.g. something like the page object pattern for webdriver[0]. This means you can sketch out your high level tests rapidly with a stub model, and then implement the mapping to your implementation once you have got the implementation more stable. Adding a layer of indirection to the implementation like this also means you can refactor your implementation as much as you like without touching the test itself. You may need to modify the mapping between the language your tests use and the implementation as you change the implementation. This sort of test can be valid across major re-writes of the implementation. The tests should also be less brittle. If you change something that several tests interact with you should only need to update one place to fix it. For integration tests I like to use the same approach, except now the language used relates to the common concepts across the two systems you are testing integration of. The concepts used in the APIs. [0] http://code.google.com/p/selenium/wiki/PageObjects http://code.google.com/p/selenium/wiki/PageObjects [1] Ubiquitous Language http://martinfowler.com/bliki/UbiquitousLanguage.html http://martinfowler.com/bliki/UbiquitousLanguage.html
stephenitis 12y ago
I liked his rant on unit testing. It's not about the # of test or the % coverage. It's the # of test required for a degree of confidence needed to sleep and further develop.
amrit_b 12y ago
Video doesn't work for me. Any other URL?
midas007 12y ago
There's no audio until 11:15.
rartichoke 12y ago
This is the best keynote he's ever given. It boils down to actually writing code and forget memorizing patterns. That can't be more true.
- karmajunkie 12y ago
  headdesk While we're at it, let's get down to just cooking and forget food science. Never mind how a recipe should be adjusted at altitude. Or what to substitute when the person eating your minimally viable meal has a food allergy to an ingredient. Or what other things go well with your main entree. We're just cooking up things we got out of a can, after all. Don't learn any patterns. Except the ones DHH wants you to—those are ok. All the rest of them just get in the way of writing software. (readers may proceed to downvote now.)
  - rartichoke 12y ago
    He never said don't learn patterns. He said it's not worth spending all your time trying to memorize them before you even write a line of code. Memorizing about 20 patterns for 3 months before you really write any code is way worse than just hacking together something and improving it because after enough time you know what's wrong. The "you just know" thing is really powerful. I'm not a professional artist but I just know that if you had a yellow background and you drew something in the foreground with the same yellow code it wouldn't work because you couldn't see it. When writing shitty code I just know it's bad because I find myself having to copy/paste something 8 times or maybe it's close enough to a copy/paste that it still feels wrong so then I fix it.
    - karmajunkie 12y ago
      I think that's good advice—great, even—for the person just learning to code. Its terrible advice for someone who is or wants to be a professional in a field in which continuous self-education is an imperative to stay employed. Patterns provide both a vocabulary and a toolbox to go to when you're solving a problem. If you don't learn the vocabulary and the tools that are available, you don't recognize problems when they arise, or you only recognize them because you're no longer able to constructively execute on new features. To take your example, yellow-on-yellow isn't an aesthetic assessment, its a functional one. You recognize that functional anti-pattern because you've experienced, at some point in your life, what happens with a lack of contrast. If you aren't colorblind, you probably don't (intuitively) recognize that red on green is also a functional anti-pattern. When you extrapolate to the world of software development, without having previously learned these patterns or something resembling them, you don't recognize the antipatterns when they occur. I'm not saying "Don't write software until you know all the patterns, ever." I'm saying that DHH has a traditional antipathy for any pattern he hasn't deigned fit to include in Rails canon, and that when you're coding solutions that need to scale in both performance and complexity, you probably don't want to take advice from someone who thinks a formalization of the AR pattern is the height of domain modeling.

48 points by johnjlocke 12y ago

pmh 12y ago

DHH starts at ~11:30 mark.

deleted 12y ago

[deleted]

trebor 12y ago

Subject of the talk?

steveklabnik 12y ago
I am not at RailsConf and haven't watched the talk yet, but: "In many ways, the prism of computer science is harmful for the development of information systems" - https://twitter.com/wycats/status/458616115451527168 https://twitter.com/wycats/status/458616115451527168 "DHH is essentially talking about how getting overly concerned with testing millions of isolated pieces is more trouble than it's worth." - https://twitter.com/wycats/status/458620203711344640 https://twitter.com/wycats/status/458620203711344640 "A good TLDR of this talk is that pseudo-CS exploits your desire for "science" but does more harm than good." - https://twitter.com/wycats/status/458622138099183616 https://twitter.com/wycats/status/458622138099183616 EDIT: I'm most of the way through the talk now, I agree with wycats' summary.
- stephenhuey 12y ago
  His finale after all that was clarity. He suggested it'd be better to aim for being a software writer more than a software engineer, and to focus on writing software well. As others have pointed out, he did argue that unit testing is sometimes a waste of energy when taking to the extreme. However, along with that he pointed out that he believes system tests are in fact important, and his take is that they're much more important than 100% code coverage in testing. Does your whole system work?

pothibo 12y ago

One thing I want to add about TDD that always made it impossible for me to build is how pointless (to me) it is to do TDD in the functional/integration areas. I tweak shit loads of forms, but as soon as a form get a little bit complex, it's impossible, for me, to apprehend the parameter's structure. Same goes with views. Your first view implementation is likely to be very different than the one you end up using. TDD is built on the assumption that you know everything from the get go which has never be the case for me. I write tests when things are settle down and ready to go live as a mean for me to say: "Ok, I think this is good enough, let's go live with this, but beforehand, let's make sure it works as expected". Then bugs appears, and I add tests to cover those cases so I don't introduce regressions in the future.

gregmolnar 12y ago
Same with me. I use "test first" with unit/model tests only. For the rest I first write the code, test in the browser and when I am happy I write a test to make sure I won't break the feature with future code changes.
benjiweber 12y ago
This shouldn't need to be the case with TDD. TDD is a tool for evolving the design & functionality. The whole reason for using it is that you don't know what you want beforehand. With TDD you write a failing test, write the smallest amount of code necessary to make it pass, then refactor. After that you add another test and go round again. You can use this to drive your design for low level unit/model tests. When writing higher level acceptance tests I like to write the tests in using the language you share with the customer [1]. If you do this then they should remain valid unless the requirements change, they should not be dependent on your understanding of the requirement. To achieve this you can have your tests manipulate a domain model. If you are not testing your model then you need a model for your tests. e.g. something like the page object pattern for webdriver[0]. This means you can sketch out your high level tests rapidly with a stub model, and then implement the mapping to your implementation once you have got the implementation more stable. Adding a layer of indirection to the implementation like this also means you can refactor your implementation as much as you like without touching the test itself. You may need to modify the mapping between the language your tests use and the implementation as you change the implementation. This sort of test can be valid across major re-writes of the implementation. The tests should also be less brittle. If you change something that several tests interact with you should only need to update one place to fix it. For integration tests I like to use the same approach, except now the language used relates to the common concepts across the two systems you are testing integration of. The concepts used in the APIs. [0] http://code.google.com/p/selenium/wiki/PageObjects http://code.google.com/p/selenium/wiki/PageObjects [1] Ubiquitous Language http://martinfowler.com/bliki/UbiquitousLanguage.html http://martinfowler.com/bliki/UbiquitousLanguage.html

stephenitis 12y ago

I liked his rant on unit testing. It's not about the # of test or the % coverage. It's the # of test required for a degree of confidence needed to sleep and further develop.

amrit_b 12y ago

Video doesn't work for me. Any other URL?

midas007 12y ago

There's no audio until 11:15.

rartichoke 12y ago

This is the best keynote he's ever given. It boils down to actually writing code and forget memorizing patterns. That can't be more true.

karmajunkie 12y ago
headdesk While we're at it, let's get down to just cooking and forget food science. Never mind how a recipe should be adjusted at altitude. Or what to substitute when the person eating your minimally viable meal has a food allergy to an ingredient. Or what other things go well with your main entree. We're just cooking up things we got out of a can, after all. Don't learn any patterns. Except the ones DHH wants you to—those are ok. All the rest of them just get in the way of writing software. (readers may proceed to downvote now.)
- rartichoke 12y ago
  He never said don't learn patterns. He said it's not worth spending all your time trying to memorize them before you even write a line of code. Memorizing about 20 patterns for 3 months before you really write any code is way worse than just hacking together something and improving it because after enough time you know what's wrong. The "you just know" thing is really powerful. I'm not a professional artist but I just know that if you had a yellow background and you drew something in the foreground with the same yellow code it wouldn't work because you couldn't see it. When writing shitty code I just know it's bad because I find myself having to copy/paste something 8 times or maybe it's close enough to a copy/paste that it still feels wrong so then I fix it.
  - karmajunkie 12y ago
    I think that's good advice—great, even—for the person just learning to code. Its terrible advice for someone who is or wants to be a professional in a field in which continuous self-education is an imperative to stay employed. Patterns provide both a vocabulary and a toolbox to go to when you're solving a problem. If you don't learn the vocabulary and the tools that are available, you don't recognize problems when they arise, or you only recognize them because you're no longer able to constructively execute on new features. To take your example, yellow-on-yellow isn't an aesthetic assessment, its a functional one. You recognize that functional anti-pattern because you've experienced, at some point in your life, what happens with a lack of contrast. If you aren't colorblind, you probably don't (intuitively) recognize that red on green is also a functional anti-pattern. When you extrapolate to the world of software development, without having previously learned these patterns or something resembling them, you don't recognize the antipatterns when they occur. I'm not saying "Don't write software until you know all the patterns, ever." I'm saying that DHH has a traditional antipathy for any pattern he hasn't deigned fit to include in Rails canon, and that when you're coding solutions that need to scale in both performance and complexity, you probably don't want to take advice from someone who thinks a formalization of the AR pattern is the height of domain modeling.