[cs615asa] hw#4
Jan Schaumann
jschauma at cs.stevens.edu
Sun May 9 21:52:47 EDT 2010
Hello,
I've graded HW#4 and I will send out your grade for this assignment
lateron. Since this class is not a programming (only) class, I
unfortunately cannot review each of your submissions in as much detail
as I'd like, but here is some general feedback on some of the most
common issues I've seen:
- don't hardcode anything that is restricted to your personal setup;
this includes the names of your ssh keys, what security group you may
use or even the hostname of the target instance -- with anything
hardcoded like this, your program simply won't work
- don't try to implement command-line options parsing yourself -- all
programming languages provide some sort of library for that, usually
named "getopts" or similar
- don't use temporary files if you can avoid it; if you must create
temporary files, make sure to use mktemp(1), mktemp(3) or your
programming language's equivalent; make sure to remove any temporary
files when your program exits (even if it's interrupted)
- don't require the user to provide an AMI name -- the specification
clearly stated that your program should take an *instance* name; if
you require an AMI and start a new instance, then your tool can't be
used to sync users against a running instance
- when you create a user on the instance, make sure to also create the
user's home directory (with the right permissions)
- when you copy the public key aws.pub to the remote instance's
~<user>/.ssh/authorized_keys, ensure that that file and directory have
the right permissions and ownership
- provide commentary for every subroutine/function/module you write; it
is good practice to explicitly note (in comments) the pre- and
post-conditions of a function as well as any edge conditions or error
behaviour
- if you're using a compiled language, get in the habit of compiling
with "-Wall -Werror" (or the equivalent); if you're using perl, get
in the habit to 'use warnings; use strict'
- always write your program under the assumption that at some point
somebody else has to review, update or maintain your code (sometimes
that "somebody else" is your future self who goes back to say "What
the hell was I thinking? This makes no sense - why is this variable
named 'a'? What is this supposed to do?") and that somebody who has
no intention to even look at the code wants to use it
The feedback you will receive may include a few very brief comments --
these are not the only criteria I have applied when grading, but are
some of the issues I noticed.
Finally, if you are not happy with the grade you receive, please
consider the following before you try to argue about it:
The assignment was extended by over 4 weeks, and you received detailed
instructions on how to lay out your code on a weekly basis. If the
program you submitted doesn't even remotely do anything resembling what
was requested, there really isn't much I can do.
At the very least, your program should be able to be executed (on
linux-lab.cs.stevens.edu) as
./ec2-sync-users -v -i <i-159abcdef> jschauma bloom djd root oinki dinky
where i-159abcdef is an already running instance.
The result would be that users jschauma, bloom and djd are created (with
whatever groups are required), that an error is generated for the
creation of the user 'root' (since that already exists) and errors
generated for the users oinki and dinky (which don't exist on the local
system).
Again, this obviously is not the only criterion used to evaluate your
program, but the very lowest minimum requirement.
-Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.stevens.edu/cgi-bin/mailman/private/cs615asa/attachments/20100509/6bec7ca4/attachment.pgp
More information about the cs615asa
mailing list