teaching machines

CS 330: Homework 0, Part 2

January 22, 2018 by . Filed under cs330, specifications, spring 2018.

Follow these steps to create your class homework repository and get homework 0 up and running.

1. Create a Bitbucket account

In this class, all your code will be stored with the Bitbucket webservice. Using this third-party service has some nice benefits: they maintain a complete history of your source code using some software called Git, you can access your code from anywhere, their servers are very reliable, and most professionals use Git or something like it to manage projects. Most importantly, your instructor will be able to access your code at any time. You won’t need to email or print any thing to submit. If you have a question, don’t “overshare” your code on Piazza. Just ask your instructor to have a look at Bitbucket.

Visit Bitbucket and create a new account—if you don’t already have one. Pick whatever username you’d like, but be sure to provide your real name so that your instructor can figure out who you are. You will need to remember your password, as you are likely to need it again soon.

2. Fork template repository

Next you will create a repository to hold all your code for CS 330. Bitbucket allows you to make many repositories, one for each project you work on. In this class, you will stick with one for the entire semester.

Your instructor has already created a template repository on Bitbucket. Your repository will be what Bitbucket calls a fork of this template repository. If your instructor adds or edits files in the template repository, you will be able to synchronize your fork with the template easily.

Find the template repository repository at https://bitbucket.org/twodee/cs330_2018a_template. You should see a page that looks somewhat like this:

Click on Source in the left navigation panel. You see a single directory. The specs directory is where your instructor has placed all the homework writeups and graders. You should never modify, add, or delete files in specs. Only you will suffer if you do.

In the left navigation panel, click on Create / Fork this repository to create your own repository based on this template. On the page that appears, expand Advanced Settings to see a screen that looks like this:

You can name your fork whatever you want—perhaps cs330. There are two other things that you must get exactly right:

  1. Check This is a private repository.
  2. Check Inherit repository user/group permissions.

The other settings can be left at their default values. Click Fork repository to continue.

Click on Source in your repository. You should see the exact same files that were in the template. But these are your copies.

Return to your repository’s main page by clicking on Overview. Copy or make note of the https://USERNAME@bitbucket.org/USERNAME/MYREPO.git URL on the top-right. You will need this in the next step.

3. Clone your repository

You are done with Bitbucket in your web browser for a while. In fact, you will only rarely need to visit Bitbucket’s web page, as most of your time will be spent at the terminal, and the git client can synchronize your files with Bitbucket directly. Go ahead and open a terminal on your Linux machine.

So far your repository is only on Bitbucket’s servers. To add new files to it, you have to clone it on your Linux machine. Bitbucket holds your remote repository, while your clone is a mirror image of it on your local machine. After you finish making changes to the local mirror, you will send them up to the remote repository.

At the command line, enter this command:

git clone https://USERNAME@bitbucket.org/USERNAME/MYREPO.git

But replace USERNAME and MYREPO with your actual user and repository names.

Enter ls. You should see a directory for your repository.

4. Complete homework 0

Navigate to your repository using the file explorer for your Linux installation.

Also, find the Homework 0 – Echoargs specification on the course website. Read the specification before proceeding further.

4.1. SpecChecker

Learning goes something like this:

  1. You do something.
  2. You receive feedback.

Your instructor doesn’t want you to spend a lot of time in stage 1 and only a little time in stage 2. So, he has provided a tool called a SpecChecker that you can run as often as you want to see how well you are meeting the homework requirements. This tool isn’t designed to fix your problems for you—only to make you aware of them. You will still have to think.

Back at the terminal, enter your repository directory and make folder echoargs:

cd myrepo
mkdir echoargs
cd echoargs

This directory will be a sibling to specs.

To run the SpecChecker for homework 0, enter this command:

../specs/grade

You should receive a message a message about the required script not being found.

4.2. Add echoargs Script

Let’s fix that error by adding an empty file with the appropriate name:

touch echoargs

Run the SpecChecker again. It should complain that permissions aren’t correct. Run this command to give you, the file’s user, execute permissions:

chmod u+x echoargs

Now, open the file for editing and add this text:

#!/bin/sh

echo "It is fun being in the same decade with you."

Franklin Delano Roosevelt wrote this message in a note to Winston Churchill.

Run the SpecChecker again. It will fail, stating your actual output doesn’t match the expected output. If you have installed vim, you can visually compare the files with vimdiff.

Fix your file so that it actually loops through the arguments and echoes them:

#!/bin/sh

for i in $*; do
  echo $i
done

Run the SpecChecker again. No differences should be detected, but you will be asked if you’ve gotten your modifications up on Bitbucket yet—which you haven’t. You still need to get your code up to Bitbucket so your instructor can grade it.

5. Add Changes

Let’s see what git says of the changes we’ve made:

git status

It should list the current directory (.) as an untracked file. Untracked files are known only locally. Technically, they don’t even exist in your local mirror, only in your working directory. You must add them.

You often want to bundle a set of related changes together, even if they occur across multiple files. Git provides a staging area or index where you can accumulate up your changes. Let’s add or stage the echoargs script:

git add echoargs

Run git status again and it will report that echoargs is a new file, yet to be committed.

6. Commit

To move files that have been added to the staging area into the local mirror, you must commit them. Run this command to do so:

git commit

You will be prompted to describe the set of changes you have staged. Provide a short but meaningful description.

After the commit succeeds, your changes have made it into the local mirror of your repository!

7. Push

But the local mirror is not synchronized with the remote repository on Bitbucket. You can tell this by running git status. It will report that you are ahead by 1 commit. Run this command to push your commits from the local mirror up to Bitbucket:

git push

8. Verify

Your last step is to verify that the push succeeded. Visit your repository in the web browser. Click on Source and navigate to the echoargs script. If you can see it on Bitbucket’s web page, then so can your instructor—assuming you set up permissions correctly.

9. Wipe Brow

If you only ever use one machine, and neither you nor your instructor ever makes mistakes, this is really all you need to know to use Bitbucket and Git this semester!

Of course, we are mistakers from birth. Continue on to part 3 to learn how to pull down revised SpecCheckers and use multiple machines.