Unity
Unity
Unity and Flask
Unity
Unity
Flask
Flask
Unity
Unity
| About: | | Overview | Schedule | Goals | Grading | Resources | |
| Policies: | | Late Work | Integrity | Accommodations | |
|
Scott Arboretum Visualizer Unity |
|
Blackjack Unity |
|
Side Scrollin' Unity and Flask |
|
Settlers of Catan Unity |
|
Sci-Fi Game Unity |
|
Trade @ BMC Flask |
|
Study Map Flask |
|
Super Coin Man Unity |
|
Fishbot Unity |
Class: TR: 11:20 - 12:35, Science Center 181
Lab A: M: 1:15 - 2:45, Science Center 256
Lab B: M: 3:00 - 4:30, Science Center 256
The goal of this course is to help students become more effective writing large programs.
Software engineering is the application of systematic, measurable, and disciplined approach to the creation of computer programs. In this course, students will learn how to plan, organize, and maintain large software projects. Topics include software development methodologies, design principles, collaboration techniques, the use of modern libraries and frameworks, quality assurance, and timeline management.
In the first part of this course, we will cover a range of topics related to software design, implementation, and tools. In the first part, you will write several small applications. Applications will be evaluated against feature criteria as well as code reviewed by your peers.
In the second part, you will split into groups of 3-5 people and complete a non-trivial project of your own choosing. During the project, each team will be expected to show weekly progress via lightning talks and weekly meetings. Lightning talks are a 5 minute persentation, with 5 minutes for questions. Lightning talks should describe a problem the team solved that week or a technology the team learned. During projects, all members of the team will meet with the instructor during lab to evaluate and reassess the project using an AGILE project development process.
We will use C# and Unity for the first part of the course. You are encouraged to use these tools for your project, but you may use a different toolset with permission from the instructor.
Prereqs: CS35
All course material is provided through class lectures and labs. Additionally, we will do quizzes during class, which will count towards your participation grade. Labs will be an opportunity to make progress on assignments.
Participate actively.
It strongly recommended that students take hand written notes in class. Some evidence suggests that taking notes is a more efficient way to learn material. Students will also help each other via code reviews and by active Q&A sessions during lightning talks at the end of the semester.
Complete all assignments.
Assignments will give you hands on experience with the course material.
Have a growth mindset.
A growth mindset means believing that you can improve through effort.
Support each other's learning.
Don't be a jerk. People learn best when they are in an environment where
they feel secure making mistakes and asking questions. Thus, we will all hold each other accountable
concerning the following:
- no 'well-actuallys' (e.g. no needless clarifications);
- no feigning surprise (e.g. *gasp* you don't know random-fact-x);
- no backseat driving (e.g don't give unsolicited advice. For example, don't interject your advice into other people's homeworks/projects in lab.);
- be aware of your biases (e.g. don't trust preconceptions and assumptions; it's lazy and often inaccurate)
Assignments will be assigned most weeks for the first part of the semester. They will be submitted electronically by pushing to your assigned git repository. You may push your assignment multiple times, and a history of previous submissions will be saved. You are encouraged to push your work regularly. The last part of the course will have students working in teams of 3-5 to complete a non-trivial project. Teams should create a git repository for storing their code and keeping track of weekly progress.
About the CS Lab:
The CS labs (Sci Center 240, 256, 238, and Clothier basement)
are open 24 hours a day, 7 days a week
for you to use for CS course work. With the exception of during times when
a class, or a class lab or ninja session is scheduled in a lab, you
may work in one of the CS labs on your CS course work anytime. The overflow
lab (238) is always available. The CS lab resources are for CS course
work. Please review the CS Lab Rules and CS User Rules about appropriate use of CS labs.
Accessing the CS labs after hours:
use your OneCard to gain access to the computer labs and Science Center (near Cornell library) at nights and on the weekends. Contact public safety if you
are not able to access these spaces with your OneCard.
Your late days will be counted at the granularity of full days and will be tracked on a per-partnership basis. That is, if you turn in an assignment five minutes after the deadline, it counts as using one day. For partnered labs, using a late day counts towards the late days for each partner. In the rare cases in which only one partner has unused late days, that partner's late days may be used, barring a consistent pattern of abuse.
You may only use up to 2 late days on any individual assignment. After you have used up your late days, you may incur a large penalty or even get a zero.
You may not use late days for the final project, lightning talks, or quizzes. A
missed lightning talk or quiz will result in a zero.
Absence/Assignment Extension Policy
Your three late days for lab assignments are intended to help when you need to miss
a class due to a minor illness or to travel for a conference or interview,
or when you have a lot of work to do in another class.
Extensions are not granted for any of these reasons;
Use your late days
if you feel that you need an extension on an assignment or that you are
unable to attend class for two or more meetings due to a medical condition
(e.g., extended illness,
concussion, hospitalization) or family emergency,
you must provide your instructors with official documentation from the
dean's office or student health center. Their documentation will help us
to provide the appropriate accommodations.
Discussing ideas and approaches to problems with others on a general level is fine (in fact, we encourage you to discuss general strategies with each other), but you should never read anyone else's code or let anyone else read your code. All code you submit must be your own with the following permissible exceptions: code distributed in class, code found in the course text book, and code worked on with an assigned partner. In these cases, you should always include detailed comments that indicates on which parts of the assignment you received help, and what your sources were.
Failure to abide by these rules constitutes academic dishonesty and will lead to a hearing of the College Judiciary Committee. According to the Faculty Handbook: "Because plagiarism is considered to be so serious a transgression, it is the opinion of the faculty that for the first offense, failure in the course and, as appropriate, suspension for a semester or deprivation of the degree in that year is suitable; for a second offense, the penalty should normally be expulsion."
The spirit of this policy applies to all course work, including code, homework solutions (e.g., proofs, analysis, written reports), and exams. Please contact me if you have any questions about what is permissible in this course.
For this course, it is fine to help each other with using utilities and tools (Unix, C++, Sqlite, man, git, make, ...), and with reading and understanding the assignments. However, you should avoid discussing the details of your solution with anyone other than your lab partner, and you should never look at anyone else's code for a solution to a lab (or to a similar project). In addition, there are many useful on-line resources of which you should take advantage. However, make sure that you do not use these resources in such a way that it violates the spirit of our Academic Integrity statement. For example, should you post questions to on-line forums or mailing lists seeking a solution to the specific problem you are asked to solve. Basically, the solution and code that you submit as your own should be your own. If you are unclear about what type of collaboration is okay and what type is not, ask me about your situation before proceeding.