1221 samples storage

[zeroasterisk]

Add samples/storage first pass for #1221

Implemented most of basic CRUD for Storage Buckets/Objects

Implemented with a bit of abstraction, but trying to keep things obvious for new users

[zeroasterisk]

Ok @dazuma that makes sense.
I was trying to make "examples of tasks" but more in the guise of an "example app doing tasks". I really like the ruby examples of CLI scriptable functionality... I could refactor into something more like that... so we could use it via CLI, could automate via tests, and make it less of an example app and more like a utility library demonstrating the client...

As you recommend, reduce the abstraction that I introduce... but things like utilities to log information and so forth are ok... right?

Give me any guidance you think is relevant and I'll get a new version of this out soon.

[dazuma]

A good guiding principle is, we should be able to point a user to one short, contiguous piece of code that demonstrates everything they need to do to accomplish one task. They should conceivably be able to copy and paste that single contiguous code block into the appropriate place in their application and have it work.

The problem with abstractions is that users must look at both the abstraction itself and the code that uses it in order to understand what's going on. They have to copy and paste two separate pieces of code into their app to have it work. The same thing could be true even for introducing utilities.

Also, if you're thinking about introducing a utility, it might be a sign you're trying to demonstrate more than one thing at a time. Instead, write two separate samples. Have a dedicated sample that shows how to log information relevant to sending an API request. And then for the other samples, don't bother showing logging. Just show how to issue the request.

As you said, there's also the idea of a "sample app" that shows how to integrate a bunch of things together to accomplish a larger task. There's definitely a place for that kind of sample, although I don't think it's what we've been discussing for this repo. If you've got ideas on this, I think we should put them in the elixir-samples repo. (And similar principles apply: try to minimize the nice utilities and abstractions you might write for a real world app. Our goal is not to demonstrate how to write abstractions. Users can learn that elsewhere. Our goal is to demonstrate how to integrate with google services. The more focused the goal, and the least code it takes to accomplish it, the more effective the sample will be.)