Syllabus

Description

Introduction to applications of computer science (including web technologies, visualization, and database design) to domains in the arts and humanities. Emphasis on principles of software engineering and best practices, including code reviews, source control, and testing. Languages include JavaScript and SQL. Students work in teams to design and implement solutions to problems proposed by faculty from departments across campus. Offered jointly with Yale University.

Class Notes

Enrollment limited; apply at cs.harvard.edu/100.

Recommended Prep

CS50 or equivalent required.

Implementation Details

The first half of the course will be focused on lectures and (hands-on) labs, with lectures ordinarily on Mondays and lectures and/or labs ordinarily on Wednesdays, both 1:30pm–2:45pm in 1 Story Street #306. Attendance is expected of all students. Via lectures and labs will paradigms of web programming be introduced via looks at Git, JavaScript, Node.js, SQL, and React. Weekly workload will include at-home completion of labs and readings on digital humanities. Along the way will we be joined in person or via video by faculty in the arts and humanities for a look at problems from their domain that might be solved computationally.

The latter portion of the course will be focused on application of lessons learned via (team-based) final projects, with teams of size three or four each tackling a problem from a domain in the arts and humanities. Each team will meet weekly with an assigned advisor for design discussions and code reviews, with milestones assigned weekly for each subsequent week. Each member of a team should expect to contribute at least 15 hours per week to the team’s milestones.

The course will culminate with presentations of final projects at the CS50 Fair on Mon 12/9, 12pm–4pm. Teams are welcome to present at the CS50 Fair at Yale as well, time TBD.

Grades

Final grades are determined using the following weights:

Grades at final projects will be determined by the extent to which teams (and the members thereof) complete their assigned milestones each week. Every member of a team will ordinarily receive the same score on the final project at term’s end except in cases of inequitable contributions.

Lectures

Lectures on topics including:

• Git and GitHub
• HTML and CSS
• JavaScript
• Databases, SQL
• Node.js
• React

Labs

Six labs will be assigned during the term, each ordinarily due on Wednesdays. Students may work with up to one partner on each lab; both partners must still submit in this case, and both partners must turn in identical work.

A schedule of labs appears below.

Final Project

The climax of this course is its final project. The final project is your opportunity to apply lessons learned in this course to develop a large-scale solution to a problem drawn from the arts and humanities fields. So long as your project draws upon this course’s lessons, the nature of your project is entirely up to you, albeit subject to the requirements below. Strive to create something that outlives this course.

• You must work on a team of size 3 or 4.
• Your project must solve a problem in the domain of the arts and humanities.
• Your project must use HTML5, CSS3, JavaScript (ES6), and React for its front end.
• Your project must use JavaScript via Node.js for its back end.
• Your project must use SQL for its database.
• Your project must be deployed to Heroku.

Extensions on the final project are not ordinarily granted, except in cases of emergency. A Dean’s excuse is required. Teams will meet with an assigned advisor for milestone meetings in the final third of the term, with each advisor setting goals for each team individually. Teams are expected to achieve these milestones. Combining your final project with that of another course is possible, but must receive approval from both courses’ instructors.

Mental Health

If you experience significant stress or worry, changes in mood, or problems eating or sleeping this semester, whether because of CS100 or other courses or factors, please do not hesitate to reach out immediately, at any hour, to the course’s instructor to discuss. Everyone can benefit from support during challenging times. Not only are we happy to listen and make accommodations with deadlines as needed, we can also refer you to additional support structures.

Academic Honesty

This course’s philosophy on academic honesty is best stated as “be reasonable.” The course recognizes that interactions with classmates and others can facilitate mastery of the course’s material. However, there remains a line between enlisting the help of another and submitting the work of another. This policy characterizes both sides of that line.

The essence of all work that you submit to this course must be your own. Collaboration on labs is not permitted except to the extent that you may ask classmates and others for help so long as that help does not reduce to another doing your work for you. Generally speaking, when asking for help, you may show your code to others, but you may not view theirs, so long as you and they respect this policy’s other constraints. Collaboration on the course’s final project is permitted, subject to this policy’s other constraints.

Below are rules of thumb that (inexhaustively) characterize acts that the course considers reasonable and not reasonable. If in doubt as to whether some act is reasonable, do not commit it until you solicit and receive approval in writing from the course’s staff. Acts considered not reasonable by the course are handled harshly. If the course refers some matter for disciplinary action and the outcome is punitive, the course reserves the right to impose local sanctions on top of that outcome that may include an unsatisfactory or failing grade for work submitted or for the course itself. The course ordinarily recommends exclusion (i.e., required withdrawal) from the course itself.

Regret clause. If you commit some act that is not reasonable but bring it to the attention of the course’s staff within 72 hours, the course may impose local sanctions that may include an unsatisfactory or failing grade for work submitted, but the course will not refer the matter for further disciplinary action except in cases of repeated acts.

Reasonable

• Communicating with classmates about labs’ problems in English (or some other spoken language).
• Discussing the course’s material with others in order to understand it better.
• Helping a classmate identify a bug in his or her code at office hours, elsewhere, or even online, as by viewing, compiling, or running his or her code, even on your own computer.
• Incorporating a few lines of code that you find online or elsewhere into your own code, provided that those lines are not themselves solutions to assigned problems and that you cite the lines’ origins.
• Sending or showing code that you’ve written to someone, possibly a classmate, so that he or she might help you identify and fix a bug.
• Sharing a few lines of your own code online so that others might help you identify and fix a bug.
• Turning to the web or elsewhere for instruction beyond the course’s own, for references, and for solutions to technical difficulties, but not for outright solutions to labs or your own final project.
• Whiteboarding solutions to labs with others using diagrams or pseudocode but not actual code.
• Working with (and even paying) a tutor to help you with the course, provided the tutor does not do your work for you.

Not Reasonable

• Accessing a solution to some lab prior to (re-)submitting your own.
• Asking a classmate to see his or her solution to a lab before (re-)submitting your own.
• Decompiling, deobfuscating, or disassembling the staff’s solutions to labs.
• Failing to cite (as with comments) the origins of code or techniques that you discover outside of the course’s own lessons and integrate into your own work, even while respecting this policy’s other constraints.
• Giving or showing to a classmate a solution to a lab when it is he or she, and not you, who is struggling to solve it.
• Paying or offering to pay an individual for work that you may submit as (part of) your own.
• Providing or making available solutions to labs to individuals who might take this course in the future.
• Searching for or soliciting outright solutions to labs online or elsewhere.
• Splitting a lab’s workload with another individual and combining your work.
• Submitting (after possibly modifying) the work of another individual beyond the few lines allowed herein.
• Submitting the same or similar work to this course that you have submitted or will submit to another.
• Submitting work to this course that you intend to use outside of the course (e.g., for a job) without prior approval from the course’s staff.
• Viewing another’s solution to a lab and basing your own solution on it.