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.

How to run locally

This is built using the GOV.UK Prototype Kit.

To run it locally, clone it down, run npm install and then npm start. It’ll then tell you a port to go to in the browser.

Alternatively run it via docker & docker-compose

Depends on docker install and docker-compose install

1. docker-compose build
2. docker-compose up

Or get a bash console where you can run npm cmds via the built container (ensure step 1 above is done)
docker-compose run --rm --service-ports --entrypoint="bash" goose

Run the tests via docker
docker-compose run --rm --entrypoint="npm run test" goose

Suggesting changes

Feedback is welcome. Either submit an issue, or open a PR.

Resources for further learning

• Udacity Accessibility course - good for futhering knowledge about writing accessible code
• GDS WCAG 2.1 Primer - good for helping you understand the Web Content Accessibility Guidelines
• GDS guidance how to conduct a basic accessibility audit - mentioned above but listed here as well
• a11y weekly - a good weekly newsletter about accessibility

Any other suggestions, free free to add them!

Other versions of the exercise

This version is forked (and revived) from the MoJ archived repo. Other forks:

• NHS Accessibility exercise
• Coop accessibility exercise - ‘Report a leaky bag of flour’

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.