day-plan

🔖
  1. Induction
  2. Energiser
  3. Practice breaking down a requirement
  4. Kickoff
  5. Morning break
  6. Group Project: Shared Bookmarks
  7. Development
  8. lunch
  9. Development
  10. Afternoon break
  11. Development
  12. Demo
  13. Wrap

Register

Induction

Welcome to the Piscine.

Before you came to class today, you should have completed the prep and attended a briefing session. If you haven’t done these things, it’s time to leave. Thanks, and try again next time.

If you have done the prep, you’re in the right place. Please make sure you have signed the register. Sign it as soon as you come in. The register isn’t just for attendance rules; we need to know who is in the building if there’s a fire, so please don’t sign in for anyone else.

Today you will kick off your first team project. Everyone will also give a demo about something they did before the Piscine. At the end of the day, we will wrap and people are welcome to stick around to socialise.

But first, let’s get to know each other. Stand up and find someone you don’t know. Introduce yourself and tell them one thing you are looking forward to learning in the Piscine.

Zip Zap Boing!

Learning Objectives

👉 Zip Zap Boing Gameplay

In a single group, have participants stand in a circle. This game works best with 5 or more players and must be played in person.

Make your zipzapper

Press your hands together in front of you, palms facing each other to make your energy zipzapper. Crackle! Feel the energy between your hands!

Point your zipzapper to the person next to you, and say “Zip”.

Point your zipzapper at anyone in the circle and say “Zap”.

Now, put both hands up in the air, jump, and say “Boing!” This reverses the direction of play.

Play the game

One person starts by saying “Zip” and pointing to another person in the circle. That person then has three options:

  1. Zip the person on your left or right.
  2. Zap anyone in the circle.
  3. Boing the energy back to them, which reverses the direction of play.

The game continues with players reacting quickly to keep the energy flowing.

If someone hesitates or makes a mistake, they’re out.

Evolve the game

Add variations to increase complexity and challenge
  • Round 2: Add a new word “Zop” which skips the next person in the circle
  • Round 3: Players must use a different gesture for each word (e.g., point for Zip, thumbs up for Zap, jazz hands for Boing)
  • Round 4: Increase the speed - anyone who takes more than 2 seconds to respond is out

Practice breaking down a requirement

Learning Objectives

In team projects, it’s important that we break large tasks down into small tasks.

It’s also important that we can coordinate across our team. This requires having shared understanding of who will do what, and how the work we do will interact.

Finally, it’s important that we arrange tasks so your team isn’t blocking yourselves, so you’ll want to find ways of working on tasks in parallel.

We will practice this together on the two of the requirements of the project:

  • Selecting a user must display the list of bookmarks for the relevant user
  • Submitting the form adds a new bookmark for the relevant user only

To complete these requirements we’d need to build most of the project! So we’ll focus on simplified versions of these requirements:

  • When the page loads, display one bookmark from User 1’s stored agenda
  • When clicking a button, add a hard-coded🧶🧶 hard-codedHard-coding refers to when developers directly write values or data into code, often replacing variables or user input with static values. bookmark to User 1

To complete the full requirements, you can build on the tasks we decide on today.

✍️Breaking down tasks

  1. Set a timer for

  2. Individually, write down all the tasks that would be needed to complete the simplified requirements above

  3. After the timer is up, go around the group and discuss the tasks you came up with. One of the volunteers should write the tasks on a whiteboard

  4. Volunteers, discuss any that you think might be missing or that might need breaking down further

Our goal right now is to make sure we refine the tickets so that two different people could be working on tasks at the same time.

✍️Unblocking group work

  1. Set a timer for

Work out what blockers would limit the tasks so that only one person could be working at a time.

Define additional tasks that can be done first to unblock parallel working.

Discuss as a group how we can unblock parallel work.

Tips for volunteers

The big insight we’re looking to drive here is that agreeing a data format in advance means we can work in parallel.

Kickoff

Learning Objectives

At CYF we work in small teams to deliver working software with tests.

💡tip

It’s important that software works and the people can use it

🎯 Goal:

You will be split randomly into groups of 2-4.

