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:
These will guide us toward meeting the course learning objectives:
Note that, because this is a three-credit course, you should expect to invest nine hours of attention to it per week.
This is an Edupunk class: we will be using the best tools for the job, recognizing that learning these tools is also part of your education. You will almost certainly encounter something new that will challenge you—and occasionally frustrate you!—but by working through this, you will gain valuable knowledge and skills.
We will use Blackboard only minimally. There is a forum that you can use to discuss course-related issues with your classmates. I will use it to post announcements and reminders, and it will serve as a hub for submissions and repository for some grades. Note that you should not rely on Blackboard's “points” total to determine your grade: use the formulae provided in this document instead.
As specified in the undergraduate catalog, students in Computer Science majors courses at the 200-level and above are expected to have a laptop computer for class. You are expected to complete the following installation and configuration steps before our second meeting of the semester.
We will be using Java and IntelliJ IDEA for in-class demonstrations. Download and install the latest Java SE Developer Kit (JDK) from java.oracle.com. Then, download and install “IntelliJ IDEA Community Edition” from jetbrains.com.
For version control, we will be using git, and although the IntelliJ IDEA integrations are good, I do find it useful to occasionally drop to the command line. See the installation documentation for details and links; for Windows, I recommend the git for Windows project mentioned therein.
You will need to sign up for a Google Account, if you don't have one already. Configuring two-step verification on your Google Account is so strongly recommended it may as well be required.
You will need to sign up for a GitHub account if you don't already have one. As always, remember to use strong and unique passwords for different Web services. As a student, you should also request the Student Developer Pack, which gets you limited no-cost private repositories.
Once you have your Google and GitHub accounts, complete the form linked on Blackboard to register these accounts with me. I will then get you access to our shared folder on Google Drive and GitHub,
The semester will be divided into three sections. For the first three weeks, we will explore new ideas and technologies while you individually complete a series of three assignments. After this, you will work in pairs on a two-week project, which will provide an opportunity to bring these new ideas to practice. The majority of the semester will be spent on your final project, which will be completed by small teams in three iterations. This project will be your most important artifact this semester, representing all that you have learned so far as a Computer Science student.
During this time, you may be earning individual achievements. You may count up to five achievements for course credit during the semester. If you're not sure where to start, I recommend Studious.
The final exam will be 7:30AM on Thursday, May 5.
First, a bit of philosophy. I grade almost everything according to my triage grading approach. Briefly, each item is graded on a three-point scale of incorrect (1/3), partially correct (2/3), or correct (3/3). These correspond to D, C, and A grades, respectively. If you get some things right and some things wrong, you should expect to get a C: that's how I interpret “average.” If you want to get a grade corresponding to “very good” or “excellent”, you will need to get things right much more often than not.
Your final grade in the course will be computed as a weighted average, using the weights given below. Assignment grades are averaged together, and up to five achievements can be counted for course credit (that is, at 3% each). Your Project score is a composite of the Two-Week Project (20%) and the Final Project (80%); however, if your Final Project score is higher than your Two-Week Project score, it will be be used instead.
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.
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.
Note that during the second half of the semester, I tend to hold a lot of meetings in the lab. I usually remember to put a note on my door to this effect, but if I don't, you can look for me there.
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.
Although my office telephone number is listed on my Web site, email and face-to-face communication are strongly preferred. I will respond to every student email I receive; I will likely not respond to telephone messages.
Students and faculty are bound by the Student Academic Ethics Policy of the Code of Student Rights and Responsibilities.
It behooves you to be aware of fundamentals of copyright law and the university's intellectual property policies for student-created work.
When file submission is necessary outside of Google Drive, all files must be submitted in open file formats. Good examples include HTML, PDF, OpenDocument, and plain text. Note that Microsoft Office and Adobe Creative Suite formats do not qualify.
Some assignments and achievements require the writing of an “essay.” I use this term in the classical sense, to describe a composition that represents an attempt to understand a complex idea. An essay is neither a summary nor a staid five-paragraph construction. As the course prerequisite implies, these essays should represent collegiate-level writing. You are encouraged to leverage our digital writing environment to compose multimodal pieces.
Want extra feedback on your papers? The Writing Center is a community of Ball State students and faculty who value writing. Come and collaborate with one of our trained peer tutors on any project for any major. The Writing Center is a comfortable, supportive environment for writers from all communities and backgrounds. It is located in Robert Bell 291. To make an appointment, go to http://ballstate.mywconline.com.
This course CS222 held in RB109 is a part of Ball State’s Interactive Learning Space Initiative. This room is equipped with ceiling video cameras that document activity in the space (video only—no sound). As a student in this course you will be asked to participate in research projects. A consent form will accompany each research project request.
If you need course adaptations or accomodations because of a disability, please contact the instructor as soon as possible. Ball State's Disability Services office coordinates services for student with disabilities; documentation of a disability needs to be on file in that office before any accomodations can be provided. Disability Services can be contacted at 765-285-5293 or dsd@bsu.edu.
Each assignment consists of a series of reading, analysis, and writing activities. Assignments are to be completed by individuals, although you are encouraged to discuss your work with your classmates. In keeping with scholarly tradition, all that you claim as yours must be authentically your own, and you must cite your sources for anything that is not. As always, your work should represent best practices of college-level composition. Keep in mind that The Writing Center is free and available for all students.
Each student will create an eponymous document in the Assignments folder on Google Drive, and that is where all of your assignment artifacts will be placed. When you are satisfied with your work, you submit the URL to the appropriate section of the document via Blackboard. This video tutorial explains the basic workflow:
The components of the assignment will be evaluated using my triage grading rubric with equal weights per part. Late work is always considered unsatisfactory.
You may only resubmit one assignment per week. Your revised assignment must begin with a changelog that summarizes the changes from the previous submission; if this is a second resubmission or higher, each previous changelog should also be included. As usual, the resubmissions is made by submitting the appropriate URL through Blackboard.
All submissions—including resubmissions—are due at 8AM on the first class meeting day of the week.
Code you select for analysis should be about 50–150 lines and written in a programming language that supports object-orientation. The code must be part of a meaningful project, not tutorial or demonstration code. You may use any code you own (such as past or current projects) or code that has been released under an OSI-approved open source license. If you are using code you do not own, clearly indicate under what license you are using it.
If you are unsure about where to look for code to evaluate, here are a few sources:
Choose source code in accordance with the defined guidelines. Evaluate the selected source code with respect to Clean naming and functions, which correspond to chapters 2 and 3 of Clean Code. Point out each violation, citing the appropriate rule from the reading. Modify the code to bring it into compliance, and briefly explain the changes required in other modules as a result of the refactoring.
Choose code based on the guidelines to evaluate and refactor as in Assignment 1, additionally considering formatting and comments. Note that mechanistic elimination of comments does not bring code into compliance: one must consider what is being expressed by the comments and whether these ideas should be expressed with other refactorings.
Additionally, compose an essay response to the Engineer Notebook reading.
Choose code based on the guidelines to evaluate and refactor as in Assignment 2, additionally considering the Single Responsibility Principle. This evaluation must include an articulation of the responsibilities of each class examined.
Additionally, compose an essay response to the reading from Holub. Be sure to contrast your understanding of object-orientation before and after having read the piece.
In this project, you will gain hands-on experience developing a project using the Clean Code standards and Test-Driven Development. You will create a GUI that pulls data from NPR's RSS news feeds, performs some analysis on these, and presents the results to the user.
You can find a full list of NPR's RSS feeds at http://www.npr.org/rss/.
A submission must compile without errors or warnings and meet all functional requirements. Provided that this is true, then a submission will be graded out using triage grading out of six points, with three points for structural rules of Clean Code and three points for procedural rules of Clean Code. The checklist may be useful in self-evaluation.
Your final project will be your focus for the majority of the semester. You will be working with a team on your own project over three iterations, each of which will produce an executable release.
You will form your own teams. It is recommended that form teams primarily around the times you are available and secondarily around shared interests. Teams will be formed during a class meeting that is scheduled for February 17. However, you are welcome to begin discussing the final project at any time; feel free to use the general discussion forum on Blackboard to initiate conversation with classmates.
Each team will give a project pitch to the class. It is strongly recommended that you review the pitch requirements with the instructor prior to your pitch. The presentation may be at most five minutes long. Slides are optional and handouts are encouraged. The pitch must satisfy the following requirements.
Pitches will be evaluated according to the following rubric.
| Requirement | Satisfactory (3) | Probationary (2) | Unsatisfactory (1) | Unaddressed (0) |
|---|---|---|---|---|
| Summary statement | ||||
| Target audience | ||||
| Key features | ||||
| Development and deployment platforms | ||||
| UI Sketch or sample clients |
A team must repeat their pitch if they earn 0 or 1 point in any category or if total points is less than 12. Revised pitches will be scheduled for the next possible class meeting.
The project is divided into three iterations, during each of which you will create an increment of your project. Increments are due at 8AM on the day that ends an iteration; these will be submitted via instructions provided on Blackboard.
Each project is to be developed by a team of three or four students from the class, using an object-oriented approach and following the conventions for your language.
Your software architecture must separate model from view, as well as the persistence layer if you have one. This should be done using a domain model—an object-oriented representation of the concepts and relationships manifest in your problem domain.
You must follow the principles of Clean Code, including structural principles (such as OOP and SRP) and process principles (such as TDD and the Boy Scout Rule), although strictly view-level code does not require automated tests.
All project dependencies that are not part of the development platform must be either tracked in the version control system (such as in a lib folder) or automatically resolved using a dependency management system such as Maven (see also the Dependency Manager achievement).
All projects will be hosted within the class' organization on GitHub. Each will have a README.md file in the root of the repository that lists the team members and any special build or execution instructions.
Each iteration should produce an executable release, also known as a potentially-shippable product. That is, your increment should be a usable, stable software system that implements a subset of your product backlog. The three releases will be tagged 0.1.0, 0.2.0, and 0.3.0, respectively.
Each increment must be tested by representatives of the target demographic who are not also on the project team. This practice constitutes acceptance testing, and it is done by giving testers specific tasks to accomplish using your system and observing their interaction with your system. The tasks should come from your user stories.
Iteration review presentations will follow on the two class periods at the end of an iteration. Each review may be no more than ten minutes long and must address the following.
At the end of each iteration, each team member will write a reflective essay on the previous three weeks. This essay should draw upon experiences from the past iteration to directly and explicitly address one of the course's essential questions. These essays will be submitted confidentially on Blackboard; they are not shared within the community, unlike many of our other artifacts this semester.
Each increment will be evaluated in two categories: code quality considers the quality of the code itself, including project configuration and version control configuration, and process quality considers evidence of procedural correctness, including TDD and version control practices. Your presentations will be evaluated based on evidence of having met the criteria for the demonstration, product backlog, critical component description, and acceptance testing results. Your individual reflection essays will be graded holistically according to how clearly you connect your experiences to the course's essential questions.
Each member of a team will also conduct a rubric-based self- and peer-evaluation at the end of each iteration, using the format given below.
| Requirement | Satisfactory (3) | Probationary (2) | Unsatisfactory (1) | Unaddressed (0) |
|---|---|---|---|---|
| Commitment | Attended all scheduled team meetings or notified the team of absence. | Missed team meetings, with notifications, with enough regularity to be problematic. | Missed one or more team meetings without notifying the team. | Regularly missed team meetings without notifying the team. |
| Participation | Contributed to project planning, implementation, testing, and presentations. | Did not contribute to one of the following: project planning, implementation, testing, and presentations. | Did not contribute to two of the following: planning, implementation, testing, presentation. | Did not contribute to three or more of the following: planning, implementation, testing, presentation. |
| Communication | Clear reports on what has been accomplished, what is in progress, and what stands in the way, thereby facilitating progress. | Sometimes is unclear about what has been done, what is in progress, and what stands in the way, creating minor impediments to progress. | Is regularly unclear about what has been done, what is in progress, and what stands in the way, creating significant impediments to progress. | Communication patterns directly disrupt team progress. |
| Technical contributions | High quality technical contributions that facilitate success of the team. | High quality technical contributions that do not directly facilitate the team's success. | Low quality technical contributions that frequently require redress by other team members. | Low quality technical contributions that inhibit success. |
| Attitude and Leadership | Listens to, shares with, and supports efforts of others, and actively tries to keep the team together. | Listens to, shares with, and supports the efforts of others. | Frequently fails to listen, share, or support teammates. | Displays an antagonism that inhibits team success. |
Your contribution score is the sum of the medians from this rubric, and your raw iteration grade constitutes 10% presentation, 10% reflection essay, and 80% project. Your grade for the iteration is the minimum of these two.
Your final project grade will be a composite of all three iterations grades, each being weighted by the square of the iteration number. That is, your first iteration contributes one unit, the second contributes four, and the third contributes nine.
|
|
|
In order to receive course credit for the achievement, you need to claim the achievement and have that claim validated. Verification is a two-step process. First, you earn a peer validation by reviewing your achievement claim with a classmate, who works with you to ensure that you have met the criteria. After peer validation, you may request expert validation using the form linked on Blackboard. The claim will be evaluated using my usual triage grading system.
All achievement artifacts should be placed in the shared folder for the course, within the Achievements directory, in documents named after the achievement. Each student working on an achievement should make their own section in the document, using a Heading 1 style label with the submitter's name. This heading then provides a unique URL to your submission, which URL will be necessary when requesting expert verification. Refer to the video on assignments page for a refresher on how to use styles and heading URLs in Google Docs.
You may request one expert validation per week, starting 8AM on the first class meeting day of each week. This may be a repeated request if a previous claim was deemed unsatisfactory.
These checklists are designed to serve as reminders as you work on your two-week project and final project in CS222. The lists come from a combination of research, documented best practices, and experience with what kinds of things student programmers tend to overlook.