Day Plan

Register

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

πŸ”— TypeScript Workshop

Learning Objectives

Introduction to TypeScript

How to run these exercises locally

Once you have cloned this repository locally, you’ll need to install all dependencies for this project. You can do this via your terminal by navigating to your local project’s introduction-to-typescript directory and then running:

npm install

You should then be able to run the tests for each respective exercise by running:

npm run test-exercise1 npm run test-exercise2 npm run test-exercise3

Expect to see red text complaining about errors until you have fixed all of the problems within the relevant exercise files exercise1.ts, exercise2.ts, exercise3.ts.

There are also TypeScript syntax examples available within src/examples should you need a hint.

Best of luck!

What is TypeScript and why do we use it?

Tips for volunteersThis will likely be trainees first time seeing TypeScript so start by introducing them to the very basics. Make time for questions and challenge them once they are ready to actively work with or comment on TypeScript.

Here are some questions you could put to trainees when touching the relevant work:
  • What is the difference between static and dynamic types?
  • What other languages have static types and why is it useful?
  • What might happen if we incorrectly expected a User type where we actually have a Promise< User > type?

At its core, TypeScript is a superset of JavaScript. This means that any valid JavaScript code is also valid TypeScript. TypeScript introduces static typing, which allows you to define the types of variables, function parameters, and return values. This additional layer of type information helps spot errors during development, making your code more reliable.

Basic examples (10 minutes)

There are many basic data types in JavaScript, including but not limited to string, number, boolean, undefined, and null. JavaScript already has dynamic types, which means variable types are determined at runtime.

TypeScript supports static types, which means variable types are known at compile time. Here are some examples of how we might specify static types in TypeScript:

let name: string = "Luke";
let age: number = 30;
let isTrainee: boolean = true;
let completedCourses: string[] = ['ITD', 'ITP', 'Piscine']

TypeScript also supports type inference. This means that TypeScript can determine (infer) the type of variables based on their initial value:

let name = "Luke"; // inferred as string
let age = 30; // inferred as number
let isTrainee = true; // inferred as boolean
let completedCourses = ['ITD', 'ITP', 'Piscine'] // inferred as string[]

age = "Thirty" // TypeScript will error here: "Type 'string' is not assignable to type 'number'".

Notice how not everything needs to be explicit. TypeScript is very smart and will be able to effectively type many things itself. In fact, it will often find incorrect typing before you do.

In our previous examples we said completedCourses is of type string[]. TypeScript lets us be even more specific by leaning on literal types:

type Course = 'ITD' | 'ITP' | 'Piscine' | 'SDC'

let completedCourses: Course[] = ['ITD', 'ITP', 'Piscine']

In our example above we are defining our own type Course which permits a number of specific strings. It uses the union type operator | somewhat similarly to how we might use the logical OR operator ||. We are stating that a variable of type Course may be 'ITD' OR 'ITP' OR 'Piscine' OR 'SDC'.

We can also define an object type. For example, maybe we want to wrap our earlier fields within an object:

type Course = 'ITD' | 'ITP' | 'Piscine' | 'SDC'

type User = {
  id: number;
  name: string;
  age: number;
  isTrainee: boolean;
  completedCourses: Course[]
};

const myTrainee: User = {
  id: 0,
  name: 'Luke',
  age: 30,
  isTrainee: true,
  completedCourses: ['ITD', 'ITP', 'Piscine']
}

If we tried to create a User but didn’t give them a name, TypeScript would tell us. If we did the same in JavaScript, nothing would tell us we missed anything, but when we tried to get a User’s name, we’d get undefined. Even this probably wouldn’t be an error - we may only find out when our UI tries to use this data and says “undefined, aged 30, has done ITD, ITP, and Piscine”.

TypeScript also supports optional properties. For example our User type might have an optional address property that can be left out from instances of the User type:

type Course = 'ITD' | 'ITP' | 'Piscine' | 'SDC'

type User = {
  id: number;
  name: string;
  age: number;
  isTrainee: boolean;
  completedCourses: Course[]
  address?: string; // equates to string | undefined
};

// myTrainee doesn't have an address property but it is still a valid User
const myTrainee: User = {
  id: 0,
  name: 'Luke',
  age: 30,
  isTrainee: true,
  completedCourses: ['ITD', 'ITP', 'Piscine']
}

Objects can become complicated data as they grow but TypeScript makes maintaining our code far easier!

A more complex example (10 minutes)

Tips for volunteersThis example has a lot of moving parts and might at first be daunting for trainees. Be sure to move through it slowly and take questions from trainees. You can always break things down further with some live code!

Steer trainees towards comparing the JavaScript and TypeScript examples and towards hopefully seeing some benefits of TypeScript.

Pointing out common JavaScript pitfalls that TypeScript avoids could be helpful. For example:
  • Misspelt properties, e.g. user.naem will likely error.
  • Variables unexpectedly being null or undefined.
  • Accidental type coercion, for example TypeScript knows 5 + "5" will be a string ("55").

Let’s have a look at this example JavaScript code which fetches a user by its ID from a hypothetical API:

async function fetchUser(id) {
  const response = await fetch(`/api/users/${id}`);
  return response.json();
}

const user = fetchUser(0);

What is a user? What does this data look like? We might have the answer in our head but TypeScript gives us the ability to define it in code. Let’s have a look at the same example but in TypeScript:

type Course = 'ITD' | 'ITP' | 'Piscine' | 'SDC'

type User = {
  id: number;
  name: string;
  age: number;
  isTrainee: boolean;
  completedCourses: Course[]
  address?: string;
};

async function fetchUser(id: number): Promise<User> {
  const response = await fetch(`/api/users/${id}`);
  return response.json();
}

const user: Promise<User> = fetchUser(0);

