Open AlinaTaoRao opened 2 years ago
gelilaa
commented
2 years ago @AlinaTaoRao could you move your check-in to a comment in this issue? The issue will be easier to understand if you have only your study plan in the main description and your check-ins + our discussions in the comments.
Let us know what you have covered in your study plan from the list of suggested-study
for reference check this issue
AlinaTaoRao
commented
2 years ago AlinaTaoRao
commented
2 years ago @gelilaa Yeah, sure. I've done what you asked for. Please let me know whether I did it right.
colevandersWands
commented
2 years ago Please let me know whether I did it right.
99.9% right! We're just in week 1, not week 2
colevandersWands
commented
2 years ago npm run spell-check conflict: code ELIFECYCLE
Give a try with these steps, that should help. Let us know if it doesn't
pull request conflict
100% what you should be struggling with these weeks! perfect. The best way to deal with conflicts is to have them all locally on your computer and only to push code once there are no conflicts. You can do this by following this workflow:
main to your local computermain to your branch locally - now you'll get conflicts. conflicts are much easier to resolve locally using VSCode than on GitHub (some conflicts can only be solved locally)Now you'll certainly have some troubles resolving your conflicts locally, that's normal. So let us know when that happens and someone will be able to help
colevandersWands
commented
2 years ago tracking/manage my issue
Working with issues is one part learning the GitHub interface, and one part building discipline in your work habits. Both of those will take time, and there's plenty of time to practice in the coming modules as well.
tracking a issue from someone other's(if I have the same question/problem)
The best tip for this is learning how to use the search feature for issues in GitHub. Besides that it's also everyone's responsibility to use helpful labels and to make sure they aren't opening many issues with the same question - there should only be one issue per topic and it should be easy to find.
If you start seeing many issues with the same question you can always mention the other issue in a comment and suggest closing one. This is common enough that it's even in the GitHub docs
AlinaTaoRao
commented
2 years ago @colevandersWands Thanks for your advice. I'll try.
AlinaTaoRao
commented
2 years ago Week 2
development strategy: analysis, strategy formation. How to set a development strategy of a website including several webpages. I need a good example.
about git branch
colevandersWands
commented
2 years ago How to set a development strategy of a website including several webpages. I need a good example.
My tip for planning one is to think in user stories and priorities (must, could, should) instead of in pages. Write a development strategy for all the must-have user stories, and just mention in each task's issue which page it should be a part of. This way your website will be gradually grow one important feature at a time, and each page will grow larger only when an important feature is added to it.
Next module you'll get a chance to build 2 multi-page websites.
colevandersWands
commented
2 years ago analysis, strategy formation.
not much to say here but time and practice, this will be the main focus of Agile Development - how to create, follow and adapt a development strategy. This is not easy and it's a never-ending learning process. When you reach Separation of Concerns and beyond you'll learn more about how to fit JS into your strategies
AlinaTaoRao
commented
2 years ago Thanks for your advice.
Study Plan
Module02 workflows-Suggested Study
Learning Objectives
[ ] - 🥚 Git Remote/Local Connection: You can create a local git repository, commit changes, connect a remote repository and push changes to the remote.
[ ] - 🥚 Linting: what is it? why does it matter? can write CSS & Markdown that passes a linting check
[ ] - 🥚 Git Branching Workflow: You can manage your work locally using branches: pull remote changes -> create a new branch -> push the branch to the remote repository -> open a PR with passing Continuous Integration checks -> merge changes to main/master.
[ ] - 🥚 Command Line Interface (CLI): You can navigate a directory, manage folders/files, make small changes in a file using nano/vim, and much more (list coming soon).
[ ] - 🥚 NPM: You can install npm dependencies and use npm scripts (dev, lint and format)
[ ] - 🥚 Browser + DevTools: You can open a local HTML/CSS project in your browser and inspect the elements, emulate different devices, and inspect the source
[ ] - 🥚 File Extensions: You can identify all of the languages covered at HYF and give the correct file extension. (You don't need to know the languages, just recognize them!)
[ ] - 🥚 VSCode: You can complete these workflows in VScode, and can use keyboard shortcuts when possible:
[ ] - 🐣 Touch Typing: You can write a README without looking at your keyboard to find any letters, numbers or special characters. (slowly is ok!)
[ ] - 🐣 User Stories: Given pictures of a website, you can describe the page with user stories: As a type of user I can do something so that something good happens.
[ ] - 🐣 Planning and Collaborating: You can comfortably complete these steps of the Planning and Collaborating process described in the Student Guidebook:
[ ] - 🐣 Development Strategies: You can work as a group to follow the steps in a development strategy and reconstruct a web page when the code is provided.
[ ] - 🐣 Atomic Commits & Feature Branches: You can organize your development process using small single-purpose commits on feature branches. You will learn to develop each of these features on a separate branch and to merge it to main/master on GitHub when the feature is complete.
[ ] - 🐣 GitHub: You can create new repositories, turn on GitHub Pages, connect the repository to your local computer, push/pull different branches, and pass Continuous Integration checks for code linting and validation.
[ ] - 🐥 GitHub Collaboration: You can collaborate in a single repository and contribute a markdown file. This includes: creating a new branch, creating and editing a file on that branch, sending a pull request, addressing any requested changes, and reviewing+merging a classmate's pull request. (this can all be done from the GitHub UI)
[ ] - 🐥 Code Review: You can use a code review checklist in a Pull Request to check a classmates code before merging.
Week 1
Check-In
I Need Help With:
What went well?
What went less well?
Lessons Learned
Sunday Prep Work