FAQ #

Each assignment will have an FAQ linked at the top. You can also access it by adding “/faq” to the end of the URL. The FAQ for Lab 1 is located here.

Learning Goals #

In this lab, we will set up the software that we will use throughout the course: the terminal, git, java, IntelliJ, etc. We will also look at a small Java program and learn a little bit about Java syntax.

Before You Begin #

Welcome to CS 61BL! We have a wonderful summer planned for y’all, and we’re so excited that you’ll be joining us!

First things first: setup! In this class, you’ll be using real-world tools, and that means that you’ll likely run into real-world problems with configuration and setup these first few days. Don’t be discouraged, and make sure to ask for help if you’re stuck! The best place to ask for help is during your actual lab time. If you attempt to do this outside of that time and run into any problems, please ask them on Ed. For more information on using Ed in this course, read through our Ed Policies and Guidelines.

If ever something isn’t working, or a screen that should show up isn’t showing up, make sure you ask for help – do not keep going because this might make it more difficult for us to identify the problem later on if you do hit a dead-end.

Partners #

For all labs, partners are optional, and you can change partners for every lab. If you’d like to work with a partner but don’t have one, your lab TA will assign you one to work with today. For more information, take a look at our Partnership Guide.

Personal Computer Setup #

Task: Configure Your Computer #

Depending on your operating system, there are a few things we need to do to set your computer up for 61B(L).

The precise steps to take depend on your operating system.

Move on to the next section only once you’ve completed the instructions above for your operating system.

The Terminal #

Learn to use the Terminal #

In CS 61BL we will be using the terminal extensively, even more than you likely did in previous classes. Bash commands can be pretty powerful and will allow you to create folders or files, navigate through your file system, etc. To jump start your knowledge we have included a short guide of the most essential commands that you will be using in this class. Please carefully read this and try to familiarize yourself with the commands. We will help you as you get started, but by the end of the class we hope that you will have become a proficient user of the bash terminal!

  • pwd: present working directory

    pwd
    

    This command will tell you the full absolute path for the current directory you are in if you are not sure where you are.

  • ls: list files/folders in directory

    ls
    

    This command will list all the files and folders in your current directory.

    ls -l
    

    This command will list all the files and folders in your current directory with timestamps and file permissions. This can help you double-check if your file updated correctly or change the read-write- execute permissions for your files.

  • mkdir: make a directory

    mkdir dirname
    

    This command will make a directory within the current directory called dirname.

  • cd: change your working directory

    cd hw
    

    This command will change your directory to hw.

  • .: means your current directory

    cd .
    

    This command will change your directory to the current directory (aka. do nothing).

  • ..: means one parent directory above your current directory

    cd ..
    

    This command will change your directory to its parent. If you are in /workspace/day1/, the command will place you in /workspace/.

  • rm: remove a file

    rm file1
    

    This command will remove file1 from the current directory. It will not work if file1 does not exist.

    rm -r dir1
    

    This command will remove the dir1 directory recursively. In other words, it will delete all the files and directories in dir1 in addition to dir1 itself. Be very careful with this command!

  • cp: copy a file

    cp lab1/original lab2/duplicate
    

    This command will copy the original file in the lab1 directory and and create a duplicate file in the lab2 directory.

  • mv: move or rename a file

    mv lab1/original lab2/original
    

    This command moves original from lab1 to lab2. Unlike cp, mv does not leave original in the lab1 directory.

    mv lab1/original lab1/newname
    

    This command does not move the file but rather renames it from original to newname.

  • touch : create a file if it doesn’t exist

    touch lab1/newFile
    

    This command will create a new empty file called newFile in the lab1 directory.

    touch existingFile
    

    This command will leave the contents of existingFile unchanged.

  • cat : catenate file(s) to output

     cat file1 
    

    This command will print out the contents of file1 to the terminal.

     cat file1 file2
    

    This command will print out the contents of file1 followed by file2 to the terminal.

    There are some other useful tricks when navigating on a command line:

  • Your shell can complete file names and directory names for you with tab completion. When you have an incomplete name (for something that already exists), try pressing the tab key for autocomplete or a list of possible names.

  • If you want to retype the same instruction used recently, press the up key on your keyboard until you see the correct instruction. This saves typing time if you are doing repetitive instructions.

