This version of Vestibule is read only. It represents an archive of the community effort to produce content for Ruby Manor 4.

A Live-Coding Odyssey

updated over 4 years ago; latest suggestion over 4 years ago

This proposal has been withdrawn...

This speaker believes that the best way for programmers to learn is to watch each other work.

This talk leaves slides behind and focuses instead on the greater information density achieved through live coding.

We'll discuss the strengths and weaknesses of real code, and refactor it right on-stage. As we do so, we'll bump into lots of meaty topics:

  • Potential downfalls of the 'extract module' refactoring (aka ActiveSupport::Concern).
  • The pros and cons of Dependency Injection.
  • How two good OO design ideas (like SRP and Tell Don't Ask) can contradict each other, and what to do about it.
  • How well-placed functional programming can improve a codebase.
  • The positive design pressure of TDD.
  • Whether the Law of Demeter should be followed religiously, and what it means if that's hard to do.
  • Why fast tests are usually good tests, and vice-versa.

Audience participation is strongly encouraged, as is stealing the speaker's vim tricks for your own use.

Suggestions

  • B68ce3695bb8dc29b9f9cb0dc0b721a5 Murray Steele suggests over 4 years ago

    ps. Here is the talk Chris referred to: Writing a language in 15 minutes. Another that does something similar is Joseph Wilks' Working Outside-in with Cucumber and Rspec from Scotland on Rails 2009

  • B68ce3695bb8dc29b9f9cb0dc0b721a5 Murray Steele suggests over 4 years ago

    Most of your bullet points could probably be expanded into talks on their own. So it feels like you might be spreading yourself a bit thin, especially if you're going to explain each thing, then do some live coding to refactor it, then discuss the results. Or are you going to assume that everyone knows the pros and cons of each approach so we just focus on the live refactoring?

    I do think there is a lot to be gained from seeing before and after versions of code, even seeing some of the intermediate working that takes us from the before to the after. What I'm not sure is so important is for me to see you type the characters into your editor. Especially given the time constraints.

    I'm keen to see some proposals that try something different, but I know how hard live coding can be. If your talk is selected you should really think about taking Chris' advice and pre-recording.

    Unless, of course, that the subtext of this talk is to show people a grab bag of vim config and scripts to help with refactoring ruby code? Which could very well be a good talk in it's own right, but then I'd be less worried about you having to explain the why of the refactoring you were doing.

  • A8486651a974d7d9ecc35d25de96c7ee Chris Lowis suggests over 4 years ago

    This sounds very brave! Live coding perhaps has greater information density, but I think it's very hard to "skip ahead". Do you think you'll be able to cover all you plan to cover in a 30 minute live coding session?

    I'd love to see something like this happen. There might be a video around of James Coglan's talk on building a scheme interpretor in 15 minutes in Ruby from a previous LRUG - he'd pre-recorded the "live coding" and narrated it. It worked very well, but I had to watch it 3 or 4 times (and read the source code at my own pace) to really understand it.