Presenting information is really important. You need to start practicing giving demos.

During this module, you must attend at least one demo session, and give at least one demo. We recommend you come to more, and give more. But you are required to do at least one. Your demo can be on anything you want. You can give this demo in any sprint.

There are demo sessions every Tuesday evening and Friday morning. They are advertised on Slack.

Aim for a 5 minute demo. But your demo must be at least 1 minute and at most 10 minutes long. Check out our guide about presenting.

You can present anything you want. If you’re stuck for ideas, some examples:

• Explain a term you have learnt and show how it works
• Tell us about a blocker you experienced and how you tackled it
• Show something you have made
• Show a tool that assists your learning
• Tell us about your dream job and how you will get there
• Teach us something about one of your hobbies

You will need to attach a screenshot when submitting your Step for this Module. Make sure to take a screenshot of you presenting on the call, showing that one of the following members of CYF staff was on your call and gave you feedback:

• Daniel Wagner-Hall
• Karen Klein
• Colin Farquhar
• Poonam Rajput
• Léon McGregor

If you are not available during any of the demo times, please message on Slack to arrange an alternate time.

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 you to prepare for technical interviews when you may need to code in front of other people or explain your solution to a problem.

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

Submission & Review

You well get feedback from the volunteer during the session. If there are specific topics you would like to receive feedback on then let them know at the start of the session so they know what to focus on.

Link to the coursework

https://www.codewars.com/collections/cyf-data-flows-sprint-3-mandatory

Why are we doing this?

Every week, you need to complete all of the katas in the collection. If you have extra time, you can do extra katas at random on CodeWars.

Spend at least 20 minutes per kata, find time at least three times a week to complete this.

Find the Collection called “CYF Data Flows | Sprint 1 | Mandatory” on the CodeYourFuture account.

Check your Codewars completion status via the Codewars Progress Checker.

Maximum time in hours

2

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 Book a pair programming slot from the available pairing appointments in the CYF Pair Programming Slack Canvas

How to submit

Fork the repo to your own GitHub account Make regular small commits with clear messages When you are ready, open a Pull Request to the CYF repo Make sure you fill in the PR template provided

How to review

Share a link in the form https://codeyourfuture.github.io/Codewars-Progress-Checker/#YOUR_CODEWARS_USERNAME.

You can obtain the link from the browser location bar after submitting your Codewars username on the Codewars Progress Checker page.

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 so it’s a good idea to practice them. 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 develop these skills by playing a game called The Bandit.

There are many levels, and many more games after The Bandit, but your goal is to get to Level 20 by the end of this module.

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 for this exercise.

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.

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

Submission & Review

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.

Why are we doing this?

Code Your Future believes in collective intelligence, which focuses on openness and sharing. This assignment will allow you to support your peers and learn from each other.

Review your Teamwork Project team members’ LinkedIn profiles and provide constructive feedback.

Consider the information added to their profile, their photos, their transferrable skills, if you can spot any grammar or spelling mistakes, what they’ve posted recently and how they are interacting on it.

When giving feedback, remember that this is an important moment to give your peer a present.

• Describe what you can see/evaluate on their LinkedIn page
• Explain why you think it is good with a clear example
• Explain the impact of it, either positive or negative
• Have a conversation about it

Maximum time in hours

1

Submission & Review

• Share the screenshot of your feedback on this issue.
• If you provided feedback in person, write it down and add it as a comment on this issue.

Link to the coursework

https://curriculum.codeyourfuture.io/

Why are we doing this?

If you are confident you have finished the course (i.e. you meet the Success criteria for all modules), you should step back and think about what you want to do next.

If you are not sure, you should talk to people! The whole community (volunteers, graduates, other trainees) may all have interesting and useful perspectives.

If you are really eager to get a job as a software engineer, you should apply for the Piscine. Read through the Piscine’s prep. You must be enrolled as a trainee to apply for the Piscine. If you are not a trainee, you should enrol now.

If you are excited about a job in tech, but don’t think software engineering is the role for you, that’s totally fine! Consider the Tracks for jobs after ITP. You must be enrolled as a trainee to join these tracks, and they only run when there are jobs available.

If you are not eligible to enrol as a trainee, for instance because you live too far from a Code Your Future class, consider other schools that may be able to help.

If you have some spare time (e.g. while waiting for the Piscine or a track), we recommend you practice your skills. Do Codewars exercises, build websites that do interesting things, work on projects that will help you practice what you’ve learned. If you’re really confident in your skills, you may want to follow one of the self-study tracks.

It’s always more important that you understand what you know really well, than that you understand lots of things. If in doubt, we always recommend you revisit prep and exercises you’re not sure about, or work on projects to get more practice.

Level 400

For level 400, you should work in the repo of your partner from level 200.

Before writing any new code, look at their level 300 implementation.

Compare their implementation to yours. Think:

1. How is it different?
2. What do you prefer about your implementation?
3. What do you prefer about their implementation?
4. What did you learn that you didn’t know before?

They should do the same with your repository.

Have a discussion about your answers to these questions. In class, together you should give a 3 minute talk about your conclusions.

Refactoring

Feel free to change anything in your codebase which you think will make it easier to work with, or to build new features.

Have your partner review any changes you have, and make sure they understand them.

Adding new functionality

Level 400 is about expanding beyond one TV show.

