🧑🏾‍🤝‍🧑🏾 day-plan

🔖
  1. Energiser
  2. Morning orientation
  3. Workshop
  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

🧰 Workshop Activity

Learning Objectives

This space is for a workshop activity of your choosing. In order for this to actually happen, you must organise it ahead of time.

What is a CYF workshop?

👷🏿‍♀️ No lectures

Code Your Future workshops are designed to be interactive. Developed by volunteers and trainees, they are not about listening to a lecture. They are about doing, discussing, and learning together.

💪🏾 No spoonfeeding

Workshops are also not tutorials, where you follow along step-by-step. CYF workshops are meant to expose gaps and mistakes in your understanding, so mentors can help you fix them. This means you should expect to be challenged and to make mistakes. This is the main value of mentor-led workshops.

👂🏿 Responding to needs

You can run a workshop in person on class days, or online in the week. Mentors volunteer to run workshops on Slack, and learners propose topics they need help with. There are a huge number of workshops available at workshops.codeyourfuture.io/.

Organise a workshop on Slack

./organise-workshops.png

🗂️ Options

Asking questions [PD] (60 Mins)

Asking questions [PD] (60 Mins) 🔗

Asking Questions 101

Prep

Today we’re going to start learning a formal language of developer questions. We will begin with this basic format:

  1. What I did
  2. What I expected
  3. What actually happened

This format helps to find the discrepancies between expectations and reality. (This is the gap in our understanding.)

It’s also an efficient way to share our current understanding with others.

Expectation vs reality

When we are surprised by an outcome it usually means we had a mental model of the world that didn’t predict the world accurately. Don’t panic when this happens, it’s completely expected for even experienced developers to run into surprises. We use these gaps as signs that we need to update our mental models.

To develop our understanding of coding, we will:

Predict & Explain

  1. Make a prediction by explaining what the outcome will be
  2. Play computer - “run” the model in our heads and predict (say before) what the outcome will be

Try

  1. Code up our idea
  2. Run the code

Compare and Update

  1. Compare the outcome with our prediction
  2. Explain the gap between our prediction and what actually happened
  3. Update our understanding

This process is cyclical.

graph LR A[Predict] B[Explain] C[Try] D[Compare] E[Update] A --> B B --> C C --> D D --> E E --> A

Updating the right model

If you stuck and can’t explain the gap in your mental model, then it’s time to ask a question!

When we ask questions, it’s important that we share our current mental model as part of your question so that other people can test the right thing, focus on the mis-understanding. Then together you can get quickly to a shared understanding of your specific problem.

Let’s look at how asking questions helps you update your mental model with an example.

Inversion, 5m

  1. Set a timer for 5 minutes.
  2. Popcorn around the room and each person give an example of a bad way to ask a question until the timer goes off. For example:

Argh I can’t make it work please help me!

Why are these not useful?

Inversion 2, 10m

  1. Set a timer for 10 minutes.
  2. Popcorn around the room and each person give a reason the previous question was bad until the timer goes off. For example:

What is it? What are you trying to do? In what way is it not working? Be specific! Share what you see. Do you have a link? What do you want it to do?

Exercise ground rules

Before we get to the next exercise, let’s just set some ground rules here:

  1. The goal is not to complete the exercise; the goal is to learn
  2. The smart thing to do is to focus on the questions you cannot (yet) answer

Framing questions systematically, 30m

Split into groups of 2-5 people. Set a whole class timer for 30 minutes.

Confound yourselves

  • Pick a problem from the bank.
  • As a group, make a prediction about what you think the answer is, and write it down.
  • Test your prediction. Try it out using the dev tools.
  • Compare your prediction with the outcome.

What happened? Is there a gap in your understanding?

Keep doing this until you find a problem you can’t solve, then write up your mental model using this format:

  1. What I did
  2. What I expected. Make sure you include your prediction here
  3. What actually happened

Include as much context as you can, including links, line numbers, sample code, etc. Use code blocks to mark up your code. If you use screenshots, they should only show the visual render (never screenshot code - paste code as text).

Now post your write up of the question in #cyf-ask-tech-stuff.

🧑🏾‍💻🙋 Developer questions contain

  1. 🔗 Links 👍
  2. Objectives - what are you actually trying to do? 👍
  3. 🖼️ Screenshots of UI 👍
  4. 📝 Code blocks 👍
  5. 📷 Screenshots of code 🙅

