ENGL 279

DH: Development and Design

Course Description

This is an intensive course in the major concepts of programming and software design as applied to the humanities (with a focus on text manipulation). We will study the UNIX operating system (briefly), the Ruby programming language in detail, and use both to explore the algorithms, data structures, and design patterns relevant to the advanced use of computers in the study of literature, history, philosophy, journalism, and related fields. We will also survey some of the more important scholarly work in digital humanities and theory of new media. Students are expected to demonstrate understanding of the material through frequent exercises.

This class meets in Burnett 126.

Contacting the Professor

Dr. Ramsay's office is in 303 Andrews Hall. Regular office hours are from 2:30–3:30 on Mondays and Wednesdays (and by appointment). He can be reached via email at sramsay {at} protonmail.com

Recommended Reading

There are no required textbooks for this course. That said, you may find these two books helpful. The first is the standard reference work for the Ruby programming language. Every programming language has one, and for Ruby, it's the book Rubyists refer to as "The Pickaxe Book:"

The second is a brief guide to the UNIX operating system. This one is far less obligatory than the first (there's nothing in it that you can't find online), but you may find it helpful when trying to figure out how to do something on the command line.

These books are not available in the UNL bookstore, but you can easily find them at your favorite online retailer (or wherever geeky books are sold). Please make sure the titles, edition numbers, and ISBNs match before purchasing.

The Problem Sets

The primary work for this course consists of a series of graded problem sets.

The problem sets are designed to reinforce the material and to encourage exploration of the tools and techniques we're studying this semester. They are not designed to trick you, make you feel stupid, cause you needless frustration, normalize the grading curve, or destroy your weekend.

Here are some general things to keep in mind:

  1. Problems sets vary in scoring. One week the set might be worth 10 points, the next week 30 points, the week after that 5 points, and so on. Generally, speaking, the number of points relates to how hard the assignment is.
  2. Most problem sets aren't "sets of problems" at all. For most of the course, the problem set will ask you to write a program to perform some task or to demonstrate your understanding of the material in some other way.
  3. "Trick questions" are, to my mind, bad questions. I purposely try to avoid writing problem sets that demand very narrow interpretations, remembrance of an off-hand comment in class, or things of that sort. However, when I grade problem sets I try to be as picky as the computer. The first thing I do when I grade a problem set is type your answer into the shell (or run the program you submitted).
  4. For this reason, it is an exceedingly good idea to test your answer by actually typing it into the shell. In fact, many questions in the beginning will require that you do this. (When we start programming, you'll have no choice but to run the program and see if it works).
  5. Be as adventurous as you can. Try it a few different ways. Break the code (or the command string) to see what happens. Add a feature. Write a related program. Do these kinds of things, and you'll get better faster.
  6. You are allowed to use any resource you like in pursuit of the answer—the books for class, your notes, google, friends and colleagues, anything—but you should always try to reason through the problem first before seeking help. It is true that this remarkably open policy introduces an ambiguous line between the honest search for pedagogically useful assistance and cheating. The important thing to understand is that plagiarism has nothing to do with how much you took, where you took it from, or (in the case of code) the nature of the information. Plagiarism is willfully misrepresenting another's words, ideas, thoughts, or expressions as your own. It is, in other words, a type of lying. The way you avoid the charge of plagiarism—which the University takes very seriously—is to be honest and forthright about how you arrived at the answer. There are nuances here, of course, but remember the core idea: if you are misrepresenting your work, you are probably doing something wrong.
  7. Stuck? Befuddled? Disheartened? Try to describe the difficulty you're having as throughly as you can—the things you tried, why you think your idea should work (even if it manifestly doesn't), your thought process while working through the problem, and anything else you think might help others to help you. You can often get partial credit (or even full credit) for giving it the Good Old College Try. I try to watch my email and the Canvas forum very closely over the weekends; your first line of defense should be the Canvas forum.
  8. Speaking of which, please try not to give away answers in the forum. This can be tricky sometimes, but most of the time, people just need a gentle nudge in the right direction. Similarly, when asking questions in the forum, try not to post large sections of code or otherwise give away the game.
  9. Problem sets are posted to Canvas shortly after the class in which they're announced. They are due no later than 8:00 pm on the announced due date (this is so I have sufficient time to look them over). No problems sets are accepted after this time, and there are absolutely, positively no exceptions to this rule.
  10. You pass in a problem set by sending me an email (at sramsay {at} protonmail {dot} com). Your email should include the following:
    1. The name of the file in which your solution appears on spacely.
    2. The path to the file in your home directory.
    Please do not send the program itself through email (spam filters love code). I will not, generally, acknowledge receipt of your problem set; if I don't see it by the deadline, I'll usually contact you.
  11. Your final grade (or your grade at any particular point) is computed by dividing 100 by the total number of points accumulated and then multiplying the resulting number by the point total. The professor reserves the right to curve final grades and to adjust individual grades up or down based on class participation, the progress of the student's work, or any other standard metric.

