[Gym] Help needed! Offer/Request

[_pyramid]

This is so cool! I’m amazed

Thank you for your clear and sensible feedback. You make a lot of good points, and this kind of interaction is what I want for the gym - group co-creation, more than one person doing all the exercises.

I think for now this forum is a good enough place to do the feedback, this way other people also have visibility. It may also be good to create a tag for it to group the different posts.

My pleasure! When future updates are pushed I’ll also provide more feedback here; perhaps a google doc with comments so you can get a line-by-line approach in addition to overview-level suggestions.

As far as your individual suggestions, two things come to mind…

All that sounds good to me.

In the recent hashes exercise, I loved how @tixel made the participants play with the hashes of the entries, as it forced you to see how they work by playing with them. How was your experience with that interaction?

Yes that was cool, well done @tixel - the effort that goes into those visual examples pays off, I think. There’s nothing quite like seeing it in action. I was actually a little surprised by the quite detailed explanation of hashing, though, not in that it was unwelcome, but rather that I was struggling to understand other things but I already knew basically what hashing was and why we did it. If the same level of explanation went into the other elements of holochain as went into explaining simple hashing, that would be amazing.

Oh one thing I can mention about the “Getting Ready” section. Maybe a brief explanation of the different hashes in the signed_header would be good: header::content::entry_hash, author, prev_header and the header::hash. This would help the user in differentiating which hash they should be searching for in their own code (the header hash, not the content hash). In the subsequent Test section, it’d then be good to remind/show the user in tests\src\index.tswhat that entryHash is (the header::hash from before) and how the get_book() code plays with that type of hash, which can be traced back to what we just learned.

We need more beta testers , so that’s awesome. Even if you want to learn more about a particular concept and would want to create an exercise by yourself, that would be even more awesome . I can offer help with the concepts to guide you in that process.

I’d love to help write something, or learn enough about it to then write it up for others. Although I tend to work better with ‘let’s make a simple X’ kind of approach, maybe exploring a solo concept wouldn’t be a bad start. Is there one you can recommend? Neighborhoods and verification come to mind, but I wonder if that’s too advanced for now.

[guillemcordoba]

Yes to all of that, thanks again.

As far as your last point goes, I think neighborhoods are out of the scope for the gym as of now (there is little that a happ dev can do about them other than knowing what they are, which may require an architecture exercise). Maybe links or source-chain would be a good start? @tixel is already working on the elements one, and the others are quite basic and have the benefit to already have the interactive exercise up and running. What do you think?

[_pyramid]

Links did cross my mind actually, and it’s yet to be completed. I can do some reading in the docs and make sure I’m up to speed with both entries and links before theory-crafting a test or getting some feedback? Don’t stop on my account, though, if you already had plans for that one - I don’t want to tread on anyone’s draft.

[guillemcordoba]

Actually my intention is to make those basic exercises be made by new contributors as much as possible, so what would be awesome. Links are a basic enough concept that it should be quite easy to start I think. I’m here for whatever help you need in understanding / building anything around that

[tixel]

Hi @_pyramid,

Thanks for all the feedback and kind words. A big part of the credits go to @guillemcordoba for building the playground/simulation component. I just copy pasted them in the parts that I wrote. Without him you would get plain text with a mousedrawn MS paint diagram Actually we wouldn’t even have the gym :kudos:

For the record: I too like the tight read-do loop the simulations enable.

@_pyramid

I think a general improvement I can recommend is this: within a chapter page, after the graph/interactive examples (which are so good), introduce a code pattern with a simple, complete example, and then end the chapter with a more complicated test.

I definitely like this idea.

@_pyramid

Maybe a brief explanation of the different hashes in the signed_header would be good: header::content::entry_hash, author, prev_header and the header::hash.

I’m currently working on a chapter on hashes, which should explain a lot of this stuff: preview. But it might be a good idea to paint a quick, more complete picture in the beginning. So that terms as entry_hash, headerhash, source-chain have touched your eyes before you dive in.
The basics idea I was following within the basic exercises, was to keep the number of concepts to a minimum. And with each exercise to repeat those concepts and a just a few more concepts. So we don’t overload people.
That is why a seasoned holochain developer might read a lot of half truths in the exercises.

Thanks again and welcome to holochain-gym staff!

[_pyramid]

Hi Tixel! I didn’t realise @guillemcordoba made those playgrounds! I misread that part of the post, my apologies for that. But yes, I think that section on playing with the hashes was good. You mentioned you were working on the hashes chapter and provided a link to a preview, but I think that link in your post didn’t go through unfortunately. Was it this branch?

Without him you would get plain text with a mousedrawn MS paint diagram

