Group Projects

A collection of group projects that can be used to teach collaboration and real-life project management skills.

Outline

Each project is designed to be undertaken by 2-4 students, preferably within a week or two. It should rely mostly on skills they already have, but in some cases students will be encouraged to independently research solutions to problems or new tools they encounter along the way.

Goals

• Provide extra challenges for students seeking them
• Develop collaboration skills on real-life projects
• Transfer skills and knowledge back to the main class
• Require as little mentor involvement and upkeep as possible
• Build out and differentiate students’ GitHub portfolios

Skills to teach

These projects were devised in response to requests from students in the Glasgow class for more practical projects and an additional mid-week class. When determining what skills to teach, we should take care not to preempt future lessons in the course, and to prioritize skills which the students can teach each other later on, when the full class gets involved in projects.

Some of the skills we’ve identified that students can help teach each other on the graduate project:

• SASS, LESS and other CSS compilers
• Breaking a project into discrete components
• Coordinating with others on pull requests, code architecture, etc
• Familiarity with third-party libs (form controls, authentication, etc)

Notes for mentors

• Ensure work is shared in projects and one person isn’t taking on everything.
• Encourage students to solve problems independently. Be the non-techy project manager who points out problems.
• Encourage students to refactor often, to develop good habits.
• Let students go down the wrong alleys a bit. It’s good learning.

Projects

Below is a short list of projects that have been compiled. Please identify, conceive and add additional projects.

There is scaffold code for many of the projects, included in a dir named scaffold. These scaffold projects are designed to be cloned and then worked on collaboratively. They contain a basic structure and some initial code to get started.

Starter projects

These projects can be completed with only a basic understanding of HTML/CSS. They are intended to introduce working together on shared code, managing version control, and resolving conflicts.

• Changes on Messaging App - Implement requested changes to a messaging app.
• Changes on Shop App - Implement requested changes to a shopping app.
• Changes on FAQ App - Implement requested changes to a frequently asked questions app.
• Changes on Reviews App - Implement requested changes to a reviews app.

JavaScript Fundamentals

These projects run on the command line and can be completed using only the fundamentals of JavaScript, such as booleans, strings, numbers, arrays, functions and conditionals.

• Grade Report - Implement a grade reporting tool.
• Budget Management - Implement a budget management tool.
• Time Management - Implement a time management tool.

JavaScript DOM

These projects can be completed using JavaScript client-side fundamentals such as fetch and DOM manipulation, without any third-party libraries.

• Payments - Implement a payments tracking tool.
• Bookshelf - Implement a bookshelf tracking tool.

Server-less projects

These projects can be completed without waiting for students to learn about React, Node or DB.

• Restaurant Website - Implement a design mockup in HTML/CSS.
• Luxury Vehicles Website - Implement a design mockup in HTML/CSS.
• Fashion Website - Implement a design mockup in HTML/CSS.
• Museum Website - Implement a design mockup in HTML/CSS.

React-only projects

These projects are designed to reinforce basic React skills and do not require knowledge of Node or DB.

• Payments - Build an app to track payments in multiple currencies.
• Countries - Build an app to learn about members’ home countries.
• Dogs - Build an app to have fun with doggies.

Express/MongoDB projects

These projects are designed to reinforce basic CRUD operations using Node/MongoDB.

• Progress Chart - Implement a small app to track your learning progress.
• Shopping - Implement a small shopping app with rating and comments.
• FAQ - Implement a small FAQ app with searching.

License

All images, mockups and other visual assets are copyright their respective owners. These assets are for educational use only. Please consult each project for licensing details.

Practice Code Review

Before jumping into group projects using JS, take some time to learn about code review and code quality automation . Practicing with these concepts now will make the transition to collaborative development much smoother.

• Big Picture
  • The Challenges
  • Planning
  • Code Review
• Writing Code
  • Repo Setup
  • Local Setup
  • Developing Your Solutions
• Code Quality Automation
  • npm scripts
  • Code Coverate
  • Continuous Integration

The Challenges

Your group’s challenge is to write as many strategies and implementations as you can! Code quality should be your main focus. You’ll practice formatting, linting, testing, and code review.

