There are three primary means for communicating between those involved in this course, in addition to the regular lecture sections. In no obvious order, these are:
The instructor and the TA(s) will have regularly scheduled hours when they will be available to discuss questions and problems with the course. The schedule is:
The course newsgroup ubc.courses.cpsc.411. The instructor, TAs, and all students are expected to read the news on a very regular basis. Late breaking information about assignments and the phases of the project, corrections to mistakes made in class, and generally useful information will often be communicated through the newgroup. You are responsible for reading the newsgroup - the plea of ignorance will not be received.
The newsgroup is also a very effective means of communication if used correctly. Questions about the assignments and project should be posted to the newgroup rather than being emailed to the instructor or a TA, as everyone will see both the question and its answer. All students are encouraged to post answers to questions posed on the newgroup as well.
Email to the instructor or TAs is effective in limited circumstances. It is the most effective means of scheduling a consulting time when the regular hours are impossible or insufficient. It is an appropriate means of asking questions concerning the grading of assignments and examinations. It is not an appropriate means of asking questions about the assignments or project - see the course newsgroup.
The following is a tentative grading scheme for the course, although it is subject to change at the instructor's discretion.
Lectures will closely follow the textbook, possibly with some ommisions or the addition of extra material. This webpage will be updated to reflect the covered material. Below is a tentative table of contents, with references to the chapters in the book. Pointers to supporting material, such as presentation slides etc. will be added to this outline if and when they become available. Note that materials may sometimes be posted ahead of lecture but such materials are always subject to last minute changes.
Your homework in this class will be divided between two short assignments and the project. The assignments are two relatively small "warm up" exercises. They are designed to help you get acquainted with the tools used in the course, before tackling the bigger project. The language of implementation for this course is Java, and so it is strongly suggested that you make an effort to learn the basics of the Java language early in the term. The assignments will be designed to help you to accomplish this.
The list of project groups is here.
The warm-up exercises are to be completed individually. However for the MiniJava project you will be required to work in groups of 2. If the number of people in class is not an even number, there will be one group of 3.
Signup deadline: Wed January 14th at midnight. Missing the deadline will cost you upto 10% of the MiniJava project mark.
Each group should have one of its members send an email to the TA Sarah Rastkar (email: rastkar@cs.ubc.ca) listing the names and unix id's of both members of your team.
If you cannot find a partner by Jan 14th, please stay behind after the lecture on Jan 14th to try to find another unpaired student. If after this you still did not find a partner, you should send an email to Sarah by the deadline, requesting that she assign you to a random group.
How you organize work between yourself is ultimately up to you. We recommend you use pair programming (recommended because it is more fun and helps each of you learn from one another). If however you decide to divide the workload between team members, this is not strictly forbidden. However, we expect that each team member completely understands the code developed by other team members. Any team member should be able to step up to the plate to answer questions about specific code details or implementation decisions. See also the section on Project Evaluation below. If you cannot answer questions about the solution you submitted you should not expect any credit for submitting it.
This year's project will be to create a compiler for a subset of the Java language. This compiler compiles Java into native x86 code (rather than JVM bytecode). The project follows the project steps as described in the textbook. Typically there is one chunk of work to be completed for each chapter in the book. However, not each one of these will be submitted individually. We will lump them together into larger chunks of related code. Each part is building upon previous parts. It is important therefore that you do not fall behind.
You will be given lots of help, in the form of hints, documentation, and sample code. Many of you should be able to attempt to extend your compilers beyond the basic requirements.
We will evaluate more than merely whether or not your code "works". Code review and a live demonstration will be an important component in assigning your final project grade.
Here we will pay specific attention to programming style; whether or not you made informed decisions on how to implement and structure your solution; and whether you can "think outside the box". To aid in this evaluation, you will have to demonstrate and verbally defend your solution to the TA and instructor.
You should be prepared to:
If you used a division of labor rather than a pair programming approach, you should be fully aware of the other member's work, and should be able to answer questions about the whole project as if it was entirely your own work.
It is very important that you think about different possible implementation/design choices throughout the project and make informed decisions. It is often the case that no single choice is "the best". Each strategy typically has some benefits and some drawbacks in terms of efficiency, code maintainability, ease of implementation etc.
To demonstrate that you can think about these choices and their repercussions, you should be able to explain alternatives and their relative benefits, as well as justify the often subjective value judgements that are inherent in chosing one solution over another.
The bulk of your project marks will be determined at the end of the course, based on the project as a whole, in it's completed form. The final project demo/defense will be very important in determining this mark.
This means that you can continue (and are encouraged!) to make revisions to the code you already submitted in earlier stages: improve it, fix bugs, revise implementation choices etc.
The deadlines for each sub-project stage should be seen as important administrative milestones. They are intended to keep you working on the project at a steady pace. Their primary purpose is not to assign marks.
In accordance with this principle, only a smaller percentage of the project marks will depend on whether you meet the "administrative requirements" of finishing certain chunks of work by a given deadline. The TA will keep a record of which teams submitted on time, and whether or not the submitted code appears to work (this will be determined by running the unit tests and doing a quick inspection of the test output and the submitted code).
The precise division between these two marking components may still change, but the current plan is as follows:
Please read the departmental policy on Plagiarism and Collaboration here.
Plagiarism means passing of someone else's work as your own. Plagiarism is a serious offense and dealt with quite harshly by the university. Cases are forwarded to the Dean's office and can result in suspension from the university as well as an entry on your academic transcript.
The key to using other people's code without commiting plagiarism is to make it absolutely clear how much of your assignment is your own work and how much it is based on someone else's work. When copying something, or adapting it as part of your solution, you are fully responsible to provide clear references to your sources, and to what extent your solution is based on these sources. Code comments are a good way to do that for programming assignments.
For the assignments, you are expected to work individually. If you do rely on other people's work, for whatever reason, and properly explain the nature and extent of the collaboration, this is not plagiarism (i.e. with proper explanation, you are not implying that the work is your own). You can submit such a properly commented solution for partial credit.
For the MiniJava project you will work in teams. It is expected that the work submitted as a team is collaborative work. As such we will treat the code as being developed by all team members together. We do not require you to provide comments about the details of exactly who wrote every single line of code. However, during the demo, if we sense that there is an imbalance in the contributions made by each team member, we may ask for clarification and we may reflect this imbalance in your final marks.
You are not supposed to copy code or otherwise collaborate with people other than those on your own project team. If you do, then you can still submit your work for partial credit, provided that you provide adequate documentation of your sources and the extent to which your solution is derived from them.
When you are provided starter code, as is the case in most of our assignments and project drops, it is automatically assumed that you did not write the starter code yourself. It is therefore not necessary to provide explicit documentation to explain this obvious fact. On the other hand, it is automatically assumed that you are claiming any code that differs from the original starter code as entirely your own work. If this is not the case, you are fully responsible to provide a clear and complete explanation of this fact. Any failure to do so will be considered academic misconduct. Forgetfulness is not an excuse.