CFP: Tutorials

Chair: Eugene Wallingford, University of Northern Iowa,

Overview

The people who attend OOPSLA are interested in a wide variety of topics in the software universe. This includes topics on object-oriented programming, systems, languages, and applications, and also topics from other areas of software development that affect their lives. It includes classic subjects that have been taught for years, and also the latest advances in technology. The OOPSLA tutorials program aspires to cover the full breadth of these interests.

To this end, OOPSLA 2006 seeks engaging, informative tutorials designed to help participants grow as software professionals. This year OOPSLA also invites tutorials as part of the second Dynamic Languages Symposium being hosted at the conference.

For the first time, OOPSLA will offer tutorials that satisfy all or part of an industry-standard certification program. Proposals for such tutorials are welcome.

About OOPSLA Tutorials

Organization. Most OOPSLA tutorials are half-day sessions, though we do offer a few full-day sessions. Each half-day session consists of two 90-minute blocks separated by a 30-minute break. Tutorials are presented in rooms that include a laptop projector, and presenters provide, several months in advance, a set of tutorial notes to be given to attendees.

Only a small number of full-day submissions can be accepted. As a result, if you wish to submit a proposal for a full-day tutorials, your submission should explain clearly why the topic requires a full day. Keep in mind that many semester-length topics have been taught successfully in OOPSLA tutorials using a half-day format.

Content and format. Attendees of OOPSLA tutorials deserve the highest standard of excellence in tutorial preparation and delivery. Tutorial presenters are typically experts in their chosen topic and experienced speakers skilled in preparing and delivering educational presentations. When selecting tutorials, the OOPSLA Tutorials Committee considers both your knowledge of the proposed topic and your success at teaching it.

Many tutorials use a traditional lecture style, with a series of slides that pace or keep stride with the speaker. An increasing number of tutorials use formats that involve attendees more actively, such as presentations that:

• show the presenter writing code, or creating some other kind of artifact, during the presentations.
• ask the attendees to develop software, or other artifacts, during the presentation.
• teach attendees an educational game and let them play it.

Compensation. Each accepted tutorial is compensated in two ways:

• a complimentary admission to the full conference.
• $500 (half-day) or $1000 (full-day).

Cancellation policy. Tutorials are subject to cancellation if they do not attract sufficient attendees. Presenters are strongly encouraged to advertise their own tutorials widely among communities of interest in the topic.

Content

Each submission must include the following information.

Electronic submission on-line

• Title. Choosing a good title can be more challenging than you might think. The title will often serve as the first synopsis of your tutorial. It is important to choose a short title that accurately describes your tutorial.
• Abstract. A 200-word (maximum) description of the tutorial. The abstract should be written to fit into the OOPSLA Advance Program. The abstract is your advertisement to, and contract with, participants will who decide whether or not to take this tutorial based largely on this information.
• Keywords. Along with the Abstract, these keywords help us to understand better the main topics of the submission and to choose appropriate reviewers.
• Presenters. For each presenter, include name, e-mail address, affiliation, address, and a brief biography indicating the presenter's expertise and experience in the tutorial's subject matter. Be sure to clearly designate the contact person for the tutorial.
• Level. The expertise level of the tutorial. Is your tutorial directed at Beginner, Intermediate, or Advanced level participants?
• Attendee background. Briefly describe the knowledge attendees must or should have in order to benefit from this tutorial.
• Tutorial objectives. Your statement of the objective of the tutorial should mirror the abstract, but without an advertising element. Explain what knowledge and capabilities the attendee will gain by attending this tutorial.
• Presentation format. What instructional format will the presenters use? Will it be a slide-based lecture, a hands-on exercise, a group problem-solving session, a game, a combination of these, or something else? Will participants be working on their laptops?
• Scheduling constraints. If the presenters have any constraints on when they can present the tutorial, these should be listed. These can refer to specific days (e.g., "I cannot present on Oct. 26"), or to other OOPSLA activities to which the presenters are committed (e.g., "If my research paper submission, entitled 'What Are Objects?', is accepted, I cannot present this tutorial during the session where my paper is presented").
• Half-Day/Full-Day. Choose from half day (3 contact hours plus breaks) or full day (6 contact hours plus breaks).
• Can repeat? Are you willing to repeat the presentation of this tutorial if there is sufficient demand?
• Tutorial presentation history. A summary of the tutorial's presentation history, if it has been presented previously. If it is a new tutorial, simply indicate that it is new. You may also comment on related presentations that show experience with the topic or the presentation format of your submission. For previously presented tutorials that relate to your submission, please indicate the following:
  • Name of venue
  • Date of presentation
  • Summary of reviews of the tutorial from participants
  • What, if anything, have you done to address participant feedback?
  • What, if anything, have you done to keep the tutorial current?