🕹️Kickoff

  1. Review the project docs.
  2. Setup your project board.
  3. Break down the project into tasks.
  4. Assign tasks to team members.
  5. Agree on a deadline for each task.

💡 Tips:

  • Review the project docs before kickoff.
  • Keep it simple. Identify the simplest way you can meet the criteria.
  • Break it down. Split the work into small tasks on a board.
  • Communicate. Make sure everyone knows what they are doing.
  • Set deadlines. Agree on when you will have each task done.

Morning Break

A quick break so we can all concentrate on the next piece of work.

🔗 Group Project: Shared Bookmarks

Project: Shared Bookmarks

As developers, we spend a lot of time reading articles on the web and we often want to record useful links to come back to them later. It is fun to share your bookmarks with others so that they can find interesting and useful links too.

Here are some examples of bookmark sites:

Your task is to write code which allows a user to save a link with a short description and share them with others.

You should make a frontend, which displays a list of bookmarked links and the user’s description. A user can create new bookmarks by submitting a form with the URL and the description. You should use HTML and JavaScript only. You should not use CSS. We want to focus on your ability to create the correct logic and not spend time on creating the perfect UI.

Supplied scaffolding

We have supplied a few sample files in the repo to demonstrate how you can define functions in one file and use them from another file. Feel free to use these files in your solution if you want, or to just use them for inspiration for your own solution.

Note that when running locally, in order to open a web page which uses modules, you must serve the directory over HTTP e.g. with https://www.npmjs.com/package/http-server - you can’t open the index.html file using a file:// URL.

We have also provided a storage.js file, which contains four functions to help with data storage. storage.js is a file containing four functions:

  • getUserIds(): when called, returns an array of strings, each of which is a user id
  • getData(userId): when called with a user id string as an argument, returns an array of objects, each of which represents a bookmark that belongs to the user
  • setData(userId, data): when called with a user id string and a data object as arguments, it will store the data for the user. The object should contain information about the bookmark, such as the URL, title and description. The function does not return anything
  • clearData(userId): when called with a user id string as an argument, it will clear any stored data associated with the user id. This is provided to help with development, and is not required in the final code

Note: None of the storage functions perform any validation or de-duplication, so ensure that you are sending the correct data before storing it.

Requirements

You must submit both a link to your GitHub repo, and a link to the deployed website.

Your website must be hosted on the internet, and must be automatically deployed when you merge changes to your GitHub repo.

Your website must include a drop-down to select a user to display information for. When a user is selected, you must display the list of bookmarks for that user. If there are no bookmarks for the user, you should present a message explaining this.

You must not implement any kind of authentication. Just a drop-down to choose which user’s information to display. You must not implement data storage yourself, as we have provided that for you.

After picking a user, your website should display the list of bookmarks in reverse chronological order. For each bookmark, it should display the title and description of the bookmark. The title should be hyperlink to the URL of the bookmark. The timestamp at which the bookmark was created should be displayed.

Your website must include a form with text inputs for the URL and title, a textarea for the description and submit button that allows a user to add a new topic. This form must be accessible, so for example, hitting the Enter key will also submit the topic name, the same as clicking the submit button.

After the new data has been stored, the updated list of bookmarks must be displayed (including the new bookmark) for the relevant user.

Your GitHub repository must contain unit tests which demonstrate that your code works. End to end tests are optional.

Every view of your website must be accessible (i.e. for each user, whether or not they have bookmarks, etc). We will test this by making sure that “Snapshot” mode of Lighthouse gives 100% accessibility for any view we look at.

Rubric

All of the below requirements must be met for the project to be considered complete:

  • The website must contain a drop-down which lists five users
  • Selecting a user must display the list of bookmarks for the relevant user
  • If there are no bookmarks for the selected user, a message is displayed to explain this
  • The list of bookmarks must be shown in reverse chronological order
  • Each bookmark has a title, description and created at timestamp displayed
  • Each bookmark’s title is a link to the bookmark’s URL
  • The website must contain a form with inputs for a URL, a title, and a description. The form should have a submit button.
  • Submitting the form adds a new bookmark for the relevant user only
  • After creating a new bookmark, the list of bookmarks for the current user is shown, including the new bookmark
  • The website must score 100 for accessibility in Lighthouse
  • Unit tests must be written for at least one non-trivial function

