Computer Science 210
Data Structures

Fall 2018, Siena College

Home     Syllabus     Schedule     Examples     Style Guide

You will work with a partner for most labs, but for this setup lab, you will need to complete the tasks individually.

As you finish each step, please have your instructor initial the hard copy of this lab handout you were issued to indicate successful completion.

Name:

Learning goals:

1. To set up an account and to gain a basic familiarilty with the git version control system and the GitHub hosting service.
2. To learn how to use the BlueJ interactive development environment with a git repository.
3. To refresh basic Java programming skills including the Scanner class to read input from the keyboard.

Submitting

Once all written items are initialed to indicate completion, turn in the hard copy of this lab handout you were issued.

GitHub for Source Code Control

We will be using the git distributed version control system for nearly all of our work this semester.

If you are not familiar with the basic idea of version control, this brief video is a good place to start.

In particular, we will be using git repositories hosted on GitHub which are managed by GitHub Classroom.

If you do not already have an account at GitHub, please visit https://github.com/ and create one. Please use your college-issued email address when you create your account (or, be sure your college-issued email address is associated with your account if you already have one), since GitHub offers free unlimited private repositories for academic use. Also, a username that incorporates your real name is probably a good idea. Building up a portfolio of GitHub repositories that contain your work is a good way to impress future potential employers, so make it a username you won't be embarrassed to put on a resume.

Trying out GitHub with BlueJ

Before you can do this task, you will need to have the GitHub classroom link (sent by email) to be able to create your repository for this lab's work.

Our first step is to create your GitHub repository for this lab. A repository is a place to store code or other files that you, and possibly collaborators, can develop. The repositories we will be creating are ones in which you, your lab partner(s) (for future labs when we have partners), and your instructor are the only ones with access. This is not a difficult thing to set up in general, but we'll be using a system called GitHub Classroom that makes it very simple. For each assignment that is managed by GitHub, you will receive an email link that will allow you to create the repository, which will then be automatically shared with your instructor. When you have a partner for future labs, only one person will click on the link to create, and the other(s) will be granted access by an invitation link sent by the instructor, who is the owner and administrator for the repository.

To create your repository for this lab, open a browser window at https://github.com and sign in. In the same browser, visit the link you received in your email. This should bring you do a page where you can "Accept the setup-lab assignment". Do so. If that worked, the next page will have a link to a GitHub URL which is your copy of this lab's repository. Follow it.

You are now on the main page for your repository. You should see a screen that looks similar to this:

Let's add your name and your Siena userid (the first part of your email address and what you use to log into the lab computers, not "901" number!) to the README.md file in the repository on GitHub. Click on its name, then in the window that comes up, click on the little pencil icon near the "Raw", "Blame", and "History" buttons to bring up GitHub's simple editor.

You'll be editing in a simple markup language called Markdown (please click here and read about it).

Add your name and userid to the file, then scroll down to the bottom and "Commit changes". You can leave the radio buttons above that set to "Commit directly to the master branch." Once you've commited your changes, you should now see the file displayed with your additions.

To get back to the main view of your repository, click on the "<> Code" tab.

So far, we've worked only on the GitHub web site. Now, we will see how to use the repository on a lab PC. If you would like to work on your own computer instead of or in addition to lab computers for any future labs, you will be able to perform similar steps to get set up there. For today, though, everyone will need to get set up on a lab PC.

On a lab PC, launch the "Git Bash" program. Once it launches, you should see a prompt that looks like this:

$ 

Git Bash is a program that allows you to issue commands directly to the operating system without navigating a bunch of windows and clicking icons and the like. You'll sometimes hear this called "the command line", "the Unix command line", "the shell" or other similar things. Most of the time, I'll probably say "at the command line" or "in Git Bash". There's a bit of a steep learning curve to get good at working at the Unix command line, but once you do, you'll find you can do many things much more quickly and efficiently. It's worth taking the time to learn. For this week, we'll learn just enough to get going.

