This course is an introductory programming course, using Java as the programming language. It is not a course in professional Java Software Development, but a course about the fundamentals of programming that happens to use Java. This eventually entails learning about the fundamentals of object-oriented programming, but in this course, we will start out with what we call functional Java. Furthermore, we will follow a teaching concept called the Design Recipe.
The course content does not consist of independent modules - they build heavily on each other. As such, it is important that you attend the workshops and keep up with the course content, as later course content requires that you understand what has come before.
The following is a description of how the various parts of the course work and interact. You can see this description as essentially a more readable version of the relevant parts of the class summary.
Workshops#
Workshops are the main delivery vehicle for course content - they are part lecture, part interactive lab exercise. By default, no recordings of the workshops will be made available, so you need to attend in person and actively participate. In cases where you are unable to participate in a workshop, we will provide guidance on book chapters and additional explanations to read to catch up on the relevant content.
The course is based on the ideas of the textbooks How to Design Programs (second edition) and How to Design Classes, adapted to our needs. Both books are freely available online under their respective links. Readings that allow catching up on missed workshops will generally point to one or both of these two books and additional notes. Note that How to Design Programs in particular was not written for Java.
It will be much more time-efficient for you to attend the workshops.
Workshops may contain graded in-class activities that form a participation mark. This participation mark is not included in your overall course mark per se, but may give you up to two bonus marks around grade boundaries. For example, with a really good participation mark, you may bumped up from 68 to 70.
Assignments and Code Walks#
Worth 40% of the course marks. All cohorts do the same assignments, up to may be some variations specified in the assignment specification.
Assignments are A1, A2, A3, and A4. They are marked in weeks 4, 6, 10, and 12, respectively, and due on Friday at 3pm Canberra time the week earlier; see Deadline Policies for details.
The first assignment is redeemable against the core-level content of the final exam. Assignments 3 and 4 contain distinction-level tasks summing up to 10% of course marks (i.e. 25% of the assignment marks). During Assignment Submission, you need to indicate whether you would like to be evaluated on distinction-level tasks if possible. Your code needs to achieve at least 90% of the points available on core-level tasks on our automated tests in order for you to be evaluated on distinction-level content. You will be told in your code walk whether this applies.
An average student should aim to achieve around 90% of core-level marks on each assessment item.
Assignments contain various programming tasks. It is important to complete these tasks in the style prescribed by the course, see in particular the Design Recipe. Assignments typically have a base deadline on a Friday at 3pm Canberra time, which can be pushed back via Extension Tokens. Essentially they give you two opportunities you can use to push a personal assignment deadline back by 24 hours each across all four assignments. You can get Extensions instead of or on top of that, but not past Tuesday 15:00 following the base deadline, as Tuesday evening is the assessment return time, which in this case marks the beginning of assessment feedback: on that moment, you will be notified whether we received a submission from you that we could sufficiently evaluate such that you can proceed to the main step of assignment marking, which is attending a code walk.
Assignment submission#
Assignment files (Java source codes, notebook, statement of originality, etc.) are submitted via Git code repositories hosted in Teaching GitLab (see the Git and Notebooks page for more details).
As a very important note, we will mark the version of your work corresponding to the latest commit pushed to GitLab before the base deadline Friday at 3pm Canberra time (or otherwise the latest commit before the pushed back deadline via Extension Tokens and/or Extensions).
You should be extremely careful to ensure that the latest commit pushed to the remote repository hosted in GitLab before the deadline is actually the one that you want us to mark. Otherwise, we could end up marking a version of your work for which you may obtain significant less marks. Due to logistic reasons, we are not able to make exceptions here. As a general recommendation, do not leave the submission of the final bits of your work to the last minute, so that you have enough time to double check that the latest commit pushed to the remote repository is actually the one that you want us to mark, and amend your submission if necessary (typically by pushing an additional final commit with the fixes required).
Code Walks#
Code walks are small-scale meetings where you explain the code you submitted to tutors and answer questions about related course content. This determines your complete assignment mark, which is based on a combination of correctness, form, and understanding, with a heavy emphasis on the latter two. A usual code walk will take about an hour and be attended by two tutors and around four students. Each student will be asked to explain their code and answer questions for around 10 minutes. The feedback will be provided at a later date, along with the results of the automarker tests.
The 4.5-hour lab you registered for on MyTimetable is an umbrella lab that contains four such code walks. It serves to make sure that everyone can get a time slot for a code walk during a time that they are available. Actual code walk time slots will be allocated closer to the code walk dates, and only when you explicitly register your intent to participate in a code walk. You have to do so for each assignment you submit, by 6pm on the day of the base deadline (this does not change via extensions or extension tokens, as we try to form a schedule over the weekend and let everyone know their slot around Monday). If you have a legitimate reason and corresponding evidence for why you were unable to register by 6pm on the preceding Friday, we will still try to find some slot for you).
In this process, you can also specify preferences for times outside of your registered lab time, and we will try to accommodate this where possible. However, we assume that you are at least available for all the times during your registered lab time.
If you did not enroll in a particular lab, we will assume that any time works for you.
If you register for a code walk and get assigned a time, but do not show up and cannot provide evidence of a good reason for that, you will lose the ability to specify time preferences and will not get assigned a time beforehand. You can still register your intent to attend a code walk (and must do so if you want to attend one), and if you do so, you can come to your allocated 4.5 hours and we will run your code walk at some point where there is capacity.
To register your intent to attend a code walk, to specify date and time preferences, and to request the number of extension tokens that you would like to use, you will need to fill a web form (see Deadline Policies for more details). The link to the particular web form will be available in the assignment specification.
Drop-In Consultations#
Drop-In consultations are open to all students in the course to get individual help and advice from tutors. You do not have to attend any of them, but can make use of as many as you want. We will continuously adjust their schedule according to demand and overall resources. Please check the weekly schedule for the current week to see relevant times. Dates in weeks further into the future may change significantly.
Mid-Term Test, Final Exam, and Hurdles#
Worth 20% (Mid-Term Test) + 40% (Final Exam) = 60% of the course marks.
The Mid-Term Test and Final Exam are invigilated assessments in computer labs without internet access or other materials (except, with School approval, unannotated dictionaries) not provided to you on the lab machines or Exam GitLab. Their marks are based on automated tests of the code you submit. Note that it is critical that the code you submit can be compiled.
Both the Mid-Term Test and the Final Exam contain 25% distinction-level content. In order for any of your submissions of distinction-level content to be evaluated and counted, you need to achieve 90% of the marks on the core-level content.
Hurdles are calculated on the total available marks (i.e. including both core-level and distinction-level content). You need to pass all hurdles in order to pass the course as a whole. If you fail at least one hurdle, but get more than 45% of the overall course marks, you can take a supplementary assessment, but at best (i.e. if you pass the supplementary exam), you final grade will be PS.
Mid-Term Test#
The Mid-Term Test is associated with the Basic Competency Hurdle. You need to achieve at least 25% of the marks on the Mid-Term Test in order to pass this hurdle. Should you not be able to attend the Mid-Term Test due to a valid reason, you can submit an ECA for an alternate assessment for the Basic Competency Hurdle. The Mid-Term Test itself is redeemable against the final exam, and as such will not otherwise be deferred or alternately assessed.
The point of the Mid-Term Test is to both give you feedback on your standing in the course and to also prepare you for the conditions of the final exam.
Final Exam#
The Final Exam is an invigilated exam in computer labs, consisting of 15 minutes of reading time and 3 hours of writing time. The Final Exam is a hurdle assessment: you need to achieve at least 40% of the available marks to pass the hurdle.