🧑🏾‍🤝‍🧑🏾 day-plan

🔖
  1. Induction
  2. Review and finalise your individual project
  3. Kickoff
  4. Morning break
  5. Practice breaking down a requirement
  6. Development
  7. lunch
  8. Development
  9. Afternoon break
  10. Demo
  11. Wrap

🫱🏽‍🫲🏾 Induction

Welcome to the Piscine.

Today you will kick off your first team and individual project. At the end of the day, each person will give a two minute demo to their group of something they have built, learned, or discovered today

Lets quickly review success criteria of the Piscine

Next up, we need to choose a timekeeper. The timekeeper is responsible for keeping us on track and making sure we finish on time. Who would like to volunteer?

⏰ 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

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.

🔗 Review and finalise your individual project

Project: Spell Checker

When writing text, it is helpful to have a tool to check that you are spelling correctly. Most computers even have it built in to the operating system.

Your task is to build your own spell checker for a simplified language called “Basic English” that contains a much smaller set of words than regular English. Use the list provided in words.json.

Make a website where a user can write some text and then check if the text is valid Basic English. You must focus on HTML and JavaScript. Some CSS can be used, but the website’s design is not the focus of the assessment. We will assess you on correct logic. You will not pass if you produce a pretty UI that has missing or incorrect logic.

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.

You must be able to explain every line of code in your project.

Your website should display a text input, which allows the user to a few sentences of text. Your website should also have some way of triggering a spell check on the text that the user has written.

When the spell check is triggered, your website should check every word that the user has typed to see if it exists in the Basic English word list that we have provided (in words.json).

If there are any words that aren’t in the Basic English word list, you should consider those words as a spelling mistake. All spelling mistakes should be presented to the user underneath the input, along with a message explaining that the words are misspelled. This message should be styled with highlighting in some way that makes it obvious that there is a spelling mistake. Note: highlighting the word within the input itself is quite difficult, so don’t attempt it as part of the assessment.

If all words are correct, then no message needs to be displayed underneath the input.

If a misspelled word is detected, there should be a way for the user to add that word to the dictionary. The spell check should then be triggered again, and the word that was added to the dictionary should no longer be considered a misspelled word (so should not be highlighted). Note: the custom dictionary does not need to be saved, so reloading the page can reset back to the initial dictionary.

When the user changes the text in the input, the warning about misspelled words should be cleared.

The input text can sometimes include punctuation (such as commas or full stops). Your website should not identify words that include some punctuation as spelling mistakes. So for example, “make a cake, please” will not highlight “cake” as a spelling mistake. However, if a word that is not in the Basic English word list and is next to some punctuation (e.g. “cakez,”), it still should be highlighted as a spelling mistake.

A hyphen (-) can join two words, which should be treated as separate. For example “blue-green” should not be highlighted as both “blue” and “green” are found in the Basic English dictionary. However, the first word in “feisty-cat” should be highlighted because “feisty” is not in the Basic English dictionary.

Words that begin with capital letters, such as proper nouns and names, should always be treated as “correct” words and so should not be highlighted. For example, “Ali” or “London” would not be highlighted, despite not being in the Basic English dictionary.

Your GitHub repository must contain at least one unit test which demonstrates that your code works. End to end tests are optional. Testing via the DOM is optional.

Every view of your website must be accessible (i.e. before entering text, after checking spelling, etc). We will test this by making sure that “Snapshot” mode of Lighthouse gives 100% accessibility for any view we look at.

Supplied scaffolding

We have supplied a few sample files in the repo to demonstrate how you can define JSON data in one file and access this both 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.

Rubric

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

  • The website has an input that allows the user to write some text
  • The website has a way for the user to triggering a spell check
  • When triggered, the spell check should check every word in the input to see if it exists in the Basic English dictionary
  • If a word does not exist in the dictionary, then it should be highlighted below the input as a spelling mistake
  • It should be obvious to the user that there is a spelling mistake, both with visuals and some explanatory text
  • If a word does not exist in the dictionary, then a mechanism should exist to add the word to the dictionary. Adding the word to the dictionary should re-trigger the spell check and the newly added word should no longer be highlighted. If more than one word does not exist in the dictionary, they should be able to be added separately one at a time
  • “Correct” words (i.e. those found in the Basic English dictionary) that are adjacent to punctuation (which is defined as the following characters: ,.?!":;) should not be marked as spelling mistakes
  • “Incorrect” words (i.e. those not found in the Basic English dictionary) that are adjacent to punctuation characters should still be marked as spelling mistakes
  • Words joined by hyphen should be treated separately, so if one or both of the words are “incorrect” (i.e. those not found in the Basic English dictionary) then it should be marked as a spelling mistake
  • The website must score 100 for accessibility in Lighthouse
  • Unit tests must be written for at least one non-trivial function

Some examples of correct Basic English:

  • he go to the island
  • they make a fire
  • he will get married, she will not
  • red-orange fire
  • I love Glasgow

Some examples of incorrect Basic English:

  • hello world
  • they create some dinner
  • she give gift, then go out
  • he like egg-nog
  • go to birmingham

Kickoff

Learning Objectives

At MigraCode 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 get togather with your groups, which were made last Saturday.

🕹️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 of fifteen minutes so we can all concentrate on the next piece of work.

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 agenda for the relevant user (see manual testing below)
  • Submitting the form adds a new topic to revise 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 revision date for one topic from in User 1’s stored agenda
  • When clicking a button, store 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. data for User 1’s agenda

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

Looking ahead to your coursework for the next week, one of your tasks will be to Refine a ticket.

✍️Refining tickets

  1. Everyone read the Refine a ticket coursework task, for

minutes. 2. Get into pairs. Each pair should then pick 2 of the tasks from the whiteboard (it doesn’t matter if multiple pairs do the same task). Spend

minutes refining your tickets in your pairs. Make sure you work through all of the workflow points. 3. Go around each pair in the group. The pair should pick 1 of their tasks and say what they think the priority, estimate, schedule and type of work the task is, and if there is anything they would need to know before starting the ticket. (Hint: the last point is important! Don’t skip it!) 4. As a group, pick a task (or two, depending on time) that needs more information. Spend

minutes discussing what actions you could take to ensure everyone has what they need to complete this 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.

🍽️ Lunch

At MigraCode, there will be scheduled community lunches throughout the year during which all of MigraCode team will joing and would like to invite you to eat with us. The MC team will let you know when the upcoming community lunch will be. Bring your home-cooked food or buy some food across the street at Glories (e.g., at the Carrefour Supermarket or pick up some to-go meal from one of the restaurants there). We share our time, food and our stories. We learn about each other and the world. We build community.👭👬

On days where there is no community lunch planned you can still stay to socialise here and use the terrace to meet you peers and connect (this goes especially for class days that are longer than just until 2pm.)

Adevinta allows us to use their beautiful space, cutlery, plates, microwaves etc - please make sure to leave everything exactly as it was before so they keep lending their precious space to us ☺️. Ah and make sure to check out the foosball table on the terrace.

🧑🏿‍🔧 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 free to grab some coffee or tea.

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