600.211: Unix Systems Programming

• Home
• Contacts
• Schedule
• Resources
• Assessment
• Assignments
• Trivia

Assignment 7: Exploring the Final Frontier

Out on: March 27, 2008
Due by: April 7, 2008, 11:00 am (before lecture)
Collaboration: Teams
Grading: Packaging 10%, Style 10%, Performance 10%, Design 20%, Functionality 50%

Overview

The seventh assignment for is all about starting your final project which will occupy you for the rest of the semester. Note that some parts of this assignment are not really about actual code. You'll see... :-)

This is a team assignment, and all of you should know which team you're in (I hope). Decide early on who is going to be responsible for submitting the assignment and when. Make sure to include all the relevant information (who is in the team?) in your README file! Decide on a schedule early on as well, nothing delays working in a team more than having to schedule meetings ad-hoc; compare your schedules and arrange to meet in advance! All members of a team will receive the same score for the project you submit together. After the assignment is over, each of you will be asked to evaluate the contribution your partners and yourself made to the assignment.

Problem 1: Team Website (20%)

Consider yourself a startup company with a plan to take over some segment of the computerized world. Your first task is to set up a website for your shiny new company; be sure to include the following:

• An overview of who you are and what you're doing (the "front door" of your site).
• Some kind of "white paper" that explains what you do and why it's special and important.
• Some kind of "time line" that lays out your basic plan for the development of your project.
• Bios for all you guys/gals, hopefully making a professional and trustworthy impression.
• Documentation for your project, addressing how to install, configure, and run it.
• A page where potential clients can download the latest tarball to try your project.
• Whatever else you can think of. :-)

Please make sure that your website validates as XHTML 1.1 (check the HTML for this page to see how to add a suitable link). Please put your website online somewhere and email us the URL as soon as possible! You still have to submit the HTML for your website when you submit the rest of your assignment!

Problem 2: Versioning and Automation (30%)

Aside from making a decent "public" impression with your website, your development environment should also be set up in a somewhat professional way. Here are some of the things you should do:

• Maintain all your artifacts for this project in the Subversion repository provided for your team. This includes your website, your documentation, your code, and any supporting scripts and programs you write (e.g. for this very problem).
• Use make to automate the build processes you need, for example to create PDFs from your raw documentation, to actually compile your project, to update your website, etc. Note that creating tarballs for distribution or running unit or system tests should also be automated.
• Use cron to regularly build and test your code (every 24 hours). The results of your tests should be emailed to your team mailing list. Aside from commit notifications from Subversion, having build and test results "visible" to everyone also increases "awareness" inside your team. And it helps you blame the right person for breaking a build. :-)

Note that documentation in some plain text format is easier to maintain in Subversion than opaque prorietary formats; we recommend plain ASCII text, troff or man page format, LaTeX, or DocBook. Also, cron can be a bit tricky to use. Remember that it works on a "per machine" basis, not on a "per account" basis. So don't change crontabs all over the place, and only have one person be responsible for setting this up. You must submit all your automation scripts and a short description of your automation setup when you turn in your project!

Problem 3: Basic Prototype (50%)

The most important part of this assignment is that you develop a first basic prototype of your project. What exactly that is depends on what your project is, but whatever the outcome of this assignment, it should run and it should fundamentally work. It might not have all the features you want, it might not be as fast as you would like, etc. but is has to work and it has to be recognizable as a first version of the final intended outcome.

So again, to make sure you get this: You must submit a working prototype! Explain what is there and what is still missing in your README file and you should be good.

Hints

There's really only one hint: Remember that you're going to maintain the code you produce for this assignment for a while. Aside from writing clean code, it may be a good idea to start documenting in a way that allows others to just read the documentation for a certain module, not the module itself. I recommend looking at doxygen for that.

Deliverables

Please turn in a gzip compressed tarball of your assignment; the filename should be the filename should be cs211-assign-7-teamcode.tar.gz with teamcode replaced by the code assigned to your team for your repository and your mailing list. The tarball should contain no derived files whatsoever (i.e. no executable files), but allow building all derived files. In particular, make sure you don't submit all those .svn folders from your repository! Include a README file that briefly explains what your programs do and contains any other notes you want us to check out before grading. We expect that your Makefile handles "the usual" targets like clean and test aside from all (which is the main way we will build your program). Include other "common" files such as INSTALL describing how to install your tool, CREDITS to pay your respects to the people whose code you're reusing, and LICENSE to describe copyright and distribution terms if you feel like it. You can look at any number of "famous" open source projects to see what kind of structure is appropriate; gif2png is a relatively small example, but you don't need everything in there. Aside from your code, what you really need is a README and a Makefile that works. :-)

Grading

For reference, here is a short explanation of the grading criteria. Packaging refers to the proper organization of the stuff you hand in, following the guidelines for Deliverables above. Style refers to C programming style, including things like consistent indentation, appropriate identifiers, useful comments, suitable documentation, etc. Simple, clean, readable code is what you should be aiming for. Performance refers to the amount of resources your program needs to produce the required results; this can include space, time, and other metrics. Design refers to proper modularization and the proper choice of algorithms and data structures; often this can be judged by asking "How hard would it be to add feature X?" and "How hard is it to replace algorithm X with algorithm Y?". Functionality refers to your programs being able to do what they should according to the specification given above; if the specification is ambiguous and you had to make a certain choice, defend that choice in your README file; if the specification is too general and you had to add certain restrictions, defend those in your README file as well.

If your programs cannot be built on ugradx.cs.jhu.edu you will get no points whatsoever. If your programs cannot be built without warnings using gcc -ansi -pedantic -Wall -Wextra -std=c99 -O we will take off 10% (except if you document a very good reason). If your programs cannot be built using make we will take off 10%. If your programs fail miserably even once, i.e. terminate with an exception of any kind or dump core, we will take off 10%. Finally, make sure to include your name and email address in every file you turn in!