11-interfaces review

[stellentus]

I am not sure of a better way to provide this feedback to Brett.

• In slide 4, (c Complex) ToString() a line is too long to fit on the screen.
• As I noted in the pull request for my talk, I have a couple of slides that might be useful for this presentation (about the Stringer interface). I realize your talk is already about a stringer interface, but I think it would be good to explain the stringer interface, so you could potentially throw my slides (with some modification) onto the end of your talk.
  My slides refer to some types I've defined in my talk, but since your talk comes right after mine, I think people will remember well enough that it could work.
  You could also use one of the exercises that I've now dropped: Write a stringer for the struct that was created for the exercises in talk 9. (This assumes that @torbiak adds an exercise to get the students to write a struct.)

[mckayb24]

Thanks for the note on slide 4 James, I've fixed it now.
As for the exercise, my aim is to show them how by using interfaces you can make your code more re-usable.
I thought that would be more appreciated if they had to do something more complicated than write a stringer. By having them Post something there is the added bonus of leading them into the capstone.

Thoughts?

[stellentus]

I'd suggest starting with a stringer because it's quick and easy, so they can feel a sense of accomplishment (and the ah-ha moment of seeing the stringer called automatically by printf). Since they've already written a method for this in the last two exercises, it will be as simple as changing the signature of the function. It's also a pretty important interface. But even if you include a stringer exercise, I agree there should be something more challenging.

I'm concerned that posting might take too long. But my exercise for the preceding talk is extremely short, so we could probably assume that my exercise will take half as long as scheduled, which would give you extra time (about 10 minutes total). It makes sense to group the exercise for methods and interfaces.

I like the idea of leading into the capstone, as long as it's not too difficult. @boersn has emphasized that the exercises shouldn't be too difficult, but he knows a lot better than me how to judge that, so perhaps he can comment.

[boersn]

@mckayb24's idea of an exercise that leads into the capstone is great, but I'm also a little concerned that it'll take too long. Do they have any exposure to the "http" package at this point? I wonder whether the exercise could be broken up into two parts. First, they write a stringer (and we expect everyone to finish). Second, they extend that program with the posting (and we expect ~50% to finish).

[mckayb24]

In the interfaces lecture I finish by describing how different structs can be used as Readers which is used as the body for calls to Post. I describe how files and bytebuffers both already satisfy a Reader.

In order to Post something the call is similar to:
resp, err := http.Post("http://example.com/upload", "image/jpeg", &buf)
Where &buf is the Reader.

I plan to meet with Matthias tonight to piggy back off the work he already did setting up the capstone server unless of course the consensus is I should make it simpler and use Stringer instead.

I'm actually conflicted now because James is right and seeing how adding a String method to a struct is used by fmt.Println is cool and useful. Thoughts?

[stellentus]

What type of data does Matthias's server accept? Can it have an API that accepts a string, returning status code success if it got a string?
If so, the exercise could be this:

1. Convert the bank account printing method you made in the last exercise to conform to the stringer interface, and test that fmt.Println(bankAccount) prints your string. [Provide a link to the stringer interface godoc, or duplicate it here.]
2. Post the string to a server at [URL] using http.Post[link to godocs]. Note this won't make use of the Stringer interface, but you'll be using your String() method to get the data to post to the server.

However, the problem with step 2 is that the io.Reader interface won't be implemented directly by the students. They'll either use a bytebuffer or call string.NewReader(bankAccount.String()). Either way, this is magic. I'm not sure how to make this understandable in less than 10 minutes.

Perhaps this:

1. [As above]
2. Use string.NewReader [link to godocs] to get an io.Reader which can output your string as bytes.
3. Use your io.Reader with http.Post [link to godocs] to upload the string to [URL].

But I think that's too many steps, and the io.Reader stuff is still magic.

I think the problem is that with io.Reader they aren't implementing the interface; they're just using it. They need to implement a reader to really understand what it does, but implementing the reader interface isn't simple.

But I can't find any other good options in the standard library. (List of interfaces: http://blog.fraixed.es/post/a-walk-through-golang-package-interfaces/) Perhaps sort?

Since it's very common to convert between types using built-in functions to implement interfaces, perhaps this is still a good example question, but we should be prepared for more questions than usual. Any time we spend addressing this here is time we would have spent during the capstone, anyway.

This could get slightly simpler if we just ask the students to post a known byte slice to the server, instead, but that doesn't explain the magic any better.

EDIT: to improve wording of exercises

[stellentus]

I suppose, Brett, that since you're explaining Post and ByteBuffer, it might not be as complicated as I think, so my first suggestion above might be enough.

[mckayb24]

I think we differ on what we think the take away from the interface talk is.
Based on what you've said my understanding of your thinking is that you want them to understand how to create a method to satisfy an interface.

What I think the take away should be is that interfaces can accept different underlying types. Until we get to interfaces we drive home the fact that Go has a very strong type system. Interfaces allows code to be re-used by different data structures.

By my way of thinking I don't actually care if they write the method as long as they understand that they can use different data structures. However, you're right that it will be more understandable if they were to implement the methods themselves. So I'll change my talk to look at fmt.PrintLn instead and have them print their struct with and without a String method.

Thanks for the help.