Class Adminstrativia: Software Methods in the Time of Coronavirus

Table Of Contents

A short list of all the places to find info, help, and me:

The Big Picture

In many ways, the outcomes for the class haven’t changed:

  1. Build medium-scale software projects in principled ways.
  2. Understand the role of specifications and abstractions, and how to validate that an implementation is correct via testing, verification, and formal reasoning.
  3. Analyze a software problem and design effective and efficient solutions.
  4. Apply concepts of modularity, separation of concerns, and software architectures to solve recurring design problems.
  5. Use contemporary programming languages and systems effectively, with a particular focus on leveraging abstraction mechanisms, Model-View-Controller UI design, concurrency, data persistence, and failure detection / recovery.
  6. Effectively learn and use additional new tools for building and analyzing software, including testing frameworks, debuggers, program checkers, profilers, version control, IDEs, etc.

We will emphasize some of these items more or less than originally planned but hopefully still hit all of them. In the first lecture of the semester, I noted that “tools change, principles are forever.” We’ll embrace that moving forward…

  • I’m planning the remaining labs involving Swift to not require Macs, XCode, or iOS app code. Instead we’ll focus primarily on building solid core data structures and abstractions. Indeed, without the UI part, I’m hoping we can focus more on building beautiful code “the right way” than we could otherwise.

  • I’m expanding the final project to give you more flexibility in what you do, and to avoid being tied to any particular platform, language, or tool. More details shortly, but I want the project to enable you to explore something you’re excited about or interesting in learning.

  • For those interested in continuing to learn about iOS apps, I’ll put my lecture notes, videos, labs on the website, but there is no expectation that you complete them. I’m also looking for suitable alternatives for those without XCode, including online tutorials based on Android, Javascript, Rust, … for those who would like to investigate these other systems. Any of these would make suitable platforms for a final project.

Software Everyone Should Install

  • Williams VPN: The VPN makes it appear that you are sitting on campus. Running it will give you access to software and sites otherwise reserved for on-campus use only. These include:

    • evolene.
    • My sample solutions on the CS326 web page.
    • Software managed by OIT.


    When you log in, be sure to select the group Student-SSL-Split. This ensures only Williams-bound traffic goes through the VPN. All other traffic (eg: YouTube) goes directly to the destination. This is the fastest option.

  • Slack: Collaboration software for messages, announcements, working in groups. One of the best systems for this around. We’ll use Slack for online discussions, announcements, questions, etc. Here are the main channels we’ll use:
    • #general: Class announcements. Check often!
    • #discussion: Anything related to the class material or assignments.
    • #random: Anything else.
    • #iOS: Channel for those wishing to work on the optional iOS topics. You’ll need to subscribe if you want to use this channel.
    • You can also direct message anyone in the class, the TAs, or me in Slack.

    Other items:
    • If you’d like to post a question or comment anonymously, start the text with /anon.
    • You can use Markdown formatting – bullets, code, code blocks, etc. Use Option-Return to create posts with more than one line.

  • Zoom: Video conference software for office hours, both for me and the TAs. I’ll add links to the calendar for connecting with us. Feel free to also use Zoom for working with your partners.

Computing Environment

Here are the basic instructions for working on the upcoming labs. Please verify your platform works by following the directions in the Verify Your Environment Works section below.

Mac

For those using Macs, you can continue using XCode just as before. We will be writing command-line tools for the remaining couple of labs, but other than that there are no substantial changes. (Note: you should also be able to use the swift build, swift test, and swift run commands described below if you are in a terminal window.)

Windows

For those using PCs, you’ll need to work on a Linux computer. There are two ways to do this:

  • ssh: First ssh to one of our servers and then ssh from there to one of the lab machines. (If the VPN is running, you can find the machine names here.)

    You will use emacs and the terminal commands below to run Swift. Putty is a good ssh client if you don’t already have one. If you use this approach, execute the following command in your terminal window to ensure you find the proper version of Swift:

    export PATH=/usr/local/swift42/bin/:$PATH

    You can put that that line in your .bashrc file so you don’t have to do it every time you start a new terminal.

  • Linux VM: A more flexible option is to run a VM on your own computer. This will let you use multiple emacs windows, Atom, etc. without being connected on the network. Set up instructions are here. You’ll need to start the VPN to view that file. I may need to update the VM, but if you want to try using the current version, let me know how it goes!

When working on a Linux computer, you will use the following commands to build, test, and run programs. You run these commands in the top level directory for the project, where you will find a Package.swift file that describes how to build and run the program you are working on.

  • swift build: builds the program in the current directory.
  • swift test: builds and runs all unit tests for the program in the current directory.
  • swift run: builds and runs the application, using the terminal for input and output.

When working on the command line, all temporary files produced by the compiler are stored in the .build directory. You should not need to ever work in that directory yourself, but if you ever get confusing error messages about compilation errors, removing that directory and rebuilding from scratch may fix the problem.

For editing code in a terminal, you can use whatever editor you like. If you are running your own Linux computer or a virtual machine, Atom is a good choice. Both Emacs and Atom can be customized to do autoformatting in swift.

Linux

If you are using your own Linux computer, you may follow the instructions for Windows above to use ssh or a VM. To run things locally, you will need to install at least the following packages: clang, libicu-dev, linux-tools-common, and linux-tools-generic. You will then need to download verstion 4.2.4 of Swift from https://www.swift.org. You mileage may vary if you go this route…

