Your portfolio should demonstrate your growth as a computer scientist with respect to your understanding of the design and implementation of programming languages. Any reasonably accomplished computer scientist (including your peers) should be able to look at your portfolio, along with your reflection on it, and see evidence of your growth. Continued...
Portfolio Preparation
Components
Your portfolio is a collection of documents. Three of your laboratory assignments, the midterm presentation, your project proposal, the final project itself compose your final portfolio. In addition to these documents, you will need to write a critical reflection that looks back at these documents. In assessing your portfolio, each component carries roughly the following weight:
|
Labs (3x) 15% each Mid-term presentation 5% Project Proposal 10% Final Project (software and report) 30% Reflection 10% |
I discuss each of these sections below; the reflection document is not detailed separately, but instead discussed in the context of each of the components of the portfolio.
Laboratories
Your laboratories are where you demonstrate your ability to implement and test code written in new languages as well as write correct interpreters for new languages you have not seen before.
It is asked that you submit three (3) laboratories as part of your portfolio. You may use the XML lab from the initial three laboratories, one or more from the "interpreter" labs, the "lazy" lab, and/or the CSP/parallelism lab.
You are encouraged to select those labs that best demonstrate your learning and improvement over the course of the semester. Your reflection should, in effect, be a code walk—you should look critically at your code and tests, and reflect on those elements of implementation and style that you worked to improve, and see evidence of improvement, from one laboratory to the next.
Midterm Presentation
An excellent presentation tells a story. The slides you employ should be highly visual, as human beings are visual creatures.
Perhaps it is important to say that your presentation should also have been informative. Your reflection should consider the feedback you received on your midterm presentation, and how you applied that to your end-of-term presentation (if you gave one).
Project proposal and Final Project
Your final project represents multiple weeks of concerted effort in the design and implementation of a substantial piece of software with tests. If you opted to explore a more well-defined path (in which there is no shame—it is a path guaranteed to provide many learning opportunities), you probably:
- ... extended your interpreter to handle recursive functions, or perhaps you implemented side-effects and an object system.
- ... opted to implement a garbage collector.
- ... focused on web application development in a popular scripting language as compared to Scheme.
If you do not choose to travel a well-defined path, then I offer two well-undefined paths that you might consider as well.
Research and Interpretation
Consider the poster copied from Peter van Roy's pages at UCL. (I've provided a local copy of the PDF as well.) You might research one of the languages in this poster, focus on those qualities that dictate where it is in this tree, and implement an interpreter for those language features.
For example, you might implement message-passing concurrent programming a la Erlang or occam; the former has single assignment and first-class functions, while the second has mutability of state within a very limited scope. Also, the former is characterized by having asynchronous channels, while the latter employs single-cell, blocking communications.
Your project will present your research, your interpreter as demonstration of your understanding, and tests that demonstrate that your project is correct. It may be subject to code review.
Reflection and Reimplementation
Another path you might take is to re-implement one or more of the interpreters from class in a language you are familiar with. In this case, code quality is critical. As a transcription exercise, it is uninteresting. Therefore, your implementation, testing, and reflection will be carefully scrutinized for their thoroughness and quality.
Deep Language Exploration
Lastly, you might focus on exploring a language you do not know deeply. This implies that you will explore the literature surrounding the design and implementation of this language (and provide a review of your reading) and implement an interesting (and ideally idiomatic) application in this language.
Reflection
In your portfolio submission, there is less room for reflection, as the final project will not have the same opportunities for revision as other parts of the portfolio. However, your writeup should highlight those aspects of your learning that you feel are reflected in your work.
Evaluation
Your final project will earn a mark of either an A, B, C, D, or F.
Poster Evaluation
To receive an A, your poster must be excellent. This is hard work; do not underestimate effort it takes to assemble an excellent poster. This rubric will be given to other faculty taking part in poster evaluation.
| Category | Excellent | Satisfactory | Passable |
|---|---|---|---|
| Titles/Subtitles | Clear and enhance readability. | Mostly titles clear and enhance readability. | Do a poor job of clarifying text. |
| Text Size/Color | All text clear, readable. Any changes in size/color enhance readability | All text clear, readable. Some changes in size/color enhance poster. | Some text clear, changes do not help. |
| Writing | Well written, well organized, easy to follow. | Adequately written/organized, easy to follow | Poorly written/organized, hard to follow |
| Graphics/Data | Graphics/data clear, labeled, easy to understand | Graphics/data clear, labeled | Existence of graphics/data. |
Report Evaluation
Your reports will be evaluated (as nearly as possible) according to the following rubric. (Much of the material for this rubric was developed by Matt Boutell at Rose-Hulman.)
| Category | Excellent | Satisfactory | Passable |
|---|---|---|---|
| Organization | Document uses headings and topic sentences. Easy for the reader to follow the discussion and find any specific topic of interest. | Some headings/topic sentences in evidence. Fairly easy for reader to follow discussion. | Use of headings/topic sentences apparently optional. Hard to follow the discussion or find specific topics in the document. |
| Clarity/Conciseness | Writing is clear and unambiguous. Not wordy. | Mostly clear. Occasionally unclear or awkward writing. | Unclear writing. Ambiguous or excessively wordy writing detracts from any points being made. |
| Spelling/Grammar | Free of errors in grammar, spelling, punctuation. | Small number of errors. | Many errors. |
| Professionalism | Document has a professional tone and format. Could be shared with colleagues elsewhere without reservation. | Mostly professional in tone. Minor revision before distribution. | Unprofessional. Majority of the document would need rewriting before sharing/publication. |
| Introduction | Document clearly describes the work so that any competent computer scientist could understand the exploration undertaken. | Document describes the work so that a competent computer scientist with knowledge of the problem domain could understand the exploration undertaken. | Fails to describe the work. Computer scientists everywhere weep. |
| Literature review | Document includes a summary of appropriate literature and its relation to this project | Document includes a brief summary of appropriate literature and its relation to this project. | Document fails to include any discussion of the literature. |
| Design and Development | Document clearly describes the overall process followed, including development methods, language experiments, data, and analysis. | Document clearly describes the overall process followed. | Document fails to make process clear. |
| Testing | Document clearly describes testing framework, tests developed, and confidence regarding completeness. | Document clearly describes tests developed. | Testing? |
| Future Work | Document includes next steps that the pair would take, given more time. | Same. | Document fails to include future work. |
| Reflection | Document clearly describes the key challenges faced in implementing the project and the lessons learned from each challenge. | Document describes the key challenges faced in implementing the project and some of the lessons learned. | Document fails to describe the key challenges or lessons learned. |
| Effort | Excellent progress made on tough problem, or other evidence of much effort and new learning. | Problem was easy or similar to what we did in class, so not much new learning needed to be done or effort expended. | Little effort expended. |
| Code | Clear code, formatted in style idiomatic to the language used. Appropriately commented and documented. Compiles without warnings or errors, and executes correctly for all reasonable inputs. | Clear code, idiomatically formatted. Comments wanting, documentation passable. Executes without error. | Poorly formatted code, crashing behavior on some inputs. Generally poor software. |
And, to be clear regarding your code: take it through a code walk. If you have not edited and revised the work you have done to the best of your ability, then it cannot represent your best work.
Summary
An excellent project is overwhelmingly excellent in all cases. Excellent projects translate into A projects.
A satisfactory project is generally satisfactory in all cases; excellent ratings are balanced out with passable ratings. Satisfactory projects generally translate into projects in the B to C range.
A passable project is likely a C.
Projects that fail to rate on this scale in one or more dimensions may do poorly. Such projects may garner a D or an F.