Here we have specified that once our user has been fetched, it is of type User. We know it is an object and we know the type of every property in the object.

Since we have to await the user being fetched, Promise<> tells us that our user will be a Promise until our API request has completed, at which point our user will be a User.

Fixing TypeScript errors (30 minutes)

Tips for volunteers
  • You can use larger breakout groups if you don't have a volunteer for every group of trainees. Alternatively volunteers can hop between breakout groups if you are confident that trainees will be able to handle the exercise without a volunteer present.
  • This part of the workshop is the main opportunity for trainees to actively engage with TypeScript. Be supportive but encourage trainees to problem solve for themselves wherever possible.
  • The nuances of exercise 3
    This is a fairly open ended exercise. The problem is that a try catch block will always treat the error as type unknown, which isn't helpful and is prone to type errors. The simplest solution is to treat an error as any type, which is commonly done in the workplace. This is a valid approach to handling errors but it has the usual problems of the any type so trainees should be encouraged to handle errors with more nuance.

    A slightly better approach is to use type coercion. For example return (error as Error).message but this is also flawed since the error type of a catch block is inherently unpredictable.

    A more robust solution would be to confirm the type of error before utilising it. For example: if (error instanceof Error) { return error.message } else { return error }

    There is no singular solution to this exercise so it is best to encourage trainees to see how far they can take error handling and TypeScript.

Setup

  • Breakout into groups of ideally 2, and no more than 3 trainees.
  • Ideally each group should have a single fork of the exercise repository from where every member collaborates.
  • Each member should clone the forked repository to a local project.
  • Navigate to the introduction-to-typescript directory.
  • Follow the instructions in the README.md to setup the project and run the exercise.

Fixing errors

Now that you’ve got the project running locally, your job is to complete the exercises in order while ensuring all tests pass for each exercise.

There are TypeScript type examples within src/examples should you need a hint but feel free to also do your own research.

Designate a driver while the rest of your group guides the driver towards solutions. Aim to swap out drivers at least every 10 minutes.

Takeaways (10 minutes)

Tips for volunteersEncourage engagement from the trainees. Steer trainees towards fulfilling the learning objectives but here are some other takeaways worth considering:
  • TypeScript makes unexpected bugs less likely.
  • It is easier to understand someone else’s code if it is written in TypeScript.
  • The output of code is more predictable. You can predict the output of a function without even seeing the code of a function.
  • TypeScript is optional but useful.

Now that you have experience with TypeScript, what do you think of it? Are you able to answer:

  • When would you choose to use TypeScript over JavaScript?
  • Would you prefer to use JavaScript or TypeScript?
  • Would you prefer your coworkers to use JavaScript or TypeScript?
  • Why would you use TypeScript if JavaScript is more flexible?

Additional reading

If you would like to further your TypeScript knowledge, there are many great tutorials online.

Total TypeScript is one such resource and has several free exercises. https://www.totaltypescript.com/tutorials/beginners-typescript

W3schools also has their own short and free exercises. https://www.w3schools.com/typescript/typescript_exercises.php

Review

Look back over the objectives of this activity - check you've met them all. If you haven't, make sure you have a plan for how to achieve them - maybe checking in with a volunteer or a fellow trainee could help?

Morning Break

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

Study Group

Learning Objectives

Trainees

This is time for you to get help with whatever you need help with.

If you didn’t understand something in the prep, ask about it.

If you were struggling with a backlog exercise, get help with it.

If you weren’t quite sure of something in a workshop, discuss it.

If you don’t have any problems, keep working through the backlog until you need help.

It can be useful to get into groups with others facing the same problem, or working on the same backlog item.

Volunteers

Don’t be scared to approach people and ask what they’re working on - see if you can help them out, or stretch their understanding.

If lots of people have the same problems, maybe you can put together a demonstration or a workshop to help them understand.

If absolutely no one needs help, consider reviewing some PRs using the process and guidelines in the #cyf-code-review-team Slack channel canvas.

Breaks

No one can work solidly forever! Make sure to take breaks when you need.

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.

Demo

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 both for interviews and for getting promoted later on.

⏰ Timekeeper

The timekeeper will keep the groups on track.

Split randomly into groups of no more than 5 people. Each person will have 2 minutes to demo their work to the group. After the demo, the group will give feedback for 5 minutes. Then the next person will demo their work.

πŸ§‘πŸΌβ€πŸŽ“ Trainees

1. Demo

You will demo your work 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?
  • I wasn’t sure if I explained what an X was very clearly, how could I have explained it better?

More tips: A Good Question Can Be the Key to a Successful Presentation.

πŸ’‘ Tips:

  • Practice your demo 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.

Study Group

Learning Objectives

Trainees

This is time for you to get help with whatever you need help with.

If you didn’t understand something in the prep, ask about it.

If you were struggling with a backlog exercise, get help with it.

If you weren’t quite sure of something in a workshop, discuss it.

If you don’t have any problems, keep working through the backlog until you need help.

It can be useful to get into groups with others facing the same problem, or working on the same backlog item.

Volunteers

Don’t be scared to approach people and ask what they’re working on - see if you can help them out, or stretch their understanding.

If lots of people have the same problems, maybe you can put together a demonstration or a workshop to help them understand.

If absolutely no one needs help, consider reviewing some PRs using the process and guidelines in the #cyf-code-review-team Slack channel canvas.

Breaks

No one can work solidly forever! Make sure to take breaks when you need.

Retro: Start / Stop / Continue

πŸ•ΉοΈRetro (20 minutes)

A retro is a chance to reflect. You can do this on RetroTool (create a free anonymous retro and share the link with the class) or on sticky notes on a wall.

  1. Set a timer for 5 minutes. There’s one on the RetroTool 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.