because data structures are great awesome
They're not so bad...
Back in the day, bitwise operations gave me the screaming heebie-jeebies. I'd look at something like
field |= ~(val & (5 << 1))
and pass out. People would have to scrape me off the pavement. Then again, I did a degree in Physics as an undergraduate. But now that I'm the one writing the websites, well... just you watch.
Our goal is an implementation of Tic-Tac-Toe with a little bit of classic artificial intelligence thrown in. The first step in any project of this nature is to design and implement the underlying representation for the data. You can't write code if you don't understand how your data will be represented. Any code that evolves the structure of the data as you go will turn into the worst kind of spaghetti code you can imagine.
So to get things started, I'm going to ask you to take my representation of a Tic-Tac-Toe board and give it a thorough going-over.
My code is in my repository, and the project is called tic-tac-toe.
First, you should write a report about what my code does. It should be thorough. Specifically, address what role each field, constructor, method plays in the functionality of the class. Then, you should provide a line-by-line breakdown of each method. In doing this, you should make it clear to your reader what each of the bitwise operations in the code actually does. This will not be a short report: it should be clear, well-written, free of spelling and typographic errors, and clearly communicate your understanding of all of the code in the class TicTacToe.
Second, you should refactor any code that you think could be expressed more clearly. For example, you might create small helper methods that make some operations clearer for you as a reader. Or, you might not make any changes. Any changes you make should be included in a second (smaller) report about your refactoring.
Third, you should use JavaDoc to comment my methods, so that all of my code has sensible, meaningful descriptions in BlueJ's documentation view. You should be able to do this easily after writing your reports.
Fourth, you should comment the code sensibly. This does not mean that you should spew your report into the code. You already have good JavaDoc in place, so the question is whether there are any additional comments that you think will clarify the code that is present.
At the 2009 OOPSLA (Object Oriented Programming Systems Languages and Applications) conference, Elisa Baniassad and Clayton Myers presented a paper titled An exploration of program as language. This is a fascinating idea: we might program in one language, but the programs we read and write represent a higher-level language unto themselves. Is this true? I think it's the topic for a marvelous discussion.
But what does this notion of "programs as languages" mean for this lab?
If you were to walk into a software project tomorrow, you'd almost certainly be walking into a big pile of other people's code. Some of that code would be well written, well documented, and well tested. More than likely, much of the code would not be well commented—or worse, there would be comments that no longer reflect the reality of the code that exists.
So if we take it as possible that every program is like a language unto itself, then learning to understand programs is a challenging interpretive and translational process. Further, it is a process you will need to engage in over, and over, and over throughout your career at Allegheny and beyond. You will encounter new languages, new constructs in old languages, new patterns and ideas... everything about computing for the next 20 years is going to be a journey where the only constant is change.
I'm working on the assumption that you aren't familiar with bit vectors, and that you're not entirely comfortable with bitwise operations. For that reason, this seems like an excellent space in which to hone your interpretation and code reading skills.
PS. I'd like to encourage you to read the paper.
Following from Piaget's stages of development, your reports will be assessed as follows.
Sensory Motor Period
Any report that contains basic grammatical errors or typographic errors has not left the Sensory Motor Period of development. I see no reason to be particularly forgiving on this front.
The Preoperational Period
Reports that are lacking in diagrams and require me to think hard about what you are saying suggest to me that you still don't fully understand the topic. As
Piaget says:
Increased use of verbal representation but speech is egocentric. The beginnings of symbolic rather than simple motor play. Transductive reasoning. Can think about something without the object being present by use of language.
Actually, that doesn't help at all, but it sounds good.
Period of Concrete Operations
Reports that have reached the Period of Concrete Operations leave me weeping for joy. My 7-month-old, upon seeing your report can't even bring himself to chew on it, object of beauty that it is. Diagrams are used consistently and appropriately, and all text is written either in iambic pentameter or a classical epic form.
Translation: it's a really good report. (No, I don't actually expect your report to be in verse, but you win huge points if it is.)
(Images from Flickr, placed in the public commons, each which tells their own story: 1, 2, 3)
Your report (written in OpenOffice) should be submitted via email. The subject line of the email that you send should read
[ DS112 ] TTT Report
Your report should be attached to your email and be named
<username>-tictactoe-report.odt
(Please replace <username> with your own username, by the way.)
Creative Commons BY-NC-SA 3.0 Licensed where possible.