Link to the coursework

https://github.com/CodeYourFuture/JS3-Module-Project

Why are we doing this?

We’re doing this project to gain experience consuming data from an API and displaying it in a visually appealing way in the browser - making it easy for our users to understand.

This project should be done in a pair-swapping style as described here. This will be a great experience as it’s actually similar to a real-world working experience where a team of developers work on a shared code base 😄

In this sprint, you will need to complete up to and including Level 100. All of this work should be done in your own repo.

Maximum time in hours

6

How to get help

Share your blockers in your class channel https://programming.codeyourfuture.io/guides/getting-help/asking-questions/

How to submit

Add a comment to this (cloned) issue with a link to:

• Your GitHub repository
• The other person’s repository your changes are merged into
• Your site hosted on Netlify (should be something like cyf-USERNAME-tv.netlify.app)

Anything else?

While doing this project, you should think about writing “clean” code - One way to do this is to think about what future readers of your code will be thinking 🤔 If they didn’t have much context, will they be able to easily understand what the code is doing? Would it be easy for them to make changes to the code?

Why are we doing this?

Code review is an essential part of self-evaluation. Get a code review for a piece of work; then reply and iterate on this feedback.

We’re using GitHub Labels in our Code Review process. In order for a volunteer to review your pull request, you will need to add a “Needs Review” label to it.

• Open your pull request
• In the right sidebar, click Labels, then select “Needs Review”

Take a look at our code review process from beginning to end. Let us know if you have any questions or need help!

You can also use any solutions to review your code independently.

Maximum time in hours

1

Instructions

1. Pair up with a volunteer and work on a kata together
2. As a trainee, you will need to explain your thought process, plan out what to do, write the code and check it works
3. Volunteers will need to ask questions to check your understanding, provide guidance if you stuck, give honest and meaningful feedback

🧭 Guidance for volunteers

• Don’t take over! It’s important trainees get used to figuring things out. Provide guidance and assistance but trainees need to struggle to overcome any obstacles with understanding and technical communication
• Give honest feedback. Trainees can’t develop if they don’t receive honest feedback about their progress.
• Ask questions. Sometimes asking a clarifying question can help learners discover errors and often promotes more thoughtful responses.
• Encourage best practices. Reinforce good practices like reading error messages carefully sessions and checking documentation.

Why are we doing this?

Pair programming is an excellent way to develop programming and communication skills. It is often much easier to work through something when working on something 1 to 1. It is also helps our trainees to prepare for technical interviews when they’ll need to code in front of other people.

Acceptance criteria

• You have pair programmed on a kata with a volunteer for at least one hour

Link to the coursework

https://www.codewars.com/users/CodeYourFuture/authored_collections

Why are we doing this?

Every week you need to complete at least three kata. Spend at least 20 minutes, three times a week, on your kata workout.

Find the Collection for this module on the CodeYourFuture account.

You should be able to complete level 6 kata during this module. Make sure to start trying some 5kyu as well.

Maximum time in hours (Tech has max 16 per week total)

1

How to get help

• Join the #cyf-codewars Slack channel
• Read the CYF Codewars docs
• Read Codewars advice from CYFers
• Read Codewars advice from mentors

Remember, after 20 minutes, take a break.

How to submit

Your codewars progress is tracked automatically and is available on the public API. You don’t need to submit it.

How to review

Once you have completed your kata, look at the other solutions in the solutions view. Consider how many different approaches there are. Is there something you would adopt for yourself? Revise your own solution.

Why are we doing this?

This task will get you to really think about the response you get back from an API. Use Chrome Dev Tools to examine the response you get back from the server.

Look at a request in Chrome Dev Tools

In Google Chrome, open dev tools network tab and enter this URL into the browser: http://api.tvmaze.com/shows/82/episodes

Answer the following questions:

1. What’s the status code the server sent back?
2. What HTTP method did the browser use to make the request?
3. What is the request path?
4. What is the first line of the response body?
5. What is the value of the response header called “Content-Type” ?
6. What is the value of the request header called “User-Agent”

Maximum time in hours

.5

How to submit

