-
Notifications
You must be signed in to change notification settings - Fork 23
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
split Cargo slides #79
Conversation
└── B = "1" X = "2.0.3" | ||
├── X = "2" X = "1.2.14" | ||
└── Y = "1.5" Y = "1.8.5" | ||
``` |
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'm guessing there's some points that would be nice to include here as speaker notes
- X is installed 2 times, at different compatible versions to both A and B (which means bumping deps to a same common version may reduce compile times)
- Resolver may choose a minor patch
A = 1 -> A = 1.0.17
or a major patchY = 1.5 -> Y = 1.8.5
if you don't specify more
Ok, I like having split up the Cargo deck to something a lot more manageable, nice work there. I may be wrong here, but I think the
I will bikeshed this and say it should instead be
|
Nit pick time: We should decide if bullet points always start with an uppercase or lowercase letter. This PR alternates between both and we should pick a style. My vote is for starting all bullet points with uppercase. I'm guessing we're gonna need a style guide at a future point. |
I don't really know about the bullet point style. I like seeing them the same everywhere, and yet once the slides are compiled and rendered by Reveal the uppercase bullet points seem too busy with capital letters almost jumping on top of each other. Meanwhile using lowercase everywhere feels very wrong sometimes, especially when the bullet point has multiple sentences:
|
In English there are two kinds of bullet points:
Versus:
|
@listochkin are you able to get this one wrapped up? |
Now we can pick and choose what part of the deck to present. * Added a dedicated "Cargo" section. * split the deck into 4: * cargo commands and "features" * dependency resolution, different kind of dependencies * cargo workspaces * rust project build time Added some extra info: * Speaker notes for Dependencies deck has a list of different private registry vendors and projects * Workspaces deck has a shell function adapted from the one I use for trainings to set up a new workspace project
I updated the summary page. Also, changed all bullet points to lowercase initials for consistency. Looking back at the original version of slides I completely agree with Raz - capitalization was wild! I decided to keep capitalizing words like Rust, Cargo, C when they are at the beginning of a bullet. However, when they represent commands like Other than cosmetic updates the content is the same. This should be ready for merging. |
As a side note: GH notifications do not work for me as a tool at all. I only saw your nudge after I finished with the code and went to write a note above. Ping me on Zulip if you want to get things bumped up priority-wise. |
What do you propose we put in the Roadmap for a standard training? Is there a "short version" we can give people so they know enough to be able to put simpleDB in a workspace? Or is the exercise enough to teach people that? |
I think "Cargo Workspaces" is the only one I would move to Applied Rust "Using Cargo" deck is mostly for completeness. A trainer is going to show most day-to-day commands to participants anyway, and everything else is in there only if there are further questions from a group (Like: "What are features?" or "Can Cargo do cross-platform builds?"). "Dependency Management with Cargo" and "Rust Projects Build Time" are similar. "Workspaces" deck alone is tiny, and can be shown / shared before the exercise. |
Now we can pick and choose what part of the deck to present.
Added some extra info: