day-plan

🔖
  1. Checkpoint Group Day-Plan
  2. Socialise

Register

Checkpoint Group Day-Plan

This sprint you are working on a group project. We expect you to be present and working with your group all day - from 10:00 until 17:00. There will be a break for lunch at 13:00 - 14:00.

At some point during the day you will be expected to give a demo. We will try to tell you in advance what time you will be giving demos, but be prepared to give them first thing. We expect you to prepare your demos before class, and to be available for demos all day.

You will be split randomly into groups for the project. You will not get to choose your groups. Together you should:

  1. Review the project description together (which you should already have read).
  2. Work out how you’re going to work together and plan.
  3. Set up your project on GitHub.
  4. Break down the project into tasks.
  5. Assign tasks to team members.
  6. Agree on a deadline for each task.
  7. Execute and communicate.

🗂️ Activities

Demo

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.

Structure

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. You must use at least 90 seconds of these 2 minutes. Your demo will be assessed according to the rubric below.

Make sure you are comfortable with the tools you use to present your work. If you are giving a demo in-person you will connect your laptop to a screen/projector and present to the room. If you are giving a demo online you will share your screen on the call.

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?

3. Assessment

The person running the session (either a member of staff or a volunteer) will assess your demo against the rubric below, give you feedback and let you know your score. You need to score at least 5 out of 6 to pass the demo, and you must pass at least 1 demo across the Checkpoint.

💡 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 at least 5 of the 6 criteria, and we recommend aiming to meet all of them. 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.

If a trainee said their demo was about writing clear code, but it was actually about how to debug a test failure, they missed this.

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. Make sure any code / text is readable when presenting.
Stick to your time limit.
Your demo must be 90-120 seconds long. You will be given a warning at 90 seconds. If a trainee finished before 90 seconds, they missed this point.

If a trainee is not done speaking at the time limit, they missed this rubric point, and anything they said afterwards will not be counted towards the rubric.
Ask engaging 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 be rhetorical - you don't have time to wait for answers.

Example topics

Below are some examples of topics you could give a demo on. You aren’t limited to things on this list, if you have another idea then you can give your demo on that!

  • One feature of your project
  • A bug you encountered
  • A way in which you refactored some code
  • A new concept you learned about
  • How you tested your code
  • Planning your project
  • The project management tools you used
  • Managing your Git workflow
  • A challenge you encountered during the project
  • How you incorporated feedback from a previous project into this one
Group Project: Shared Bookmarks

🔗 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 for this. We want to focus on your ability to create the correct logic and not spend time on creating the perfect UI. You are allowed to use CSS, but you are strongly advised to focus on the logic, and only add styling when you are finished. You will not get any credit for styling.

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 project must meet all project submission requirements.

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.

Each bookmark should also have:

  • A button which, when clicked, copies the URL to the clipboard.
  • A like counter/button. When a bookmark is first saved, its like count should be 0. Each time a user clicks the like button, that number should go up by one, and be displayed. This like count should be persisted such that closing the page and coming back to it, it is preserved.

Your website must include a form with text inputs for the URL, title, and description, and submit button that allows a user to add a new topic. This form must be accessible, so for example, a user using the keyboard should be able to submit it without using a mouse.

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

The data should persist across sessions, so if you close your browser then re-open it and select the same user, the data must still be there. The data is not expected to be viewable from another computer - storage is only local.

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
  • Each bookmark’s “Copy to clipboard” button must copy the URL of the bookmark
  • Each bookmark’s like counter works independently, and persists data across sessions
  • 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

Optional: Socialise!

Learning Objectives

At CYF we learn as a community. You’re going to be spending the coming months with the people around you. After that, they will form part of your professional network too.

We encourage you to spend time getting to know them! This is optional. But after class, we encourage you to do something like:

  • Hang around in the class space chatting or playing games.
  • Go sit in a nearby park together.
  • Go to a local cafe for hot drinks.
  • Go to a nearby pub.
  • Or any other ideas you have!

Make sure everyone who wants to join in will feel welcome wherever you go (e.g. a lot of people don’t like drinking or being near alcohol).

If CYF is paying childcare expenses so that you can come to class, we’re happy to pay for this time as well.