Verify Your Environment Works

Regardless of how you plan to work, please do the following to ensure you can compile and run Swift code:

  • Download the SwiftOnLinux project and unzip it. (If you are working via ssh, the command wget http://www.cs.williams.edu/~freund/cs326/SwiftOnLinux.tgz will download that file.)

  • If the file doesn’t unzip automatically, you can do that with the command tar -xzf SwiftOnLinux.tgz on the command line.

  • For XCode: Open the SwiftOnLinux XCode project. Build, test, and run the project. Be sure your scheme and target are set to tool and My Mac, as follows:  

        This runs the program as a command line tool rather than an iOS app.

  • For Unix: If you are using ssh or the VM, cd into the SwiftOnLinux directory, and then run swift build, swift test, and swift run.

  • Verify the output of your run is:

    The happy herd: ["Abba", "Amelia", ..., "Suzy", "Wanda", "Indigo"]

    (These are some of the cows at Cricket Creek Farm.)

  • If you run into any problems, let me know.

Partners

You may continue (and are strongly encouraged!) to work with partners as before. You should even be able to work if one person is on a Linux machine and one is on a Mac. If you run into any hitches along the way just let me know and we’ll figure it out.

Working Remotely With Partners

Communication is vital on any group project, and software development is no different. Indeed, we could spend an entire semester talking about all the processes that have been developed to help software engineers communicate and collaborate effectively. We won’t go that far, but this is definitely an opportunity to think about these things.

Here are a few hints on working remotely with a partner or group, mostly based on what I’ve found works well for me. I’m sure many of you have found good ways to work with people who are not sitting in the same room as well. If you do have things that work particularly well for you, let me know and I’ll add them to the list!

Text Communication
  • Email is always good for many things, but mostly asynchronous communication. The overhead/latency can be a drag for anything that requires rapid turnaround.
  • That’s where a tool like Slack comes in. Text messages on your phone and other chat programs work well too, but Slack is great because it stores everything and allows richer content than other systems.
Verbal/Visual Communication
  • Also, always agree on a standard way to get in touch when verbal discussion is useful: Zoom, Google Meet, FaceTime, Skype, phone, etc.
  • My colleagues and I use Zoom because we like its screen sharing, especially the shared whiteboard. The whiteboard is good for diagrams and “mathy” stuff, though a little annoying unless you have a drawing tablet.
  • GoogleDocs work great for online discussions too. My main colleague and I often have a shared GoogleDoc open while we talk on the phone, and we even copy/paste code into it as an expedient way to edit it together.
Shared Files
  • Of course, a Git repository containing every file is essential for any project these days.
  • GoogleDocs are a great option for any sort of prose.
  • The important thing is to avoid having multiple versions of the same file floating around. (Eg: don’t email files back and forth.) Eventually this will lead to problems.
Pair Programming Remotely

  • Simplest. Can be as simple as both partners having source files from a project open locally while talking on the phone, with edits communicated via Git commits.

  • Editor Support. Some editors have built-in support for remote pair programming. Essentially, GoogleDoc-like collaboration for code…

  • Remote Control. There are a variety of tools that allow you to control your partner’s computer remotely.

    • Zoom has it.
    • TeamView has been used by some students with success.

    These can be great for working together. They do need a good network connection on both ends, but I’ve experimented with them a bit and they have been quite useable. One trick I’ve used is to lower the shared display’s resolution to reduce the amount of bandwidth required to send the video feed.

Lectures

I’ll post lectures on the web site no later than the morning they are listed. You may watch them whenever you like.

TAs

TAs will continue to have office hours. I’m working on the schedule right now. They will be available on Slack and via Zoom.

Labs

We’ll stick to the usual schedule on labs (due Tuesday, but any time until midnight).

I will mark up PDFs of your lab submissions and return them by commiting and pushing the PDF to your repositories. You should already see feedback on lab 3. I’m working on lab 4 right now.

Midterm

Nope. But perhaps another HW instead.

Swift Text Input/Output

Here is a very short summary of how to read and write to the terminal in command line programs.

  • Printing: Same as always, but you can control whether or not a printed message ends with a new line with the option terminator: parameter:

    print("A message ending with a new-line.")

print("A message with no newline. ", terminator: "")
print("More text.")

    Output:

    A message ending with a new-line.
A message with no newline. More text.

  • Reading Text From the Command Line: Use the readLine() command to wait and read a line of input. It may return nil if input cannot be read. The following shows how to do that, and also how to split text into words, using spaces as the separator between them. The text.components(separatedBy:) method returns an array of strings:

    print("Enter some text:", terminator: " ")
if let text = readLine() {
  let words = text.components(separatedBy: " ")
  print("You entered \(words.count) words.")
  print("Here they are with no spaces:")
  for w in words {
    print(w, terminator: "")
  }
  print("")
}

    Output:

    Enter some text: this is a test.
You entered 4 words.
Here they are with no spaces:
thisisatest.

  • Reading a Number: Here’s an example of reading a number as a String and converting to an integer:

    print("Enter a Number:", terminator: " ")

if let line = readLine(),
   let x = Int(line) {
  print("\(x) squared is \(x*x)")
} else {
  print("eh?")
}

    Output:

    Enter a Number: 5
5 squared is 25
Enter a Number: moo
eh?