Schedule

Our schedule will alternate between formal instruction and theoretical meditation. We will study programming and software engineering in detail, but as we move through the technical material, we'll also be reading some of the more important scholarly works in digital humanities and media studies from the last forty years or so.

Every group of students represents a different set of interests and skills, and so it is difficult (one might say futile) to create a tight schedule for a course like this in advance. For most of the semester, we will be learning new material on Wednesdays, engaging in spirited discussion of various readings on Fridays, and going over problem sets on Mondays. However, the basic pattern may change occasionally depending on the difficulty of the material or other factors.

Here's a rough roadmap of the technical schedule:

(All class meeting are Burnett 126)

Week 1
Introductions, Accounts, UNIX Survival
Week 2
UNIX and the UNIX Philosophy (Part I)
Week 3
UNIX and the UNIX Philosophy (Part II)
Week 4
Introduction to the Ruby Programming Language
Week 5
Control Structures: Conditionals
Week 6
Control Structures: Simple Loops
Week 7
Data Structures, Arrays and Iterators
Week 8
Hash Tables
Week 9
Functions, Scope, and Visibility
Week 10
Regular Expressions
Week 11
Object-Oriented Design (classes)
Week 12
Object-Oriented Design (inheritance)
Week 13
Object-Oriented Design (modules)
Week 14
Algorithms
Week 15
More Algorithms
Week 16
Loose ends

General Policies

All academic work must meet the standards set forth in the University's Student Code of Conduct concerning academic honesty, and all use of University computing infrastructure must comply with the guidelines set forth in the Policy for Responsible Use of University Computers and Information Systems. Each student is responsible for informing themselves about these standards and policies before performing taking part in the class. Students are also expected to arrive prepared and on time for all scheduled classes. The professor reserves the right to exact grade penalties (at his discretion) for failure to comply with the policies of the course.

The campus policy states that the instructor be informed of anticipated absences for religious holidays by the beginning of the second week of school.

Services for Students with Disabilities (SSD) provides individualized academic support for students with documented disabilities. Support services can include extended test time, textbooks and handouts in alternative formats (electronic texts, Braille, taped texts, etc), classroom notes, sign language interpreters, and transcriptionists. SSD not only accommodates students that have visible disabilities, but students with other varying types of disabilities that impact college life.

If you have a documented disability that is impacting your academic progress, please call SSD at 472-3787 and schedule an appointment with the Director, Veva Cheney, or the Assistant Director, Barbara Woodhead.

N. B. The course syllabus is a general plan for the course; deviations announced to the class by the instructor may be necessary. The authoritative version of this syllabus is available only at http://spacely.unl.edu/index.html

Achievement Centered Education (ACE)

This course will satisfy ACE Learning Outcome 3: Use computational and formal reasoning (including reasoning based on principles of logic) to solve problems, draw inferences, and determine reasonableness. Students have opportunities to acquire the knowledge and skills necessary to achieve these learning outcomes in the lectures, problem sets, and weekly seminar discussions for the course. The problem sets, which constitute the only graded work for this course, are the main way in which fulfillment of this outcome is assessed.

Opportunities to achieve this outcome

Students will learn and practice computational methods while solving complex problems that involve computational thinking and formal reasoning. By developing facility with a programming language, students will be introduced to a variety of software design concepts (including control structures, data structures, algorithms, exception handling, structured programming, object-oriented design, and the general principles of software engineering).

Opportunities to demonstrate achievement of this outcome

Through a series of increasingly complex and sophisticated programming exercises, students will demonstrate proficiency in programming and software design.