This is not the current offering of the course. You may want the next offering at, or scroll down for the winter 2022 material.

Week 5

Week 5 – It Works on My Machine

Due This Week

Notes from Class

1pm Monday

2pm Monday

3pm Monday

Lab Tasks

As usual, some of the lab tasks could change a bit before Wednesday, but the general outline is here.

Note that the skill demonstration description is firm, and we’ll only add clarifications and extra information, not change the task, at this point.

Today is a bit “potpourri” and a bit “choose your own adventure.” There are a few short things I want to make sure everyone does, and then a few options for how to spend your time. These include some cool tips and tricks that might help you out in the future, some situations that students have run into explicitly in class, and a space to chat about what you’re doing for your skill demo.

Do the required tasks, then as a group pick some of the others to try. If you have time, do them all!

Required Task – Synchronize Your Group Work

You’ve all done some work either in the same repository or in different repositories over the last few labs. Take some time to make sure everyone has the most up-to-date version of the markdown-parse you’re working on as a group. You could do this in a few ways; figure out which strategy works best for your group! For example, you might:

  • Put all links to Github repositories in your shared notes doc
  • Have one person add all the tests + fixes from the other repository to their repository
  • Have everyeone else copy that work back to their own copy
  • Have everyone pull/clone their copy and make sure they can run the tests

Write in notes: Include screenshots from each group member getting it all to work.

Required Task – Setup Github Actions on a Repository

In class on Monday, we saw how to create a Github Action that would run our tests. Refer to that video. Set up a Github Action that runs your JUnit tests from last week. (You can see how it was set up here:

Commit and push a failing test. How does it show up on Github? Do you get any other notifications?

Commit and push a fix to the test. How does it show up on Github? Do you get any other notifications?

Write in notes: Take screenshots of and copy links to the output from the above steps.

Required Task – Improve markdown-parse

In the past few labs, you worked on adding tests and improving markdown-parse.

Do this once more – add one new failure-inducing input, add it as a JUnit test, then commit and push with the failing output in the commit message.

Then, come up with a fix/improvement to the code to address this case while still succeeding on all the previous test cases. Commit and push the change.

Write in notes: Add the links to the commits you made above.

Group Choice 1 – Streamline ssh Configuration

When you log into ieng6 from your laptop, you type something like:

$ ssh

That’s a lot to type and remember! SSH, like many programs, has configuration files that can save you some typing. You can put an entry in ~/.ssh/config that tells SSH what username to use when logging into specific servers, and even give servers nicknames. For example, try opening ~/.ssh/config (on your computer, creating it if it doesn’t exist), and adding these lines:

Host ieng6
    User cs15lwi22zzz (use your username)

And then try this command:

ssh ieng6

If things are set up correctly, this should use the key and log you in with the username you specified using your public key.

If this doesn’t work, you can try adding a line to explicitly refer to your id_rsa file:

Host ieng6
    User cs15lwi22zzz (use your username)
    IdentityFile ~/.ssh/id_rsa_ucsd

Note that paths may look a little different on Windows, they may use \ instead of / for instance. Talk with your group and think about any errors you get, and if they could be related to paths or other issues you’ve seen in the past!

Write in notes: Take screenshots of your new login that’s faster and easier to type! It will look something like this:

⤇ ssh ieng6
Last login: Tue Feb  1 15:54:09 2022 from
quota: No filesystem specified.
Hello cs15lwi22, you are currently logged into

You are using 0% CPU on this system

Cluster Status
Hostname     Time    #Users  Load  Averages
ieng6-201   15:55:01   21  0.25,  0.44,  0.62
ieng6-202   15:55:01   20  0.11,  0.07,  0.07
ieng6-203   15:55:01   13  1.27,  1.32,  1.28

Tue Feb 01, 2022  3:56pm - Prepping cs15lwi22

You can change ieng6 after Host to another name if you like; it’s an alias you are inventing for ssh to interpret.

A related post is this answer.

Group Choice 2 – Set up Github Access from ieng6

In command-line git, we saw in class how to use clone and pull to get code from Github, and git status to check the status. We didn’t see as much how to commit and push from the command line. In fact, if you try to do this from the command line, you’ll likely see an error! Here’s what it looks like for me after I make an edit to and try to add, commit, and push it:

⤇ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)

no changes added to commit (use "git add" and/or "git commit -a")
⤇ git add
⤇ git commit -m "adding a line"
[main 4cbda16] adding a line
 1 file changed, 2 insertions(+), 1 deletion(-)
⤇ git push origin main
Username for '': jpolitz
Password for '':
remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead.
remote: Please see for more information.
fatal: Authentication failed for ''

The error message, with this article referenced, explains that you can no longer use a password for this operation. You must use a token-based login mechanism like SSH keys.

To address this, you can follow the instructions here in this tutorial to add the public key you made as part of the remote access lab to Github. You can also make a new SSH key and have one for your access to ieng6 and one for access to Github. Try it!

Write in notes: You’ll know you’ve succeeded when you can use git push origin main after committing to push your changes to Github from the command line.

Managing Multiple Keys

