Overview

Course Objectives: This course has the following main goals:

• One is to introduce fundamental concepts in data structures and important concepts in object oriented programming.
• A second is to develop good programming skills and habits, including for example, good software testing skills.
• A third is to encourage students to think critically.
• A fourth is to have fun along the way. The more fun you have the better you would learn.

To accomplish these goals, the course has a heavy programming component, to be completed using Java.

Class Times and Schedule:

• Lectures: Tuesdays/Thursdays 11:00 AM - 12:30 PM @ GDC 5.302
• Discussion: Fridays 11:00 AM - 12:00 PM @ GDC 2.210

Course Staff and Office Hours:

Name	Office Hours
Emmett Witchel	Fridays 1:00 PM - 2:00PM GDC 6.432 or Zoom or by appointment
Anavi Nayak	Mondays 2 - 3:30 PM in the GDC 4th Floor Atrium (4.100)
Shashank Iswara	Tuesdays from 5-6:30 in the GDC 4th Floor Atrium (4.100)
Ojas Phirke	Thursday 5:00 - 6:30 PM in the GDC 4th Floor Atrium (4.100)

Mail sent to cs314h-staff will reach all course staff. See more on Course Communication.

Textbooks:

• Required: M. Weiss. Data Structures and Problem Solving using Java. 4th Edition. Addison-Wesley, 2006.
• Supplementary texts:
• Java Reference Book: Cay. Horstmann. Core Java Volume 1 - Fundamentals. 11th Edition. Pearson, 2018.
• OOP Design: Head First Design Patterns: Building Extensible and Maintainable Object-Oriented Software. 2nd Edition. O'Reilly, 2020.
• Game Design: Game Programming Patterns (Prof. Oliver Jensen's Pick)
• Best Practices: Joshua Bloch. Effective Java. 3rd Edition. Addison-Wesley, 2017.

Course Prerequisites: Computer Science 312 or 312H (or a equivalent college-level course) with a grade of at least C-.

Topics: We’ll cover the following topics, roughly in the following order, although some of these topics are sprinkled throughout the course. Some of the basic topics will be covered extremely briefly. There will also be assigned reading from other portions of the book that are not listed here.

1. Introduction. Course overview, administrivia.
2. Java. Basic goals and concept. (Weiss Ch 1-2)
3. Object Oriented Programming. Encapsulation. Inheritance. Polymorphism. (Weiss Ch 3-4, 6)
4. Programming Skills. Xtreme Programming, debugging, testing, application of OOP concepts. (Pair Programming Reading. Related Chapters in Effective Java, Head First Design Patterns)
5. Basic data structures. Stacks, queues, linked lists. (Weiss Ch 16-17)
6. Algorithm analysis. (Weiss Ch 5)
7. Recursion. (Weiss Ch 7)
8. Sorting. Mergesort, quicksort, bin sort, heap sort. (Weiss Ch 8)
9. Trees. Traversal. Binary search trees. (Weiss Ch 18-19)
10. Hash Tables. (Weiss Ch 20)
11. Balanced Trees. Splay trees. AVL trees. Red-Black trees. B Trees. Union-Find trees. (Weiss Ch 22)
12. Priority Queues. Binary heaps. (Weiss Ch 21)
13. Graphs. Graph algorithms. (Time permitting.) (Weiss Ch 21)

Attendance: Attendance is strongly recommended as we may cover material not included in the readings that you will be expected to know. Any lecture notes that are provided are not intended as a replacement for the lectures. Classes are also heavily discussion-oriented so reviewing recordings will not be as valuable as being in the discussion in real time. However, your attendance record will not directly affect your grade.

Illness and Absences: If serious illness prevents you from handing in an assignment or taking a test, you should contact me or the TA immediately if you’d like to receive special consideration.

 

Grading

Grading: Final grades will be decided by the following approximate weights. For details, please see canvas. The exact weights might shift a little as the semester progresses.

• Programming Assignments: 55% (Approximately 7 of them)
• Exams: 45% (Report immediately for conflicts if any)
  • Midterm 1 (20%): Oct 12 Wednesday @ 6-9 PM
  • Midterm 2 (25%): Nov 29 Wednesday @ 6-9 PM

Letter grade assignments:

• 100-93%: A
• 92.99-90%: A-
• 89.99-87%: B+
• 86.99-83%: B
• 82.99-80%: B-
• 79.99-77%: C+
• 76.99-73%: C
• 72.99-70%: C-
• 69.99-67%: D+
• 66.99-63%: D
• 62.99-60.01%: D-
• 60-0%: F

Grading Disputes: Students are responsible for carefully inspecting all graded material. If you believe your work was graded incorrectly, you may submit a regrade request to the course staff. You must submit a regrade request to cs314h-staff within three days of the date the grade became available on Canvas. Your complaint must contain supporting evidence and arguments which explain why your work was graded incorrectly. (For example, it is not sufficient to submit a note that says ”regrade question 3”.) Grade change requests that do not meet these requirements will not be considered.

Late Work Policy: Unless otherwise specified, assignments are due by 5 PM on their due date. Late assignments will be penalized by 10% per day (1% per hour up to 5%, followed by a 5% cliff). Technical problems such as printer failures, account lockouts, etc. are not cause for extensions. Start early. Requests for grade corrections must be made within three days of the assignment of the grade.

 

How to Succeed in the Course

This course moves fast, so I encourage you to keep up with the reading and programming assignments. If you get behind, it can be difficult to catch up. If you have any problems or questions, please come talk to me or the TA as soon as possible so that we can help.

There may be times when your background has holes relative to your classmates. In these situations, you should certainly seek extra help, but you will at times be expected to do a certain amount of reading and learning on your own. If you are unwilling to do this, you should consider dropping the course.

There may be some of you for whom parts of this course are old material; if this is true, I encourage you to try some of the more advanced, optional parts of the assignments.

Help each other learn. One of the best ways to ensure that you understand a concept is to explain that concept to another person. (Note that while you are not allowed to help each other write programs, I encourage you to discuss concepts that are presented in class and in the book. For example, a particular programming assignment might ask you to use a particular data structure; you are encouraged to discuss the properties and details of this data structure in the abstract, without looking at each other’s code.)

Finally, to succeed in this course, it’s very important that you learn to think for yourself. For example, you will find that certain aspects of your programming assignments will be underspecified—it’s up to you to think about what the right thing to do is

How to Fail in the Course: Ignore the above advice. Assume that you can learn everything from the textbook. Start homework assignments late, and don’t even start reading the programming assignments until 3 days before they’re due.

 

Collaboration and Cheating

Let's talk about pair programming, because that happens for several assignments in this class. You may choose your pairs, but each pair must be unique throughout the semester. That means that you can only have a given partner for one assignment. Feel free to talk about partnering in class or use Ed Discussion to look for partners. Programming is a social activity!

Collaboration is a very good thing. On the other hand, plagiarism or cheating is considered a very serious offense. Please don't do it! Concern about cheating creates an unpleasant environment for everyone. We will use technological means including Stanford Moss and other means to detect cheating.

 The principles of the collaboration policy are:

• Discussion is encouraged!
• We expect highly ethical behavior.
• Representing someone else's work as your own is unacceptable.
• Familiarize yourselves with the UT policies on academic integrity.
• If you have a question about what is allowed, ask!

Violating the collaboration policy will result in failing the class and a letter in your University file.

A Few Examples of Cheating: There are many examples of cheating, but these include accessing another student’s account, looking at someone else’s code, copying or downloading someone else’s code, or allowing others to copy or access your code. Of course, this means that you should not look on the Internet for code to solve your problems.

Protect Your Code: Do not leave your laptop unlocked. This is a good practice for security purpose as well. Also never post your code for the assignments online such as Github, Gitlab, etc.

Group Work Policy: You are free to discuss the course material and all aspects of the group assignments with your teammates/partner, but teams are expected to make clear their division of labor for each aspect of the project. Students are expected to do individual work on their portion of the project.

Discussion within/without teams is permitted, indeed, encouraged! You can learn a lot from others; you can avoid getting stuck; and teaching someone else can be the best way to cement your own understanding. You may have discussions with anyone you like, including other students following the rules and guidelins below.

Gillian's Island Rule This rule says that you are free to meet with fellow student(s) and discuss assignments with them. Writing on a board or shared piece of paper is acceptable during the meeting; however, you should not take any written (electronic or otherwise) record about the assignment away from the meeting. This applies when the assignment is supposed to be an individual effort or whenever two teams discuss common problems they are each encountering (inter-group collaboration). After the meeting, engage in a half hour of mind-numbing activity (like watching an episode of Gilligan's Island), before starting to work on the assignment. This will assure that you are able to reconstruct what you learned from the meeting, by yourself, using your own brain.

