Slide 144 Presenters Notes

[eeyun]

We should not teach people to use double quotes when not necessary, it reinforces bad coding behaviors. It might be harder to remember to write single ticks for people that are new to writing code but, the presenters note #1 on this slide says that "Most of the time in Chef you will use Double Quotes." I want to strike this out.

A note should be added to cover the rest of the ruby data types. We are already covering array's and strings. We should also cover hashes and ints at least.

[gmiranda23]

FWIW, there is no singular consensus on single quotes vs double quotes. Github's Ruby style guide prefers double quotes. Rubocop prefers single quotes. Most other Ruby style guides have no preference. If we're going to teach it, we should teach that it's a style choice. If we're going to prescribe single quotes because Rubocop, then we should say because Rubocop.

I agree that we should cover Ruby datatypes. To prevent coming across as focused on Ruby, I've found it typically works best to talk about a data type as it appears in the material. When we first see an array we talk about arrays, when we first see a boolean we talk about TrueClass and FalseClass, etc. A common critique of Chef is that it requires Ruby knowledge and that's seen as a barrier to entry. By introducing just enough Ruby as needed, we demonstrate that in-depth Ruby knowledge is not actually a barrier to entry.

[eeyun]

Re: Single v Double quotes - You're totally right. @burtlo and I were discussing this today in an on-site engagement. Personally I don't care about double v single so much as consistency across a codebase. However: We are currently bundling rubocop into our development kit which prefers single quotes for non-interpolated strings by default (obviously we can tweak all of these settings).But, out of the box it defaults to this preference. I'd argue that yes we should definitely point this out as a stylistic choice, but by bundling that tool into our BRANDED sdk we are inherently (whether or not its the case) telling our customers that we agree with enough of its preferences that they should use it with our products. Thats my primary issue with it. Customer is taught that it doesn't matter, customer downloads the CDK and starts doing linting of code, extra tool tells them "hey this is dumb don't do this". Customer then thinks the solutions engineer that was on site doesn't really know their stuff. We have a large group in this on-site and multiple people asked about what the general preference was and some individuals did not seem totally satisfied with an answer that was: well theres not total consensus on what the right thing is.

I can get behind your feeling for teaching the data types and I realized today that later in the deck we do actually have presenters notes on a couple other data types. In relation to the open issue maybe it makes sense to cut out the notes here on the other data type in this slide? It might also might make sense to just put the note in anyways and hit this detail more than once?

[gmiranda23]

I get your reasoning and I'm behind it. My point is simply that if we're going to explain it, we should be clear about it. If we switch to all single quotes, this talking point (single vs. double) comes up soon enough the first time we do string interpolation. So we can make a recommendation, but we should be prepared to fully explain the stance. And the stance is simply "because Rubocop". If not for Rubocop, the choice is entirely arbitrary. That may not be satisfactory, but it's the truth. "We recommend single quotes because Rubocop, but the truth is it's arbitrary." And, as instructors, we should convey that nuance when appropriate.

Some newer teaching materials include an instructor guide (talking points, in-depth notes, etc) and a sample script. That may be the "right" place to store notes like ruby data types. But since these materials doesn't have a guide, you should probably modify the notes as you see fit.