CS222: Advanced Programming, Section 2, Fall 2013

Course Information

Course Title

Advanced Programming

Section

CS222 Section 2

Meetings

MWF 1:00–1:50 PM in RB122

Credits

3

Prerequisites

CS121 and CS124

Instructor

Paul Gestwicki, Ph.D.

Overview

The course catalog provides this short description of the course:

Project-intensive study of advanced topics and best practices in software development, including advanced language features, modular decomposition, and development tools.

This semester, our inquiry will be guided by the following essential questions of advanced programming:

1. What does it mean to be a "professional" in software development?
2. How do you know when a feature is done?
3. How do small teams of developers coordinate activity?
4. How does a Computer Science professional use ubiquitous and chaotic information to be a lifetime learner?

Note that, because this is a three-credit course, you should expect to invest nine hours of attention to it per week.

Books

Required

• Clean Code: A Handbook of Agile Software Craftsmanship, by Robert C. Martin

Technology

Each student is expected to bring a laptop computer to class that is configured for software development. This must minimally include:

• Eclipse
• The MercurialEclipse Plug-in

In order for the MercurialEclipse Plug-in to work, you will need to install the Mercurial binaries for your operating system. On Windows, these can be downloaded during the plug-in installation process; users of other operating systems will need to install binaries manually. You will not need the CodeBeamer component of the plug-in.

You will need to create and edit a Mercurial configuration file that specifies your username. Refer to the first step of the Mercurial QuickStart for instructions.

Evaluation

Your grade will be based on the achievements that you earn during the course of the semester and your reflections on these. Claiming achievements and submitting reflections are done via Blackboard; check the course site for instructions.

Claiming Achievements

You earn achievements by exploring the content of the course in such a way that addresses our essential questions. Each achievement has its own criteria, and all of them require you to create one or more achievement artifacts that represent your work.

When claiming an achievement, ensure that you have met all the criteria to a high standard of quality. When dealing with natural languages, your work is expected to be clear and concise, free of spelling and grammar errors, and representing elegance of form; when dealing with programming languages, your work is expected likewise to be clear and concise, free of compiler warnings and errors, and representing elegance of form. Note that this means that the standards for quality necessarily increase during the semester as you develop a better understanding of advanced programming.

Achievements can be claimed for collaborative work, although each contributor must credit his or her collaborators. As always, cite your sources!

For the purpose of claiming an achievement, "production code" refers to code that was developed for an external purpose, as opposed to code that was invented strictly for the achievement's sake. This can be any code you are legally allowed to modify, including your own code (such as past or current assignments as well as hobby projects) or code you are licensed to modify (such as free and open source software).

Note that the achievements are divided into categories. Some may be claimed at any time, and some require us to be in a specific portion of the semester.

Reflections are written after completing all criteria of an achievement, and they provide an opportunity for you to focus on what you learned through the process. Reflections will be evaluated using my triage grading rubric based on the following criteria; it is strongly recommended that your reflection be formatted in three paragraphs, one for each criterion.

• The reflection provides an explicit characterization of an essential question of the course. This characterization should be grounded in your experience and supported by evidence.
• The reflection provides implications to your own personal practice or, when relevant, your team's collective practice. Note that this is forward-looking: it is not a description of what happened but a commitment to future action. Now that you've done an achievement and characterized an essential question, what will you do?
• The reflection identifies and addresses a criticism of this characterization. Note that this is not a criticism of the achievement or its artifacts but of your characterization itself. This aspect of the reflection forces you to consider multiple perspectives to defend your characterization. This works best if you identify a specific and real criticism rather than a hypothetical one.

Each reflection is worth up to nine points. You may submit up to two reflections per week; details and deadlines will be posted on Blackboard.

You may resubmit reflections for re-evaluation. Each time you resubmit a reflection, you enter a five-day "cool-down" period: you may not resubmit again until five working days have elapsed. Resubmissions will not be accepted after the start of finals week. Note that resubmission presupposes submission: you cannot "resubmit" something that was never submitted.

Whereas achievements can be earned collaboratively, reflections are necessarily personal. See the List of Achievements below for details on each achievement's criteria.

Grades

Your grade will be determined according to the following table. It is recommended that you pursue two achievements per week before starting the final project and one achievement per week afterward. Note that meta-achievements are achievements—that is, they count in the Minimum Achievements column—and hence they require explicit claiming and permit achievement reflections.

