CoderFaire Nashville '12
25 - 26 Aug 2012 at Nashville School of Law

If I were going to give this talk, I would want to change a few things.

- If I was going to put an example of bad code on the screen, I would use my own code.

- If I was going to put an example of good code on the screen, I would use somebody else's code.

- I would avoid ever saying "you should", "you must", or "is important". Instead, I'd say something more like "I always try to ... because ...". But that's just me.

There is nothing wrong with an opinionated talk. It's entertaining and engaging.

The example could have been less contrived, but it did the job, which was to trigger discussion.

I would have liked to see what proportion of the audience actually does continuous integration, what percentage always include thorough automated tests in every commit, what percentage test first, etc.

The people who came with questions suggesting "i'd like to do testing but we don't do that at my company" did not get satisfactory answers, I don't think. Ultimately, you just have to work someplace where testing is de rigeur. That's all it takes. You'll never go back.

Not bad. Audience participation really kind of carried it though.

This was good talk and the audience interaction portion was a real treat.

This talk was fantastic very creative slides, and a good simple message.

Good talk. The detailing of all the separate types of board was a bit dry, but the pace quickly picked up after that.

Best talk of the conference so far. I considered myself pretty knowledgeable in this area but it was very thought-provoking.

Wonderful talk. I apologize for leaving my phone on. :(

Sorry this is so long...

I think people who are totally new to HTTP would be better served by initial examples that just show what's going on as a typical web page loads--what the browser sends in order to get scripts and css, following a link, submitting a form. That way, it's immediately obvious what the client and server are trying to accomplish, and those are completely familiar things.

This avoid situations where the listener is thinking: "Wait, what sort of software exactly is the client in this exchange? Why are we doing this? When would I write code that does this? What is this JSON for?"

I was able to tell what was going on with the /books examples, so maybe I'm just wrong and it's plenty easy to follow already.

Separately: At the beginning, to motivate the talk, you brought up an analogy about hiring an electrician -- it's not a bad analogy, but the direct approach would work fine:

- of *course* you want to know how things work inside and why.
- the nice libraries that supposedly do all that for you don't *really* hide HTTP effectively, even when things *are* working; many don't even try.
- and when they break, knowing HTTP is invaluable in debugging them.
- plus, if you don't know what's going on underneath, you could spend a ton of effort re-inventing things that HTTP already does well, like caching.

On the whole, though, good talk, nice work!

Good talk, it very the concept very accessible.