There are already a few challenges in the /src folder, but feel free to add a new one if there’s a different problem you’d like to solve. And it’s ok if someone has already tried using the same strategy to solve the same problem you want to work on. You can always find a slightly different approach, and comparing your solutions will be a good topic for the retrospective.

Take it easy and have some fun.

Template

./.template-solution

/practice-code-review
  /.template-solution
    /README.md
    /sandbox.js
    /solution-name.js
    /solution-name.spec.js

Example Solution

./src/sort-numbers/example-built-in-sort

/practice-code-review
  /src
    /challenge
      /strategy
        /README.md
        /sandbox.js - for experimenting and logging
        /solution-name.js - for your function
        /solution-name.spec.js - for your tests

Planning

Your group doesn’t need to plan much for this, it’s a group exercise not a full project. There’s no need for a backlog, dev-strategy, wireframe, … all you need is a a project board with:

• todo - solutions someone wants to try writing
• doing - the solution you are currently working on
• ready for review - solutions waiting for a code review
• done - solutions that have been merged to main/master

You don’t need to use milestones, but a label for each behavior (challenge folder) and different strategies can help finding similar solutions for inspiration. There is a template Issue and a template Pull request in this repository that point you in the right direction.

Besides that, just go for it.

Code Review

Writing your solution is only half of the exercise, reviewing each other’s code is the other half.

Branches and PRs

Develop every single solution on a separate branch then push each branch to GitHub when it’s ready for a review. There should be 1 issue, 1 PR and 1 code review for each and every solution submitted. You’ll know you’re ready for review when you’ve

1. Formatted your code
2. Passed your linting checks
3. Passed all your tests
4. Written your README

When you open your PR be sure to use the Pull Request Template for code review. After you’ve opened your PR it’s time to:

1. link your PR to your solution issue on the project board
2. request a review from 1 or two classmates
3. get started on a new solution

The Checklist

No code review is complete without a checklist. This repository has a Pull Request Template for code review with all the things to check in your code review. The checklist covers 3 different aspects of the code:

• Behavior: Is the code well documented? Do the tests make sense? Do the tests pass?
• Strategy: Is the strategy clear and well explained?
• Implementation: Is the code well-formatted? Does it pass the linting checks? Are variables well-named? Is the code clear to read and understand?

This checklist is very long to help you learn what’s important when reviewing code. Code review checklists in future projects be shorter and less detailed than this one.

Repo Setup

Not much to do, you aren’t building a web page so there is no need for boilerplate code or GitHub pages. All that matters is:

• Everyone in your group is a contributor with write access in the group repo
• in the Branches section of your repo’s settings make sure:
  • The repository requires a review before pull requests can be merged.
  • check Dismiss stale pull request approvals when new commits are pushed
  • The master/main branch must “Require status checks to pass before merging”
  • The master/main branch must “Require require branches to be up to date before merging”
• In enable the Actions section of your repository so the automated checks will run each time you send a PR to master/main

Local Setup

So you’re ready to start coding? If you haven’t cloned this repository already you should, and then …

1. Clone this repository:
   • $ git clone git@github.com:CodeYourFuture/CYF-Code-Review-Group-Project.git
2. Navigate to this repository in your local computer
   • $ cd CYF-Code-Review-Group-Project
3. Install the project’s development dependencies - you will need these for the code quality automation:
   • $ npm install

If you would prefer to develop your code with the browser’s devtools, you can use Study Lenses:

1. $ npm install -g study-lenses
2. Navigate into this folder on your local computer
3. $ study
4. The directory will open in your default browser, and you’re good to go.

Developing your Solutions

You can write, run and test your code in Node.js or the browser. Whichever you prefer.

• In the Browser: you can use Study Lenses to edit, lint, format, test and debug your code from the browser. Just make sure that the environment open is selected and set to module
• In Node.js: you can also do everything directly from VSCode using the terminal to run your code (node path/to/file.js), and the debugger to step through it. You will need to use the |> current spec file option to debug a file with tests.

Code Quality Automation

Writing code is hard. To write even just 10 lines there are 100 things you need to think about, and 1000 mistakes you can make. Developers are clever and lazy people. They have built tools to help with all of this.

