Guidelines for Java Oral Presentation and Written Reports
These guidelines assume you will present some Java feature, library class, or other aspect of the Java programming language. Your presentation should explain a topic (usually with short code example(s)). Do not use terms that have not been used in class without explaining them first. Be sure that you explain the benefit of the feature you are talking about - that is, what features, functions, capabilities, etc. that it will provide to a Java program.
The basic rationale is this: pretend you are working for a company with a new project and it has been suggested that the feature/technology that you will explain should be used in this project. The other members of your team don't know anything about this new thing, and you have been assigned to find out about it and give them a summary so they can better decide if it should be used or not. You assume they know the basics of Java, and you want to tell them the basics of this new feature/technology - including what it is good for, how complex it is, what is needed to get it to work (extra software or databases, or hardware...) and a good introduction to what it looks like at the code level.
If you include code, present a minimal code example - a sort of "hello, world" example for this feature. You may omit lengthy obvious details like laying out and adding components to an Applet, etc. Do not spend time in your presentation explaining things that your audience already knows. Bold-facing and numbering important lines of code will help your audience find the specific statements you will discuss.
Your presentation should take about 20 minutes. You may use an overhead projector or the blackboard. Computer projector is allowed if you arrange it.
For presenters, prepare a 1 to 6 page handout summarizing your talk for the class, including your code examples. Make sure there are enough to go around. You could include longer code examples for study.
Note clearly: your job is NOT to impress me with how much you know and how many buzzwords you can use. Your job IS to impress me with how well you can explain (ie. teach) new material to me and your classmates. This is for them as much as it is for you.
Guidelines for a Typical Written Report
If you are asked to submit a report, the report should be at least 6 pages long in font size 12. The report should be in your own words. If English is not your native language, do your best. You will not lose credit for grammatical errors.
You need to organize the report into sections typically as follows:
Citations (applicable to both the handout and the written report)
At the end of the handout, cite the references you have consulted to prepare the talk (books, magazine articles, Web URLs, etc.). You should consult and cite at least three different sources.
In addition, understand that this presentation and the handout should be in your own words. If English is not your native language, do your best. You will not lose credit for grammatical errors.
You may quote from other sources, but any direct quotation more than half a sentence long must be cited at the point in your document where the quotation occurs. If the quotation is more than a sentence, it should be indented. (we should be able to see clearly who wrote it, in what article or book or Web site, page number, if any, etc.). Examples:
1. A single sentence in your own narrative:
Java is fast becoming a mainstream language. For example, E.R. Harold notes in his Web site "The College Board, the monopoly that brings you the SAT and the Advanced Placement Tests, has announced that starting in 2003 the AP Computer Science test will include object orientation (about 10 years late); furthermore, the language will change from the current C++ to Java." (http://www.ibiblio.org/javafaq/)
2. A paragraph:
Alternately, you could use endnotes and place the actual citation at the end of your document.
Please Note: Failure to do this is called plagarism and is considered to be academic misconduct.
Be aware of your audience's needs. In particular:
1. Set up the overhead projector or computer in advance.
2. Prepare and pass out enough handouts before you begin your talk.
3. Check the lighting and be sure that it is not too bright for people to read the screen, but not too dim for them to take notes.
4. Be sure your slides can be read at the back of the room. This involves focus and size. (See point 3 above)
5. Speak loudly enough to be heard in the back. Don't talk too fast.
An Outline of a Typical Presentation
1. Give a brief (one minute) summary of what your presentation will cover.
I will describe the RandomAccessFile Class and some of its most important Methods, and then show how it can be used in an Application to implement a simple Relative Record File Access Method.
2. Describe what the language feature will allow a program to do.
The RandomAccess File class allows a program
- To move a file-pointer to a specified byte position in a file
- To move the file-pointer to the beginning or end of the file
- To read or write a specified number of bytes at the current location in a file
Using these facilities, we can implement direct access file operations similar to a VSAM RRDS or KSDS. (The latter would require a lot of work.)
3. Explain what you need to do in a program to implement a simple version of this feature.
4. Present some simple code that illustrates the feature.
As an example, present two demonstration programs that:
- write out a series of fixed length records filled with blanks to serve as an "RRDS" file all of whose "slots" are "empty".
- Accept data from a user and
- write data records to appropriate slots according to some well-defined scheme.
- Read data records from the file
In each of these demo programs, use pseudocode or indicate via comments the details not relevant to the File operations.