Week 6

Week 6

This is not the current offering of the course. You may want the next offering at https://ucsd-cse15l-w23.github.io/, or scroll down for the fall 2022 material.

Table of Contents

Due Dates & Links

  • Quiz 6 - Due 11:59am (just before noon) Wednesday November 2, 2022

Lecture Materials

Notes from class

Monday

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

Material

Lab Tasks

Sharing What You Learned

Share the link to the Github Pages site for your Lab Report 3 in your group’s lab doc, and write which command you researched for the lab report along with it.

Pair up with someone else in your lab group who chose a different command to research than you for Lab Report 3. Try one another’s examples, and talk about what you learned from trying them out. Are there any useful ways to combine the two commands? Do they answer any new questions you hadn’t thought of before?

Share what you think the coolest example is from each of your lab reports with the whole group. Write these down in notes

Doing it All From the Command Line

Editing from the command line: vim

Log into ieng6. Run the command vimtutor. Set a timer for 15 minutes.

Complete the first two lessons (go past lesson 2 if you can in 15 minutes). Really do the exercises!

After the 15 minutes are up, clone the repository from the first skill demonstration. If you already have it cloned, you can clone a new copy by giving the name of a new directory to make after the git URL, like this:

$ git clone https://github.com/ucsd-cse15l-f22/skill-demo1 week6-skill-demo1

This will clone it and put it in the week6-skill-demo1 directory.

Then, in pairs, you are going to write down exactly the keys to press to make an edit to fix the test. You’ll share these instructions in your shared lab doc, and the next group is going to use them to try and replicate what you did.

So: Fix the test using what you learned about vim in the tutorial (as a reminder, you’re changing the 10 to 1391 in the expected value of the test). Re-run the tests to make sure it works. Keep extremely accurate track of what you had to type to make this happen. You might even want to change the file back to its initial state (u is the command for undo in vim) and double-check that the instructions you are giving are good. When you’re satisfied, write down the list of keys that need to be pressed (including all uses of Backspace, Enter, Escape, and so on!) in the shared notes doc. Have one partner in your pair do this typing; the other partner shouldn’t make the edits yet because they will in the next step.

Then, go around the groups. The group to your left should use your instructions to try and make the edit, then the next group to their left will use their instructions, and so on. Watch carefully! Was each group able to? Why or why not? Did the group typing do something that didn’t match the instructions, were the instructions not complete, or did something else happen? Don’t leave any mysteries!

You can press Ctrl (or Cmd)-Shift-p and start typing “screencast” to turn on screencasting mode so others can see what you type.

Discuss and refine: After you do this, discuss how you could make the process easier. Did you have to press the arrow keys a lot? Are there vim commands that could have improved the process? How short of a key sequence can you make it to perform this edit? Can you get it under 20 keypresses including save and exit? Under 15?

Then, each group should choose one of the following tasks, and repeat this whole process (design the keys to press in pairs, write them down in the notes, then go around and try the instructions one pair at a time, with others looking on and observing).

  • In DocSearchServer.java, change the name of the start parameter of getFiles, and all of its uses, to instead be called base.
  • In DocSearchServer.java, add a new line right before File[] paths = f.listFiles(); that prints out the toString of f and a message saying it’s a directory.
  • In DocSearchServer.java, change the main method so that rather than hardcoding the search on the ./technical directory, it uses the second command-line argument for the path to search
  • Challenge In TestDocSearch.java, copy the test called testSearchCount, rename the new test to testSearchCount2 and change the query string being tested to tax rather than taxation.

After watching the other groups do their work, can you think of any ways to improve your instructions?

Practice

If you have more time, use vim to make the other change from the skill demonstration—making the server search by pathname rather than by file contents—and similarly make a commit for it.

Show the resulting git log in the notes doc.

Also write down in notes:

  • What errors or surprising behavior did you run into while doing this?
  • What’s a situation where you can imagine needing or wanting to use these command-line tools instead of more familiar ones like VScode?

If you have more time, practice doing these tasks in as few keypresses as possible.