William (1) [Avatar] Offline
#1
I notice that the shorthand "po" is used in some places, and the full "pod" in others. For the purpose of the book, would it be clearer to just always use "pod"? Or at at least keep it consistent?

E.g. page 83 mixes both styles in the one example:
$ kubectl label pod kubia-dmdck type=special
pod “kubia-dmdck” labeled
$ kubectl describe po kubia-dmdck | grep Labels
Labels: app=kubia,type=special
Marko Lukša (47) [Avatar] Offline
#2
I believe I mention that shorthands can be used and how to look them up somewhere in the beginning.

Now I'm a little torn. I used shorthands because I personally use them when interacting with Kubernetes and it felt like a good idea to teach readers to do that as well (to work more efficiently). But I see how this can cause extra cognitive load on the reader.

However, using the full name will probably lead the some commands wrapping to the next line (when they currently don't) - for example, when using replicationcontroller instead of rc. I hate commands that don't fit into a single line. It makes them much less readable.

I don't know. What do other readers think about this? I'm in the final stages of polishing up the book, so it would be great to get some feedback on this in the next few days.

Thanks for your comment.
boyarsky (67) [Avatar] Offline
#3
I like the mix of abbreviations and "long form." I imagine many people use the short form in real life so it is good to see both. Maybe add a table somewhere in the book (or appendix) that lists all the pairings. If it isn't already there, I think I saw one.

That said, I think it would be helpful to avoid mixing in the same code snippet.
Marko Lukša (47) [Avatar] Offline
#4
I'll add callouts to wherever I use a shorthand the first time. I'll also make sure I don't mix in the same listing.

All the resources, their shorthands and the API version&group they belong to will be shown in a table on the inside covers.

Thanks for your suggestions.