[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