I do love those drawings though! This one made me laugh. And the analogy with the islands was beautiful, so there’s something to be said about a good MS paint masterpiece.

The basics idea I was following within the basic exercises, was to keep the number of concepts to a minimum. And with each exercise to repeat those concepts and a just a few more concepts. So we don’t overload people.

Definitely worth building upon the concepts piece by piece, and I think it’ll take a few goes for me to get that balance right: knowing exactly how much to say now or save for later.

Thanks again and welcome to holochain-gym staff!

Oh thank you It’s really cool to be a small part of this and contribute, so thanks for being so welcoming (@guillemcordoba too). I’ve already taken a look at the links chapter currently online and made some notes, so when I’m ready to get some feedback on my ideas I’ll post it up - should I make a branch in the holochain gym repo or just DM it here on the forums?

One last thought: In my original post I mentioned that I had some familiarity with Rust, but I probably didn’t make it clear that I’d still consider myself a beginner in the language. In my plans and feedback for chapters, occasionally I’ll have a question for you and guillem that might be rust-specific, but I’ll try and keep these to a minimum and google instead Hope that’s ok.

[tixel]

@guillemcordoba

Removing EntryHashB64, as it doesn’t add any new thing here and it isn’t worth to explain in this exercise

Guillem,
Please leave the EntryHashB64 stuff in there. I was looking for an elegant way to get hashes in and out of zomes. And this works more explicit than WrappedEntryHash.
Plus we can remove hc_utils dependency, as you did. And make the general setup simpler.

[_pyramid]

Hi there @tixel, @guillemcordoba. Over the past few days I’ve produced a draft of some code examples for links including Orchestrator tests. In addition, I’ve been working on a write-up to complement what is already in the links.md page of the gym. I’ve made a fork of the developer-exercises and pushed my changes to a new branch. Once the code looks right, I’ll upload my changes to the gym

Very keen to get any sort of feedback on Rust structures, how the functions behave, what the tests are like.

[guillemcordoba]

Hi @_pyramid, thanks for this

So the code looks good, but I would do something much more concrete, not so generic. I would make a Post struct, and two functions:

create_post(content: String) -> EntryHash: create entry and link entry from agent_info()?.agennt_latest_pubkey
get_posts_for_agent(agent_pub_key: AgentPubKey) -> Vec<Post>: get links from the given pubkey and do a get for every link target

This way, you can get a much more “usual” use case in which you wrap the hdk core functions with the actual endpoints that your app needs. This makes it much more understandable IMO.

What do you think?

[_pyramid]

Thanks for the suggestions; I think you’re right. My current examples tend towards very basic inputs and outputs, where I can instead show a more usable example. I’ll work on this and let you know when another update is ready for review.

[_pyramid]

Another update here, and testing here

[guillemcordoba]

That is awesome! Congrats for this. Do you wanna make a PR?

[_pyramid]

Thank you! Yes I’d love to, I’ll do that later today.

[_pyramid]

Hi everyone, I’ve just read through the Paths exercise and I have some more feedback to share

The visual examples are great, once again, and I think the explanation for the index-style notation is good too. While I won’t give too much feedback on the prose of the exercise for now, I’d say that re-iterating high-level points from this sub-section of the core concepts at the beginning of the gym exercise would help ease developers into the task at hand.

Conceptually, I’m having trouble understanding why Paths are different to Links. Having read through the gym chapter and played around with the visual example, I’m not confident that I now have the ability to tackle the exercises or understand how I go about working with the Path structure. Heading over to the docs and reading through the functions, it doesn’t seem like the hdk content matches the lesson in the gym.

Here is my impression about what paths are: they are entries with a string that can be interpreted as a path because of their period delimiter. Maybe.

While the Core Concepts chapter indicates that Paths/Anchors serve as Entry/Link combination indexes for users to find data, functionally it appears to me that Paths are simply entries with the ability to be searched as though they had links.

So before I can begin to understand and appreciate the utility of Paths, it would be great to have the following clarification:

1. How are Paths different from Links
2. When do I want to use a Link vs a Path
3. Where are the functions I need to begin playing around with Paths
4. How do I denote a path inside my entry
5. What does it mean that I can access paths [A D] over [A B C]

I noticed that on the updated Remote Call exercise that there’s a code example straight from the docs - having that in the Paths chapter would be really great to see.

~

Other things. I’ve made a PR on the developer-exercises, ready for comment and review. Would you also like me to have a go at re-writing/editing the links chapter on the gym to update the information there?

[tixel]

Hi @_pyramid,