Your first command to the command line will create a directory (that's our grown up computer scientist Unix word for what Microsoft and Apple want you to call a "folder") for your work for this course. If you want to name it "ds", use the command:

mkdir ds

Maybe you'd prefer "CSIS210" or "210" or "DataStructures" or "BestClassEver", but whatever you choose, it's best not to include any spaces in the directory name. That would cause some headaches later.

Note that you are working here in what from the Windows view is your "Z drive" so the mkdir command also created a folder there.

Back in Git Bash, change your working directory to that new directory:

cd ds

Next, click on the green "Clone or Download" and copy the URL that pops up. Note that this can be done by clicking on the small "clipboard" icon next to the URL on the page. After copying, go back to your Git Bash window and type

git clone ...

at the command line, replacing ... with the URL you copied from the web page. You can paste the URL into the window by right-clicking on the Git Bash window and choosing "Paste" from the menu. Be sure to type the git clone command and a space before pasting.

When prompted, log in with your GitHub credentials. You should then see some messages, and a new directory will be created.

Before going further, we have a bit of configuration to do for your git setup in the Git Bash window. Issue these commands (replacing with your own GitHub username and your email, of course) at the terminal prompt:

git config --global user.name "jcool"
git config --global user.email "jcool@teresco.org"

Please note that these steps will need to be repeated when you use other computers.

One of the files in your directory is a Java program, so let's bring it up in BlueJ to compile and run it. On the lab PC, navigate to the directory where you cloned the repository and double-click on the "package" icon with the little blue jay image (not the Java program) to launch BlueJ. Once it opens, click on the Hello210 class to open the editor. It's a very simple Java program. Compile it by pressing the "Compile" button in the upper left of the editor window. Run it by right-clicking on the class in the object workbench window and choosing the "void main(String args[])" entry. This will bring up a dialog box for command-line parameters that you can ignore for now by pressing "OK".

If all goes well, you should see the "Hello, CSIS 210 world!" printout in the BlueJ Terminal Window.

Now, make a couple changes to the Java program. Put your name in the comment at the top, and add at least one more println statement to print additional messages. These should include the name of your hometown, your favorite restaurant there, and your favorite item on their menu.

Next, create a new Java class within the same BlueJ project (use the "New Class..." button on the object workbench window). Name the class ConsoleIO, which will create a file ConsoleIO.java.

You might find the section "A Quick Scanner Review" later in this document to be useful as you work on this practice program.

So you now have two copies of the repository, one on the GitHub server (the "origin" repository) and one on the Z drive of your account on your lab PC (a "clone"). Later in the semester, you might have multiple clones in various places (maybe your own computer, or in your lab partner's account) and will want to be able to keep them in sync. This is one of the great benefits of using version control. Your clone has changes (one new file, and one modified file) that are not in the origin on GitHub.

git knows what's changed, so let's ask it, in the Git Bash window:

git status

You should see something like this:

On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   Hello210.java

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	ConsoleIO.class
	ConsoleIO.ctxt
	ConsoleIO.java
	Hello210.class
	Hello210.ctxt

no changes added to commit (use "git add" and/or "git commit -a")

This means there is one file that git "knows about" that has changed: Hello210.java, and there are five files that git doesn't know about listed under the "Untracked files" header.

Since the two .class files are compiled versions of your Java classes that gets generated from the Java files, we don't want to store those in our repository. And the .ctxt files are also generated by BlueJ, and we'll ignore those too. But the ConsoleIO.java file is one we want to put in the repository (only because it's part of the grading). We can tell git to start tracking it with

git add ConsoleIO.java

You might get a (hopefully harmless) warning here about line feeds. You can ignore it.

Rerun the git status command, and it should now be listed as a new file. In future repositories, a special file called .gitignore will be included that will tell git to ignore files with certain extensions, including .class and .ctxt files.

Once we're happy with a change or set of changes to files in our repository, we need to commit those changes to the repository. In this case, we will issue a command for each file, with an appropriate message in each:

git commit -m "Added name and extra printout." Hello210.java
git commit -m "Practice program." ConsoleIO.java

One of our goals for the semester is to learn how to use lots of commits with good commit messages.

Now git status should show something like this:

On branch master
Your branch is ahead of 'origin/master' by 2 commits.
  (use "git push" to publish your local commits)
Untracked files:
  (use "git add <file>..." to include in what will be committed)

	ConsoleIO.class
	ConsoleIO.ctxt
	Hello210.class
	Hello210.ctxt

nothing added to commit but untracked files present (use "git add" to track)

Your changes have been committed to the clone, but they are not yet back up on the origin repository on GitHub. To do that, you will use

git push

This is short for "git push origin master", which says push the changes from this repository to the origin on the master branch. So far, we have not talked about let alone created any branches, so everything is on the master. The "origin" is the instance of the repository that is in some sense the primary version. Later on, you might have several clones of the same repository, and you'd normally have all of them communicate back and forth with the origin to keep them all in sync.

If your push command is successful, you should now see your changes reflected on GitHub (in the web page).

One last step: let's make a change right in the origin repository on GitHub and then "pull it down" to our clone on the PC. Edit the README.md file again to include a bulleted list of the git commands you used in this lab. Use Markdown to make it look pretty. You can find a quick guide to Markdown

here.

When you are done, include a meaningful commit message and use the green button to commit your changes.

Now the repository on GitHub has changes that aren't in your clone. Back in Git Bash, we want to "pull down" the changes:

git pull

Now, your README.md on the lab PC should include the changes you made on GitHub.

A Quick Scanner Review

This section is provided for reference for those who might not be familiar with or do not remember the use of Java's Scanner class. There are no additional lab tasks in this section. As you complete the ConsoleIO practice program, you'll want to remember the following:

• Console output is most commonly achieved with the System.out.print and System.out.println methods. In BlueJ, this output is sent to a window called the Terminal window, which is created the first time you print anything.
• Console input is accomplished most easily with the java.util.Scanner class:

  Java API Documentation: java.util.Scanner

  Don't forget to add the

    import java.util.Scanner;
  

  at the top of your program.

  You create a Scanner capable of reading from the keyboard in your main method with a line such as:

    Scanner keyboard = new Scanner(System.in);
  

  This declares a local variable keyboard and initializes it with a reference to the result of the construction of a Scanner.

  Once you have this Scanner, you can use its methods to read various kinds of input from the keyboard. In BlueJ, this is also done through the terminal window. For example, you might read a single word and store it in a (newly-declared) variable with code such as:

    String streetName = keyboard.next();
  

  Other common Scanner methods include nextLine() to read an entire line as a String, nextInt() to read a number and return it as an int, nextDouble() to read a number and return it as a double, along with hasNext() and related methods to return whether the Scanner has input to return.