The Freedom of Information Rule: To assure that all interactions are on the level, you must always write the name(s) of who you talk with about your assignments on your assignment. These names should be listed in a prominent location at the top of the first page of your assignment. If it is a programming assignment, include this as part of the comment. (eg. “Susan and I discussed various approaches to testing our code.” eg. “I am using the quicksort algorithm described in Chapter 8 of Weiss”).

Code Reuse: The code you submit should be your own. The only exceptions: You may use code (with attribution) from our primary textbook and from the Java standard libraries.

You must write up anything you submit on your own: Your code (which includes tests and documentation), problem answers, etc. must represent your own understanding, as explained solely by you, and your team members for the group assignments.

You may not view other people's code or solutions beyond your teammates: You may not share any of your own code (including, as always, tests and documentation) with others, including bringing it to a meeting with others. You may not allow anyone except the course staff to view/access your code. Don't post large amounts of your code (more than about 5 lines) to the forum.

As an exception to the prohibition against viewing another student's work, you are permitted to assist another student with tool-related problems (such as difficulty using IntelliJ, etc.), even if such assistance results in incidental viewing of snippets of code. But, regardless, each student is expected to write and debug the assignment code individually. Debugging your code is not a tool-related problem.

You may not represent someone else's work as your own: You must give credit where credit is due. When you turn in assignments, you must list everyone with whom you've had substantive discussions. Likewise, if you obtained a key idea from some other resource, such as a textbook or a website, then you should credit it.
You may not view and/or use any substantive material or solutions from similar assignments this term or previous terms at UT Austin or elsewhere, including anywhere on the Internet, transcribing solutions from any other source, etc.