Task: Terminal Test Run #

Let’s ensure that everything is working.

Tip: We have a video below that shows what the correct outputs for these commands should look like.

  1. First open up your terminal. Check that git is a recognized command by typing the following command:

    git --version
    

    The version number for git should be printed. If you see “git: command not found”, or similar, try opening a new terminal window, restarting your computer, or installing git again.

  2. Second, let’s check that javac and java are working. javac and java allow Command Line Compilation, or in other words, the ability to run Java programs directly from the command line. In practice, most developers run Java programs through an IDE like IntelliJ, so we won’t be using command line compilation for much this semester other than testing your setup. Start by running the following commands at your terminal.

    mkdir ~/temp
    cd ~/temp
    
    1. In this newly created directory, create an empty file HelloWorld.java.

      touch HelloWorld.java
      
    2. Then, open the file using your operating system’s text editor. You can do this from the command line:

      • Mac: open -e ./HelloWorld.java
      • Windows: notepad ./HelloWorld.java
      • Linux: xdg-open ./HelloWorld.java
    3. Copy paste the following code block into the editor, then save and close.

       public class HelloWorld {
           public static void main(String[] args) {
               System.out.println("Hello world!");
           }
       }
      
    4. In your terminal, type cat HelloWorld.java. You should see the contents of the file we just created.

    5. In your terminal, enter ls (list the files/folders in this directory). You should only see HelloWorld.java listed.

    6. Run javac HelloWorld.java. If this produces any output, then something may be wrong with your setup. Try opening a new terminal window or restarting your computer. If that still doesn’t work, see the Troubleshooting section under the directions for your operating system.

    7. Type ls, you should see both HelloWorld.java and a freshly created HelloWorld.class (the javac command created this file).

    8. Run java HelloWorld. It should print out “Hello world!” for you. If it didn’t, something is wrong with your setup!

    9. You’re done! You can also delete the “temp” folder and its contents as you please.

    The video below shows what we’re hoping for when we run through the steps above. If you see something similar to this, your java setup is complete.

GitHub and Beacon #

Instead of bCourses, CS 61BL uses an in-house system for centralizing your grades and student information called Beacon.

In this section, we’ll set up your Beacon account as well as your CS 61B GitHub repository (“repo”), which you will need to submit all coding assignments.

Task: Account Setup #

  1. Create an account at GitHub.com. If you already have an account, you do not need to create a new one.
  2. Go to the Beacon website and you’ll be guided through a few steps to complete your GitHub repository registration. Please follow them carefully! You must be logged in to your Berkeley account to complete the Google Form quiz. If any errors occur while you’re working through the steps, please let your TA know immediately.
  3. After completing all of the steps, you should receive an email inviting you to collaborate on your course GitHub repository. This email will be sent to the email that you used to create your GitHub account, which may not necessarily be your Berkeley email.

Don’t follow the instructions that GitHub says you might want to do. We have our own set of instructions later in this lab.

Task: Follow the steps above to create your GitHub and Beacon accounts, and connect them.

Your Repository #

Your repository will have a name containing a number that is unique to you! For instance, if your repo is called “su23-s42”, you’ll be able to visit your private repository at https://github.com/Berkeley-CS61B-Student/su23-s42 (when logged into GitHub). If your repo number is not “42” this link will not work for you. Replace “42” with your own to see your repo on Github.

Additionally, the instructors, TAs, and tutors will be able to view your repository. This means you can (and should!) link to your code when creating gitbugs posts on Ed. No other students will be able to view your repository.

As a reminder, you may not post code from this course publicly, even after completing the course. Doing so is a violation of our course policies and you might be subject to disciplinary action.

Git #

