CITS2002 Programming and Systems - Project 1 Feedback (2017)
Q8: Any comments or suggestions to improve the project assistance in
future years?
In tutorial or Lecture programming examples done live would be
awesome because while my program worked it was very hacked together
and probably didn't follow best practice. Not because I was being
lazy but because I didn't know what good C programs looked like.
It's one thing to show simple examples of flow control, etc. but I
think an in depth look at best practices and structuring out programs
would make tackling the project easier.
Thanks for your comment.
While not addressing all of your points,
Friday's workshops are intended to draw out discussion on solving
(smaller) whole programs by drawing on the simple data and control-structure
examples introduced in lectures, and to then develop them live.
A shame that they're poorly attended.
The many points of what a good large program looks like goes beyond this unit,
addressed in the School's Software Engineering units.
What makes a good C program (of this size)
is very similar to good programs in other languages supporting procedural
techniques (such as Java and Python).
During the last lab at 10am on Friday the lab instructor was absent.
There has not been a scheduled lab on Friday mornings all semester.
A lab timetable on the CITS2002 page would be useful.
There has been a lab timetable on the unit's webpage all semester.
Q12: Any comments or suggestions about the nature of the project?
I believe the requirement for the project to fork and execute an
external program should be an implicit requirement rather than an
explicit requirement.
Unsure of your point about implicit.vs.explicit.
The goal was to require students to fork()+exec() an external program
(to assess that knowledge)
rather than implementing a sorting algorithm in the basic program.
Without explicitly stating the fork()+exec() requirement,
many would have just implemented their own sorting
(and we hadn't yet covered structures).
I have no idea if this is possible. But perhaps showing us how to
get the wifi packets data from our routers at home so we could test
with that could have made the project a bit more interesting.
Better to capture packets using your laptop, rather than your router -
search for the many examples of 'packet sniffing' software.
Also, constructing your own 'fake' data files with diverse data,
to test edge cases,
would be more effective than capturing more real data.
I feel like making using sort/fork a requirement quite forced.
Making it's use a part of the assignment may be more elegant and
will make it more obvious why it's needed
Unsure why you've described it as 'forced',
and then describe it as 'elegant'?
It's a standard (systems) programming approach to use established
(and tested and efficient)
external programs and resources, rather than reimplementing them.
I think, being that this is a "systems" unit,
the project should
have had a greater focus on the system.
Agreed, but there's other introductory
material to cover and assess before we 'get there'.
Note that even fork()+exec() requires an understanding of
character arrays (strings) and (ideally) the switch statement.
As you can see from other comments, many students found this difficult enough
(and you've completed 3 other programming units :-).
I found the most valuable learning took place only at the end of
the project when learning about forking processes etc.
Several example input files and output files would be great so we
can test our programs with more data.
May have been due to me being dumb/unable to complete the project,
but doing this alone I found that the difficulty of most of the lab
questions didn't prepare me for the assessment (however the content
covered did). But I feel I wasn't prepared. Again this may have
been my personal case and probably was but I felt confident after
doing the labs going into this.
This was seriously difficult even for a 2nd year with previous
programming experience (CITS1001 and CITS2401) and I found this
close to impossible. Fortunately I managed to complete the project
on time (with a lot of help from Mr Google, Tutorials Point and
Stack Overflow), but I know people who completed both units as well,
stayed in the labs until 3AM the NIGHT BEFORE the project was due,
and still couldn't manage to complete it by the deadline. So I'm
probably not the only one. And worth 15% as well... for this level
of difficulty it should really be worth more. I also had to do
independent research in order to complete the project, the lecture
material was seriously insufficient in terms of providing us with
the required knowledge/tools required to tackle the project. Learning
how to use pointers and string tokens from Stack Overflow were
essential to complete the project, both of which had not been covered
up to the Week 6 lectures. This was nothing like the labs which
were easy by comparison, and are meant to prepare us for this sort
of work? There also wasn't enough time, we were working up to 12pm
in the CS labs and our code STILL had bugs in it. Fortunately it
was mostly working and we hopefully didn't have too many bugs. To
be fair, I've heard other students found it ridiculously easy, so
there may have been a wide range of opinions on the difficulty
and/or time constraints of this project. Now I'm dreading the second
project at this stage... but I'd better stop commenting now in case
this survey isn't really anonymous.
As was stated many times,
the project could be completed using only the material presented to Week-6.
If you felt that this was untrue,
you should have appreciated that your approach was likely incorrect,
and sought assistance.
Please have a look at the sample solution.
It is composed of a number of small functions -
checking command-line arguments;
opening and reading files;
storing integers and characters into arrays;
iterating over those arrays;
performing simple arithmetic.
Pointers were not required.
I appreciate that you had difficiulties with the project,
but most of the code could be 'cut-and-paste' from lecture material and
sample laboratory solutions.
And, yes, the survey is anonymous, but we're all adults here.
The students I had talked to in the labs had mentioned the project
was hard and the general progress seemed to be slow
I think numbercrunching and formatting like this is a good application
of the kind of stuff we've learnt so far in the unit
Good project for thinking about how to approach the problem (on
paper), and then how to implement it in C. Noticed that many that
didn't plan out before starting had issues which simply couldn't
be fixed as their logic had not been planned out, might be worth
teaching the importance of planning solutions.
Q13: Do you have suggestions/comments to assist the planning of the 1st
CITS2002 project for next year?
I think that the unit material up to week 6 did cover everything
that we needed to know for the project. It demonstrated how to use
specific functions such as snprintf and fgets, however, more emphasis
could have been placed on programming techniques such as loose
coupling, and where and when to use helper functions. In the weeks
leading up to the deadline I felt that I knew how to do everything
but had forgotten how to write well modularised programs, and found
myself trying to remember back to what I learnt in CITS1001. Without
the skeleton functions that we got in 1001 it was quite difficult
to decide how to structure the program. For example, I wasn't really
sure if we should treat globals in C like fields in Java.
I agree with some of your comments, but they identify the two challenges -
not all students take all prior units (nor remember them!),
and we can't 'fill' this unit with material new to some, but repeated for others.
I think perhaps make it a bit harder. I felt like a lot of the
things that I hadn't used before like fork and execv weren't really
used too much in the project and were only really at the end. I
think I'd we were forced to have the processes interact with each
other more it would have been much more interesting.
It certainly could have been harder but,
as the comments here show,
the project has to challenge a wide diversity of abilities.
The project itself and the support from Chris, Trent and Ryan was
top notch. The only suggestion I would make for next years project
is to shift the focus. Less text processing and more system related
tasks like forking processes, calling external programs etc.
Thanks for that first sentence :-)
Please dig as deep as possible into each C data types properties
and usage. Also perhaps covering pointers right before the project
starts. The bug chasing caused by my lack of understanding the
language basics really distracted from the problem solving aspect
of the project.
I don't believe that pointers can be introduced much earlier and,
if so,
what early material should be removed?
If we're to have two assessed projects
(rather than just one, which could fall into a catastrophic heap)
we first need to cover and assess a number of basics.
Have the projects worth more and the mid-semester test less.
Doing so would require all projects to be individual efforts,
as UWA only permits shared work to total 30%.
I believe that most students are comfortable receiving up to 20% for the
mid-semester test, and its average 13/20 suggests that it's neither too easy
nor too hard.
MORE TIME TO COMPLETE THE PROJECT! Seriously. Especially so close
to the study break with mid sems coming up it's really hard to focus
effectively in the limited time available. Not to mention the level
of difficulty of the project.
Balancing the timing and difficulty is certainly a challenge.
And next year UWA moves to 12-week semesters :-(
Finding and working in a pair isn't easy and is mostly a gamble,
personally I would prefer a slightly smaller 1-person project but
that is strictly my opinion. I've been extremely impressed with how
the unit has been run thus far.
