πŸ§‘πŸ½β€πŸ€β€πŸ§‘πŸ½ day-plan

πŸ”–
  1. Energiser
  2. Morning orientation
  3. Teamwork Project
  4. lunch
  5. Study Group
  6. Code Review
  7. Afternoon break
  8. Study Group
  9. Retro

✍🏽 Register

Energiser

Every session begins with an energiser. Usually there’s a rota showing who will lead the energiser. We have some favourite games you can play if you are stuck.

  1. Traffic Jam: re-order the cars to unblock yourself
  2. Telephone: draw the words and write the pictures
  3. Popcorn show and tell: popcorn around the room and show one nearby object or something in your pocket or bag and explain what it means to you.

🎑 Morning orientation

Learning Objectives

Planning during the week

🧭 During the week, create a post on Slack and get some people to take on the roles of facilitator and timekeeper. Nominate new people each time.

πŸ‘£ Steps

If you haven’t done so already, choose someone (volunteer or trainee) to be the facilitator for this morning orientation block. Choose another to be the timekeeper.

πŸŽ™οΈ The Facilitator will:

  1. Assemble the entire group (all volunteers & all trainees) in a circle
  2. Briefly welcome everyone with an announcement, like this:

    πŸ’¬ “Morning everyone, Welcome to CYF {REGION}, this week we are working on {MODULE} {SPRINT} and we’re currently working on {SUMMARISE THE TOPICS OF THE WEEK}”

  3. Ask any newcomers to introduce themselves to the group, and welcome them.
  4. Now check: is it the start of a new module? Is it sprint 1? If so, read out the success criteria for the new module.
  5. Next go through the morning day plan only (typically on the curriculum website) - and check the following things:

Facilitator Checklist

  • Check the number of volunteers you have for the morning
  • Check someone is leading each session
  • Describe how any new activities works for the group
  • Decide how best to allocate trainees and volunteers for a given block - most blocks will make this clear

⏰ The Timekeeper will:

  • Announce the start of an activity and how long it will take (check everyone is listening)
  • Manage any whole class timers that are used in an activity
  • Give people a 10-minute wrap-up warning before the end of an activity
  • Announce the end of an activity and what happens next

Teamwork Project S3

Learning Objectives

Preparation

Post-its and a collaborative board.

Introduction

When mapping a product, we go from the high to the lowest level to plan our delivery. The reason for that is so that the team and stakeholders all have the same knowledge of the strategy of the product and the main end goal.

However, we cannot deliver everything at once. And we also cannot plan every detail. We can prioritise the must-haves and then focus on them.

Product > Features > User Stories > Tasks

This mapping process is also sometimes called User Journey mapping or Story Mapping. And you can - and should - do it whenever you are starting a new project.

What questions should we ask to identify what needs to be built?

🎯 Goal: To understand the requirements of building a library website. (5 minutes)

Let’s assume we have been asked to build a library website that allows you to borrow books.

  • Discuss briefly as a class what questions we should ask to understand better what we will build.
  • Write these questions on post-its and share them on the collaborative board.

Make sure to encourage different people to share their ideas

Focus is on the questions, not the answers!

What features should this website have?

🎯 Goal: To understand the process of breaking down a product into features. (10 minutes)

Let’s assume we got answers to all our questions about the product. (We are not going to actually answer them)

Overall, the goal is to build a website with a catalogue of books that can be borrowed online.

  • In small groups, identify the main features you would expect to see on this website. In this example, features could be a shopping cart, book search, etc.
  • One person of each group to share the group’s thoughts with the class.

Breaking features down into user stories

🎯 Goal: To understand the process of breaking down features into user stories. (15 minutes)

Now that we have all the features, we need to break them down into user stories.

In small groups, pick one of the features and break it down into at least 2 user stories. For example, for the shopping cart feature the user stories could be:

  • As a library user, I want to be able to remove items I have included in my shopping cart so that when I checkout the remaining books are the ones I want to borrow.
  • As a library user, I want to be able to pay with credit card for the books in my shopping cart so they can be delivered to me

Different group representatives volunteer to share thoughts with the class.

Tasks needed to deliver this user story

🎯 Goal: To understand the process of breaking down user stories into tasks and distributing those tasks among team members. (15 minutes)

Now that we have user stories, it is time to break them down into tasks. Tasks are used to break down user stories into smaller components that can then be assigned to individual team members.

