Improve example 8.1

[zacsketches]

Let me begin, by saying how much I appreciate you work on this repo. As an
experienced programmer coming to Golang I have been blessed by your incredible
dedication and the thoroughness of your solution set. I wanted to give back a little
by making a few minor improvements here and there. THANK YOU for this
repo which has made my journey in Go richer and more enjoyable. This pull
request improves on example 8.1 a little by making the clock server more
configurable and the client more exemplary of the wall of clocks requested in
the exercise.

This commit improves both the clock server and the clockwall client
from example 8.1.

clock.go is updated to add a feature that reads from an environment
variable 'TZ' to set the time zone of the time server from one
of the defined IANA time database timezone definitions. This allows
each clock to report in its assigned time zone without configuration
by the client, and is in keeping with the instructions for EX 8.1
which suggests the use of a 'TZ' variable when launching the
clock

clockwall.go is rewritten to implment the in-place updates typically
seen on a wall of clocks. The original provided concurrent updates
from several clock servers, but the input scrolled down the screen
and did not reflect the use case of a clock wall that visually
tracks times in multiple time zones as typically seen in some hotels,
command and control centers, and data centers with worldwide
customers. The updated clockwall.go provides continuous feeds from
clock servers on a single line in keeping with the idea of a clock
wall.

[torbiak]

Thank you so much for your kind words. I'm glad it was useful to you. It took a while for me to go through them all, but I enjoyed it.

And thank you for the pull request. Indeed, I didn't fully complete the exercise. But please understand that since this repo is almost completely all my solutions it would feel weird for me to merge code that isn't in my voice, as it were. If you're interested, I'd be happy to review your code and explain my view/preference on a number of points. Considering the goal of the review would be to make the code true to my voice, I'm afraid that it would be quite nitpicky and could hurt your sense of authorship. Alternatively, I could add the missing features to the solution in my own style and credit you for inspiration. Or maybe there's a better option that I haven't considered. What do you prefer?

[zacsketches]

Thanks for writing back and glad we can continue the conversation.

I completely understand your desire to have the solutions reflect your "voice". As a matter of fact, I have found myself taking a look at your solutions to various exercises after I have marched off to do them myself because I am at a point with Go where I can get the job done, but I am SURE that I am not yet using the most idiomatic method to achieve various outcomes. I find that once I understand the requirements for a particular solution and have a minimally viable program it is useful to see the way you implemented idiomatic Go to achieve the same outcome.

You have the highest "starred" repo of solutions to K&D. So I think your "voice" is becoming an important part of the movement in the Go language. For folks that are looking to use Go professionally, many will turn to the K&D book and then many of them will in turn look to your solutions as the "right" way to program in Go. That is something you should be quite proud of, and also careful about protecting so ALL of the solutions reflect your "voice". Therefore, I completely understand your point about protecting the integrity of the repo.

One additional point to consider is that the success of Go thus far has been the development of an inclusive community. I just got back from Gopherpalooza in San Francisco a few weeks ago. It was my first Go conference and I was delighted to find developers from large and small companies engaged in an open and utilitarian focused discussion about Go best practices, new ideas and emerging patterns the community will be adopting. Also there was the Go language team from Google who were earnestly interacting with folks to ensure they were building towards a tool and a language that served the broadest need with professional appreciation of the Go's role in long-running infrastructure.

With the success of Go built around community engagement and inclusive collaboration there is an idea that your repo and your rise as an important voice in the fast-growing Go community may be accelerated by helping grow the community through encouraging pull requests to the solution set.

To balance those two ideas, I would welcome a VERY "nitpicky" code review. In fact, this sort of code review would help me better understand your perspective on style and coding which I want to learn. I am less concerned with a sense of my own authorship, and much more interested in learning to write Go code that conforms to the style precedent you have already set and earned the right to maintain by the scope of work you put into a full solution set to the book's exercises.

So I think the way forward is that you give me a tough code review then I will make all the changes. This seems to balance preserving your "voice" in the repo and still building a community of people working through the learning process for the language beyond the basics of Golang Tour. What do you think?

All the best,
Zac