In this course, you’ll be required to use the Git version control system, which is wildly popular out in the real world. Since the abstractions behind it are fairly tricky to understand, don’t be worried if you encounter significant frustration as you learn to use git. Towards the middle of the semester, we’ll be learning the inner workings of git in much greater detail but, for now, let’s just get a working knowledge of how to use git.

Before you proceed, read sections up to the Remote Repositories section of the Using Git Guide.

Do not proceed until you have read sections up to the Remote Repositories section of the Using Git Guide. You do not need to read past that.

Setting Up Git #

Before we use git, we have some short commands to configure it appropriately.

First, set the name and email that git will use with these two commands:

git config --global user.name "<your name>"
git config --global user.email "<your email>"

Set git’s default branch name:

git config --global init.defaultBranch main

Set the “merge strategy”:

git config --global pull.rebase false

We’ll also change the text editor associated with git. Sometimes, git needs your help when inputting things like commit messages, so it will open a text editor for you. The default editor is vim, which is notoriously difficult to use.

Follow the instructions here. This will configure Git’s default editor (make sure that you follow the correct instructions for your operating system). If you’ve worked with a text editor like VSCode, Sublime Text or Atom before, we suggest setting whatever you’re most familiar with as the default editor. If not we suggest using Notepad for Windows, TextEdit for MacOS and Nano for Linux.

Task: Configure git by following the above instructions, and set your preferred editor.

Task: Git Exercise #

Now that you’ve read the first 3 sections of the Using Git Guide, you’re ready to start using git! As part of your lab checkoff, you will be working through a small git workflow by setting up a git repository and making a couple commits to the repository. An academic intern or staff member will look at your git repository during checkoff to ensure that it is in a good state.

If you need help with creating directories, creating files, changing directories, etc., refer back to Learn to use the Terminal.

  1. Create a directory called lab01-checkoff. You can put this directory anywhere on your computer (unless you have already cloned your su23-s*** repository, in which case, you should not put this directory inside of your su23-s*** repo).
  2. Move into the lab01-checkoff directory, and initialize a git repository in this directory.
  3. Create a file called 61b.txt in any way you’d like. In this text file, add the text “61b version 1” into it.
  4. Create another file called 61bl.txt in any way you’d like. In this text file, add the text “61bl version 1” into it.
  5. Begin tracking only 61b.txt, and create a new commit containing just this file, with the following commit message: “Add 61b.txt”.
  6. Make a modification in 61b.txt by changing the text in the file to: “61b changed to version 2”.
  7. Make another commit, this time containing both 61b.txt and 61bl.txt. The commit message should be: “Update 61b.txt and add 61bl.txt”.
  8. Make one more modification to 61b.txt by changing the text in the file to: “61b changed to version 3”. Don’t commit this version.

At this point, if you were to type in git status and git log, something like this should show:

  1. Using git only, restore 61b.txt to the version in the first commit.
  2. Using git only, restore 61b.txt to the version in the most recent commit.

Be sure to save this repository and directory until you complete the asynchronous checkoff form on beacon and obtain a magic word. We’ll be using this magic word later in the lab.

Task: Do the steps above, then get checked off by filling out the Beacon form.

Git and Remote Repos #

First, read the Remote Repositories section of the Using Git Guide.

In this course, you’ll be required to submit your code using Git to your course GitHub repository that you created in Account Setup. This is for several reasons:

  • To spare you the incredible agony of losing your files.
  • To submit your work for grading and to get results back from the autograder.
  • To save you from the tremendous anguish of making unknown changes to your files that break everything.
  • To ensure that we have easy access to your code so that we can help if you’re stuck.
  • To dissuade you from posting your solutions on the web in a public GitHub repository. This is a major violation of course policy!
  • To expose you to a realistic workflow that is common on every major project you’ll ever work on in the future.
  • To enable safer, more equitable partner collaborations.

Task: Setting up your Git Repository #

Clone your su23-s*** Git Repository #

Navigate to the spot in your folders on your computer that you’d like to start your repository. In the example below, we’re assuming you want all your stuff in a folder named cs61bl, but you can pick a different name if you’d like.