📚 Further reading

Devtools [Tech] (60 Mins)

Devtools [Tech] (60 Mins) 🔗

Inspector Gadget

Prep

For this workshop you will need:

You’ve already used a little bit of Devtools in ITD when you used Lighthouse to audit your code. But there’s much much more! Devtools is an entire IDE (Integrated Development Environment) running inside your browser and it has hundreds of ways to inspect, test, and develop your code.

💡 Explore

Each browser has its own Devtools. Download Safari, Chrome Canary, and Firefox Developer Edition to explore the differences.

Inspect the DOM

Explore

In groups of no more than five. Take it in turns to swap the driver for each section of this workshop

  1. Set a whole class timer for 10 minutes.

  2. Inspect the page with Devtools.

  3. Write down the answers to these questions:

    • What is the name of the font used on the page?
    • What is the CSS variable that holds this value? (Hint: variables start with --, like, --paper)
    • What is the brand colour value (Hint: it’s set in a variable)?
    • What is the brand colour value used for in the page?
    • What variables hold CSS length data type values?

  4. When the timer goes off, share your answers with the other groups. Paste them in a thread in Slack and go quickly to the next challenge.

So we’ve seen that fonts, colors, and spacing are often stored as CSS Variables, or custom properties. This allows them to be easily changed throughout a project by simply altering one value. Let’s experiment with this.

Experiment

  1. Set a whole class timer for 10 minutes.
  2. Inspect the CSS of the page with Devtools.
  3. Find the CSS Variables (hint: variables start with --, for example, --paper)
  4. Try changing the values of these variables and see how it affects the page.
  5. Some questions to answer. (Make a prediction about what you think will happen first, and then test it)
  • What will happen when you click the value of --finger and press up arrow ten times?
  • What will happen when you delete the value of --copy
  • What will happen when you change the value of --space to red?

Reflection

When the timer goes off, set a new timer for 10 minutes to share your answers with the other groups.

Grid Inspector

Next, let’s see how the page layout is handled. Modern websites use the CSS Grid for layout and you can manipulate grids with Devtools.

Grid Editor

  1. Set a whole class timer for 10 minutes.
  2. With Devtools, locate a grid element on the workshop page.
  3. Activate the Grid Badge in the Elements panel.
  4. Use the Grid Editor to try changing the layout.
  5. Go straight to the next challenge!

Lighthouse

It’s important that software works and that people can use it. Lighthouse can help you write code correctly by pointing out your errors. But even better, it can teach you to fix the errors.

Audit

  1. Set a whole class timer for 10 minutes.
  2. Run a Lighthouse audit on the workshop page.
  3. Look at the results and identify the issue.
  4. Now, how will you fix it? Click on the error. Lighthouse explains what is wrong and provides a link to a detailed explanation on why it’s wrong, how serious it is, and how to fix it!
  5. If you have time, fix the error, but in any case, once the timer goes off, paste the link to the detailed explanation page into the workshop thread in Slack.
  6. Go straight to the next challenge, after which we will spend some time discussing what we discovered.

Hover for more

In fact Devtools is a great teacher. In the Styles panel, hover over any CSS property to get a quick definition of that property. Click ‘Learn More’ to go straight to the MDN page for that property.

If the explanation doesn’t make sense to you, ask ChatGPT (a generative AI) to explain it further.

⚠️ Plausible Hallucinations

Remember: Generative AIs are regularly confidently wrong; it can be helpful, but never trust it over Devtools.

If something doesn’t make sense, or seems confusing or maybe wrong, it’s better to ask friendly humans in Slack.

Explore and Explain

  1. Set a timer for 10 minutes.
  2. Select <main> in the Elements panel
  3. Hover over the ruleset attached to main in the Styles panel.
  4. Copy the Devtools explanation and ask ChatGPT to explain it, like this:
Please explain this to me like I'm a beginner learning HTML and CSS.

Determine a grid item’s size and location within the grid by contributing a line, a span, or nothing (automatic) to its grid placement. Shorthand for ‘grid-row-start’, ‘grid-column-start’, ‘grid-row-end’, and ‘grid-column-end’.

  1. Come back together as a large group.

Reflect

