Unit home

Project 1

help2002

Lecture & Workshop
recordings on LMS

Schedule

FAQ

Unit outline

C textbooks

OS textbooks

Information resources

Extra reading

Past projects

Recent feedback

Working effectively

Look after yourself!

CITS2002 Programming and Systems - Project 2 Feedback (2017)

• It was challenging, but not overly so. I definitely felt as though I had to work hard for the marks. It was very interesting and systems focused. I enjoyed working on a project that is actually useful / usable, being able to compile my code using the shell that I was working on was kind of fun, and it beats working on a project that does something abstract or not directly applicable.
• I thought it was very interesting, to mirror the behavior of a shell. Despite the fact that it was difficult to wrap your head around what was going on initially, it was a very adequate choice for a second project in a Level 2 CS unit.
  Thanks; the page of 'histograms' seems to back up your comment, too.
• I don't know where version control and collaborative work fits in to the degree structure but I feel that some reference material would have been helpful, particularly for this project.
  I agree; the growing challenge is the wide variety of students - Computer Science, Data Science, Software Engineers, other-Engineers, and MIT - and the lack of common pathways through their degrees. I would definitely like to (re)introduce material on better programming practices, somewhere, but most students already feel thet there's too much material. Add to your list debugging and performance measurement.
• Too mac specific. No one likes mac
  You have clearly missed an important message - that we focused almost exclusively on POSIX specific system-calls, which provide portability across the 3 contemporaty desktop operating systems. Windows-NT was the first ever operating system to achieve POSIX certification (in 1993). There was no 'mac specific' code required in this project.
• - Project sample solutions should've been searched for more thoroughly before reusing project
  - Project could've been more specific in requirements for certain features such as background execution and pipelines, possible could've without much effort by requiring functionality to match bash
  Fair points (though near 20 students will ikely be unhappy with their outcome re: your 1st point).
• A lot of the elements in the second project, such as pipes and signals, were not taught in lectures, and a lot of the other aspects of the project which were required to know in great detail were merely briefly mentioned in lectures. Overall, almost the entirety of the second project was extremely difficult to complete given the information given to us, and almost everything required internet searching. At that point, why am I even taking the unit, if the majority of the project's aspects required knowledge that wasn't taught, sufficiently or at all, in lectures, workshops, or labs? Thoroughly disappointed. Please, if you require something in the project (for example, pipes) then teach it first!
  This was a project for students with one or two unit's programming experience, who have complete nearly two years of their degree. It's certainly not school any more, were you're only assessed on material that you've been taught. I politely suggest that you talk with some of your peers about this, else you will likely find 3rd year units even more difficult.
• I found the project a bit too broad in some areas and dealing with edge cases was difficult - it did make it a really good learning experience but also makes me worried that I might have missed edge cases and lost marks.
• I felt that the second project was quite clear in what it wanted us to achieve and how Chris broke it into separate steps made it considerably easier to do. At different points parts of the project were difficult but not impossible. I quite enjoyed this project in comparison to the first project.
• Slightly better than the first project in terms of difficulty, the extensive use of recursion in functions required a lot of thinking however. The last question was too difficult to attempt, and we ran out of time towards the end.
• It was quite difficult for 15%, felt much more like a 20% project. Can't fault it otherwise. It was a very good learning experience (though frustrating)
• I think the project was very interesting but in my opinion was quite large. I feel that this would of been better executed if it was split into 2 parts like a previous CITS unit I've done, as I found the first project quite mundane and not really having anything to do with systems programming.
• The project was set up very well, there were some aspects in the chilli step that caused confusion, specifically the behaviour of the shell and what we should try to achieve.
• I felt the project was mostly straight forward and I managed to progress through it relatively rapidly but also feel that I was comfortable with the material before starting the unit. I do think that the preparatory material was perhaps insufficient for the cohort as a whole. Perhaps that information was, if not held back from the class, at least not provided as readily as it could be in order to make an even playing field for the project. This is to the benefit of those that have friends, family or peers that are more willing to provide this information but to the detriment of those that may not be used to man pages and the density and low level nature of C. I think I spent far too much time on the chilli question for what it was worth and could have learnt more about the topic of systems programming as a whole if help had been more forthcoming instead of spending so much time trying to fix small issues that seemed to effect a fair number of people here. Overall I feel that I could have learned more in this project if there had have been more detailed answers to questions as well as more stuff to do. I think maybe an option to extend past the chilli stage or possibly having more chilli questions could have served as some purpose here.
  Thanks for the many points in your comment; (no excuse, but) getting the balance right in a large class, of diverse abilities, is a challenge but the unit is improving each year.