NPM Scripts

This repository’s package.json has 4 scripts to help write the cleanest code you can:

Formatting

Linting

• npm run lint:ls: checks all the folder & file names in your project to make sure they fit the project conventions.
• npm run lint:md: checks all your markdown files for syntax and style mistakes.

Testing

Code Coverage

Code Coverage is a measure of how many lines of code in your function are executed during testing. For example, a unit test for a solution that uses conditional statements does not have complete coverage until every path of the conditional is executed while running the tests.

Each time you run the testing script in this repository it will build a report of your the most recent tests’ coverage in ./coverage/lcov-report/index.html. For example, if you test one challenge’s tests the report will contain info for only that challenge. If you run all the tests (npm run test -- ./src) then there will be a report for every function in the /src directory.

These reports will not be pushed to GitHub, but having poor code coverage will cause your CI to fail. So it’s a good idea to read through the code coverage report for your solution before pushing.

Careful! 100% code coverage does not mean 100% perfect code, it just means you have tested every line of your code. If your test cases are not correct, or if your function does the wrong thing, then perfect test coverage is not helpful.

Here are some links that can help you interpret the reports:

• Amy Pellegrini (stackoverflow)
• Atlassian
• Software Testing Help

Continuous Integration

For now you can think of Continuous Integration is a fancy way to say “automatically check your code before you merge”. This repository has 3 CI scripts to help your group maintain a quality and consistent code base. If any of the scripts encounter a mistake you will not be able to merge.

hint: remember to enable GitHub Actions in your repository!

lint.yml

npm run lint:ls && npm run lint:md && npm run lint:js -- ./src locally to check if this action will pass

This action will run a linting check on the ./src folder each time someone sends a PR to or pushes to main/master. All of the linting checks must pass before you are allowed to merge changes.

Don’t forget to use npm run format before pushing! The linter will also check your code’s formatting.

test.yml

npm run test -- ./src locally to check if this action will pass

This action will run all of the .spec.js tests in the ./src folder each time someone sends a PR to or pushes to main/master. All of the linting tests must pass before you are allowed to merge changes.

Incremental Development

« Precourse | Home | UX/UI Design »

“Nearly all Agile teams favor an incremental development strategy; in an Agile context, this means that each successive version of the product is usable, and each builds upon the previous version by adding user-visible functionality.”

• agile alliance

Incremental Development is a strategy for developing software. In this strategy you start with the simplest code you can possibly write to get things started. This can even be just empty files with the right names in the right folders! Then in small steps you add more code so that each little step works, builds on top of the last step, and is a little closer to the end goal.

This strategy is sooooo important to learn because programming is hard. All developers (even your coaches!) make mistakes all the time. The best way to manage mistakes is to work in small, understandable steps and making sure that each step works before moving on.

Incremental Development is more about discipline than talent. Every minute you spend practicing this now will save you hours of debugging and make collaboration a breeze!

Contents

• Module Projects
• Learning Objectives
• Suggested Study
• Weekly Details:
  • Week 1
  • Week 2
  • Week 3
• Class Recordings

Module Projects

Projects in Incremental Development are all about the workflows. Take plenty of time to familiarize yourself with Planning and Collaborating, practicing these steps is your main objective for the coming 3 weeks.

TOP

Learning Objectives

Skills and concepts you will learn in this module

TOP

Suggested Study

hackyourfuture.github.io/study

References, Tutorials and exercises to help you through this module

TOP

Week 1

This week will you will focus on how to plan, organize, and develop a software project. You will work in groups to reverse-engineer a website, with finished code as a starting point.