Reflect

  1. Set a timer for 5 minutes.
  2. Spend five minutes discussing what you will share with the rest of the class about your experiments so far. What was a surprise to you? What will you use regularly from now on? What confused you? Elect one person to represent your group.
  3. Set a timer for 20 minutes.
  4. Popcorn round the representatives and share your findings. We’re not done yet so keep to time.

Many ways of examining the same thing

So we’ve explored the Elements panel, the Styles panel, and the Lighthouse panel. There are many many more panels, and they all expose a different way of interpreting, interacting with, or understanding the same code. Computer systems frequently do this. It’s a mistake to think that the way you use a website is the only way it can be used. Bots, crawlers, screenreaders, integrations…there are many and various consumers of your code, so it’s important to make sure you construct it properly.

For example, you have just looked in the Elements panel. This is not really your HTML, this is the DOM, an API the browser builds using your HTML. An example of how the DOM is different from HTML is that JavaScript can change what’s in the page - this changes the DOM, but doesn’t change the actual HTML. The DOM isn’t the only API it builds. Let’s look at another one right now!

A New Lens

  1. Set a timer for 5 minutes.
  2. Find the Accessibility Panel and check ‘Enable full-page accessibility tree’
  3. Now click the “Universal Man” button in the Elements Panel.
  4. What is Ignored in the Accessibility Tree that is present in the DOM?
  5. When the timer goes off, share your answer with the other groups by pasting in the workshop thread.

Reflect

Develop Your Skills

  1. Set a timer for 10 minutes.
  2. Discuss how your team will work on developing your skill with Devtools. Make your goals SMART. For example, you might audit a website you have built already with Lighthouse and improve its score using the guides. You might schedule a study group where each person researches and then teaches the group about a different panel in Devtools.
  3. Write down your learning goals with Devtools on a piece of paper and sign it underneath. Elect a new person to represent your group.
  4. Set a timer for 10 minutes.
  5. Popcorn round the representatives and share your commitments.

And that’s it for today! We have covered a lot, but remember, as developers, we are lifelong learners. Always be curious and don’t be afraid to explore new tools and concepts. Soon we’ll dive even deeper into Devtools, so make sure to keep exploring.

More

  1. Inspect web pages as you use the internet. Do this all the time! What font does Youtube use? What about CSS Tricks? Hackernews is still using tables - what’s wrong with this?

  2. Try changing the style and content of some websites. Make your favourite website bright pink. Make the BBC News page tell people about something great you did. Send a screenshot of something cool you changed to your cohort’s Slack channel.

  3. There are crash courses in Devtools all over YouTube and Udemy etc. Find a useful tip and share it in your class channel.

Components 1 [Tech] (60 Mins)

Components 1 [Tech] (60 Mins) 🔗

First Components

Today we’re going to think about components. We’re going to build a page using a design system and we’re going to collaborate on a feature branch workflow.

The overall mission is to compose “components” / groupings of HTML elements to re-build this web page: CYF Components Workshop.

Learning Objectives

Requirements

Before you start, make sure you’ve installed the CYF Extension Pack in VS Code.

Set up your feature branch 15m

Set up your feature branches

Divide the class into three teams: header, footer, card. Use the team generator to help you do this.

Set a whole class timer for 10 minutes.

Each team, choose a driver

  1. Driver, clone this repository
  2. Driver, create and checkout a new branch for your team named like this: feature/cohort-component, where cohort is your cohort name and component is the component you’re building, for example: feature/nw6-header
git switch --create feature/cohort-component

Now you’re all set up to make changes to together.html.

Find your docs 10m

Find your docs

Set a whole class timer for 10 minutes.

Deployed from this repo is a mini design system. This design system has several documented components: card, header, and footer. Each component view has some sample code and some statements about the components.

Your mission is to find the docs for your component and read them.

Together separately

Set a whole class timer for 30 minutes.

Parallel Development 30m

Now build your component. Elect a new driver.

  1. Find together.html in the /components-1 directory. Your mission is to complete this page.
  2. In the correct portion of the page, make your changes to build your feature on together.html.
  3. Driver, commit your changes to your feature branch.
  4. Open a pull request from your branch to main, with your changes.
  5. Remember, docs will help you.
  6. Do the simplest thing that could possibly work to begin with. You can always update your PR with more changes.
