Incomplete grades

Incomplete grades will be given in case you have a genuine personal or medical emergency that strikes in the last 1/4 of the class and prevents you from completing the course work. Because time pressure is a fact of student life, no incomplete grades will be given simply to allow you to finish your work.

Real Programmers....

• Don't eat quiche. They don't even know how to spell quiche. They like Twinkies, Coke, and palate-scorching Szechwan food.
• Don't write applications programs. They program right down to the bare metal. Applications programs are for dullards who can't do systems programming.
• Don't comment their code. If it was hard to write, it should be hard to understand and even harder to modify.
• Don't draw flowcharts. Flowcharts are, after all, the illiterate's form of documentation. Cavemen drew flowcharts; look how much it did for them.
• Don't use COBOL. COBOL is for wimpy applications programmers.
• Don't use FORTRAN. FORTRAN is for wimpy engineers who wear white socks, pipe stress freaks, and crystallography weenies. They get excited over finite state analysis and nuclear reactor simulation.
• Don't use LOGO. In fact, no programmer uses LOGO after reaching puberty.
• Don't use APL, unless the whole program can be written on one line.
• Don't use LISP. Only effeminate programmers use more parentheses than actual code.
• Don't use Pascal, BLISS, Ada, or any of those sissy-pinko computer science languages. Strong typing is a crutch for people with weak memories.
• Never work 9 to 5. If any real programmers are around at 9 a.m., it's because they were up all night.
• Don't play tennis or any other sport that requires a change of clothes. Mountain climbing is OK though, and real programmers often wear climbing boots to work in case a mountain should suddenly spring up in the middle of the machine room.
• Don't like the team programming concept. Unless, of course, they are the Chief Programmer.
• Have no use for managers. Managers are a necessary evil. Managers are for dealing with personal bozos, bean counters, senior planners, and other mental defectives.
• Don't drive clapped out Mavericks. They prefer BMWs, Lincolns, or pick-up trucks with floor shifts. Fast motorcycles are highly regarded.
• Like vending machine popcorn. Coders pop it in the microwave oven. Real programmers use the heat given off by the CPU. They can tell what job is running just by listening to the rate the corn is popping.
• Know every nuance of every instruction and use them all in every real program. Puppy architects won't allow execute instructions to address another execute as the target instruction. Real programmers despise such petty restrictions.
• Don't bring brown bag lunches to work. If the vending machine sells it, they eat it. If the vending machine doesn't sell it they don't eat it. Vending machines don't sell quiche.

--Anonymous, from many years ago!

Tentative Schedule

This schedule will be revised as we go along, especially as interesting guest lectures become available. We will try to reserve some time on Thursdays for working lab exercises, so please bring your laptops if you'd like to work along.

CSCI 4760 Assignments for Spring 2010

Please name your working directories "Assn1," "Assn2", ... "Assn5". Use the submit command on atlas to submit your working directories.

Course coding guidelines

For the required format of variable names, function spec comments, and loop comments, see the Coding Guidelines for this course.

Grading: A grading rubric will be provided for each assignment. You will note that adherence to the course coding guidelines is often worth a significant amout of credit. From previous semesters, I have observed a significant amount of weeping and gnashing of teeth from students who could not believe that I would actually take off points for not commenting code. Just a heads-up here.

