Week 7

Week 7

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

Lecture Materials

Notes from class

Monday 12pm

Monday 1pm

Wednesday 12pm

Wednesday 1pm

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

Material

Lab Tasks

In this week’s lab you will write an automatic “grader” for some of the methods we worked on in week 3.

In particular, you’ll write a script and a test file that gives a score to the functionality of a student-submitted ListExamples file and class (see ListExamples.java). The specific format is that you’ll write a bash script that takes the URL of a Github repository and prints out a grade:

$ bash grade.sh https://github.com/some-username/some-repo-name
... messages about points ...

This will work with a test file that you write in order to grade students’ work. You can use this repository to get started with your grader implementation; you should make a fork:

https://github.com/ucsd-cse15l-f22/list-examples-grader

“Student” Submissions

Assume the assignment spec was to submit:

  • A repository with a file called ListExamples.java
  • In that file, a class called ListExamples
  • In that class, two methods:
    • static List<String> filter(List<String> s, StringChecker sc)
    • static List<String> merge(List<String> list1, List<String> list2)
  • These methods should have the implementations suggested in lab 3

You should use the following repositories to test your grader:

Your Grading Script

For each of the submissions above, your grader should produce either:

  • A grade message that says something about a score (maybe pass/fail, or maybe a proportion of tests passed – your choice) if the tests run.
  • A useful feedback message that says what went wrong if for any reason the tests couldn’t be run (compile error, wrong file submitted, etc.)

A general workflow for your script could be:

  1. Clone the repository of the student submission to a well-known directory name (provided in starter code)
  2. Check that the student code has the correct file submitted. If they didn’t, detect and give helpful feedback about it.
    • Useful tools here are if and -e/-f. You can use the exit command to quit a bash script early.
  3. Somehow get the student code and your test .java file into the same directory
    • Useful tools here might be cp and maybe mkdir
  4. Compile your tests and the student’s code from the appropriate directory with the appropriate classpath commands. If the compilation fails, detect and give helpful feedback about it.
    • Aside from the necessary javac, useful tools here are output redirection and error codes ($?) along with if
    • This might be a time where you need to turn off set -e. Why?
  5. Run the tests and report the grade based on the JUnit output.
    • Again output redirection will be useful, and also tools like grep could be helpful here

Do the work in pairs! As a pair, you should produce one implementation – push it to one member’s fork of the starter Github repository and include the link to that repository in your notes.

Write down in notes screenshots of what your grader does on each of the sample student cases above.

Running it Through a Server

We’ve also provided our Server.java and a server we wrote for you called GradeServer.java in the starter repository.

You can compile them and use

java GradeServer 4000

to run the server.

Look at the code to understand the expected path and parameters in GradeServer.java. Loading a URL at the /grade path with one of the repos above as the query parameter. What happens?

That’s quite a bit of the way towards an autograder like Gradescope!

Write down in notes: Show a screenshot of the server running your autograder in a browser.

Discuss and write down: What other features are needed to make this work more like Gradescope’s autograder? (Think about running for different students, storing grades, presenting results, etc)

Congratulations! You’ve done one kind of the work that your TAs do when setting up classes 🙂

Week 7 Lab Report

This week’s lab report focuses on material from the week 6 lab; you can start it before the week 7 lab.

Part 1

Pick one of the tasks from the week 6 lab that your group completed in Vim in the second set of tasks. The full descriptions are in the week 6 descriptions; as a brief reminder:

  • Changing the name of the start parameter and its uses to base
  • Adding a new line to print before File[] paths = f.listfiles()
  • Changing the main method to take a command-line argument

Pick one of these, and give the shortest sequence of vim commands that your group came up with to accomplish the task. (If you don’t have access to your group’s notes or otherwise don’t know for some reason, come up with your own that is less than 30 total keys pressed).

Write out the sequence of keys to press using code formatting (with backticks `). Use <> to indicate special keys (<Backspace> or <Enter> or <Esc>) and just the keys themselves for other keys pressed. Then, for each command where you move the cursor or change the text, take a screenshot and describe which commands/keypresses got to that step.

Write out every key pressed, including if you use the arrows or h j k l to move around. These count towards the 30 keys pressed!

For example, if I were opening a program and changing the first occurrence of the word “apple” to “banana” in a file containing blueberry apple sauce, I might write:

/apple<Enter>cebanana<Esc>:w<Enter>

  • A description/screenshot of typing /apple<Enter> and the cursor jumping to the start of apple
  • A description/screenshot of typing ce, switching into input mode and deleting the word apple
  • A description/screenshot of typing banana<Esc>, replacing the text and returning to insert mode
  • A description/screenshot of typing :w<Enter, saving the changes

Part 2

When you go on to CSE30/courses beyond, internships that involve configuring servers, or any other tasks where you work on remote machines, you’ll have to make decisions about how you manage your workflow. These aren’t the only two options (indeed, here we don’t even discuss using git, for example). However, it’s useful to compare two potential strategies.

Consider performing the edit task you chose and re-running the program when you have to run it remotely. Time yourself twice:

  • Once, start in Visual Studio Code and make the edit there, then scp the file to the remote server and run it there to confirm it works (you can just run bash test.sh on the remote to test it out). Consider having the appropriate scp command in your command history or easily copy-pasteable!
  • Second, start already logged into a ssh session. Then, make the edit for the task you chose in Vim, then exit Vim and run bash test.sh.

Report how long it took you to make the edit in seconds in both styles, and any difficulties or details that came up in doing so.

Then, answer this question with a few sentences:

  • Which of these two styles would you prefer using if you had to work on a program that you were running remotely, and why?
  • What about the project or task might factor into your decision one way or another? (If nothing would affect your decision, say so and why!)

Submission

Post both parts as a page on your Github Pages site, and submit the printed-to-PDF version of the .html page to the “Lab Report 4 –  Vim” Gradescope assignment.