gitGraph commit id: "start" branch feature/cohort-component commit id: "paste html from docs" commit id: "fill in the blanks" commit id: "lighthouse revisions" checkout main merge feature/cohort-component

Review and merge

Now we’re going to review each other’s work. If a mentor is available, they can be the driver for this part and you can actually merge your PRs. If not, please don’t try to merge as you could make a mess of this shared repo.

Note to mentor: please revert together.html to the initial commit after you’re done so the next class can use it. (Or if your group has time for it, you can merge on a fork instead.)

Set a whole class timer for 30 minutes.

Review 30m

  1. Go to the pull requests for this repo.
  2. Either individually or as a group, review each other’s PRs.
  3. Once you’re all happy with the PR, merge it.
  4. Did it work? Why/why not? Discuss.

Acceptance Criteria

  • We have worked in three teams to build a page using a design system
  • We have used a feature branch workflow to collaborate
  • We have reviewed each team’s PR

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.

CYF-ITP-South Africa | Natalie Patel | Module-User-Focused-Data | Week2 Wireframe - Resubmission 🔗

Self checklist

  • I have committed my files one by one, on purpose, and for a reason
  • I have titled my PR with COHORT_NAME | FIRST_NAME LAST_NAME | REPO_NAME | WEEK
  • I have tested my changes
  • My changes follow the style guide
  • My changes meet the requirements of this task

Changelist

Due to having committed my previous Wireframe project to the main branch and being unable to rectify it, I had to refork the repository and am resubmitting the PR to the correct branch. This PR will contain my styled wireframe Git page.

Questions

Ask any questions you have for your reviewer.

Start a review
CYF London | Rihanna Poursoltani | Module User Focused Data | Form controls | Week 2 🔗

Learners, PR Template

Self checklist

  • I have committed my files one by one, on purpose, and for a reason
  • I have titled my PR with COHORT_NAME | FIRST_NAME LAST_NAME | REPO_NAME | WEEK
  • I have tested my changes
  • My changes follow the style guide
  • My changes meet the requirements of this task

Changelist

  • Added valid inputs with associated labels for name, email, radio, date and select.All of inputs are required.
  • My Lighthouse Accessibility score (for Desktop and Mobile) is 100.
  • Added 6 options for size with select and 3 options for colours with using fieldset and radio inputs.
  • Adde two buttons for submit and reset.
  • Added style, hover and focus for labels, inputs and buttons.

Questions

  • I had problem for setting size for select option. As you can see width is not the same as others in the page.How can I fix that?

Ask any questions you have for your reviewer.

Start a review
LONDON | DANIEL ALEXANDER | FORM CONTROLS | WEEK 2 🔗

Learners, PR Template

Self checklist

  • I have committed my files one by one, on purpose, and for a reason
  • I have titled my PR with COHORT_NAME | FIRST_NAME LAST_NAME | REPO_NAME | WEEK
  • I have tested my changes
  • My changes follow the style guide
  • My changes meet the requirements of this task

Changelist

Written up HTML and CSS for basic form.

Questions

Would like to have a rolling date feature where the min date in calendar is always day of accessing website but it seems this is a JS feature?

Start a review
CYF-ITP - South Africa |Azharuddin Meyer | Module-User-Focused-Data Form Controls | Week2 🔗

Self checklist

  • [yes ] I have committed my files one by one, on purpose, and for a reason
  • [yes ] I have titled my PR with COHORT_NAME | FIRST_NAME LAST_NAME | REPO_NAME | WEEK
  • [ yes] I have tested my changes
  • [yes ] My changes follow the style guide
  • [ yes] My changes meet the requirements of this task

Changelist

Briefly explain your PR.

I have created a a product form using HTML and CSS.

Start a review
WEST MIDLANDS COMMUNITY/MILLENA MESFIN/Module-User-Focused-Data/week#2 🔗

Learners, PR Template

Self checklist

  • I have committed my files one by one, on purpose, and for a reason
  • I have titled my PR with COHORT_NAME | FIRST_NAME LAST_NAME | REPO_NAME | WEEK
  • I have tested my changes
  • My changes follow the style guide
  • My changes meet the requirements of this task

Changelist

Briefly explain your PR.

Questions

Ask any questions you have for your reviewer.

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