cd cs61bl

Before you can clone your repo we need to login to GitHub. Verify that you have the GitHub package.

gh --version

You should see a version number displayed. If you instead see a command not found error, please install GitHub cli again by following you OS specific instructions and restarting your computer.

Next login with your account.

gh auth login

You’ll be asked a few questions with some options to select from. You don’t have to worry about them, simply select the first options for all of them and proceed. You’ll be provided with a one time code, and prompted to open the browser.

Enter the code in the browser window and select authorize github. You should now be logged in!

Windows Users: if you run into an error that says “could not prompt: Incorrect Function” run winpty gh auth login instead.

Verify that you have correctly logged in using

gh auth status

The entire process should look like this video:

Enter the following command to clone your GitHub repo. Make sure to replace the *** with your class repository number (this should be the repo number you were assigned through Beacon, not your lab section number).

git clone https://github.com/Berkeley-CS61B-Student/su23-s***.git

After cloning your terminal will report “warning: You appear to have cloned an empty repository.” This is not an issue, it is just git letting you know that there are no files in the repo, which is what we expect here.

Move into your newly created repo!

cd su23-s***

Now we will add the skeleton remote repository. You will pull from this remote repository to get starter code for assignments. (Make sure that you are within the newly created repository folder when you continue with these commands.) Enter the following command to add the skeleton remote.

git remote add skeleton https://github.com/cs61bl/skeleton-su23.git

Listing the remotes should now show both the origin and skeleton remotes.

git remote -v

If you see an error like fatal: not a git repository make sure you have properly moved into the su23-s*** directory using cd.

Getting the Skeleton #

Task: Follow the instructions in the Getting the Skeleton section of the Assignment Workflow guide to get the skeleton code for Lab 1.

At this point, you should have a lab01 folder, with the contents src/Arithmetic.java and tests/ArithmeticTests.java. If you do not have these contents, don’t make it manually! Instead, pull from the skeleton or ask a staff member.

Pushing to GitHub #

You will need the magic word (obtained from checkoff) to complete this step.

Open the file lab01/magic_word.txt in a text editor, and edit it to contain the magic word obtained during the git exercise.

Now stage and commit magic_word.txt (make sure you’re in your repo!).

git add lab01/magic_word.txt
git commit -m "Added Magic Word"

Right now, the modified magic_word.txt is only on your computer. We want to push these changes to the GitHub repository so that your changes can be seen by us and Gradescope. Push these changes to the main branch on the origin remote repo.

git push origin main

You can verify that this was successful by checking your repository online on GitHub’s website. It should contain the updated magic_word.txt file. If it doesn’t, make sure that your add and commit were successful. In particular, make sure that you are in your repo, su23-***.

Task: Follow the instructions above to push your magic word to GitHub, and check that it appears.

Our work is now on GitHub, and ready to submit!

Submitting to Gradescope #

Although we use GitHub to store our programming work, we use Gradescope to actually grade it. The last step is to submit your work with Gradescope, which we use to autograde programming assignments.

We added everyone’s CalCentral email to Gradescope on the first day of labs. Make sure to login using the email address listed on CalCentral.

If you’re having trouble accessing the course on Gradescope or would like to use a different email address, ask your TA!

As above, we strongly encourage you to make frequent commits! Lack of proper version control will not be considered an excuse for lost work, particularly after the first week.

Task: Follow the instructions in the Submitting to Gradescope section of the Assignment Workflow guide to submit to Gradescope.

At this point, Gradescope should show you something similar to the following:

gradescope failure

In CS 61BL, we use automated tests to check that your code is written correctly. In your first submission, you:

  • Should be passing “Magic Word”, if you received the magic word
  • Should be passing “Test product correctness”
  • Should not be passing “Test sum correctness”

We’ll now show you how you can work on and check your code locally, which is much easier than checking on Gradescope every time.

Setting Up Java Libraries #

