Objectives

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

Objectives

Link to the coursework

https://github.com/CodeYourFuture/Module-Data-Flows/tree/main/Sprint-1/destructuring

Why are we doing this?

Destructuring is very useful and used a lot in React. Both array and object destructuring are worth exploring.

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.

Anything else?

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

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://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.

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 20 by the end of this module.

Try to get to at least level 10 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.

Objectives

• Plan and author a technical document
• Edit a technical document for clarity and correctness

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://github.com/CodeYourFuture/Project-TV-Show

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 😄

All the rest of the tickets for this project are in the TV Show Project repo. Look there to find out what to do.

Maximum time in hours

6-8 per sprint

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?

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.

Pick one piece of programming you’re doing (we recommend a codewars kata) and pair up with a volunteer to work on it together.

See the mentored pair programming guide for guidance.

Book time with a volunteer using one of the Scheduling links in the #cyf-pair-programming slack channel’s canvas. If there are no available times, please post in #cyf-pair-programming.

Remember, as a learner, you will need to explain your thought process, plan out what to do, write the code and check it works

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 learners to prepare for technical interviews when they’ll need to code in front of other people.

Acceptance criteria

• You have pair programmed on a piece of programming with a volunteer for at least one hour this sprint.

Objectives

• Talk aloud when thinking about a problem.
• Write code in front of someone else.
• Analyse your strategies for solving problems in code.

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.

Level 0

The goals of level 0 are to:

• Create a GitHub repository with the starter scaffolding in-place.
• Deploy your repo to Netlify.
• Make sure whenever you push changes your Netlify site will be updated.

Create your repository

1. Go to https://github.com/CodeYourFuture/Project-TV-Show
2. Click on the green button: Use this template.
3. Name your new repo exactly this: Project-TV-Show
4. Do not enable Include all branches
5. Click the final green button Create repository from template

Deploy your site

1. Follow the guide to deploy your site to Netlify.
2. Configure your site for auto-deployments.
3. Ensure your Netlify site is named exactly cyf-USERNAME-tv.netlify.app where USERNAME is your GitHub username.

Get set up on your laptop

1. Clone your repository
2. Open your repository in VS Code
3. Open the index.html page in Chrome
4. Make sure in Chrome you can see the text “Got 73 episode(s)” in red. If you can’t, something has gone wrong.
5. Edit index.html to include your name and github username in the page title instead of “(My Name (My GitHub username))”.

Push your changes

1. Commit your changes to your index.html to your git repository (with a clear commit message).
2. Push your changes to your GitHub repository. Make sure they show up on GitHub.
3. Ensure your updated site has been deployed to Netlify.

Completion criteria

You have completed level 0 when:

• You have a GitHub repository called Project-TV-Show which is not a fork of this repo.
• The index.html page on your GitHub project contains your name and GitHub username.
• Your project is deployed to Netlify at cyf-USERNAME-tv.netlify.app.
• Your deployed project has your name and GitHub username in its title.

Level 100

For level 100, we are going to display information about every episode of a single TV show.

Requirements

1. All episodes must be shown
2. For each episode, at least following must be displayed:
   1. The name of the episode
   2. The season number
   3. The episode number
   4. The medium-sized image for the episode
   5. The summary text of the episode
3. Combine season number and episode number into an episode code:
   1. Each part should be zero-padded to two digits.
   2. Example: S02E07 would be the code for the 7th episode of the 2nd season. S2E7 would be incorrect.
4. Your page should state somewhere that the data has (originally) come from TVMaze.com, and link back to that site (or the specific episode on that site). See tvmaze.com/api#licensing.

Screenshot of minimal version

Note: Provided your project meets the above requirements, it can look however you want. Do the simplest thing to begin with.

Here is one example layout.