Team Development

Learning Objectives

This time is set aside for you to work together as a team to make progress on your project.

Remember: At your interview, you may be asked about any code in your project, not just the code you wrote. You need to understand and be able to explain the code your team mates wrote. Make sure you read their code, review it, and talk to them about it.

Community Lunch

Every Saturday we cook and eat together. We share our food and our stories. We learn about each other and the world. We build community.

This is everyone’s responsibility, so help with what is needed to make this happen, for example, organising the food, setting up the table, washing up, tidying up, etc. You can do something different every week. You don’t need to be constantly responsible for the same task.

Team Development

Learning Objectives

This time is set aside for you to work together as a team to make progress on your project.

Remember: At your interview, you may be asked about any code in your project, not just the code you wrote. You need to understand and be able to explain the code your team mates wrote. Make sure you read their code, review it, and talk to them about it.

Afternoon Break

Please feel comfortable and welcome to pray at this time if this is part of your religion.

If you are breastfeeding and would like a private space, please let us know.

Team Development

Learning Objectives

This time is set aside for you to work together as a team to make progress on your project.

Remember: At your interview, you may be asked about any code in your project, not just the code you wrote. You need to understand and be able to explain the code your team mates wrote. Make sure you read their code, review it, and talk to them about it.

Demo

Learning Objectives

At CYF we expect you to demo your work to the class. You must have many opportunities to practice how to clearly and simply explain your work to others. This is really important for interviews and career success.

⏰ Timekeeper

The timekeeper will keep the groups on track.

Split randomly into groups of no more than 4 people. Mix up your teams. Each person will have 2 minutes to demo their work to the group. After the demo, the group will ask questions or give feedback for 5 minutes. Then the next person will demo their work.

🧑🏼‍🎓 Trainees

1. Demo

You will demo something about your project work this sprint to the group.

You will have 2 minutes to explain what you did and why. It’s ok to show broken code or code that doesn’t work yet. Just make sure your demo is interesting.

2. Feedback

After the demo, the group will give you feedback for up to 5 minutes. It’s smart to suggest what kind of feedback you want by asking some “generative” questions. For example:

  • I wasn’t sure if it makes sense to try X. What do you think?
  • I liked the way I did X, but I know there are other approaches, what did you do?
  • I found X really confusing, did anyone else have the same problem?

💡 Tips:

  • Practice the format of demos before class.
  • Keep it simple. Don’t try to show everything you did. Just show one interesting thing.
  • Keep it short. Two minutes is enough.
  • Explain what you did and why.
  • Show your code.
  • Ask for feedback.

Rubric

These are some criteria we will be using to assess your demo. You must meet 5 of the 6 criteria, and if you skip one we recommend you skip asking a question. This is not an ordered list - you can complete these criteria in any order.

Clearly introduce the topic of the demo.
Someone watching should be able to state the topic of the demo in one sentence. This topic should match how the trainee introduced their demo.

The topic must not be "I will tell you about my project". It must be more specific than a project overview.
Explain what was done
Someone watching should be able to state what you have done in one sentence.
Explain the reasoning behind a choice.
Someone watching should be able to explain why you did at least one thing a particular way (and why it was a better choice than alternatives).
Show relevant code or artifacts (e.g. a website, a ticket, an discussion).
Someone watching should be able to identify at least one artifact of your work. Slides don't count as an artifact.
Stick to your time limit.
You should know how long you have for your demo, and stick to that time. You will be given a warning when you're running low on time.
(Stretch goal): Ask questions.
Someone watching can state at least one question that was asked of the audience that is not "any questions?". The point of this is to engage the audience and get them thinking/caring about the demo. The question should generally be rhetorical - you don't have time to wait for answers.

Wrap

You are done for the day. Take a moment to reflect on what you have learned and achieved.

Stand in a circle and share:

  • 📛 your name
  • 💪🏽 one thing you built today
  • 👷🏾 the task you are going to work on next
  • 🛟 one thing you need help with

Give yourselves a round of applause. Now you have earned your rest. Usually people go for a drink (or a coffee) after class. You are welcome to join and wind down together.