The instructor reserves the right to make modifications to the balance and allocation of points as necessary to reflect the needs of the community of learners. Any such modifications will be announced in a class meeting.

Schedule

During the first week, we will review fundamentals of Java programming (within the Eclipse IDE) and object-oriented design.

In the first month of the course, we will read and discuss the first twelve chapters of Clean Code according to the table below. Note that the table also provides recommendations on which achievements would dovetail nicely with these readings. How you sequence Clean Code achievements with the Java-oriented achievements depends on your experience and comfort level with Java.

In mid-September, we will begin a small project in pairs, through which we will put the Clean Code principles to practice.

In early October, you will form a team and pitch a project idea to me and the rest of the class. The remainder of the semester will focus on the context of these projects. They will be created in three iterations of about three weeks each.

Unrestricted

Studious
For reflecting on what "studying" means
	Read Bill Rapaport's How to Study: A Brief Guide and then write a study plan for this course. Be sure to include a grade goal as well as an assessment plan. The assessment plan needs to include measurable steps by which you will determine the effectiveness of your plan and how it will be iteratively improved.

Master of the Big Three
For reflecting on the semantic constraints of Java objects
	Create a tutorial, based on production code, that demonstrates how to override toString, hashCode, and equals according to best practices of Java.

Java Core Sampler
For investigating a new aspect of Java
	Create a tutorial that demonstrates a concept that you learned from reading a section from the Learning the Java Language or Essential Java Classes trails of The Java Tutorial. The section should appropriate to your level of experience with Java. Post the tutorial on the wiki.

Community Learner
For using our learning community to further your personal knowledge
	Describe a concept you learned from a classmate's presentation, such as an in-class presentation or a wiki page. Demonstrate how you have used this concept on the wiki.

Badge Forger
For contributing an achievement
	Create your own achievement for the course—including name, description, criteria, and image—and have it approved by your instructor.

XP Investigator
For investigating extreme programming
	Write an essay response to the Extreme Programming methodology and, in particular, An Extreme Programming Episode.

TDD Investigator
For investigating test-driven development
	After reading at least the three chapters of Kent Beck's Test-Driven Development, which are available on electronic course reserve, create your own TDD tutorial on the wiki.

Decaf Cleaner
For applying Clean Code without Java
	Apply Clean Code to production code in a programming language other than Java. Document the process and results on the wiki.

Reflective Practitioner
For learning from failure
	Consider one of your failures from this course and write a postmortem about it on the wiki. Use the format described by Fitzpatrick and Collins-Sussman.

Clean Coder, Phase 1
For contemplating Clean Code chapter 1
	Read Clean Code Chapter 1 and identify which of the definitions of "Clean Code" resonates most with you. Explain your choice on the wiki.

Clean Coder, Phase 2
For contemplating Clean Code chapter 2
	Apply a theme from Clean Code Chapter 2 to production code. Document the process and results on the wiki.

Clean Coder, Phase 3
For contemplating Clean Code chapter 3
	Apply a theme from Clean Code Chapter 3 to production code. Document the process and results on the wiki.

Clean Coder, Phase 4
For contemplating Clean Code chapter 4
	Apply a theme from Clean Code Chapter 4 to production code. Document the process and results on the wiki.

Clean Coder, Phase 5
For contemplating Clean Code chapter 5
	Apply a theme from Clean Code Chapter 5 to production code. Document the process and results on the wiki.

Clean Coder, Phase 6
For contemplating Clean Code chapter 6
	Apply a theme from Clean Code Chapter 6 to production code. Document the process and results on the wiki.

Clean Coder, Phase 7
For contemplating Clean Code chapter 7
	Apply a theme from Clean Code Chapter 7 to production code. Document the process and results on the wiki.

Clean Coder, Phase 8
For contemplating Clean Code chapter 8
	Apply a theme from Clean Code Chapter 8 to production code. Document the process and results on the wiki.

Clean Coder, Phase 9
For contemplating Clean Code chapter 9
	Apply a theme from Clean Code Chapter 9 to production code. Document the process and results on the wiki.

Clean Coder, Phase 10
For contemplating Clean Code chapter 10
	Apply a theme from Clean Code Chapter 10 to production code. Document the process and results on the wiki.