• One criticism: I wish I knew ahead of time how much more difficult the last step was compared to all preceeding steps. I know it was given a chilli indicating that it was harder but I found out to my horror that I had not made enough room in my schedule to complete it well enough to be happy with the final version. It was very difficult to determine (from man pages, text books, internet) what needed to be done to complete the step and determining what needed to be done ate up an enormous amount of time. A little more direction would have been very helpful.

• Start the project well in advance as they take some careful thought and planning, it's not something that can easily be thrown together in a day.
• Don't underestimate pointers!
• Pre-read the lectures and do the labs - weekly! You can't 'cram' pointers...
• Avoid this unit if possible
• Expect to know what was never taught.
• It's not a difficult unit - just learn the things once and learn it right
• Do not fall behind in this unit as there is a lot of content to cover. *insert pointer pun here*
• DON'T START THE PROJECTS LATE! THEY ARE MUCH, MUCH HARDER THAN YOU THINK
• Put in the work and you will be okay.
• Make sure you do CITS1001 or a prior unit beforehand. There was no way this could be done as a first programming unit.
• do projects with a partner
• The sooner you get your head around the basic/boring stuff in C the sooner you get to do the interesting Systems stuff you want to do.
• Do not even consider attmepting this unit unless you are a gun programmer or you have done a few CS courses with a heavy amount of programming in a general purpose language.

Perhaps an explanation as to why I asked this question. I strongly believe that everyone learns more and thus, hopefully, enjoys material more, if there's a 'critical mass' of students contributing to discussions, asking and answering questions, offering alternative points of view. I felt that we didn't have this form of engagement this year, and that's a shame. We had a small, hearty cohort asking and answering up-to-date questions on the help forum, but this didn't 'work' as well as in previous years, with many anonymous, repeated 'catch-up' questions whose answers were rarely acknowledged. Simple attendance is not engagement, and I'm an opponent of awarding marks simply for attendance - the value should come from the knowledge gained, not the marks.

• Making labs compulsory would work. In my experience, people don't attend if they can easily complete the work at home (which is true for most things in computer science I would imagine).
  Forced attendance, when the work can be complete anywhere (else), at anytime, increases resentment. There needs be a beneficial reason for the attendance. Historically, of course, it was necessary to attend labs to use the expensive shiny computers, and students interacted when there. Much of that beneficial interaction is now lost.
• I think it may have been due to the instability at the lecturer position. Also maybe due to the difficulty of the projects, people decided to go to lectures less as they were doing the project! I had clashes so I couldn't attend very many lectures in person
• I can't comment on attendance for the back half of the semester (I have started working full-time this semester and attending the Thursday lecture became difficult) but there seemed to be two schools of students: the ones who appreciated the concepts of the unit and those who only used the lecture slide examples to figure out how to start the projects. Perhaps giving a 5% mark for the labs and reducing the mid-sem mark (if possible) would increase engagement. The lab material was great, really comprehensive and interesting. Chris, I enjoyed your lectures and I found your discussion on the topics very engaging as you went beyond the depth of what was covered in the slides. However, I suspect some students didn't grasp the foundations of the concepts from the lecture just by reading the slides and this is where I found the labs incredibly helpful.
  Thanks for your comments; I try to emphasis that the lecture material is not the only source of (assessed) knowledge for the unit, and that labs, workshops, and true textbooks (not just webpages/documentation) are important resources.
• Increase interactivity of labs and possibly lectures, possibly include workshop questions in labs and review them in the workshop.
• No. The nature of the unit is boring, and it's just something that students need to sit through in order to get the understand they need for the future.
• I think the drop was due to uncertainty about who was lecturing - the tutors we're very good but I began to stop coming after Chris started to take time off - not his fault
• Having more lab sessions.
• The lecturer seems to go off track a lot during the lectures. Other than that it was pretty good and the lab tutors were extremely helpful. The lecturer himself is also very helpful during the labs, not so much during lectures.
  I'd welcome hearing more about 'going off track a lot', as I'm unsure where any lecture time was wasted, and how to provide more help in lectures?
• Incentivize the Tutorial sessions (""Workshop sessions"") with attendance marks?
• I think the labsheets were perfect in terms of content and perhaps my recommendation to split the project over the semester would increase engagement (building up something over the semester)
• I personally did not (and very rarely do, with any unit) attend many classes in person. This is becuase I live very far from campus and it is simpy not time efficent to be there all the time. Although I was not there I found the lectures (watching online) to be some the best presented I've ever experienced at UWA.
• CITS2002 felt very much do it yourself and figure it out yourself without too much guidance, I think more structure and spoon feeding of basics and intermediary C with a more challenging project would have kept my engagement. make weekly labs have 10% for attempting or something similar.
• More Chris
  I'm workin' on that :-) Hopefully we'll all enjoy Networks and Security next year.