If you do make another key, you can also make a change to your .ssh/config on your computer to have an entry for Github. For example, Joe has this entry in his .ssh/config:

    User jpolitz
    IdentityFile ~/.ssh/id_rsa_github

When I made that key, I didn’t just press Enter to use the default filename, but made a new file by writing out the path to it:

⤇ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/joe/.ssh/id_rsa): /Users/joe/.ssh/id_rsa_github

A Key on ieng6

For even more command-line pushing fun, you can also run ssh-keygen while logged into your course-specific account, then copy the public key to Github following the tutorial above. That will allow you to push to Github from the ieng6 machines. If you’re working on those computers while physically in the labs, it’s a good idea to get this set up!

This kind of use case is why Github lets you upload multiple different public keys.

Group Choice 3 – Copy Whole Directories with scp -r

We’ve often been working with entire directories of files (like with lib/). Our strategies for copying a single file with scp from week 1 won’t necessarily work as a result, or at least will be much more onerous (we’d have to copy file after file). And with subdirectories like lib/, we’d have to figure out how make the directories on the remote server, and then copy the files inside… tiring and error prone!

Thankfully, scp has an option for handling this. We can ask scp to copy recursively, meaning it will copy a directory and all the files and directories within it, and all the files and directories within those, and so on.

That means we could copy our whole markdown-parse directory to the server with one command (and then use other tools we know to run the code there).

Say we’re in a terminal, and the working directory is our checkout of markdown-parse:

⤇ pwd
⤇ ls

We can use scp to copy this directory (represented by .) to the remote server. We also have to give a name of the directory we want it to copy into on the remote server:

$ scp -r .

The -r option tells scp to work recursively. The . is the source, and is the current directory. The ~/markdown-parse tells scp to create the markdown-parse directory on the remote server (if it doesn’t exist), and then copy the contents of this directory recursively there.

If we do this, then we can log into the server with ssh and see all of our files there in a directory called markdown-parse:

⤇ scp -r . ieng6:markdown-parse                                 100%   39    13.5KB/s   00:00                        100%  568   205.4KB/s   00:00
...                                 100%   27    12.8KB/s   00:00                                 100%  110    56.1KB/s   00:00
⤇ ssh
[cs15lwi22@ieng6-201]:~:99$ ls markdown-parse

Note that when we do this it copies not just the files we see with ls, but all of the files in .git as well. This is fine for most uses you’ll run into. However, you can have more control over what gets copied. Try this command:

⤇ scp -r *.java *.md lib/

What does that copy? What do you think *.java and *.md mean?

Write in notes: Take a screenshot of copying the files with scp as above. Can you come up with a way to write a single command that will copy a whole directory, then ssh to the server and run a command?

Note that if you did the first option for streamlining your .ssh configuration, you can use the short name for ieng6 in all of these scp and ssh commands! For example you could shorten the second command to

⤇ scp -r *.java *.md lib/ ieng6:markdown-parse

(A useful reference on scp -r is this answer online on serverfault)

Group Choice 4 – Discuss Strategies for Skill Demo Video

Have a conversation about tips, techniques, and strategies for your first skill demonstration video! The sample video and task is below. Feel free to ask questions about it on Piazza.

Skill Demonstration 1

For your first skill demonstration video, you will record a screencast of yourself (using Zoom is one good way) demonstrating some of the concrete skills you learned in the first 4 weeks of the course.


In the video, show:

  • Your face + a photo ID (that’s the only time you have to show your face)
  • Creating a new repository on Github
  • Creating a file with a Java class
  • Creating another file with a JUnit test for a method in that class, the test must fail initially
  • Add any code/libraries needed to make the JUnit test run
  • Commiting all of the code/libraries required for running that test
  • Running the test in your cs15l course-specific account
  • Fix the test so it passes, then run it again on your cs15l1 account and commit/push the changes (you can commit/push and run the update in any order)

Constraints and Examples

You must do this all in one take (you can’t stitch together multiple videos) and the video needs to be less than 15 minutes. Probably your first try won’t be 15 minutes – you may have to practice several times to get the process down to 15 minutes; you are free to ask for any help you need in getting your own process down to that time!

The classes and method you create can be anything, and you could copy/paste their contents from somewhere, but you have to create the files as part of your video.

Similarly, you have to create a new repository as part of the video, perform all commits as part of the video, show the tests running as part of the video, and so on.

It’s up to you how to run the test in your cs15l account:

  • You could scp the relevant files after they are created and/or updated
  • You could ssh into your account and clone the repository, then pull on updates
  • You could do something else that you prefer

Here’s an example of Joe doing the task:

A brief tutorial on how to make a recording with Zoom is here:


The video must be submitted by 5pm Friday, February 4.

Upload your video file to the Skill Demonstration 1 - Video assignment on Gradescope. Make sure to try uploading well in advance of the deadline for two reasons:

  1. Make sure that you aren’t recording an extremely large/high-definition video; there are some (reasonable) file-size limits
  2. Make sure you have time to upload the video

If something goes wrong for you uploading near the deadline (for example, you only have a link to a video instead of an actual video to upload for some reason), upload a README file explaining the situation to the best of your ability instead of the video itself.

Once submitted, you should be able to see the video file you uploaded and check that it plays within Gradescope. Please do so!