Late assignments: An assignment is considered on time if you submit it before midnight on the due date, or as late as you stay up that night to finish it. (If you're persistently staying up after midnight on the due date, this indicates poor planning.) After that time, ten points will be deducted for each week or fraction of a week the assignment is late. This really is not worth it! My recommendation is to go ahead and submit whatever you have completed on time, and get started on the next one.

TA Lab Hours

TBA

The Assignments

Here is a tentative listing of assignments and due dates for Fall 2009:

Software development guidelines for Web programming

Requirements analysis

This step defines what the proposed system needs to do. If the new software is to fit into an existing organization, you need a good understanding of how the organization works. In a class context this part is usually not hard, because the instructor tells you what the software should do!

Software design

Each module (program, script, function, etc) of the software system needs a clear specification. The specification should include:

• A brief description of what the module does. One or two sentences is good. Traditionally, the first sentence of this description has an implied subject that is the module being specified.
• The named inputs used by the module;
• The return value of the function, if any;
• How any error conditions, including violations of the preconditions, will be handled. (Note: please do not specify debugging and testing printouts, which should be removed or commented out in the final version.)

To make the description more specific, refer to the named inputs whenever their values affect the result. For example, note the use of the named input student_tearjerkers in the following:

/**
 *   Returns the number of non-null values in the array student_tearjerkers
 *   @param student_tearjerkers  array of student excuses
 */
     int n_excuses(String[] student_tearjerkers)

Inputs are specific sources of data which must be present before the module runs. The following can be inputs:

• Variables in the module's environment . For modules running in Web context, the environment includes request and response objects, session storage, etc.
• Files and databases
• Input parameters (used by functions in Java or other programming languages)

Note especially that any information which the module can find by itself should not be listed as an input. An example is the current date and time, which the module can find via an appropriate system call.

The spec is considered a contract between the designer and the implementor. A good spec has the following properties:

1. For any implementation, it is unambiguous whether that implementation satisfies the spec or not;
2. If the implementation does satisfy the spec, then it correctly does the task it is designed for;
3. The spec specifies desired results, but not how those results are obtained.

Most of our specs won't satisfy requirement (2) above, because I am not requiring enough detail to nail down the precise action of the module. Ideally, we should strive for this level of precision.

For a few thousand good examples of spec comments, see the Java APIs at http://java.sun.com/api/index.html

Java error handling

Java provides robust error handling features that we will use to create something a little closer to "industrial strength" code.

• Throw exceptions to report error conditions. Do not return a special value, e.g. NULL or -1, to indicate an error. However, if the method's task is returning a count of some entity, zero is a legitimate return value.
• Throw exceptions on NULL input values that are not supposed to be NULL.
• Each exception should contain a short, informative message describing the problem.
• Handle all exceptions appropriately. If the problem can only occur because of a programmer error, printing a stack trace is an appropriate response during the development phase. You would not include these messages in the spec. If the error could occur in correct operation, you must decide on the application-appropriate response. For example, a part of an application might fail because the network is down. In this case the appropriate action would be to inform the user that the network is down.

Example Design Exercise

Suppose we are asked to design the URLopener class that extracts character data from a remote URL:

• The high-level architecture for the class;
• The java method comments for the class;
• The javadoc output for the class;

Writing code without a design?

Sometimes we do write code without a design:

"I think I understand what the client needs, but I'm not sure." A prototype is a quick-and-dirty implementation that illustrates to the customer how the finished product will work or look.

"This looks like a good application of technology X, but I have never used X." In this case we write some exploratory test code to verify that we can get X, it runs on our system, we can learn it, and it does what we thought it can do.

Note that each of these situations we are writing throwaway code. It is unwise to assume that any code written in advance of the design will make it into the final project.

Design first, then implement!

The worst programming disasters typically result from forcing a bad design. In my experience, one hour of design time saves ten hours of debugging time. I am happy to go over your design with you before you start to code.

Coding Guidelines

As you begin to implement your design, please follow the following coding guidelines. These are intended to make your code easier to read and modify, but you will find that they also make it easier to get your code to run correctly in the first place.

Variable and function names

• Each variable should represent a well-defined concept, and its name should represent that concept. Exceptions are the loop-index variables i and j, which may be used to represent the index into a one-dimensional array and the column index into a two-dimensional array, respectively.
• The name of a variable should be a noun phrase if it represents a data item or object, e.g. projectStartDate. For a variable which represents a true-or-false condition, use an adjective phrase, e.g. hasMoreElements.
• If the primary task of a function or module is to return a single result, name the function or module after the result, e.g.
  int largestElement( int[] elementArray).
  Otherwise, the function's name should be a verb phrase, e.g.
  void insertStudentRecord(String studentName, int studentID, String course)
• Functions that return a collection of values can be named getXXX, where XXX describes the collection returned. For example, a function that returns a list of the attribute names of an element could be called getAttributeNames().
• Make variable names as specific as possible, even at the expense of longer code. Never name a variable name! Use studentName, clientName, etc.
• Named constants and shell variables should be in all upper case with underscores for readability, e.g. MAX_SESSION_DURATION. Otherwise, use variable names starting with a lower-case and using upper-case letters to start new words, such as userZipCode.

Loops

Every loop control statement should be followed by a short comment explaining what is accomplished on one iteration of the loop:

while (transactionRecord != null) {
//write contents of transactionRecord to a row of the HTML table
  System.out ("<tr><td>"+transactionRecord.clientID+"<td>...");
  ...
}//while

Again, note that we have used the variable name, transactionRecord, to increase specificity.

If you find it difficult to describe what a single iteration does, then STOP! You may have a serious design problem that can result in hours of wasted debugging time.

Formatting and indenting

Indent the body of any function, loop, if statement, or other code block. Put the opening brace on the line after the function declaration or control statement, and line up the closing brace underneath the left-hand character of the function declaration or control statement.

For code blocks more than a few lines long, comment the ending brace with a short description of the block being ended.

See the code block above for examples.

Module size

Break modules and functions up so that each module has a single, well-defined task and is small enough to be easily understood. Normally the source code for each module should fit on a single printed page, but you may stretch this somewhat for modules which contain a lot of embedded HTML and little or no program logic.

Code examples

HTML and CSS

• Unformatted list example
• Absolute position example
• Absolute position example
• Z-index xample

Core JavaScript

• JavaScript Arrays

JavaScript DOM examples

• Dynamic Element Creation
• Off-by-one error
• Cross-browser positioning
• Animation 'by hand', part 1
• Animation 'by hand', part 2
• Almost-W3C events
• Actual W3C events

PHP

• Worker-friendly application

Networking Lab Exercises

Java and Extreme Programming

HTML and CSS

Usability

HTTP and Web Servers

Unix

JavaScript and Dynamic HTML

Browsers and display issues

XML

AJAX

PHP and MySQL

Ruby on Rails Model-View-Controller (MVC) Development

Servlets and JSP resources

Spring Model-View-Controller (MVC) Development with Java

Java Web Services

Enterprise Java Beans (EJB)

Database access

• Writing JDBC applications with MySQL
• MySQL documentation
• Using a JDBC Connection Pool

Wireless devices

• UGA Wireless Web (talk by Al DeSimone, chief UGA Web guru)

Encryption and security references

• Encryption
• Open Web Application Security Project (OWASP)
• PHP Data validation from OWASP

General tutorial collections

• Web abstracts
• W3 schools
• The Java Tutorial from Sun
• Java Web Services Tutorial from Sun

Perl

• Perl manual
• The Perl debugger
• Complete Perl reference
• Rex Swain's Perl 5 Reference guide
• Greg Whitlock's introduction to Perl (stored at UGA for faster access)
• Perl regular expression tutorial (stored at UGA for faster access)
• Another Perl regular expression tutorial
• Perl function reference
• another Perl function reference
• CGI module reference
• CGI 101
• RocketAware search engine -- look up Perl concepts and functions
• Fool's Guide to CGI.pm