Home Assignments Lecture Blog Resources Discussion Group

91.204.202 Computing IV, Spring 2014
Prof. Fred Martin, ⚠ (:html:)<a href="" onclick="'', '', 'toolbar=0,scrollbars=0,location=0,statusbar=0, menubar=0,resizable=0,width=500,height=300'); return false;" title="Reveal this e-mail address">click for fred's email</a>(:htmlend:)
TA: Bhanu Khausik,
Mon/Wed/Fri, 10a – 10:50a, OS402


Materials for this course will provided on this site and in links to other sites. We will not use a textbook.


As of Spring 2014, the catalog listing for 91.204 Computing IV says:

Development of large software projects. Software engineering principles and practice. Object-oriented analysis and design. CASE productivity aids. Development techniques for program-translation software and web software.

This is old, and we'll be shortly revising it to something more like:

Advanced C++ programming, which deepens studentsí understanding of object-oriented analysis and design. Basic software engineering principles and practice, including documentation standards. Principles of large software projects, including work with APIs. Topics may include program translation, web software, parsing, and regular expressions.

But even this doesn't tell the whole story, because various faculty who have taught / are teaching the course do very different things:

Probably the only thing that can strongly be claimed about the course throughout the years is “do stuff in C++, ” “have the students write lots of code,” and “do cool stuff.” (Of course, this last one depends on one's definition of cool.)

I'd also say that there definitely existed a point in time when having all students learn how to write a linker was absolutely the correct answer.

Now in Spring 2014 though, the course is an oddball in that it's required, but it's allowed to vary a lot based on instructor interests.

So, what will be doing in my class this semester?

  • We will definitely be writing lots of code
  • We will be doing it in C++
  • We will be using some pretty cool APIs, including SFML, a free, open-source “simple fast media library“ for C++, which is available for Mac, Win, and Linux (translation: it's a gaming library)
  • Best of all, we'll be working through some awesome problem sets developed over the last 15 years at Princeton by Robert Sedgewick.

The Princeton stuff is great because it's all about how computing connects to the larger world.

It's not the usual stuff about using computing to do ever-more complicated things. This is necessary and valuable, but it's kind of self-referential and insular. Dare I say, incenstuous.

Here are some of things we'll be doing:

  • Using Newton's laws of planetary motion and the “leapfrog finite difference approximation” method (don't worry; it's easy) to create a totally realistic simulation of our solar system—complete with live animation
  • Comparing sequence strings based on their on their “edit distance”—a technique widely used in bioinformatics for DNA analysis
  • Using a linear feedback shift register to cryptographically encode and decode an image
  • Simulating the vibration of a guitar string, with a thing called the “Karplus-Strong algorithm (also not too bad). This will include generating actual audio files and listening to them

Also in a partnership with Kronos, a Chelmsford, MA-based company which happens to be the largest employer of software developers that has its headquarters in MA:

  • Parsing 0.5 MB error logs generated by malfunctioning InTouch devices, their hardware time-clock unit. Note: these are not neatly well-formed like proper XML!

Based on the historical role of the course in UMass Lowell's computer science curriculum, and my hopes/plans for the semester, I shall predict the following learning outcomes:

  • You will become much more comfortable writing C++ code and using object-oriented methods.
  • You will gain experience architecting solutions to reasonably well-structured problems.
  • You will learn how to use some great C++ APIs (not only SFML, but Boost—by the way, we're going to be doing some unit testing stuff).
  • You'll gain practice with the most important thing about documentation, which is: Naming. Stuff. Well.

Collectively, these things represent to me what is the most important learning outcome of the course, which is you progressing down your journey of becoming an effective and confident software engineer.

Also, I won't be teaching you to use an IDE. You are welcome to use your favorite one, but I won't be requiring their use nor teaching them.

I do hope you all share your favorite development environments with each other.

When I do stuff with you in class, you'll be seeing Emacs, the Unix shell, and Makefiles.

Also #2, you're welcome to use your favorite platform (as long as it is one of Linux, Mac OS X, or Windows).

  • I'll be using Linux. If you don't have a strong preference you should choose that.
  • I can provide you with some help for Mac, as long as you're not using Xcode.
  • If you're on Windows, that's fine, but you'll need to turn to your classmates for support.

OK, that's the course overview! Now on to some more tactical things.

Course Structure and Grading

The class will have regular weekly assignments, which will be graded and returned.

Cumulatively these assignments are worth 50% of your overall grade.

Assignments will be accepted up to 1 week late with a 50% reduction in that assignment's value. If you fall behind on your homework, it is much better to cut your losses and work on the current assignment, instead of running behind trying to catch up.

There will be two in-class exams during the semester. Each is worth 10% of your overall grade.


I am aware it is a good teaching practice to announce the dates of in-class exams on the first day of class. I apologize that I am not doing this. It's because I prefer to schedule these exams when I may be away, and I'm not sure of those dates now. I will make sure to give you two weeks' notice for all in-class exames.

There will be a cumulative final, worth 20% of your overall grade.

Classroom participation is worth 10% of your overall grade. In practice, if your other grades put you on a marking boundary, this will push it one way or the other.

To summarize:
50% Weekly homeworks
20% Two exams
20% Final
10% Classroom participation

Discussion Group / E-Mail List

We will use Google Groups for class conversation and announcements. Please join this group.

There are two ways to sign up:

⚠ (:html:) <table style="border:1px solid #aa0033; font-size:small" align=center> <tr> <td rowspan=3> <img src="" height=58 width=150 alt="Google Groups"> </td> <td colspan=2 align=center><b>Subscribe to 91-204-202-s14</b></td> </tr> <form action=""> <tr> <td>Email: <input type=text name=email></td> <td> <table style="background-color:#ffcc33;padding:2px;border:2px outset #ffcc33;"> <tr> <td> <input type=submit name="sub" value="Request"> </td> </tr> </table> </td> </tr> </form> <tr><td colspan=2 align=center> <a href="" target="new">Browse Archives</a> </td></tr> </table> (:htmlend:)

If you do the Google web method, I'd advise setting your preferences to immediate, individual delivery of messages—click the “Edit my membership” tab.

If you do the email method, and you provide an address that's not linked to your Google account, I'll choose those delivery options for you, and then if you don't like it you'll have to ask me to change it, and we'll both be annoyed, so don't do that.

In either case you can send email to the list with

If you sign up on the web, you can browse conversations at the group link (see top of this page).

Lecture blog and lecture capture

I will strive to maintain a daily blog of highlights of what happened in class each class meeting. These notes will be recorded in the Lecture Blog page.

In-class activity will be recorded using the University's Echo360 lecture capture system. This material is intended for your use if you must miss class, or if you want to go over again something that was presented/discussed in class.

A link to the Echo360 recordings is at the top of the Lecture Blog page.

Echo360 makes a high quality recording of the classroom's data projector and the instructor's voice.

It also produces a low-resolution recording of the front of the room (i.e., me walking around writing stuff on the white board), and a low-volume capture of student remarks (depending how close to the microphone you're sitting, and how loud you are).

If you arrive at class after 10a, and walk across the front of the room, you'll be captured by the low-res overview cam.

If you're a talker and you're at a decent volume and near a mic, people will be able to hear you on the recording. (They won't see you sitting in your chair—maybe the back of your head if you're at the front of the room.)

If it bothers you that your voice will be captured, and you want to feel comfortable speaking up, please let our TA know and the TA will anonymously refer your concerns to me. We'll set up the captures in a more private way.

Collaboration policy

Individual work. Most assignments must be completed individually. You are welcome to discuss ideas in the class with your peers. You may not look at each others' code, nor allow others to look at your code. If you need to post code on our own course forum for help, or a public forum, do not post more than three lines.

When turning in an individual assignment, you attest that, beyond any starter code I have provided or has been provided in standard API and reference documentation, you are the sole author the code that it includes.

Pair programming. A few specific assignments may allow pair programming. There will be highly structured rules for these (which are intended to make sure both partners have a substantial learning experience).

This will be discussed later in class, and this document will be updated at that time.

Academic integrity. Please be familiar with the university's policy on academic integrity.