[QuickStart] Add mockgen as a dependency to the instructions

[Olshansk]

Objective

Improve the onboarding experience for devs to Shannon.

Origin Document

Goals

• Smoother onboarding experience for new devs

Deliverables

• [ ] Add mockgen to the quickstart guide
• [ ] Add a Makefile helper to error out if mockgen is not installed when running various commands
• [ ] Add links / instructions on how to install mockgen
• [ ] Ensure that running make install_ci_deps is in the quickstart docs

---

Creator: @Olshansk Co-Owners: @red-0ne

[jorgecuesta]

following the steps of the quickstart guide, get an error about missing dependency mockgen, I figured out the need to run make install_ci_deps, then I ran make go_develop_and_test but failed after 10m with the errors that are on the attached file. error.log

[jorgecuesta]

Step 2.2 does not explain that the address could be retrieved from the same way as step 2.1 (it was obvious to me, but not for everyone maybe?)

Why not add the log of the address to the create command?

[jorgecuesta]

Step 3.2 has a grammatical issue I think...

We need a blockchain node (i.e. a backend data node) backend data node to configure a supplier. Since LocalNet is already has a running anvil service, we can re-use that as our backend.

[jorgecuesta]

Step 3.3 does not explicitly explain that the cat ... command will create a file for those that are not very well versed on bash.

[jorgecuesta]

Step 3.5 failed with the following error: {"level":"error","error":"listen tcp :9090: bind: address already in use","message":"failed to listen on address for metrics"}

Checking what is using the port 9090, the result was:

lsof -i :9090
COMMAND    PID          USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
tilt    242516 overlordyorch   93u  IPv4 832033      0t0  TCP localhost:9090 (LISTEN)
tilt    242516 overlordyorch   94u  IPv6 832034      0t0  TCP ip6-localhost:9090 (LISTEN)

For the night I just tuneup the example and change:

#...
metrics:
  enabled: true
  addr: :9091 # changed from 9090 to 9091
#...

Also, so far I have checked on the tilt website there is a RelayMiner already running on the local cluster, so maybe it should not be there until this step is reached.

[jorgecuesta]

Step 3.5 explicitly ask to open a new terminal and leave the relay miner running, then on Step 4.3 the command poktrolld query application show-application $SHANNON_APPLICATION --node tcp://127.0.0.1:36657 use the previously exported env variable $SHANNON_APPLICATION but it will not be available on the new terminal windows because is a new session.

Maybe a better way to handle this is creating an .bashrc_shannon file and load it with source or something like that (dunno so much about bash)

[jorgecuesta]

The warning on Step 4.5 probably could be better and use something like: echo -e "127.0.0.1\tanvil\n127.0.0.1\trelayminers" | sudo tee -a /etc/hosts

[jorgecuesta]

There is something on Step 5.1 that is weird to me, I can send a relay, and then the next one fail, the next one works, the next one fail and so on... Please check the image:

also checking the Grafana dashboard I just see as expected 3 relays, because it was successful only 3 times on my tries.

[jorgecuesta]

Why Step 5.1 send relay to http://localhost:42069 that is running inside of the cluster if on steps 4.5 & 3.5 we are required to start AppGateServer and RelayMiner locally (on the bash)

[Olshansk]

Got some feed from another individual which I capture below.

Going to tackle everything next week but just aggregating it all in one place first.

In addressing tutorial feedback, challenges due to complexity in the pocket universe terminology were highlighted. Clarity on terms like Shannon and relay is suggested for better understanding, aiming to simplify the content for newcomers. Streamlining the onboarding process by emphasizing key concepts early, particularly the significance of relaying, could enhance clarity for beginners.

Transitioning to community engagement strategy, users are encouraged to engage on platforms like the Cosmos Hub forum to gain insights into their needs. This approach can facilitate the identification of relevant issues faced by node operators within the cosmos community, promoting a greater understanding of user perspectives and challenges.

Concerning improving communication, a need for clearer problem statements regarding contributions to the cosmos community was noted. Recommendations include defining challenges tackled and seeking input from active forums, fostering ecosystem exploration for potential solutions. Drawing attention to this lack of clarity could lead to more effective communication and solution development within the community.

Overall, the feedback loop suggests a desire for refinement in content delivery and communication strategies within the cosmos community. Addressing complexities, streamlining content for new participants, engaging users actively, and refining problem statements can collectively enhance user experience, foster community growth, and promote collaborative problem-solving within the cosmos ecosystem.