• Classification. Indicate whether your tutorial is best described as presenting research material, practice-oriented material, educational material, or material that covers several areas.
• Target audience. Indicate the audience who will most benefit from your tutorial: researchers, practitioners, managers, educators, and/or others. If you check "others," please explain in the Remarks field.
• Status. The current status of the material covered by this tutorial. You must, at minimum, indicate one of the following:
  • The tutorial covers new ideas, which are not yet validated as of the time of the proposal submission.
  • The tutorial covers material for which some preliminary validation or proof-of-concept exists. These include being accepted for publication at a major peer-reviewed conference or journal; being used in test applications or evaluation scenarios; being presented to standards boards; etc.
  • The tutorial covers material for which significant validation exists. This includes acceptance by standards boards; being used in non-trivial applications and/or real-world settings; publication of material in a book by a major publisher; etc.
• URL with additional info. If you have additional information about the material contained in the tutorial available on the web, please include a URL for this web site.
• Take a Tutor to Dinner. Are you willing to be taken out to lunch or dinner on the day of your tutorial by some of the attendees? This relatively new feature of the Tutorials program gives attendees the opportunity to take presenters to dinner for deeper discussions or just for social contact -- if the presenter is willing.

Auxilliary information

In addition to the elements required by the electronic submission system, you may upload a separate file that contains information that you think will help the tutorials committee evaluate your proposal. This file might include a sample of tutorial materials, such as slides or a game board, or more information about the presenters' or the tutorial's history. This information may help the committee make a more informed decision about your submission.

It is especially important that you include your requirements for equipment, room set-up, or limitations on attendance. All of these are essential elements in accepting and scheduling.

Submission Process

Electronic submission of proposals is required through the OOPSLA submission system. You will receive confirmation by email that your proposal has been received and is complete. Proposals may be modified online up until the submission deadline.

The tutorials committee will evaluate all tutorial proposals. The committee consists of practitioners and researchers, from industry and academia, who have extensive experience teaching OO and related technologies.

When evaluating proposals, the committee will consider the following criteria:

• Relevance, interest, and value of the topic to OOPSLA attendees.
• Completeness, clarity, and quality of the tutorial proposal.
• Expertise and experience of the presenters in the proposed topic.
• Expertise and experience of the presenters in delivering a successful educational presentation.
• Effectiveness of the proposed presentation approach.

Accepted tutorials become part of the OOPSLA 2006 Tutorial Program and are described in the Advance Program using an abstract provided by the submitter as part of the proposal.

Examples

Below are some exemplary examples of four portions of a tutorial proposal: the Abstract, the Tutorial Objectives, the Attendee Background section, and the Presentation Format. We provide these as good examples of the requested information. No endorsement of the topic or content is implied; they are merely for illustration.

Example Abstracts