Clean Coder, Phase 11
For contemplating Clean Code chapter 11
	Apply a theme from Clean Code Chapter 11 to production code. Document the process and results on the wiki.

Clean Coder, Phase 12
For contemplating Clean Code chapter 12
	Apply a theme from Clean Code Chapter 12 to production code. Document the process and results on the wiki.

Any Project

Domain modeler
For doing what needs to be done
	Read the chapter on domain modeling on electronic course reserve, taken from Martin Fowler et al. Patterns of Enterprise Application Architecture. Incorporate domain modeling into your project and document your example on the wiki.

Debugger
For using your tools effectively
	Learn how to use the breakpoint, step, and watchpoint features of an integrated debugger. Write your own tutorial for an IDE of your choice and post it to the wiki.

Third-Party Librarian
For being pragmatic about features
	Meaningfully incorporate a third-party library into your project. Describe the library you are using, why you chose it, and how it is used on the wiki.

Pair Programmer
For decreasing your error rate via social engineering
	Use by-the-books pair programming for one iteration of your project. Write a brief report of your experience on the wiki. The ideal report would include actual interactions in the style of An Extreme Programming Episode.

Checklisted
For using the proven best method of error detection
	With your project team, develop a code review checklist based on Clean Code Chapter 17. Use this checklist during a timeboxed formal code review. Share the checklist and your findings on the wiki. Be sure to make explicit the connections between your checklist and the chapter.

Advice seeker
For incorporating perspectives of the experienced
	Conduct a timeboxed code and/or design review with a software expert such as your instructor. Describe the process and key findings on the wiki, and demonstrate how this feedback was incorporated into the project.

Technical Writer
For writing a project whitepaper
	Write a whitepaper about your project. Post it to the wiki along with a justification of the whitepaper's content and form.

Hierarchical
For parsing structured data
	Incorporate an XML, YAML, or JSON data source into your project. Describe on the wiki what parser you chose and how you parsed the data for use in your project.

Pattern Disciple: Observer
For decoupling change dependencies
	Incorporate the observer design pattern into your project. Describe and justify the pattern reification on the wiki.

Pattern Disciple: Strategy
For decoupling algorithm specifications from their implementations
	Incorporate the strategy design pattern into your project. Describe and justify the pattern reification on the wiki.

Pattern Disciple: Builder
For decoupling object construction from other responsibilities
	Incorporate the builder design pattern into your project. Describe and justify the pattern reification on the wiki.

Pattern Disciple: Decorator
For preferring delegation over inheritance
	Incorporate the decorator design pattern into your project. Describe and justify the pattern reification on the wiki.

Fluent
For making programs read like natural language
	Design a fluent API within your project. Describe some representative and critical uses of this API on the wiki.

Integrator
For using continuous integration
	Configure continuous integration for your project using the department's Jenkins server. Write a wiki post describing the process and configuration.

Maven
For managing your dependencies
	Use Apache Maven to manage your project dependencies. Document the process and share your configuration files on the wiki.

Final project

Risk Manager
For considering mitigation and contingencies
	Use MSF Risk Matrices to make your pitch or to manage one iteration of your project. Share the risk matrix on the wiki.

Storyteller
For articulating requirements in a user-centric way
	Frame your pitch or organize one iteration of your project using user stories, in Mike Cohn's style, with measurable conditions of satisfaction. Share these user stories on the wiki.

Paper Prototyper
For mitigating design defects in the cheapest and easiest way you can
	Create a physical prototype of your project. The prototype should be designed to answer specific, explicit questions about your design. Test this prototype with representative end users. Document this process and results on the wiki.

Crystallizer
For being principled about agile software development
	Incorporate the seven Crystal principles into your methodology for one iteration of your project. Share representative artifacts on the wiki to describe the connection.

Public releaser
For doing it for everyone to see
	Publicly release your project. Be sure to clearly indicate under what terms the project is licensed. Link to the project from the wiki.

Enlightened
For giving presentations that aren't terrible
	Read Presentation Zen (which is on reserve at the library) or a similar pre-approved resource and follow its principles in a course presentation. Share your presentation artifacts on the wiki along with a description of the relationship between the artifacts and presentation principles.

