Week 7

Week 7

Table of Contents

Due Dates & Links

Lecture Materials

Lecture Video (Leads into Wednesday)

In-class notes

Wednesday Notes (1)

Wednesday Notes (2)

Video Shorts

In-class notes

Wednesday Notes (1)

Wednesday Notes (2)

Note: Links will require you to log in as a UCSD student

Lab Tasks

Discuss with your group:

Image

Write down your answers (and why you chose them!) in your group’s shared doc.

CLDQ – CSE Labs “Done Quick”

Introduction

There are many things we can do to speed up working with the command line, making it more efficient and easy to use. Working quickly can dramatically change how difficult future programming tasks are for you, so it’s worth spending time getting better at using your tools.

In this lab, you’re going to learn how to make this process a lot easier for you. Then, you will compete in small teams against your peers to see who can accomplish the given command line tasks most efficiently - and maybe pick up some winners’ tricks along the way.

Challenge Tasks

These are the tasks you will be timing yourself on. As setup, Make a fork of the lab 7 repo on your Github account, so it starts as an exact copy of our repository. Before timing yourself again, make sure to delete and re-fork the repository so you’re starting from a clean state. The TAs were able to get under 5 minutes after a couple of tries.

So a run through this process will look like this. Don’t do it just yet, though. There’s a little bit of setup involved.

  1. Setup Delete any existing forks of the repository you have on your account
  2. Setup Fork the repository
  3. The real deal Start the timer!
  4. Log into ieng6
  5. Clone your fork of the repository from your Github account
  6. Run the tests, demonstrating that they fail
  7. Edit the code file to fix the failing test
  8. Run the tests, demonstrating that they now succeed
  9. Commit and push the resulting change to your Github account

Github and Login Command-Line Setup

Generating SSH Keys for ieng6

With the setup we’ve used so far this quarter, each time you log in to your course-specific account, you have to type the password. You might have noticed that during the skill demonstration you didn’t have to type the password for our instructor accounts! Here, you’ll learn how to configure that for yourself (it will save lots of time).

  • In your local terminal, run ssh-keygen
  • Keep entering <Enter> until the program shows some text it calles the “randomart image”.
    • Note the path where the public key is saved (underlined below).
    • Image
  • Now, log into your remote course specific account on ieng6
  • Run mkdir .ssh in the terminal
  • Logout of your remote account
  • Now, we want to copy the public SSH key you created onto your remote account, specifically inside the .ssh directory you just created, in a file called authorized_keys.
  • Scroll up a bit to where you were creating the SSH key, find the line where it says: Your public key has been saved in: <path to your public SSH key>, copy the path. Make sure you get the public key file, ending in .pub, here, not the private file.
  • From your local computer, run scp <path to your public SSH key> cs15lwi23__@ieng6.ucsd.edu:~/.ssh/authorized_keys
    • Enter password when prompted (this will be the last time you have to type it!)
  • Try to log onto your remote account again, you shouldn’t be prompted for a password anymore. If you are, ask for help and carefully review the steps above with your partner.

Generating SSH Keys for GitHub

You can access and write data in repositories on GitHub.com using SSH. When you connect via SSH, you authenticate using a private key file on your local machine, which in our case will be the ieng6 machine.

Create a private SSH key file in ieng6. This is a new private key just for accessing Github from your course-specific account.

  • Login to ieng6 as usual (hopefully, without typing a password now!)
  • Run the command ssh-keygen, and again press Enter until the command completes and shows the “randomart image”

Next, we want to add a the public key to your Github account. This is like the step of copying the public key to authorized_keys on ieng6, but instead we’re copying to Github.

  • Display the SSH public key generated above to your clipboard using cat like below; you can copy it by highlighting and right-clicking
    • cat <path of your ssh key .pub file>
  • Open your Github account on the browser.
  • In the upper right corner, click on your profile photo, then click Settings.
  • In the “Access” section of the sidebar, click SSH and GPG keys.
  • Click New SSH key or Add SSH key under the “SSH keys” section.
  • Add a “Title” to your key (ex: Your Name’s ieng6 machine).
  • Select the “Key Type” to be an Authentication Key
  • Copy your public key from the output of the cat command and paste it into the “Key” field
  • Click Add SSH key.
  • If prompted, confirm access to your account on Github.

Go back to the ieng6 terminal and:

  • Run the following command to add Github.com as a recognized host (this avoids the scary yes/no prompt about accepting new connections the first time you connect)
    • $ ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts
    • >> means “append stdout of the command to file”
  • Check your connection by running the following command:
    • $ ssh -T git@github.com
    • It will say something like “Hi supercoolstudent1234! You’ve successfully authenticated, but GitHub does not provide shell access.”

Now we have an SSH key which can be used to authenticate to GitHub! In addition to using https clone URLs, we can now use SSH clone URLs that look like this:

Image

Crucially, these will allow both cloning and pushing to the repository (as long as your account has access). With this done, try cloning your fork of the lab 7 repository (make a fork if you didn’t already), then making a small change, and pushing it with the command line.

If you’re not sure how to add, commit, and push from the command line, refer to the lecture video from Monday.

Make sure you can make a change to your repository by editing, adding, and pushing all from the command line before going on!

Baseline