I’m probably not the best person to answer your questions, since I’m on the same part of the learning curve as you are.
Assuming I’m not making mistakes: Paths are the successors of or an improvement on anchors. The docs are not brought up to date yet. I believe the team is laser focused on adding functionality.
That said I’m currently using the following analogy in my head.
Paths are like labels in gmail: you can have 3 mails with these label:
mail 1 - work
mail 2 - work/projectx
mail 3 - work/projectx/meeting
When you fetch mails for the label: work you get 3 mails, mails for label projetx: 2 and for meeting 1.

And links, in my mind are more like mailthreads. There is an incoming mail, then I reply, then I get a reply on the reply. This would be something for what you would use links.

@_pyramid

• Where are the functions I need to begin playing around with Paths
• How do I denote a path inside my entry
• What does it mean that I can access paths [A D] over [A B C]

I cannot really help you with this at the moment. Still learning myself.

@_pyramid

Other things. I’ve made a PR on the developer-exercises , ready for comment and review.

I’m merging it in the solution branch at the moment. I will merge into master, after the tests have run on solution.

@_pyramid

Would you also like me to have a go at re-writing/editing the links chapter on the gym to update the information there?

Yes go ahead!!

[tixel]

I’m thinking about improving the setup of holochain-gym users:
The idea is as follows:
you start nix-shell from one place only, the root of the repo
$ ~/developer-exercises: nix-shell
and you build and run test with scripts
$ ~/developer-exercises/basis/0.entries: ./run_build.sh
$ ~/developer-exercises/basis/0.entries: ./run_tests.sh

In these scripts is a check that verifies if you are running in a nix-shell.

You can check it out in my fork: https://github.com/tixel/developer-exercises

Let me know what you think.

ping: @guillemcordoba @_pyramid

[_pyramid]

Hi @tixel, thanks for the reply and explanations, it’s helped me better understand the utility of Paths. Seems to me like Paths offer a richer pattern to discover data by way of node hopping - that is, if you know the work path then you can hop to meeting without having to return and query projectx in the middle. Once the docs are up to speed, I’d like to see the interplay between Links and Paths. It looks like you can actually gather link data with this children function, which seems to indicate that you query a Path, find the deepest section that relates to your data and then return the links. Keeping in theme with the mail client, this might be a good exercise to try: query the Path down to the level of meeting and get all the entry posts that have been linked with the ‘meeting’ link.

You can check it out in my fork: https://github.com/tixel/developer-exercises

Looks good, this would definitely cut down on the number of nix environments we need to make! I can’t imagine there would be many instances where we’d need to change the environment, only to add more packages relating to specific examples. In that case, we might as well load it all up on the first nix-shell call.

[guillemcordoba]

Hi @tixel and @_pyramid thanks for all the work and interest

I like a lot the simplification for the setup. It seems the nix files setup is quite hard to understand at first because it’s not really that usual, so simplifying is cool.

About paths:

• Paths are just another entry: in reality the hdk only exposes helper functions to help you, but you could achieve the same things by implementing your own functions. Paths themselves don’t add any other primitive to what we already have available: entries, links and headers.
• Paths are the successor of anchors:
  • Anchors are normal entries that are committed to the DHT, but everyone is able to compute them beforehand (eg with a hardcoded function in the zome code).
  • Since everyone knows the anchor’s content, everyone can compute it’s hash without any request.
  • Example:
    • Everyone agrees that when creating a Post entry, a link will be attached from the anchor to the post.
    • If I want to get all posts in the DHT I just need to do a get_links on the anchor, and I will get the hashes of all the posts.
• Paths are like a tree of anchors: to avoid having a million links attached to the same anchor, we subdivide them into “little anchors” segmented by what the app deems important to query for (in the gym example, this is by time).
• With this, you sacrifice storage (you are committing more entries and links) for much better performance when the DHT scale: instead of having to load the million posts in this DHT, you can just get the 50 from the latest hour.

I think we need a first exercise on Anchors, where we could manually implement anchors to see that there is no magic underneath, just normal entries, and then go ahead and delve into the complexity of paths. What do you think?

[_pyramid]

Wow. This is a great explanation! I understand much more about Paths now, so thank you for writing all of that

I think we need a first exercise on Anchors, where we could manually implement anchors to see that there is no magic underneath, just normal entries, and then go ahead and delve into the complexity of paths. What do you think?

I think this would be good stepping stone, yes. When we give the user an ‘aha’ moment by showing them how anchors are just entries that can be pre-computed, adding Paths on top of that becomes a lot smoother. What do you think @tixel

[tixel]

Yes, seems like a good idea. I do think anchors should be part of the intermediate section if they build on entries, headers & links.