Like in Python, we sometimes want to use libraries that others wrote. Java dependency management is a bit of a mess, so we instead provide a git repo that contains all the dependencies that we will use in this course.

First, move out of your su23-s*** repo with cd ... Failing to do so can cause many headaches later.

Then, run:

git clone https://github.com/cs61bl/library-su23

Below is shown the directory structure of library-su23. Look inside the folder using ls library-su23 and make sure you see the .jar files listed below. There are many more, but we only list the first few. If you’re using your operating system’s file explorer, the jar part might not show up in the filenames, and that’s OK.

library-su23
├── algs4.jar
├── animated-gif-lib-1.4.jar
├── antlr4-runtime-4.11.1.jar
├── apiguardian-api-1.1.2.jar
└── ...

Task: Follow the instructions above to get the course libraries.

IntelliJ Setup #

IntelliJ is an Integrated Development Environment or IDE. An IDE is a single program which combines typically a source code editor, tools to compile and run code, and a debugger. Some IDEs like IntelliJ contain even more features such as an integrated terminal and a graphical interface for git commands. Finally, IDEs also have tools like code completion which will help you write Java faster.

We highly recommend using IntelliJ. Our tests are written to run in IntelliJ, and we will explicitly use its debugger in later labs. Additionally, IntelliJ is an industry-standard tool that you will almost certainly encounter if you work with Java again in the future.

We will assume that you are using IntelliJ, and will not offer support for other editors, including VSCode.

IntelliJ is a real world, industrial software development application. There are many features that we will not use, and you will sometimes encounter situations that do not make sense. Ask for help if you are stuck or something seems broken! It can be very hard to guess the right thing to do in IntelliJ. Check out the IntelliJ WTFS Guide for solutions to some common problems.

Before continuing, make sure that you have completed all above tasks besides the git exercise:

  1. You have installed Java 17 or higher.
  2. You have successfully created your local repo for the class on your own machine. This is the su23-s*** repository you earlier.
  3. You have pulled from the skeleton, and you have a lab01 directory.

Installing IntelliJ #

  1. Download the Community Edition of IntelliJ from the JetBrains website. As a student you can actually get a student license for the Ultimate version, but there are not any additional features that we will use for this class. It is recommended and assumed that you proceed with the Community Edition.

If you have an M1 or M2 Mac, select “.dmg (Apple Silicon)”. Otherwise, select “.dmg (Intel).”

  1. After selecting the appropriate version for your OS, click download and wait a few minutes for the file to finish downloading.

  2. Run the installer. If you have an older version of IntelliJ, you should uninstall it at this time and replace it with this newer version.

While IntelliJ downloads, you can read / skim our Using IntelliJ Guide. You don’t need to read or internalize all of this to complete the lab. IntelliJ is complicated, but the core features should feel somewhat familiar to text editors you have used in the past.

Installing Plugins #

Open IntelliJ. Then follow the steps below.

Make sure you’re running IntelliJ Version 2021.2 or later before continuing. This is because we will use Java 17. We are using IntelliJ Version 2022.3. Older versions may also work but we haven’t tried them ourselves.

  1. In the Welcome window, click the “Plugins” button in the menu on the left.

    Configure Plugin

  2. On the window that appears, click “Marketplace” and enter “CS 61B” in the search bar at the top. The CS 61B plugin entry should appear. If you click the autocomplete suggestion, a slightly different window from what is shown below may appear – this is okay.

  3. Click the green Install button, and wait for the plugin to download and install.

    Search CS 61B

    If you have the plugin installed from a prior term, make sure to update it.

  4. Now, search for “Java Visualizer”, and click the green Install button to install the plugin.

    Search Java Visualizer

  5. Restart (close and reopen) IntelliJ.

For more information on using the plugins, read the plugin guide. You don’t have to read this right now.

Creating Projects #

Task: Follow the instructions in the Opening in IntelliJ section of the Assignment Workflow guide to open lab01.