It's about your integrity, not just your grade: Integrity is crucial to a working engineer. Computing is at the core of almost all societal systems, and its discrete nature makes it especially unforgiving. Software has been responsible for death and damage. If you cut corners in your work, or are unprepared for it, then you, too, could cause such problems. We expect you to show high ethical standards in CS 314 H, and in the rest of your career. Accordingly, violation of academic honesty (for instance, by cheating or by collaboration beyond what is permitted) will be taken very seriously.

Exam policies

No devices: I ask you to power down all phones for the exam. That does not mean putting the phone away, but it means actually powering it down. For exams given on Canvas the assumption is that you have a web browser open with a single tab that shows the exam. Accessing the Internet in any way during the exam is not allowed and will be considered cheating.

Summary sheet: The exam is closed book and closed notes. But you can bring a single, double-sided 8x5x11 inch paper to the exam. The sheet can be handwritten or it can contain printing in at least 10pt font. It may NOT contain a printout of "handwriting" from an iPad, any writing must be created by physical pressure on the receiving medium. I sort of can't believe that I have to spell this out but I do. My point is that the process of choosing and writing is useful. If you just take a picture of page and shrink it, you do not get the benefit of curating the information you bring to the exam.

Course Communication

Canvas: We'll use Canvas for offical announcements, posting grades, sharing lecture recordings and notes. Find the Canvas link here.

Ed Discussion: We will be using Ed Discussion for posting assignments and technical discussions. You can access Pizza from Canvas. We encourage all members of the class to help one another on the forums. If someone asks a question to which you know the answer, then please answer it. Helpful, friendly replies are appreciated and will contribute to the class participation part of your grade. If you are overwhelmed by the forum volume, you don't have to read all of the forum messages (the staff will disseminate any truly important information by email), but if you have trouble, are likely to find it helpful to read the forum. Please don't re-ask questions that have already been asked or answered there; search before you post. Finally, to help your classmates who are reading all the forum messages, please do not post content-free “noise” messages saying just “Thanks for the post” or “You're welcome” or “Me, too” — we have had complaints about them cluttering the forum. Thanks!

Github classroom: github classroom for posting and collecting code for assignments.

Slip days: Every student gets 4 slip days for the semester, to be used when you want. If you turn in an assignment 5 minutes late, you can use a slip day so that it is no longer late. Slip days cannot be split up. You do not have to use all of your slip days.

