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:
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 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 Eclipse for in-class demonstrations. Download and install the latest Java SE Developer Kit (JDK) from java.oracle.com. Then, download and install the “Eclipse IDE for Java Developers” from eclipse.org.
Some demonstrations will make use of JavaFX, which requires a separate download. Launch Eclipse and open the Eclipse Marketplace through the Help Menu. From there, search for “JavaFX”. You should see an entry for e(fx)clipse, an Eclipse plug-in that permits JavaFX application development. Install this plug-in.
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.
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.
After the first three weeks of the semester, you will have the opportunity to earn achievements to distinguish yourself. The achievement system is designed to encourage your independent exploration of relevant course topics. If you have an idea for a new achievement, email a formal proposal to the instructor.
You earn an achievement by completing its unique criteria, but an achievement is more valuable if it is validated by someone else. The more rigorous the validation, the more credit the achievement contributes to your final grade; you may earn up to 20 credits during the semester. Achievements can be validated at three different levels. Note that higher levels of validation subsume lower ones, so you can earn at most four credits per achievement, not seven.
Achievement claims are made by sharing an artifact on the shared drive in an eponymous document. If a document does not yet exist for the achievement you are claiming, create one. Because these achievement documents will contain artifacts from multiple students, be sure to start your own section by placing your name in the Heading 1 style, similar to how you offset each entry in your assignment document.
You may make one achievement claim per week, due 10AM on Mondays, using the form linked from Blackboard. The form will ask you to identify if the achievement is self- or peer-validated and, if it is peer-validated, if you are seeking expert validation. Note that peer-validation is required before requesting expert validation. If you request expert validation but do not receive it, you may make the claim again, following the same processes described above; this is itself an achievement claim and hence is subject to the one-claim-per-week rule.
Most achievements are designed as individual exercises, although some may be attempted by small groups—usually pairs, but potentially an entire final project team. In this case, multiple-authored claims should be submitted as a set of individual claims with the other authors as peer validators.
As in video games, achievements are optional, but you will need them if you want to earn top recognition. If you are not interested in defining your own path or if you find the list daunting, start with Studious. Also, while many achievements deal with technical issues, keep in mind the more “social” achievements as well, such as Capstone Connector, Community Connector, or Seeker.
First, a bit of philosophy. I grade almost everything according to my triage grading approach.
Briefly,
each item is graded as incorrect, partially correct, or correct. These correspond to
Your final grade in the course will be computed as a weighted average, using the weights given below. Each achievement earned contributes equally to the Achievements score. Your Project score is a composite of the Two-Week Project (20%) and the Final Project (80%); 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 my personal favorite, 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.
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.
A student's assignment submissions will go into a single shared Google Docs document for that student, separating each using the “Heading 1” style; you will submit the URL of that heading to Blackboard, as demonstrated in this video.
The components of the assignment will be evaluated using my triage grading rubric with equal weights per part. Late work is always considered unsatisfactory.
Once per week, you may request re-evaluation of an assignment you have revised; to be clear, this is one request per week, not one request per assignment per week. The re-evaluation is requested by resubmitting on Blackboard, indicating in the submission or comments area that it is a re-evaluation request. Place your revision immediately below the original submission within your Google Docs document, giving it a unique heading such as “Assignment 1 Resubmission 1”. This section must begin with an overview of the changes since the previous submission—an ad-hoc changelog—followed by a complete submission, without no further references to the previous attempt. Additionally, before a re-evaluation request will be considered, the revision must be reviewed and signed by a classmate. Signing the revision indicates that you and the reviewer have collectively reviewed your resubmission and believe it to meet the highest standards. A reviewer signs an assignment by including, at the bottom of the re-evaluation request, the reviewer's name followed by a one-sentence summary of the review.
Assignment essays or resubmission requests are due at 10AM on the indicated due date. Resubmissions are due 10AM on Mondays.
Choose source code in accordance with the guidelines listed below. 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.
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.
The client for this project is an investigative journalist who was inspired by the recent banning of hundreds of paid editors banned from Wikipedia. A consultant has met with the client and developed the following user stories to capture the client's desires. Each story is listed with its conditions of satisfaction.
System.out
, although you may incorporate a
logging framework.
The technology behind Wikipedia is called MediaWiki, and it has an extensive API for developers. Wikipedia has an API Sandbox that you can use to learn the API by playing with live data. Doing so helped me come up with the following HTTP request, which pulls down information about the 30 most recent changes to the Soup page as an XML document:
https://en.wikipedia.org/w/api.php?action=query&prop=revisions&format=xml&rvprop=timestamp%7Ccomment%7Cuser&rvlimit=30&titles=soup&redirects=
This link takes you to the sandbox page, with all of the options from that Web request selected, in case you want to use that URL as a starting point.
The sample project skeleton demonstrates how to open a connection to Wikipedia, specify your user-agent, read data into an XML document, and conveniently process that document using XPath. Using this toolchain is recommended but not required: there is more than one way to get at the information you need to complete this project.
Once you have read the data from Wikipedia, you need to put it into your domain model. You should be able to build your domain model programmatically, without ever touching the network; this makes it much easer to test your domain model without introducing unnecessary dependencies.
As with any TDD project, you should start by making a task list. That is, start by taking a small piece of your system and determining unambiguously what it should do. Keep in mind that the SMART or FIRST may be useful in defining the behavior you are going to test.
It is recommended that you build your solution in thin vertical slices. Think about a feature the user wants, based on the user stories. Write a few tests to get the domain model in place, then put together a simple user-interface to demonstrate that it is working to the user. Continue in short iterations, making sure that all your code is clean as you go. Even though the graphical user-interface will not have unit tests, you can still approach it from the philosophy of Red-Green-Refactor: first make it work, then make it right.
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. This project 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, developing it 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, tentatively scheduled for September 30. 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.
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 10AM 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 TDD.
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 writes a reflective essay on the previous three weeks. This essay should directly address one of the course's essential questions, drawing upon experiences from the iteration. 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.
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.
Requirement | Satisfactory (3) | Probationary (2) | Unsatisfactory (1) | Unaddressed (0) |
---|---|---|---|---|
{{item.name.innerHTML}} | {{item.v3.innerHTML}} | {{item.v2.innerHTML}} | {{item.v1.innerHTML}} | {{item.v0.innerHTML}} |
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.