• Abstract. When the performance penalty of object-oriented systems is mentioned, a common response is to blame antiquated hardware designs for not supporting object-oriented languages as they deserve. To what extent can the performance gap between conventional languages and object-oriented languages be closed using hardware? What architectural changes benefit object-oriented systems, and by how much? There have been many attempts to make hardware that better supports object-oriented programming. This tutorial describes some of these systems, and the extent that they have succeeded or failed in their aims. These systems include the iAPX432, SOAR, Rekursiv, and MUSHROOM, as well as some features from mainstream architectures such as SPARC.
• Abstract. This tutorial presents techniques for improving, understanding, and expressing object analysis and design models. These techniques include development of: Use Case Conversations, User Stories, User Navigation Models, CRC cards, object behavior stereotypes, control-style analysis, behavior refactoring worksheets, hot spot cards, and flexibility design. These techniques can be successfully applied to augment your analysis and design toolkit, regardless of methodology. This tutorial will be conducted as a hands-on-workshop where we review guidelines and examples to illustrate key techniques, and use the techniques to develop the artifacts.
• Abstract. There are many issues that need to be addressed before a truly reusable C# class library can be built. This tutorial will examine these issues from both an abstract perspective (design) and a pragmatic perspective (code).
• Abstract. As Java projects grow, they tend to hit the Java productivity wall - the point at which added resources do not contribute proportionately to project progress. This can happen at any point between three to six or more developers. This tutorial defines the problem, surveys available products, and provides generic and customized practical solutions using CVS as a model.
• Abstract. A project that is using object technology and an iterative development process faces a number of unique issues in order to deal with the project's entire life cycle. This tutorial presents a process framework that can be tailored to a specific project's situation. The tutorial follows a logical order of topics facing projects. Topics include estimating, scheduling, methodology selection, iterative development, and reuse. Specific advice derived from multiple project experiences is given during the discussion of each topic area.

Example Objectives

• Objective. The intermediate level C# programmer who attends this tutorial will gain experience in the following areas: the relationship of ASP.NET and code-behind; the creation of skins and a few other advanced GDI+ capabilities; leveraging delegates and events; techniques for efficient operator overloading; the use of anonymous methods.
• Objective. This tutorial is intended to prepare the participant (1) to determine whether a native XML database is appropriate technology for his or her database needs (2) to understand the technical tradeoffs between relational and XML technologies, and (3) to evaluate the commercially available XML persistence products.
• Objective. Participants will learn 10-15 GoF patterns well enough to explain their purpose.
• Objective. Participants will be acquainted with a comprehensive test plan that includes test-driven development, the new relationship of developers and test teams, and how to position testing as a function within a typical corporation.

Example Presentation Formats

• Presentation Format. This tutorial will be lecture based.
• Presentation Format. This tutorial will be 70% lecture and 30% individual paper exercises.
• Presentation Format. This tutorial will offer a minimum amount of lecture, with the majority of time spent in small groups trying to solve specific problems. Lectures will be used to deliver the key points but after approximately every 30 minutes of lecture, participants will complete a set of short exercises to reinforce the lecture material. Solutions to the exercises will be presented and discussed.
• Presentation Format. After a brief introduction by the presenter to set the scope and objectives for the session, participants will be divided into groups, and each group given one of four different problems to solve. Then two groups that have tackled different problems will swap members to compare solutions and prepare a poster that explains how the differences in the problems affected the solution approaches taken. There will then be an opportunity for all participants to view and discuss the posters. In the second half of the session the process will be repeated but with different group memberships and different problems. The session will end with the presenter drawing together the results of the exercises and explaining how they compare with recently published research results.

Example Attendee Backgrounds

• Background. Participants should be experienced Java programmers.
• Background. Participants should have a general familiarity with the object-oriented paradigm, preferably being fluent in one or more object-oriented languages. Familiarity with C# will be useful, but not required. The intended audience is professionals charged with developing or managing instruction in object-oriented techniques, either in a university or industry context.
• Background. The tutorial is targeted to those individuals interested in the managerial issues that influence the success of object-oriented software development efforts. It is assumed that the audience has some familiarity with the basic concepts of object technology and have begun to worry about how to effectively employ the technology.
• Background. Basic knowledge of the operational behavior of languages, particularly inheritance and polymorphism, but with no formal theoretical understanding. Only a knowledge of simple set theory will be required; and a willingness to perform certain mathematical substitutions. The tutorial is aimed at software professionals wanting to write type-correct software; language designers wanting to understand type issues in OOP; final year undergraduates and first-year graduate students wanting to relate traditional notions of type to OOP.

For more information