Staff mailing list: This will be used for non-technical issues (re-grade requests, reporting absenses, etc). For technical questions, always use Piazza. Note mail sent to cs314h-staff@cs.utexas.edu will reach all course staff. As with any message, it is professional to use a descriptive subject line. Your question might be overlooked if you reply to an unrelated message or use a generic subject like “CS 314H Question”.

Mail to you: You are responsible for regularly checking (at least every 24 hours) both your CS email and your email officially registered with UT for class work and announcements. Your CS address may be forwarded to another account (see http://apps.cs.utexas.edu/udb/update/).

Office Hours: Please visit the staff during office hours if you have anything you'd like to discuss about the course or course materials. If the office hours are not convenient, then send email to schedule an appointment. It is most helpful if you suggest several times when you are available.

Constructive Comments (aka no "whining"): We always welcome feedback and comments about the course. We are excited to have you in the course building and improving the course together. Please remember to be constructive when making comments either privately or publicly. We all know whining is counter-productive, will only irritate the course staff, and will negatively impact other students.

git source code management

The course uses the git software version control system. You can find a lot of tutorial information for git on the Internet. For example, here is a nice visual tutorial on git branching, and here is a nice description of the model, and here is a very basic tutorial. More resources here.

The course will host all code on github, so you must make an account. Go here.

Our workflow with github is documented here .

The course will have a Demo repository that will have code that we go over in class that is example code. You can git pull to get the latest.

We use github classroom (link). I don't think you will spend too much time on this site specifically, but it is nice to know about.

Here are some command lines, for reference. Please remember to push your code after commit.

• git clone https://github.com/ut314-f2023/prog1-(githubid).git
...then modify the README and the Android studio project...
...and commit all my modifications...

• git commit -a -m "Starting my awesome assignment early."
• git push

We will post an invitation link on the discussion site for each programming assignment. Github will create a repo for you after you accept the assignment. The repo will contain a directory with starter code for the exercise. You can open this project directory in your code editor or integrated development environment (IDE). Inside this directory will be a README file that you need to fill in (e.g., with your eid). The name of your repository will have your github id. If your github id is supercoder, then you will clone prog1-supercoder. If we need to correct anything about the starter code, we will post it to the discussion site. Unfortunately, we can't change the starter code and push the changes to y'all.

How to Ask Questions

We want to help you by answering your questions! We would much rather that you ask us than that you waste your time in confusion and frustration. Here we suggest some ways to make your question more likely to elicit a useful answer. The two key points are to explain what you know and to explain what you have tried.

If you are having trouble with a tool or with code: Please be sure to include all the relevant information, and to be precise, so that others can help you. First, say what machine you are working on: the operating system, and whether it is a lab machine or your own personal computer. Then, state exactly what you did that caused the problem; this might be an action in a GUI or a command run from the command line. Also, state the exact outcome or output (not just “it gave an error”, for example), such as giving all the text from a popup message, or cut-and-pasting all the output from the command line. In case you want to include the output of terminal or textual output, please cut-and-paste the complete text and include it (rather than pasting the screenshots). The text is easier to read, is easy to make complete (unlike screenshots which may show only a portion of the output), and is searchable. Also, it can be helpful (to you and to others) to create the smallest possible test case that reproduces the problem. This helps to avoid being distracted by irrelevant details. You can proceed by binary search: cut away half of the input or the program at a time until you have isolated the problem. Even if you cannot do this, do still ask your question.

If you are having trouble with a concept: Please explain as much as you already understand. Saying “I don't understand anything about X” is unlikely to be true, and unlikely to be helpful in clearing up your confusion. For example, explicitly answering these questions can be a good place to start:

• What problem is being solved?
• Why is this an important problem?
• What is wrong with other approaches?
• Do you understand all the terminology?
• Where have you looked for the answer?

For any question: an excellent approach is to logically explain why your problem seems impossible. If your code is giving a wrong answer, then state a detailed logical argument about why the observed output is impossible. If you cannot understand a statement in the readings or in lecture, then state why it is a logical contradiction (or why it is not relevant, or what part of it just makes no sense). Also, be specific about what confuses you — for instance, give a page number. It's essential to say where you have already looked — in what books or handouts, what web search (Google is often smarter than the course staff and your friends), etc. Even if you do not discover your problem, this will help others to quickly understand the confusion — for example, perhaps you are misunderstanding a particular term, or you have forgotten to account for aliasing. And, it will prevent people from suggesting something you have already tried — such an answer delays you getting the help you want.

When NOT to ask questions? When you haven't tried to solve it yourself. You shouldn't ask a question until after you've at least tried to solve it yourself. As a general rule, that is actually good advice: sometimes you'll solve it on your own and, in any case, you can provide much better information about the problem. That information will make it much more likely that you quickly get a useful answer. Otherwise, someone might just suggest something you have already done, or might be confused about your problem.

When to ask questions? When you are stuck! It's great to make some headway on your problem before asking a question. But, stop when you are no longer making headway! If you get stuck, then stop wasting your time and get help from someone else. We definitely don't want you to waste your time in frustration, afraid to ask a question. Just explain what you know and what you have tried and ask the staff (or others) for help. Oftentimes there is a simple answer that can get you going again.

After your questions are answered: Finally, if you ask a question by email or in the forum and later discover the answer, then please let everybody know! This will help others, and will prevent anyone from wasting time continuing to answer a moot question.

Code of Conduct

The University of Texas Honor Code: The core values of The University of Texas at Austin are learning, discovery, freedom, leadership, individual opportunity, and responsibility. Each member of the University is expected to uphold these values through integrity, honesty, trust, fairness, and respect toward peers and community. Here is a link to the honor code.

Professionalism: Professional conduct is expected in this course. Professional conduct is built upon the idea of mutual respect. Such conduct entails (but is not necessarily limited to):

• Attending class: The class benefits from the attendance and participation of all students. For both lectures and discussion, in-person attendance is required. In case the lecture is provided via Zoom, plan to have your video on during class and be certain that your display name is your actual name (the one you use in person). However, we understand that there may be extenuating circumstances that prevent you from attending. Therefore, we will provide lecture recordings after the class. Note there will not be synchronous Zoom option during in-person class sessions.
• Arriving on time: Please do not hesitate to come to class, even if you are arriving late. I would rather you attend some of class, than miss out altogether. However, if you must arrive late or leave early, please be considerate of others.
• Minimizing disruptions (for Zoom): You are invited to participate in class synchronously regardless of the noise-level of your location or the number of people in your background (or foreground). However, please do keep yourself on mute during lecture so as to make sure all can hear. During office hours and discussions, please keep mute turned off to allow for a more natural conversation---unless noise levels are high in your location. In this environment, some disruptions are unavoidabl. Please do not allow fear of disruptions to prevent you from attending.
• Respect: You should act respectfully toward all class participants.
• Appearance: Please arrive at class events clothed for both in-person and online meetings. You don't have to look great, but being covered is not optional.

Failure to follow the Code of Conduct may result in penalties ranging from being banned from office hours to dismissal from the course. Note that the Code of Conduct encompasses treatment of both fellow students and course staff.

Creating Welcoming Environment for All

Diversity and Inclusion: Professional courtesy and sensitivity are especially important with respect to individuals and topics dealing with differences of race, culture, religion, politics, gender, and nationalities. I ask that all students work with me to create a welcoming environment that is respectful of all forms of diversity, including diversity in race, gender, mental health, religion, ability, parenting status, and outside responsibilities.

Students with Disabilities: My policy is to fully support all students with disabilities to the best of my ability. At no time is it required that you disclose the nature of your disability to me, and I will not ask you to do so. If you are a student with a UT-acknowledged disability, I ask that you meet with me in person to discuss accommodations as soon as you have your accommodation letter in hand. I do ask that you meet with me by the 12th class day so that we can put your accommodations in place as soon as possible. If you are a student with a disability that has not yet been acknowledged by UT's Services for Students with Disabilities, I hope that you will be willing to disclose your status to me and I ask that you meet with me in person to develop a plan for your success this semester.
University-required language: The University of Texas at Austin provides upon request appropriate academic accommodations for qualified students with disabilities. For more information, contact the Division of Diversity and Community Engagement, Services for Students with Disabilities at 471-6259, 471-4641 TTY.

Mental Health: We are going through a difficult season and I want you to know that you are not alone. There are many helpful resources available on campus. Learning how to ask for help is a sign of strength not weakness. If you or anyone you know experiences any academic stress, difficult life events, or feelings like anxiety or depression, we strongly encourage you to seek support. You may begin by talking to any of us, and we'll help you get connected to resources, or the Counseling and Mental Health Center is here to help you. http://www.cmhc.utexas.edu/individualcounseling.html

Religious Holidays: Religion (or lack there of) is an important part of who we are. If a holy day observed by your religion falls during the semester and you require accommodations due to that, please let me know as soon as possible. Email is an acceptable form of communication, though please use the format described above so I am more likely to receive it. If I do not indicate that I have received it, please do talk to me in person (virtually) or follow-up again in email. In order to guarantee accommodations around exams and other big deadlines, I will need notice of two weeks or more. If you are unable (or forget!) to provide that notice, please contact me anyway in case I can still accommodate you.
University-required language: A student who is absent from an examination or cannot meet an assignment deadline due to the observance of a religious holy day may take the exam on an alternate day or submit the assignment up to 24 hours late without penalty, if proper notice of the planned absence has been given. Notice must be given at least 14 days prior to the classes which will be missed. For religious holy days that fall within the first 2 weeks of the semester, notice should be given on the first day of the semester. Notice must be personally delivered to the instructor and signed and dated by the instructor, or sent certified mail. Email notification will be accepted if received, but a student submitting email notification must receive email confirmation from the instructor.

Harassment Reporting Requirements: Senate Bill 212 (SB 212), which went into effect as of January 1, 2020, is a Texas State Law that requires all employees (both faculty and staff) at a public or private post-secondary institution to promptly report any knowledge of any incidents of sexual assault, sexual harassment, dating violence, or stalking "committed by or against a person who was a student enrolled at or an employee of the institution at the time of the incident". Please note that the instructors and the TAs for this class are mandatory reporters and MUST share with the Title IX office any information about sexual harassment/assault shared with us by a student whether in-person or as part of a journal or other class assignment. Note that a report to the Title IX office does not obligate a victim to take any action, but this type of information CANNOT be kept strictly confidential except when shared with designated confidential employees. A confidential employee is someone a student can go to and talk about a Title IX matter without triggering that employee to have to report the situation to have it automatically investigated. If you would like to speak with someone who can provide support or remedies without making an official report to the university, please email advocate@austin.utexas.edu. For more information about reporting options and resources, visit http://www.titleix.utexas.edu/, contact the Title IX Office via email at titleix@austin.utexas.edu, or call 512-471-0419.

Emergency Situations: If you experience an emergency situation during the semester, Student Emergency Services is here to help you. They can help in the event of family emergencies, medical or mental health concerns, and interpersonal violence, among other situations. If you experience such an emergency, you may contact them directly through email (studentemergency@austin.utexas.edu) or by phone (512-471-5017), or you may contact one of us and we will assist you with the process.

Final Note

This syllabus is a plan of action for the semester. It is not a contract and is subject to change. As the instructor, I may make additions, deletions, and modifications to the syllabus and the course requirements with reasonable notification to the students enrolled in the course. You are responsible for any changes announced in class or on the course website.

Copyright Notice: These course materials, including, but not limited to, lecture notes, problem sets, and projects are part of CS core curriculum. You must ask me permission to use these materials. This copyright extends to any and all video or audio recordings of this class. I do not grant to you the right to publish these materials for profit in any form.

Class Recordings: Class recordings are reserved only for students in this class for educational purposes and are protected under FERPA. The recordings should not be shared outside the class in any form. Violation of this restriction by a student could lead to Student Misconduct proceedings

Credits: In the preparation of this course, I used materials from Mikyung Han, Calvin Lin, Oliver Jensen, and textbook authors. In building this syllabus, I borrowed language and formats from Mikyung Han, Calvin Lin, Oliver Jensen, and Michael Ernst.

Acknowledgements: Many thanks to Mikyung Han, Calvin Lin, Oliver Jensen, Alison Norman, Devangi Parikh, Mike Scott, Chand John, Sarah Abraham, Glen Downing, Lili Qiu, Don Fussell, and many other collegues for their valuable feedback, tips and tricks which helped me greatly build this course. Also I owe Michaela Cicero, the amazing helpreq/preq team, and all other staff members a debt of gratitude for their strong and timely support getting me on-board both remotely and in-person successfully. Thank YOU ALL!