This repository contains all of the assignments exercises that need to be handed in for the JavaScript modules (i.e., JavaScript, Browsers and UsingAPIs) of the HackYourFuture curriculum.
Please read this README carefully before starting work on the assignment exercises.
Throughout your HYF journey you will be asked to do certain exercises. This repository contains all of these exercises for the JavaScript modules (JavaScript, Browsers, UsingAPIs). The module repositories will tell you how to hand in the assignment, the curriculum will indicate what week you will need to do.
Note that a fork of this repository will be created on the HackYourAssignment GitHub account specifically for your cohort. The name of the repository will have the format
Assignments-cohortXXwhereXXis your cohort number,
After forking and subsequently cloning your forked repository execute the following command from the command line to complete the installation:
npm install
This command:
- Installs required software dependencies from the Internet.
- Sets up folders and files used to track your progress.
You will be spending a lot of time in VSCode while working with this repository. To open it with VSCode you can use the command line:
code Assignments-cohortXX
When working on your assignment it is strongly recommended to open
Assignments-cohortXXfolder itself in VSCode rather than one of its sub-folders. This gives VSCode and all its extensions the full view on the repo for the best overall developer experience.
Important: When you open the repository for the first time you may be invited to install a set of recommended VSCode extensions. These extensions will provide useful help and guidance when you are creating and editing files in VSCode. Please install these extensions when invited to do so.
If, for some reason, the prompt to install the extensions does not appear then please install the extensions manually (click on the triangle below for details).
Manual installation
If for some reason you do not see the VSCode message box inviting you to install the recommended extensions you can do so manually by clicking the Extensions button in the VSCode sidebar, pressing the Filter button and then selecting Recommended from the drop-down menu as shown in the figure below. Please install all extensions listed under the Workspace Recommendations header.
The directory structure containing the assignment for a specific curriculum module (in Figure 1 below, the JavaScript module), looks like this:
Figure 1. Directory Structure for the 1-JavaScript folder.
A similar directory structure exists for the Browser module (
2-Browsers) and the UsingAPIs module (3-UsingAPIs).
Each assignment folder contains files and (sometimes) sub-folders that make up the exercises. The exercises consist of starter files that you need to complete. Some exercises consist of a single JavaScript (for example, ex1-giveCompliment.js). Exercises that are browser-based are mostly contained in sub-folders (for example, ex1-bookList in the 1-Browsers/assignment folder).
You should not change anything in the
unit-testssub-folder. The purpose of this folder will be explained later.
As mentioned, each exercise comes with starter code. Inside the starter code you will find comments that indicate the places where there is something for you to do. For example, in the code of the JavaScript file ex1-giveCompliment.js as shown in Figure 2 this is:
- The parameter list (if needed, for you to figure out) of the function
giveCompliment. - The function body of
giveCompliment. - The value of the variable
myName.
export function giveCompliment(/* TODO parameter(s) go here */) {
// TODO complete this function
}
function main() {
// TODO substitute your own name for "HackYourFuture"
const myName = 'HackYourFuture';
console.log(giveCompliment(myName));
console.log(giveCompliment(myName));
console.log(giveCompliment(myName));
const yourName = 'Amsterdam';
console.log(giveCompliment(yourName));
console.log(giveCompliment(yourName));
console.log(giveCompliment(yourName));
}
// ! Do not change or remove the code below
if (process.env.NODE_ENV !== 'test') {
main();
}Figure 2. Starter code example: file ex1-giveCompliment.js.
In general, you should only change or add code in the places indicated by the // TODO comments. Once you have implemented what the // TODO comment asks you to do, remove the // TODO comment itself.
You should not delete or rename existing function(s), nor should you change the file names of the starter files. This repository comes with an automated test facility that relies on the presence of these files and functions.
You are allowed to add additional functions and/or global variables (but avoid global variables if you can).
When you are in the process of making changes to a file you will notice a dot or bullet appearing after the file name in the tab of the editor window, as shown in Figure 4 below:
Figure 3. Unsaved changes
This indicates that you have unsaved changes. Once you are done, you can use the File, Save menu commands (or a keyboard shortcut) to save the changes. However, in this repository we have included a setting that automatically saves changes for you whenever you click away from the editor window.
If you are curious about the VSCode settings that we included in this repo, check the file
settings.jsonin the.vscodefolder. The setting we mentioned in the previous paragraph is: "files.autoSave": "onFocusChange".You can learn more about VSCode settings here: User and Workspace Settings.
This is a recommended VSCode extension that we have included in this repo. Prettier is an automatic code formatter to make your code look "pretty". However, it is not just that your code is made pretty, it formats your code into a popular standard that has become well established in the JavaScript community. Other developers, whether trainees, mentors or, later, your colleagues will thank you for using it.
Ensure that you do not install any other code formatter extensions, for example, Beautify, in addition to Prettier. This may cause formatting conflicts.
Another recommended extension is we have included is ESLint. This tool will check your code for coding style errors. Style errors will not necessarily prevent your code from running correctly. However, they indicate that your code does not conform to a preferred coding style. For instance, if you define a variable using the let keyword and you do not reassign that variable elsewhere in your code then ESLint will warn you to replace let with const. In Figure 4 below you can see that the variable name myName has a squiggly colored underline. If you hover your mouse over the variable a pop-up window will appear.
Figure 4. ESLint warnings
You can also inspect the Problems pane or the left hand size of the VSCode status bar to see whether any problems have been detected, as shown in Figure 5.
Figure 5. VSCode Problems Pane
A further extension that we have included is a spell checker that understands code. It particularly understands that variable, property and function names are often multi-word names that use camelCase, PascalCase, snake_case or kebab-case. When it checks for spelling errors it knows how to break up these multi-word names before checking the broken down words against its dictionary. Spelling mistakes are indicated by squiggly underlines and also reported in the Problems pane.
Take pride in the correct spelling in your code. It is a sign of professionalism!
While working on the exercises you can test-run your code in the usual way, either using the command line (for node-based programs) or by running it in the browser (for browser-based applications). As mentioned earlier, in the JavaScript module you will be working with Node-based programs.
To run the exercise while in VSCode, first open a VSCode Integrated Terminal. You can do so from the VSCode menu, by selecting the Terminal, New Terminal menu commands, or by using the keyboard shortcut as listed in that menu.
Tip: for an overview of the keyboard shortcuts available in VSCode, select the Help, Keyboard Shortcut Reference menu commands. This will open a PDF file in the standard browser, listing all available shortcuts.
The most convenient way to run an exercise from the command line is to use the exercise runner included in this repo. Type the following command to run an exercise this way:
npm start
This will lead you through a series of prompts, similar to as shown below, to select the exercise to run:
? Which module? 1-Javascript
? Which week? Week3
? Which exercise? ex1-giveCompliment
Running exercise, please wait...
You are exciting, HackYourFuture!
You are marvelous, HackYourFuture!
You are awesome, HackYourFuture!
For Node-based programs the console output will be shown in the terminal window. For browser-based application an HTTP server will be started and your web page will opened in the default web browser.
Alternatively you may choose to run the exercise manually. The easiest way for a Node-based program is to open a new terminal window directly in the folder that contains your exercise, to right-click its name in the File Explorer pane and select the Open in Integrated Terminal option from the context menu, as shown in Figure 6 below.
Figure 6. Open in Integrated Terminal
This will open a terminal window at the bottom of the screen, as show in Figure 7 below (using PowerShell in Windows or bash or zsh in MacOS or Linux):
Figure 7. Terminal Window
Because we used the context menu in the VSCode File Explorer, the current directory in the terminal window is already the assignment folder containing the exercise. We can execute our program (in this example ex1-giveCompliment.js) by typing node, followed by a space and then enough characters to uniquely identify the file. Then press the Tab key to expand the file name. Because the names of all exercises start with exπ, where π is a number, it is enough to type just that and press the Tab key:
node ex1- (press TAB)
This will run the code and any console.log statement will print in the terminal window. The unmodified code example will just print:
β― node .\ex1-giveCompliment.js
undefined
undefined
undefined
It is now up to you to complete the code so that it, perhaps, produces something like:
β― node .\ex1-giveCompliment.js
You are lovely, HackYourFuture!
You are great, HackYourFuture!
You are awesome, HackYourFuture!
Once you are satisfied with the results it is time to use the test runner, as described next.
IMPORTANT: it is not recommended to use the test-runner if your code still crashes when run directly. This will just crash the test runner too. You should at least have some running code before trying it with the test runner.
The repository includes an automated test facility. It serves two purposes.
-
It allows you to test yourself whether your finished exercise meets some important requirements of the assignment. Consider this a form of early feedback. Your assignment will also be reviewed by a mentor for more thorough feedback later but that make take a while to complete.
-
It allows mentors to gain a quick insight on some key quality benchmarks, giving them a head start in the review process.
The tests that we have provided here cannot possibly test conformance to every detail of the exercise assignments. Therefore running a successful test is just a first indication of success. Ultimately, it will be the mentor reviewing your assignment to give the final verdict.
Each time you have made changes to an exercise you need to test your changes.
To run a test, type the following command from the command line:
npm test
The test runner examines the exercise files in your repo and if it finds exactly one modified exercise it will prompt you whether you want to test that one. For example:
? Test modified exercise (1-JavaScript, Week2, ex1-giveCompliment)? (Y/n)
If that is what you want, accept the default by just pressing Enter to run the test. Otherwise enter n and press Enter to let the test runner present you a menu from which to select an exercise to test.
? Which module? 1-JavaScript
? Which week? Week2
? Which exercise? ex1-giveCompliment
Once an exercise has been selected the test runner will execute the test, as illustrated in the example of Figure 8 below:
Running test, please wait...
*** Unit Test Error Report ***
Command failed: npx jest H:/dev/hackyourfuture/temp/Assignments/.dist/1-JavaScript/Week2/unit-tests/ex1-giveCompliment.test.js --colors --noStackTrace
FAIL .dist/1-JavaScript/Week2/unit-tests/ex1-giveCompliment.test.js
js-wk2-ex1-giveCompliment
β should exist and be executable (2 ms)
Γ should have all TODO comments removed (1 ms)
β `giveCompliment` should not contain unneeded console.log calls (1 ms)
Γ should take a single parameter (1 ms)
β should include a `compliments` array inside its function body (1 ms)
Γ the `compliments` array should be initialized with 10 strings
Γ should give a random compliment: You are `compliment`, `name`! (1 ms)
β js-wk2-ex1-giveCompliment βΊ should have all TODO comments removed
expect(received).toBeFalsy()
Received: true
β js-wk2-ex1-giveCompliment βΊ should take a single parameter
expect(received).toHaveLength(expected)
Expected length: 1
Received length: 0
Received function: [Function giveCompliment]
β js-wk2-ex1-giveCompliment βΊ the `compliments` array should be initialized with 10 strings
expect(received).toHaveLength(expected)
Expected length: 10
Received length: 0
Received array: []
β js-wk2-ex1-giveCompliment βΊ should give a random compliment: You are `compliment`, `name`!
expect(received).toBe(expected) // Object.is equality
Expected: ""
Received: "compliment is not randomly selected"
Test Suites: 1 failed, 1 total
Tests: 4 failed, 3 passed, 7 total
Snapshots: 0 total
Time: 1.71 s
Ran all test suites matching /H:\\dev\\hackyourfuture\\temp\\Assignments\\.dist\\1-JavaScript\\Week2\\unit-tests\\ex1-giveCompliment.test.js/i.
No linting errors detected.
No spelling errors detected.
Figure 8. Running a test.
Unit tests are software tests that determine whether a particular part of your code produces an expected result. If is it does, it is said to pass the test. If it doesn't, the failing test will be reported in the console.
In Figure 8 the test results are shown for the still unmodified version of ex1-giveCompliment. There are 4 such failing unit tests (marked with x). The messages are hopefully sufficiently informative for you to correct the error(s).
Once you have corrected the error(s), rerun the test to try again.
These are not programming errors but coding style errors. For instance, the unmodified exercise ex3-tellFortune.js produces this ESLint error:
ex3-tellFortune.js
46:10 error 'selectRandomly' is defined but never used no-unused-vars
In this example the error message indicates that a style error was detect in line 46, column 10 of the file ex3-tellFortune.js. The variable (or function) selectRandomly was defined but never used.
Style errors do not prevent your code from running correctly. However, leaving them in is simply a bad practice and is a recipe for trouble in the future when other developers attempt to understand and maintain your code.
Leaving spelling errors in your code is just plain embarrassing, especially so when there are tools to check for them. Always correct spelling errors, or, if you know the spelling to be correct, add the word to the workspace dictionary in VSCode so that it is not reported again.
If there are no unit-test, style and/or spelling errors then all is well and you should see:
All unit tests passed.
No linting errors detected.
No spelling errors detected.
When you run a test the results are reported to the console, but also written to a report file in the test-reports folder for the assignments of current week and a test summary in the .test-results folder.
You should include the test report files in the pull request that you will make to submit your assignments. This will enable reviewers to get a quick overview of your progress, without the need to run the tests again themselves.
IMPORTANT: You are expected to run all the tests for the current week before submitting a pull request.
You should strive to complete all tests with no errors reported, however it is okay if for some reason you were unable to fix some error and need your mentor to help during review. Nevertheless, you are required to run the tests, whether successful or not.
More information about the review process:
Here you will find some documentation how to write exercises and unit tests.
The HackYourFuture curriculum is subject to CC BY copyright. This means you can freely use our materials, but just make sure to give us credit for it :).
This work is licensed under a Creative Commons Attribution 4.0 International License.