Share your answers with the other learners on Slack. Did you get different answers to other people? Ask them how they worked them out!

Link to the coursework

https://code.visualstudio.com/docs/introvideos/debugging

Why are we doing this?

For months now we have been building a toolkit to help us write great software. In our toolkit we have:

Specifications, like user stories, acceptance criteria, and Given/When/Then Help us understand what to write and check we’ve written the right thing.

Tests, like unit tests and assertions Help us break down our problems and check our solutions work even when we change things.

Asking questions Help us formally reason through our problems and identify gaps in our mental models.

Playing computer Helps us reason about code with a mental model.

Audits, like Lighthouse Help us identify performance and quality improvements we can make to our code.

And now we can add debuggers to our toolkit.

Debuggers are tools that help us find and fix problems, or “bugs”, in our JavaScript code. They let us step through our code line-by-line while it runs to see what is happening. This helps us find the place where our mental model of the code is different from our implementation. Your browser has a debugger and so does VSCode. You have used a similar program to “step through” code in your prep work.

Key reasons we use debuggers:

• See what’s happening inside functions
• Check if variables have expected values
• Pause execution and step through slowly
• Find exactly where mistakes happen

JavaScript debuggers give control over execution flow to methodically test and fix bugs. Watch the first four minutes of the video and then explore the VSCode Debugger on your machine.

Maximum time in hours

.25

How to get help

AI can help you here. Code along with AI so it has the context and ask it when you get stuck. Use this starting prompt:

Act as a friendly, supportive, knowledgeable programming mentor. I am learning the debugger in VSCode.Talk me through the interface step by step. Provide a simple example of a Node script with a bug in it and walk me through finding the bug by setting breakpoints with the debugger. Don’t tell me what the bug is. When I get stuck, answer my questions in CEFR B2 English meant for an adult professional speaking in a second language. When I ask for hints, give me useful pointers. Say okee dokee if you understand and begin your walkthrough.

Remember to use careful prompting when you don’t understand, so you get real learning out of the exchange. Say things like:

The execution is paused and it shows me that i is undefined and this is undefined, but I don’t understand why it says that. Can you explain this to me?

I made you a bot specifically for this coursework, right here: https://poe.com/CYF_Learn_Debugger

Remember you should always ask your friendly humans in Slack when you get really stuck.

Link to the coursework

https://overthewire.org/wargames/bandit/

Why are we doing this?

Basic Linux skills are essential for roles in Cloud, DevOps, Cyber, and SRE. Junior Cloud and DevOps roles are growing in the industry; React and fullstack junior roles are becoming more scarce. So it’s a good idea to practice Linux skills to make yourself more employable. At the basic level this means using a computer from the command line instead of a GUI. You will learn to use commands to move from folder to folder, to open and edit files, and to get info like the size of a file or its location. At CYF we build this skill by playing a game called The Bandit.

Your goal is to get to Level 30 by the end of this module.

Try to get to at least level 21 this week.

Maximum time in hours

1

How to get help

Work through the puzzles together in #cyf-over-the-wire

Don’t share solutions in this channel, or you steal from others the opportunity of learning.

How to submit

There is no submission step. However, to apply for some roles and some courses (like CYF+ ) you must demonstrate these skills, so it would be a good idea to learn them.

Anything else?

Here’s a ChatGPT prompt you can use to get the best, most helpful learning experience:

Please act as a friendly, warm, straightforward technical mentor. You are an experienced Site Reliability Engineer who uses the terminal regularly and understands all shell commands in bash. You can explain clearly, using English mostly at CEFR B2 level, how to execute shell commands and how to navigate Linux file systems. We will be playing The Bandit, Over the Wire, shell game together. I don’t want you to give me all the answers. I want you to walk me towards the answer, helping me to find out and learn Linux commands, explaining clearly what is happening as we go. Please answer my questions carefully and do not offer code solutions, just explain in English the approach I should take and then review the commands I suggest to you. Say okee dokee if you understand.

And remember: every time ChatGPT offers code you must write “Is this valid” before you continue. ChatGPT makes up invalid code all the time.

Link to the coursework