Before you (potentially) race against others, you are going to see how much you can improve your own time. So you’ll first take a baseline measurement of performing the tasks above by timing yourself. Your phone may have a timer app, or you can find one by searching for online timers. The steps from above are duplicated here:

  1. Setup Delete any existing forks of the repository you have on your account
  2. Setup Fork the repository
  3. The real deal Start the timer!
  4. Log into ieng6
  5. Clone your fork of the repository from your Github account
  6. Run the tests, demonstrating that they fail
  7. Edit the code file to fix the failing test
  8. Run the tests, demonstrating that they now succeed
  9. Commit and push the resulting change to your Github account (you can pick any commit message!)

Write down in notes: What was your baseline time? Did your lab partner have a faster baseline than you? If so, do they have any tips to help you get started on boosting your efficiency?

Speed Up

Now, you will explore various ways that you can speed up your work. Try all the steps below, and find out what works best (and what doesn’t work) for you!

Auto Completion

  1. Using Bash History (up/down arrows)
    • You can use the “up” and “down” arrows to go through the history of commands you have executed, it makes executing the same command much easier! If you run the commands you care about, then log out and back in, they are still in the command history!
    • You can use Ctrl-R to search your command history. At the bash prompt, type Ctrl-R and then start typing part of a command – what shows up? Experiment with using Ctrl-R
  2. Using Tab
    • You can use the Tab key to speed up typing commands in the command line in the following ways:
      • Start typing the first few letters of a command or path. Pressing tab once will autofill the rest of the line up to the point where there are multiple potential possibilities. If you press tab a second time, it will show you all of the possibilities for what it could autocomplete to.
  3. Keyboard Shortcuts while editing commands
    • More details at: https://www.redhat.com/sysadmin/shortcuts-command-line-navigation
    • Have you had a time where you mistyped one of the commands and had to backspace all the way back to fix the problem? There’s a better way!
      • Ctrl-U deletes everything from the current cursor position to the beginning of the line
      • Ctrl-K deletes everything from the current cursor position to the end of the line
      • Ctrl-A goes back to the beginning of the line
      • Ctrl-E goes to the end of the line
      • Ctrl-W deletes the last word
      • Alt-Left/Alt-Right (Windows) or Option-Left/Option-Right (Mac) to move by word
      • Click the “left” or “right” arrow to go to the left/right end of any selection!
  4. Quick Copy/Paste
    • Use these keyboard shortcuts to highlight text quicker:
      • Double click – selects an entire word
      • Triple click - selects an entire paragraph
      • Alt+Shift-Left/Alt+Shift-Right (Windows) or Option+Shift-Left/Option+Shift-Right (Mac) - select multiple words
    • On Mac:
      • Command-C to copy
      • Command-V to paste
    • On Windows:
      • Ctrl-C to copy
      • Ctrl-V to paste
      • Right click to paste in Windows terminal

New PR!

After practicing with the above, time yourself again doing the same tasks. Don’t forget to delete and re-fork the repository before timing!

Write down in notes: How much were you able to improve from your baseline?

The Tournament – CSE Labs Done Quick (#CLDQ)

Now, it’s time to race your peers in small groups! By the end of lab, only one lab group will come out on top.

Image

Find Your Group’s Champion

Within your group, anyone who wants to be a contestant in the CLDQ championship should have an initial race.

Have someone start a timer and say “go” (make sure you have a fresh fork, etc, before starting!), and race the others in your group to finish. Whoever goes fastest in your group will be the representative of your group in the Aisle stage.

There are 20 total minutes for this stage. After you select the champion, the whole group should work together to think of ways to speed up their process. All members should help the champion to prepare for the competition. Look at their preferences, and make any suggestions that you think could speed them up even more (make sure to have them try, first).

Write down in notes: Who was the champion of your team to compete in the first round? Did you make any last minute changes to their plan before the aisle race?

Aisle Round

In this round, your tutor will organize you and give you the signal to start the clock! Race against the lab group next to you.

Then, after you have the winner, the whole aisle should work together to suggest improvements for the final round across lab aisles. Take 5-10 minutes to do this.

Write down in notes: Who was the champion of your aisle in the first round? Did you make any last minute changes to their plan before the aisle race?

Final Race

For the final round, the course staff will help organize the 2-4 champions from the aisle for optimal comparison. Pay attention to their instructions to get set up, and wait for their signal to get started.

The winner of each lab room will get a full pass on their second skill demo…. most likely. Not officially as a prize or anything. It’s just a good signal that they’ll succeed at skill demonstrations.

Reflect

Write down in notes:

  • What were the strategies used by the finalists?
  • How were they similar and how were they different from the strategies used by your group?
  • What’s something you learned from one of the contestants outside of your group?

(The “Done Quick” naming scheme is from a charity video game marathon called Awesome Games Done Quick)

Lab Report 4 (due start of week 8)

For the lab report this week, reproduce the task from the competition on your own. For each numbered step starting right after the timer (so steps 4-9), take a screenshot, and write down exactly which keys you pressed to get to that step. For special characters like <enter> or <tab>, write them in angle brackets with code formatting. Then, summarize the commands you ran and what the effect of those keypresses were.

For example, when you run the tests, you might want to use the up arrow or Ctrl-R to access your bash history rather than typing in the full command with classpath, etc. You might say something like this accompanying the screenshot for running the tests:

Keys pressed: <up><up><up><up><enter>, <up><up><up><up><enter>

The javac -cp .:lib/hamcrest-core-1.3.jar:lib/junit-4.13.2.jar *.java command was 4 up in the search history, so I used up arrow to access it. Then the java -cp .:lib/hamcrest-core-1.3.jar:lib/junit-4.13.2.jar org.junit.runner.JUnitCore command was 4 up in the history, so I accessed and ran it in the same way.

Add this lab report to your Github Pages site, and submit a PDF of it as usual.