Dynamic Modeler
For paying attention to the most important part of software design: its behavior
	Document a critical aspect of your project's behavior using a UML sequence diagram or communication diagram. Post this diagram and a brief description to the wiki.

Static Modeler
For using the de facto standard modeling language
	Document a critical aspect of your project's architecture using a UML class diagram. Post this diagram and a brief description to the wiki.

Build scripter
For controlling your builds
	Incorporate a build scripting (such as Ant) into your project. Post and describe your scripts to the wiki.

Test-Driven
For always knowing your next step
	Use Test-Driven Development for one iteration of your project. Describe the process, with examples from your iteration, on the wiki.

Acceptable: Level 1
For conducting acceptance testing
	Create an acceptance testing plan for one of your iterations, conduct acceptance testing with potential end-users, and document the plan and results on the wiki.

Acceptable: Level 2
For conducting acceptance testing
	Create an acceptance testing plan for one of your iterations, conduct acceptance testing with potential end-users, and document the plan and results on the wiki.

Acceptable: Level 3
For conducting acceptance testing
	Create an acceptance testing plan for one of your iterations, conduct acceptance testing with potential end-users, and document the plan and results on the wiki.

Meta

Clean Coder
For professionalism in code
	Complete every Clean Code phase achievement.

Engineer
For combining creativity and discipline
	Complete the Domain Modeler, Static Modeler, Dynamic Modeler and all the Pattern Disciple achievements.

White collar
For paying special attention to the business of development
	Complete the Enlightened, Risk Manager, Storyteller, Technical Writer, and all Investigator achievements.

User-Centered Designer
For focusing on the user's needs
	Complete the Storyteller and Paper Prototyper achievements along with all levels of the Acceptable achievement.

All files contributed for achievements and reflections must be submitted in open file formats. Good examples include HTML, PDF, OpenDocument, and my personal favorite, plain text. Note that Microsoft Office and Adobe Creative Suite formats do not qualify.

Exams

Traditional examinations are not expected for this class, although the instructor reserves the right to modify this policy to serve the needs of the class. Note that we will have a class meeting during the university-scheduled final exam slot, as required by university regulations. This meeting will be Friday, December 13, at noon.

Attendance and Related Policies

Your learning is commensurate to your participation, and so attendance is expected. You are responsible for your learning regardless of attendance. If you miss a class meeting, you should consult with trusted classmates to ensure you have the appropriate notes. I will not repeat myself unnecessarily over email, during office hours, or by appointment. Meetings begin at the time scheduled, and you are expected to be ready to begin at this time; late admittance is prohibited.

Communication

Office Hours and Appointments

Students who come to office hours are helped on a first-come, first-served basis; no appointment or prior contact is required. If a student wishes to make an appointment to meet outside of office hours, he or she should email the instructor the request along with several possible meeting times.

Email

All email communication to the instructor should be from a BSU-affiliated address. This policy ensures that senders can be correctly identified and protects your privacy. Email sent from other domains may not be answered.

The instructor may access email through services not affiliated with the University. Please note that such messages necessarily pass through the campus firewall in an unencrypted format, and they may be stored on servers not owned or managed by Ball State University. It is therefore advisable to restrict confidential information to office hours or appointments.

If you are emailing regarding questions in a computer program, it is recommended that you send a copy of the code in question in your email. The preferred method is to copy the code into the body of your message, using plain text and following standard formatting conventions. Alternatively, if the code is in a publicly-readable repository, email the URL.

Telephone

Although the instructor's office telephone number is listed, email and face-to-face communication are strongly preferred. I will respond to every student email I receive; I will not necessarily respond to telephone messages.

Academic Integrity

Students and faculty are bound by the Student Academic Ethics Policy of the Code of Student Rights and Responsibilities.

Intellectual Property

It behooves you to be aware of fundamentals of copyright law and the university's intellectual property policies for student-created work.

Miscellany

We will be using Google Docs and other connected technologies to coordinate community activity. If you do not already have a Google account, you will need to create one. Using two-step verification is strongly recommended.

All students have free access to The Writing Center.

Notice for Students with Disabilities

If you need adaptations or accomodations because of a disability, if you have emergency medical information to share with the instructor, or if you need special arrangements in case the building must be evacuated, please make an appointment as soon as possible.

Image Credits