https://github.com/CodeYourFuture/Module-Data-Flows/tree/main/fetch/programmer-humour

Why are we doing this?

We’re making a very tiny application, the smallest one you can think of, that fetches from an API and shows something on a page. You should do this many times. Make ten more of these if you finish this early. Make it as simple as possible.

Remember: always do the simplest thing that can possibly work.

Maximum time in hours (Tech has max 16 per week total)

1

How to submit

1. Fork to your Github account.
2. Make a branch for this project called feature/xkcd
3. Make regular small commits in this branch with clear messages.
4. When you are ready, open a PR to the CYF repo, following the instructions in the PR template.

There are several projects in this repo. Make a new branch for each project. This might feel challenging at first, so this is a good problem to bring to class to work on in groups with mentors.

Don’t make one giant PR with all your work in for the module. Make a separate PR for each assignment.

How to review

1. Complete your PR template
2. Ask for review from a classmate or mentor
3. Make changes based on their feedback
4. Review and refactor again once the coursework solutions are released.

Link to the coursework

https://github.com/CodeYourFuture/Module-Data-Flows/tree/main/fetch/array-destructuring

Why are we doing this?

Array destructuring is very useful and used a lot in React.

https://www.freecodecamp.org/news/array-destructuring-in-es6-30e398f21d10/

Maximum time in hours (Tech has max 16 per week total)

1

How to submit

1. Fork to your Github account.
2. Make a branch for this project called feature/destructuring
3. Make regular small commits in this branch with clear messages.
4. When you are ready, open a PR to the CYF repo, following the instructions in the PR template.

There are several projects in this repo. Make a new branch for each project. This might feel challenging at first, so this is a good problem to bring to class to work on in groups with mentors.

Don’t make one giant PR with all your work in for the module. Make a separate PR for each assignment.

How to review

1. Complete your PR template
2. Ask for review from a classmate or mentor
3. Make changes based on their feedback
4. Review and refactor again once the coursework solutions are released.

Coursework content

1. Set up a LinkedIn profile if you don’t already have one.
2. Find 3 LinkedIn profiles that you think are good and reflect on why they are good or effective.
3. Think about what you can use/adapt from these people’s LinkedIn profiles to yours.

Estimated time in hours (PD has max 4 per week total)

0.5

What is the purpose of this assignment?

To create a presence on LinkedIn and to get familiar with its workings.

How to submit

• Share the link to your Linkedin profile on this issue.
• Share the list of things you would like to use/adapt on your profile as a comment on this issue.

Link to the coursework

https://developers.google.com/tech-writing/one

Why are we doing this?

Every engineer is also a writer.

This collection of courses and learning resources aims to improve your technical documentation. Learn how to plan and author technical documents. You can also learn about the role of technical writers at Google.

Take the prep course before class and do the in-class workshop… in class!

Maximum time in hours (Tech has max 16 per week total)

2

How to get help

Arrange a mid week study session to work on this course together. Can you invite a native speaker to support you? What skills do you already have in your group? Has someone worked as a writer, teacher, translator, or journalist?

How to submit

There’s no submission step. Just use the course to improve all your technical writing, readmes, and docs as you progress.

Link to the coursework

https://programming.codeyourfuture.io/data-flows/success/

Why are we doing this?

🔑 The most important thing is that you are secure in your understanding.

At the end of the course, we will expect you to build novel applications using your understanding. If you cannot build things, we cannot put you forward for jobs. It is in your personal interest to make sure you have properly understood this module.

To progress to the next module you need to meet the success criteria for this module. How will you as a cohort meet the module success criteria? Discuss it in your class channel and make a plan together.

Maximum time in hours

.5

How to get help

Discuss with your cohort. Support each other.

How to submit

At the end of your module you will need to submit your own work in the CYF dashboard. This means things like pull requests you have written sent from your GitHub account, and Google Docs you have written.

What you need to submit is listed on the success page for the module.

Remember - the goal is your understanding. If you are not confident you could delete and re-do the work you’re submitting easily, you should take more time to revise the topics. It’s more important that you understand the work, than that it gets done quickly.