- [ ] [repo](https://github.com/_/_) (with a complete README)
- [ ] [live demo](https://_.github.io/_) (GitHub Pages, not Netlify)
- [/planning](https://github.com/_/_/tree/master/planning)
  - [ ] communication plan
  - [ ] constraints
  - [ ] backlog
  - [ ] wireframe
  - [ ] development strategy
  - [ ] retrospective
- [ ] [project board](https://github.com/_/_/projects/1)

TOP

Week 2

This week you will start a 2-week project where your group needs to reverse-engineer a live website, without any starter code.

- [ ] [repo](https://github.com/_/_) (with a complete README)
- [ ] [live demo](https://_.github.io/_)
- [/planning](https://github.com/_/_/tree/master/planning)
  - [ ] communication plan
  - [ ] constraints
  - [ ] backlog
  - [ ] wireframe
  - [ ] development strategy
  - [ ] retrospective
- [ ] [project board](https://github.com/_/_/projects/1)

TOP

Week 3

Second week of reverse engineering sprint.

TOP

TOP

This project was bootstrapped with Create React App.

Set up

Please fork and clone this repository. There are instructions for how to do that (and more), in the first half of the syllabus’s “Making a Pull Request”

Then navigate to the correct directory using the command line.

Once you’re in the project directory, you can run:

npm install

npm start

This runs the app in the development mode.

Open http://localhost:3000 to view it in the browser.

Test to see if it worked

Edit App.js and add a tiny change, like adding your name, to see if the change appears.

Add and commit this change to git, and push it up to your remote github repo:

git add App.js
git commit -m "Added my name to the app"
git push

Pay attention to any errors, and then check that your changes made it to github, by visiting github.com with your browser and inspecting your repo there.

All good? Then let’s get coding.

Instructions

Aim

You will be connecting to a real-time weather API to make a weather app that looks like this:

1. Getting started: Static HTML and CSS

Let’s start slow by creating the HTML and CSS we need to make the app look like the design: do this is App.js and App.css

Don’t worry about fetching data yet, you can use invented, “hardcoded” values for now - just focus on getting content up on the page and imitating the design provided. However, do not leave out the values! Put numbers in so that you can confirm how the layout will work with numbers present. Using the numbers that occur in the screenshot is a good idea.

A few things to think of:

• The font you need is called Raleway and is already loaded up into the project - but remember you’ll need to declare it in your CSS.
• You’ll need to copy the colours, spacing, layout and size of elements in the design. This is a core skill as a front-end developer! :)
• The weather icons you need are in the img/weather-icons folder, but you can use a placeholder image like this one for now if that’s easier. See the next section below for help with images.
• Extra points if you use media queries to make the app responsive ;)

A note on using images in React

There is a special way to show images from a React app created with create-react-app. You can read about how to add and use images in a create-react-app project in the official docs, but in short, you’ll need to do these two things:

At the top of your component, import the image like this (remember to give it a name!)

import storm from '../img/weather-icons/storm.svg';

Then later in your <img/> tag, use the imported value as the image source, like this:

<img src={storm} alt="storm icon" />

Once you’re happy with the way your app looks, it’s time to move on.

2. Break your HTML into React components

This is about cutting up your one big single block of HTML and putting sections of it in React components instead.

You’ll need several components - you can decide how much you want to break things up into different components, but at minimum you will need a <Search /> component, and a <CurrentWeather /> component (you can choose the naming you like).

If you find yourself copy-pasting an HTML section multiple times with small changes, you’ve probably found a good candidate for a reusable React component.

Note that your React components at this stage should still have hardcoded numbers for temperature, etc.

3. Practice using props to populate your values

If you’re still new to React and props you should now spend a little time practicing passing props from parent component to child component, and using those props to populate the values (such as the temperature).

Don’t invest too much time in this, however, because what we pass will change in the next step.

4. Let’s try it with a STATIC JSON file

Now let’s use an example static JSON file and use the data in that JSON object for our temperature and other values. This means your app will read those values locally, from a static JSON file you should include in your project.

You can use this JSON file: https://samples.openweathermap.org/data/2.5/forecast?q=M%C3%BCnchen,DE&appid=b6907d289e10d714a6e88b30761fae22.

Copy all contents into a new file and add it to your project somewhere under the src/ directory. Perhaps name it FakeWeather.json and store it in a new folder src/data/.

Import it into your react app with

import FakeWeatherData from "./data/FakeWeather.json";

Into which react component should you load it? The highest component in the hierarchy that needs to know about the weather, or that needs to communicate it to its children.

About the JSON structure

Spend some time investigating the json structure and figuring out which bits you need to use.

This JSON represents weather data for just one city.

It includes an array called list containing the weather predicitons for the next 5 days, split into 8 x 3-hour chunks Each object inside list contains a weather array with an object that looks like this:

"weather": [
  {
    "id": 521,
    "main": "Rain",
    "description": "shower rain",
    "icon": "09d"
  }
]

Note: the list data includes 36 items (to cover forecasts for 5 days). The design only requires you to use enough to cover 24 hours - so you won’t need every single item in the array.

Extracting the values from the Fake Weather json

Now it’s time to replace all of the hard-coded values in your HTML (or JSX) with values from FakeWeather.json.

You will probably have to pass sections of the weather object to child components, as props.

Once you’ve got this all working, it’s time to fetch some real weather data!

5. Getting the LIVE weather data

We’ll be using data from this API: https://openweathermap.org/forecast5 for which you’ll need an API key:

1) Register to get your personal API key. This is free, and will enable you to make (limited) requests to fetch the weather data you need. Follow the steps here: https://openweathermap.org/appid

2) Once logged in, go to the API keys tab and copy the default Key. Keep this somewhere safe as you will need it when you fetch data.

3) The format you’ll need to follow to make API calls is: http://api.openweathermap.org/data/2.5/forecast?q=${CITY_NAME}&cnt=8&units=metric&appid=${YOUR_API_KEY}

where CITY_NAME is replaced by the city you’re looking for, for example ‘London’, and YOUR_API_KEY is replaced with… your personal API key, of course.

example format: http://api.openweathermap.org/data/2.5/forecast?q=London&cnt=8&units=metric&appid=57cf9da04987637a23fcbc26f5356e12 (this doesn’t work because it’s a fake API key, but when you replace it with yours, it will ;) )

Think about when you want to fetch your data…

Thinking about data flow through your components

Look at the design:

• Which components need access to the weather data?

• The first parent of all of those is probably the one in which you would fetch the weather data. It would then pass the details to its children via their props.

• The search input (e.g. ‘Birmingham’) will need to be inserted into the API url during the fetch (see CITY_NAME above)

• The response you get from the API will need to be passed down as props to the <CurrentWeather /> component so it knows what weather to display.

• As we’ve seen before, the response will include a list array containing the weather forecast for the next 5 days, split into chunks. You will only need the first item in list to display the current weather (you will use the rest of the items later to display future weather).

• Each object inside list contains a weather array with an object that looks like this:

"weather": [
  {
    "id": 521,
    "main": "Rain",
    "description": "shower rain",
    "icon": "09d"
  }
]

The id is what we’ll use to display the current weather icon (you can ignore the “icon” key in the above object).

6. Matching up the weather id with the appropriate icon

We will not be using the icon property of the data, we will only use the id and match it with our own SVG icons. You can find these SVGs in src/img/weather-icons.

You will need to write some code to do the following:

So for example, in the above response, the id was 521, which is between 500 and 599, so the icon to display will be rain.svg

7. Showing more weather information

Once you’re showing the icon, you can also display information about the temperature, the humidity etc. Have a look at the response from the API to find this information, and try to display it as shown in the design!

8. Error-Handling

What should happen if the network is down, or if someone searches for a city which doesn’t exist, or is misspelled?

Stretch goals

Display the weather forecast for the next 24 hours

Add a new section to your app that will display the weather over the next 24 hours in the given location.

Think about how you can manipulate the data to display the weather for each 3-hour chunk…

Good luck!

Record a goose sighting

Go to the ‘Record a goose sighting’ exercise

This is a fictional service, to help you record any sightings of geese (geese are awesome). It’s using the GOV.UK Design system, which are WCAG 2.1 AA compliant, and benefits from hundreds of hours of work and testing. However, even if you’re using a Design System, stuff can still go wrong…

There are places where the Design System is misused, misimplemented or misunderstood. This has caused accessibility issues, which range across code, design and content - because accessibility issues can be introduced by all of these disciplines. As such, anyone is welcome to have a go and use this as an exercise!

How to use this

The task is to find as many of the accessibility issues in this site as you can in ~20 minutes.

There is a worksheet, and there is also a list of answers - but give it the full 20 minutes before you look at the answers first, if you’re working through this alone!

If you are running this as a group workshop, there is an answerless ‘Record a goose sighting’ exercise, that you can use with attendees. This prevents them from finding answers before you’re ready to go through them!

What testing tools to use

I would recommend working through the site in the following order:

• Can you access everything by pressing the tab key?
• Does WAVE show any errors, or highlight any issues with the HTML structure?
• Does the colour contrast tab on WAVE throw up any errors?

Government Digital Services have recently published how to conduct a basic accessibility audit, which is worth a look at too.

Testing like this is a good way to identify basic accessibility issues. It would not replace an audit against WCAG 2.1 to level AA, and its ~50 criteria. Why still do it? These are tests that are quick to run, and it’s easier to fix accessibility issues at the start, rather than the end.

CYF Web Developer London test requirements

Deadlines and commmunication

• The deadline is set in Slack
• Commit often, and update your Pull Request after each stage, and ask a mentor to review it.
• We expect status updates on your progress twice per week sent by email to your Programme Manager or Tech Ed leader (ask).
• Write a professional email addressing us (the client) asking for more details. Even though most of our communication is through Slack, Emails remain an important communication tool (especially when applying for jobs).
• Continue communicating on Slack as usual
• Important - this page will be a starting point for future work including node.js/server side development.

Instructions

1. Build the page in the image attached using valid HTML/CSS

   • Please build the page so that it has all the features shown in the attached image, using the guidelines below. You are free to add your own creative design to it. If you would like to add additional features or styling, you are encouraged to do so.

   • We want to see how you build the page, so please do not use any libraries or frameworks.

   • Do not use a library for JavaScript (don’t use jQuery) - just plain vanilla JavaScript.

2. Show/Hide news Item

   • This functionality will be implemented using JavaScript - when the User clicks on a news items, it should hide. When they click again, it should show.

3. ’More Information’ form

   • The ‘More Information’ form should include client-side validation.

   • The creative identifies what fields in the form are required, but there are also some additional levels of validation that should be implemented. The complete set of requirements regarding validation is as follows:

   • The field ‘Contact name’ is required and needs to be populated to allow submission

   • The field ‘Contact email address’ is required and needs to be populated to allow submission

   • The field ‘Contact email address’ needs to conform to the format of an email address to allow submission.

   • The field ‘Contact phone number’ is NOT required, although, if this field is populated, it must contain only digits and be a maximum of 11 characters long upon submission.

4. Submitting the form with an AJAX call

   • We want the list of news to be populated dynamically from an API using an AJAX call. Once you have the first three requirements met, then please contact us to get the exact requirements for the API call.

   • The form should dissapear after a successful AJAX call with an acknowledgment that the user has successfully submitted their details.

   • If there is an error upon submission, a user friendly error message should be displayed.

5. Populating news with an AJAX call

   • We want the list of news to be populated dynamically from an API using an AJAX call. Once you have the first three requirements met, then please contact us to get the exact requirements for the API call.

   • Contact us by email NOT on Slack - with the subject of the email being “API requirements”

General requirements and considerations

Generally, you should build the web page in the way that you feel it should be built, however the following should be taken into consideration:

1. Accessibility: Ensure that your mark-up takes into account basic accessibility standards. For example, ensure form fields are accessible; that the page can be viewed and used without the need for JavaScript to be enabled and any alt attributes and similar are set. Please also consider page weight when saving images.

Google and read about accessibility if you don’t understand this requirement

2. Standards compliance: Ensure that your mark-up is W3C compliant. For example, all tags are correctly closed, tags are nested correctly and that all necessary attributes for a tag are set. Your page should validate against the online W3C checker.

3. Semantics: Ensure that your mark-up is semantic. For example, header tags are used where relevant, information follows a logical flow throughout the document and that information is displayed using the most appropriate tag.

4. JavaScript: Ensure you write neat, tidy JavaScript that you would consider suitable for a live web site. If you test your code (or even better use TDD), this will be a bonus!

5. Browsers: We only care about it running on the latest Google Chrome and one of (Safari, Firefox or Internet Explorer 10+) - always test your page on these two browsers.