Once you’ve done this, you should see at least these three files in the left pane:

  • magic_word.txt, which should contain the magic word you added.
  • src/Arithmetic, a Java file which contains your first programming exercise.
  • tests/ArithmeticTest, another Java file which will check that Arithmetic is implemented correctly.

arithmetic intellij

When you open Arithmetic and ArithmeticTest, you should not see any red text or red squiggles.

IntelliJ Test #

To test if everything is working correctly, run the Arithmetic class by opening the file, clicking on the green triangle next to public class Arithmetic, then clicking “Run ‘Arithmetic.main()’”.

arithmetic_run_main

You should see a console pop up, prompting you to enter a number:

arithmetic prompt

If you follow the prompts, you will (probably) see something wrong! Don’t fix it yet.

Testing Your Code #

While we could run the Arithmetic file again and again to check that our code works correctly, it would take a lot of time to type into the program each time, and manually check that the output is correct. Instead, we use tests.

Open ArithmeticTest, and click the green triangle(s) next to the public class ArithmeticTest. This will run the tests that we have provided in this assignment. At this point, you will see the following:

arithmetic test failed

The green checkmark indicates tests that you have passed, while the yellow X indicates tests that you have failed. Don’t worry about the doubled output; this is a strange quirk of IntelliJ.

This should look familiar. The test that failed on Gradescope is the same test that we see here! We can run these tests locally, very easily!

Task: Fix the bug in Arithmetic.java so that the tests pass.

Saving Your Work using Git and GitHub #

As you are making changes to your code, it is good practice to save your work often. We have briefly discussed the commands, but now we will explain how they should be used in practice. In the case that you ever want to go back to another version of your code, it is better to have more options to roll back to. The next set of instructions will talk you through git’s version of saving work through snapshots of your file system called commits.

  1. After you have made some changes to the code within our local repository, git will take notice of these changes. To see the current state of your local repository, use the command git status. Run this and try to interpret the results. Do they make sense to you or do they match your intuition? It is a good habit to run this before running other git commands to know what the state of things are.

  2. To save work that we have completed on a file, we first stage the file, and then we can commit it. We stage a file with the command git add. This does not save the file, but it marks it to be saved the next time you commit. The two below commands show what saving work looks like in a git repository. For git add depending on what directory you are in, the path to the file you are adding might differ (use git status to see the path).

    The -m "Completed Arithmetic.java" part of the commit command specifies a message to be attached to this snapshot. You should always have a commit message to identify what exactly happened in this commit. As an example workflow:

    git add lab01/src/Arithmetic.java
    git commit -m "lab01: Completed Arithmetic.java"
    

    If you run git status, you will see that Your branch is ahead of 'origin/main'. You will also see that the staged changes are no longer staged, and are instead committed. If you haven’t edited since staging, you shouldn’t have any changes not staged for commit.

  3. We want to push these changes to the GitHub repository so that your changes can be seen by us and Gradescope. Your changes will also be available to pulled if you had your repo initialized in other places or other computers.

    git push origin main
    

    git status will now show that Your branch is up to date with 'origin/main'.

Get into the habit of saving your files and doing the git commit step often (i.e. every 15 minutes). It will be incredibly helpful when you mess things up, since it allows you to back out of changes and to see what you have changed recently.

Basically, right when you sit down to work in your repository, first git pull to make sure you are starting with the most recent code. While you are working, frequently commit. When you are finished, git push so all your changes are uploaded and ready for you to pull again next time.

Task: Follow the instructions (again!) in the Submitting to Gradescope section of the Assignment Workflow guide to submit to Gradescope. This time, you should receive a full score on the lab.

Deliverables #

As a reminder, this assignment has an FAQ page. There are two required files, all inside the lab01 directory:

magic_word.txt
You should have received the correct magic word from completing the git checkoff.
Arithmetic.java
You should have fixed the bug so that the tests pass. We check this file with an autograder! For this lab, the autograder tests are the same as the ones you have on your computer.

Be sure to submit again according to the submission section, so that you submit your completed lab. Congratulations on finishing your first CS 61BL lab!