-
Notifications
You must be signed in to change notification settings - Fork 2
Cleanup suggestions #5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
- ✅ Isolated from your host system | ||
|
||
## Local Setup | ||
### Local Setup |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
did you look at this rendered? H2s being underlined have a nice visual distinction isolating their content. These core "setup" sections should be h2s to make their content very clear where it is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's more important to be explicit that the ### DevContainer Setup
and ### Local Setup
are both options under the ## Setup Dev Environment
versus both being steps that need to be followed. If they're H3's, a learner can look at the outline and understand the high level page structure as:
- Setup Visual Studio Code
- Setup Dev Environment
- Verifying Setup
- Troubleshooting
- Next Steps
Since we haven't decided if this will be in the academy, read from github, or cloned locally, it feels weird to break semantic html patterns just for styling.
That said, I do agree the raw file and preview both needed visual distinction, and personally kept wanting to have AI add an emoji to each H2 & H3. So I get it if you decide to make them H2, we'd just want an inline way to be explicit that they're not both required steps.
It could be by making the headers something like "## Recommended DevContainer Setup" & "## Alternative Local Setup" and removing the "## Setup Dev Environment"
- Make server files executable | ||
- Configure VS Code extensions | ||
- Set up port forwarding for MCP servers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to add instructions or solution notes on how a learner can verify they setup correctly?
#### **Steps:** | ||
|
||
**Download and install:** | ||
|
||
- Go to [code.visualstudio.com](https://code.visualstudio.com/) | ||
- Download the installer for your operating system | ||
- Follow the installation instructions | ||
1. **Clone the repository**: | ||
<!-- todo: minor discussion: these "clone" instructions should match the "clone" instructions in the DevContainer setup. There, it clones from inside VSCode terminal with different commands, this assumes use of a generic terminal. Maybe use the instructions for inside vscode, so there's no one fighting with `code .` not working? Those these are simpler and what most devs would do 🤷 --> | ||
|
||
**Required VS Code Extension for DevContainer Setup:** | ||
```bash | ||
git clone https://github.com/bitovi/mcp-training.git | ||
cd mcp-training | ||
``` | ||
|
||
- **Dev Containers** - [marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) | ||
Then open the folder in VS Code: `code .` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[minor discussion]
These "clone" instructions don't match the "clone" instructions in the DevContainer setup. There, it clones from inside VSCode terminal with different commands, here it assumes use of a generic terminal.
Initial recommended changes, including minor discussion comments that should be implemented or removed.
Big changes are:
Common Setup Steps
were only used inLocal Setup
which was confusing.