91.204.202 Computing IV, Spring 2014
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?
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:
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:
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:
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).
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.
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:
If you do the Google web method, I'd advise setting your preferences to immediate, individual delivery of messagesclick 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 mailto:email@example.com.
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 chairmaybe 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.
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.