In this week’s lab you will:
- meet the tools you’ll need in this course:
go through the steps you’ll need to submit all assignments in this course (so it’s really important you can do them now—don’t leave this stuff till the last minute)
- put a circle on the internet (yew)
Introduction: a pre-lab
Lab 1 is a bit of a weird lab—it’s more like a pre-lab before the normal lab material starts in week 2. You can work through it at any time, either on campus or at home (or wherever). If you get through it ok (and can show a circle in your browser) then you’re ready to start the course. If you get stuck that’s ok: you can either ask questions on the COMP1720 forum or come to one of our week 1 drop-in lab sessions (see timetable) on Microsoft Teams.
This first lab is optional (although from week 2 onwards you’ll need to attend your lab if you want to have your visual diary entry assessed).
If you’re really familiar with this stuff, there’s a tl;dr version at the end. Again, though, I want to emphasise that it’s ok if this is all new—you’ll get plenty of support in this course to get the hang of it. All we ask is that you put in the effort.
Part 1: software setup
In this course you’ll write code using the VSCode text editor, run the code in the Firefox web browser, and download/view/submit your lab & assignment code with git You’ll also use Microsoft Teams to access lectures and labs, and to hang out with other students synchronously.
There’s a separate page dedicated to software setup, so if you’re on your own laptop you should head to the software setup page and follow the instructions.
You’ll also want to have a look at the instructions for attending online labs and lectures.
For 2020, we advise you to install the software on your own machine and to try using a virtual lab machine: ANU Virtual Information Commons.
The Virtual Information Commons lets you connect remotely to a computer running at ANU. You get the same experience as logging into a machine in a computer lab on campus. So far, there is a Windows machine available. There’s a Linux machine coming soon (should be available in Week 1).
If you are going to use your own machine (e.g. your laptop) to do the work in this course then you must read the course “own machine” policy. “I couldn’t get the git submission stuff working on my machine” is never an acceptable excuse for late/incorrectly submitted assignments.
Part 2: forking the lab 1 template
From here, we’ll use a few git-specific terms, and in general we’ll explain everything along the way. If you’re confused, though, there’s a section on git help in the course FAQ or some extra installation help available in the software setup FAQ
Once you’ve got the software you need, you have to log in to the GitLab server at using your normal ANU credentials (uni ID and password) and bring up the lab 1 repository. A repository (often abbreviated to “repo”) is basically just a box which stores a bunch of files and their history (the changes they’ve been through over time). Whenever you hear the word repo/repository, think “a directory of files which Git is keeping track of”.
If you like, there are some extra steps you can take so that you don’t have to type in your uni ID and password every time, but it’s not essential and you can also add that stuff later. If you’re new to all this git stuff, probably just stick with the ID & password for now.
This template is a starting point for everyone who wants to complete this lab, so before you can start working on it you need to create your own “copy”. This is called forking, and creates a new repo (your “fork”).
To fork the lab 1 template, click the fork button on the GitLab page in your web browser (I’ve circled it in red).
Once you’ve done that, you should see a page like the one below—you now have
your own fork (copy) of these files on the server, as indicated that it
shows your name in the top-left-hand corner (circled in green). The files are
exactly the same, but the repo is now attached to your GitLab account, rather
comp1720/2020 GitLab account, so you can change the files and push
things up to the GitLab server without messing up anyone else’s starting point.
This part of the process is covered in the forking screencast video.
Part 3: cloning the lab 1 template
Your fork of the template repo is still on the GitLab server, though. To actually work on these files, you need to clone (download) this repo to the computer you’re working on.
In VSCode, open the command palette (View > Command Palette, or
Pon macOS) and a prompt will appear in the top.
git cloneand hit enter. A box will appear asking for the repo url.
Back on gitlab, open your fork of the lab code. Directly under the page title there’s a box that looks like this (if it doesn’t say
HTTPSon the left hand side, click that box and select it. Now click on the right hand side box to copy the URL to your clipboard.)
Back in VSCode, paste the url into the prompt box and hit enter — making sure that the “Clone from URL” option is highlighted.
A window will open asking you where to save the files. If this is your own computer it might be a good idea to create a
comp1720folder and clone all your repositories there. If this is a lab computer, make sure you save this to your university homedrive (it’ll be called
u1234567). When you’ve found a good spot for you files hit Enter or click “Select Repository Location”.
Now you’ll be asked to enter your username and password. This will be the same uid and password you used to log into GitLab.
If you entered your uid and password correctly, a popup will appear in the bottom right of VSCode asking you to
Add to Workspace. Today we’re going to choose
Open Repository, but they have a similar effect.
Great job! Now lets make that circle.
This part of the process is covered in the cloning screencast video.
Part 4: making a circle
Now you’ve got the template files in VSCode you can get to work.
In the sidebar on the left you can see all the files in the template folder.
Throughout the course we’ll explain what each of these files is for but for now
the one we care about is
sketch.js. Click on that one and VSCode will open it
up and look something like this
You’re getting close to creating the circle you’ve been thinking about all
along. In the
draw function (immediately below
// your "draw loop" code goes
here) add the following lines:
Now save the file.
The final piece of the puzzle is to run/view the sketch. To do this, you need to start the live server:
- Open the command palette (View > Command Palette)
- Type “Open with live server”
- Hit Enter
Your default browser will open up and should show a white circle on a charcoal background.
As stated on the software setup page you should use Firefox as your web browser for the course, and (for convenience) you could set it to be your default browser (since that’s what the live server extension will open the sketch in).
It might not look like much, but you’ve made your first p5 sketch, and you should take a moment to enjoy your success.
Part 5: committing & pushing the changes
Now that you’ve successfully completed today’s task of putting a circle on the internet it’s important that you save your work and push it up to GitLab. This process is important to learn because it’s the way you’ll submit all your assignments for this course!
The first thing to do is save your
sketch.js the usual way (i.e. File > Save
or Ctrl-S/Cmd-S depending on your OS).
Now you want to upload your changes to the
sketch.js file back to gitlab so
it’s safe and sound. This involves some more VSCode commands so open up the
command palette using View > Command Palette.
git commit all and press enter. You’ll get a popup which says “There
are no staged changes to commit. Would you like to automatically stage all your
changes and commit them directly?”. Click
Now you’ll see a popup asking for a “Commit Message”. Write a note about the changes you made (e.g. “I added a circle to the sketch”). This message is just so you can remember what this change was so write whatever makes sense to you.
In Git’s terminology, a commit is a snapshot of your code at a particular time that you can always return to. This means that if you break your code somehow you can always feel safe knowing you can just return to your last commit where everything was working. When working on assignments you’ll want to commit your code regularly just to be safe.
Now all you have to do is push (upload) these committed changes to GitLab with
the push command. Open up the command palette using View > Command
git push and hit Enter. You might need to put your UID &
password in again at the push step. If you get an unauthorised message, try once
more and if it still doesn’t work seek help from a tutor or friend.
If everything worked successfully, then when you refresh the GitLab project page
for your fork (i.e.
https://gitlab.cecs.anu.edu.au/uXXXXXXX/comp1720-2020-lab-1) you should see
the first line of that commit message as shown:
And if you click on the
sketch.js filename further down you should see the new
version with your
ellipse line in there. Hooray!
Part 6: putting your circle on the internet
It might have felt like your sketch was already on the internet when you were building it before because it was in your browser, but really it was only visible to you. By pushing your code to gitlab, your page was automatically published online within the ANU network.
If you’re on ANU campus wifi or ethernet right now you can check this worked by
copying and pasting this link into your browser and replace
uXXXXXXX with your
If you can see your circle, great job, you’re done!
If you happen to be away from campus right now, you’ll need to use the ANU’s
reverse proxy login. This allows you to
access ANU resources (like the library) from outside campus. Use your anu id and
password to log in. Then paste the URL above (with your university id swapped
in) and click
If you can see your circle, great job, you’re done!
It’s good to get in the habit of checking the published version of your sketch every week because this is what your tutor will see when they mark your assignments.
For more information on the ANU Reverse Proxy, see the FAQ.
Part 7: the short version
Here’s the tl;dr version (if you’ve done this version control thing before, or if you’re just after a refresher):
to work on the sketch, fork the template repo to your own GitLab account
clone your fork2 to the computer you want to work on
open the folder in VSCode and start the p5 live server (
File > Command Palettetype
Open with live serverand hit Enter)
to submit your work, commit and push the changes to your fork (you can do this as many times as you like)
Congratulations! In this pre-lab you learned how to use the tools you’ll need to participate in the course. If you feel like you just typed in a bunch of things and didn’t really understand what went on, then that’s ok—we’ll explain everything during the course. But it’s imporant that you at least check that everything works for you, because if it doesn’t then you’ll have problems later on.
See you in lectures :)
If you’re on your own machine or on a lab machine, you’ll only have to do this once—after that they’ll be saved to your home directory and will be automatically detected when you log back in. Some on campus lab machines, need you to install the COMP1720 extension each time you log in (a pain, but it only takes a second). ↩
make sure you clone your own fork (i.e. the one with your uni ID in the url) to your local machine, not the template (because obviously you aren’t able to change the template for everyone—GitLab won’t let you) ↩