Chose a user story and in tο»Ώhe same groups complete the following:

  • Identify the tasks that need to be completed in order to deliver value to the user, providing the outcome described in the user story.

  • Identify relationships and dependencies between tasks.

    • How does a change in Task A affect other tasks?
    • Does Task A need to be completed before we can work on Task B?

  • Size those tasks taking into account complexity and dependencies.

  • Answer these questions: when is it the right time to assign tasks to team members, what would be the criteria you would follow when assigning tasks?

Examples of tasks for a user story describing the book search functionality could be Search Box, Text Autocomplete, Database creation and setup. Discuss in small groups.

Again, a different group representative volunteer to share thoughts with the class.

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.

Study Group

Learning Objectives

What are we doing now?

You’re going to use this time to work through coursework. Your cohort will collectively self-organise to work through the coursework together in your own way. Sort yourselves into groups that work for you.

Use this time wisely

You will have study time in almost every class day. Don’t waste it. Use it to:

  • work through the coursework
  • ask questions and get unblocked
  • give and receive code review
  • work on your portfolio
  • develop your own projects

πŸ›ŽοΈ Code waiting for review πŸ”—

Below are trainee coursework Pull Requests that need to be reviewed by volunteers.

Bump ws from 8.13.0 to 8.17.1 πŸ”—

Bumps ws from 8.13.0 to 8.17.1.

Release notes

Sourced from ws's releases.

8.17.1

Bug fixes

  • Fixed a DoS vulnerability (#2231).

A request with a number of headers exceeding the[server.maxHeadersCount][] threshold could be used to crash a ws server.

const http = require('http');
const WebSocket = require('ws');

const wss = new WebSocket.Server({ port: 0 }, function () {
const chars = "!#$%&'*+-.0123456789abcdefghijklmnopqrstuvwxyz^_`|~".split('');
const headers = {};
let count = 0;


for (let i = 0; i < chars.length; i++) {
if (count === 2000) break;


for (let j = 0; j &lt; chars.length; j++) {
  const key = chars[i] + chars[j];
  headers[key] = 'x';

if (++count === 2000) break;
}

}
headers.Connection = 'Upgrade';
headers.Upgrade = 'websocket';
headers['Sec-WebSocket-Key'] = 'dGhlIHNhbXBsZSBub25jZQ==';
headers['Sec-WebSocket-Version'] = '13';
const request = http.request({
headers: headers,
host: '127.0.0.1',
port: wss.address().port
});
request.end();
});

The vulnerability was reported by Ryan LaPointe in websockets/ws#2230.

In vulnerable versions of ws, the issue can be mitigated in the following ways:

  1. Reduce the maximum allowed length of the request headers using the [--max-http-header-size=size][] and/or the [maxHeaderSize][] options so that no more headers than the server.maxHeadersCount limit can be sent.

... (truncated)

Commits
  • 3c56601 [dist] 8.17.1
  • e55e510 [security] Fix crash when the Upgrade header cannot be read (#2231)
  • 6a00029 [test] Increase code coverage
  • ddfe4a8 [perf] Reduce the amount of crypto.randomFillSync() calls
  • b73b118 [dist] 8.17.0
  • 29694a5 [test] Use the highWaterMark variable
  • 934c9d6 [ci] Test on node 22
  • 1817bac [ci] Do not test on node 21
  • 96c9b3d [major] Flip the default value of allowSynchronousEvents (#2221)
  • e5f32c7 [fix] Emit at most one event per event loop iteration (#2218)
  • Additional commits viewable in compare view

Dependabot compatibility score

You can trigger a rebase of this PR by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the Security Alerts page.

Note Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

Start a review
See more pull requests

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.

Study Group

Learning Objectives

What are we doing now?

You’re going to use this time to work through coursework. Your cohort will collectively self-organise to work through the coursework together in your own way. Sort yourselves into groups that work for you.

Use this time wisely

You will have study time in almost every class day. Don’t waste it. Use it to:

  • work through the coursework
  • ask questions and get unblocked
  • give and receive code review
  • work on your portfolio
  • develop your own projects

Retro: Start / Stop / Continue

  Retro (20 minutes)</span>

A retro is a chance to reflect. You can do this on a FigJam (make sure someone makes a copy of the template before you start) or on sticky notes on a wall.

  1. Set a timer for 5 minutes. There’s one on the FigJam too.
  2. Write down as many things as you can think of that you’d like to start, stop, and continue doing next sprint.
  3. Write one point per note and keep it short.
  4. When the timer goes off, one person should set a timer for 1 minute and group the notes into themes.
  5. Next, set a timer for 2 minutes and all vote on the most important themes by adding a dot or a +1 to the note.
  6. Finally, set a timer for 8 minutes and all discuss the top three themes.