Until now, your site has only showed information about the episode of one TV show.

But TVmaze has information about lots of TV shows, all in the same format.

We want to display any of them.

Requirements

1. Add a select element to your page so the user can choose a show.
2. When the user first loads the page, make a fetch request to https://api.tvmaze.com/shows (documentation) to get a list of available shows, and add an entry to the drop-down per show.
3. When a user selects a show, display the episodes for that show, just like the earlier levels of this project.

You will need to perform a fetch to get the episode list. 4. Make sure that your search and episode selector controls still work correctly when you change shows. 5. Your select must list shows in alphabetical order, case-insensitive. 6. During one user’s visit to your website, you should never fetch any URL more than once.

Screenshot of minimal version

Note: Provided your project meets the above requirements, it can look however you want.

Here is one example layout.

Level 500

For level 500, you must switch back to your original codebase.

You must have merged someone else’s level 400 implementation.

Once again, compare their implementation to yours. Think:

1. How is it different?
2. What do you prefer about your implementation?
3. What do you prefer about their implementation?
4. What did you learn that you didn’t know before?

Have a discussion about your answers to these questions. In class, together give a 3 minute talk about your conclusions. Do this in small groups so you don’t spend hours doing this.

Refactoring

Feel free to change anything in your codebase which you think will make it easier to work with, or to build new features.

Have your partner review any changes you have, and make sure they understand them.

Adding new functionality

Level 500 is about adding a front-page which lets users select (and find) shows from your shows list.

Requirements

1. When your app starts, present a listing of all shows (“shows listing”)
   1. For each show, you must display at least name, image, summary, genres, status, rating, and runtime.
2. When a show name is clicked, your app should:
   1. Fetch and present episodes from that show (enabling episode search and selection as before)
   2. Hide the “shows listing” view
3. Add a navigation link to enable the user to return to the “shows listing”
   1. When this is clicked, the episodes listing should be hidden
4. Provide a free-text show search through show names, genres, and summary texts
5. Ensure that your episode search and episode selector controls still work correctly when you switch from shows listing to episodes listing and back
6. During one user’s visit to your website, you should never fetch any URL more than once.

Screenshot of minimal version

Note: Provided your project meets the above requirements, it can look however you want.

Here is one example layout.

Link to the coursework

https://github.com/CodeYourFuture/Codewars-API-Project

Why are we doing this?

Let’s play with grabbing some data from an API and displaying it on a website. We will be using the the Fetch API to make requests to the Codewars API and the Web Components API to display the data we get back.

Maximum time in hours

0

How to get help

General advice on asking for help can be found on the curriculum pages. You can always share your blockers in your class channel and get help from your colleagues. Your mentors track trainees’ progress through the set katas in a very similar way - why not ask them for advice?

Submission & Review

Fork the coursework repo to your own GitHub account. Make regular small commits with clear messages. When you are ready, open a Pull Request to the CYF repo. Make sure you fill in the PR template provided. A volunteer will review your submission and send you feedback.

Link to the coursework

https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/HammockDrivenDev.md

Why are we doing this?

This video is from a conference in 2010 and talks about a different approach to problem solving. The link above will take you to a transcript.

All the way through this course, we are trying to teach you one Big Idea: programming is problem solving.

We never want you to have no problems on this course! We want you to find problems and then solve them. The more problems you have, the better you are doing.

Maximum time in hours

0

Submission & Review

There is no submission step for this task, but if you have any comments or questions you can share them in your Slack channel.

Link to the coursework

https://github.com/CodeYourFuture/Module-Data-Flows/tree/main/challenges

Why are we doing this?

The concepts you have been learning about so far can be applied in many different situations. Often you will need to combine them, for example writing tests to ensure you are retrieving the correct data from an API. These exercises will give you further opportunities to develop these skills.

No time given as this is a stretch goal.

Maximum time in hours

0

How to get help

General advice on asking for help can be found on the curriculum pages. You can always share your blockers in your class channel and get help from your colleagues.

Submission & Review

Fork the coursework repo to your own GitHub account. Make regular small commits with clear messages. When you are ready, open a Pull Request to the CYF repo. Make sure you fill in the PR template provided. A volunteer will review your submission and send you feedback.

Extra options

Do not do any of these until you have completed level 500!

Here are some ideas for consideration for further work:

1. Add cast listing to your show listing, http://api.tvmaze.com/shows/1?embed=cast
2. Add cast listing to your episode listing, http://api.tvmaze.com/shows/1?embed=cast
3. Allow clicking a cast member to present a view of all shows the person has appeared in http://api.tvmaze.com/people/1/castcredits

• Linking those back into your episodes view of each show.

4. Truncate long summaries and provide a “… read more…” control to reveal more.
5. Allow the user to choose to have the show list sorted by rating (highest rated shows first)
6. Have your search support start-of-word search, or other search types.
7. Make the browser’s back and forward buttons navigate through your changed views (see History.pushState()).
8. Allow user to mark “favourite” shows
9. Allow user to store notes on each episode
10. Use local storage to cache the above, and perhaps also to cache episode lists
11. Paginate through results with a “load more” button - don’t load 100s of episodes at a time.
12. Experiment with infinite scroll
13. Responsive design
14. Style your page to fit the theme of the show (colours, typography, background images, etc). Commit to one show to do this.