Programmer's Pursuit Reevaluation

After some months of development, balancing school, teaching, and work, and two weeks of illness, I am forced to admit that I will not be able to complete Programmer's Pursuit before the end of the semester.  Many of the components of the game are working, but of those many are still unrefined and have difficulties fitting together.  Although this is disappointing, I have every intention of continuing work on the project over the summer.

Programmer's Pursuit was intended to provide the students in my ICS 111 class with an entertaining way to review the course material.  The game would have included a facsimile of a Computer Science midterm.  While I certainly cannot complete Programmer's Pursuit before the semester ends, I believe that I can create a workable (if somewhat unpolished) sample exam for the students to use in preparation for their final exam.  Since many of the students have expressed their desire for a practice exam, I expect that this will provide the students with something that they want and that will prove of use to them.

Aside from helping the students, I intended to use Programmer's Pursuit as a means of continuing the use of various software engineering tools.  As usual, I have Eclipse for my IDE.  The source code for this exam application is on Google Project Hosting largely as a backup in case something should happen to my computer, though the ability to track issues will prove useful soon.  I have reverted to using SVN largely due to my familiarity with using it, though I will certainly continue to work on learning Git once I have more free time.  Ant remains my build tool, though the files that I am using with it are much reduced in functionality.  I am only using JUnit, Jacoco, and CheckStyle for my testing; PMD and FindBugs have been temporarily removed.  I am using CheckStyle instead of PMD or FindBugs mostly because I was able to discover how to modify the appropriate configuration file for CheckStyle to fit my stylistic preferences. 

The link to the project site for the ICS 111 Practice Exam is:
http://code.google.com/p/ics111-practice-exam/

The practice exam is currently functional.  Questions may be multiple-choice or fill-in-the-blank (for short-response questions).  The user is presented with each question in sequence and can navigate between questions using the Previous and Next buttons at the bottom or through typing in the number of a particular question and clicking the Go button in the lower left. 

Once the student has completed the exam, he or she may click on the End Exam button in the lower right portion of the window.  This produces a prompt to confirm that the user wishes to stop.

Clicking Cancel returns the user to the exam.  Clicking OK goes to a results page that contains the score that the student received and lists any incorrect questions with the user response and the correct answers.

There are a few more features that I have to work on; in particular, I want to add a button that opens up a list indicating which questions have not yet been answered and a button to access supplementary materials for particular questions.  As some may note, the exam questions shown in the images here and that are in the code on the project site at the moment are all on HTML; this was because my testers for the layout are not familiar with Java but do somewhat understand HTML.

Programmer's Pursuit - Initial Commit

Since my last post, I have been working on test-driven development and using Git as my version control system.  Test-driven development, as noted in that previous post, is working quite well; although it does have its problems, the benefits far outweigh the costs.  On the other hand, I have been less successful with Git.  In fairness, I can use Git to some extent, and at least in theory Git sounds better for a single-developer project such as this.  However, at the moment my limited knowledge of Git is roughly as useful as telling someone that the way to get to the University is to go three blocks down the road, then turn right, then turn left at the next two lights, then go onto the freeway, and then drive for a dozen or so miles until reaching the University exit: the instructions might help the listener in this specific instance, but as soon as said listener has to deviate from those directions he or she will have a much more difficult time completing the task.  (The difficulty has absolutely nothing to do with my poor sense of direction.)  I can use Git to complete simple tasks (most of the time), but anything more than pushing changes onto the Google project site is currently beyond my abilities.

The project site finally has some code on it.  Unfortunately, it also has a fair bit more than just the code and documentation; the various libraries, results from testing, and byte code are also on the site.  Since I do not know how to get Git to remove those files (and the end result of trying to get Git to do so was that my computer crashed), those files will have to stay there for now.  Since I wrote that I would use Git, I have every intention of continuing with it until I learn how to become competent in its use; if it begins to pose too many problems though, I may create a separate project site for me to communicate with through SVN.

There are now some Ant build files in the project (that are supposed to be there).  At the moment, these only perform very basic tasks such as compiling, running JUnit tests, and generating JavaDocs.  I will add in automated testing once I learn how to configure Checkstyle and PMD to my preferences; although the stylistic guidelines that I followed a few months ago are quite similar to my personal style, the few differences would undoubtedly produce a few hundred warnings that would make passing the verify test impossible. 

As for the project itself, the three basic classes (Item, Person, and Room) are completed.  I have also created the enumerated type Direction to specify the valid types of movement.  The next task for me to work on then is the parser and handling commands; after looking at the original code, I suspect that this should be a relatively simple task.  The parser can probably work as a static class since it does not particularly need specific instances.  At the same time, I will be considering how to extend these base classes. 

Programmer's Pursuit: Test-Driven Development

There has been little tangible progress on the project over this past weekend, and a lot of that is due to my experiment with test-driven development.  This lack of progress is partly due to trying to do something in a way that I have never tried before.  Perhaps more than that though, I had to code while essentially blind: without an implemented Room class, any tests on the Room class will necessarily fail.  Admittedly, I have my notes on how I intend to design the basic classes, but that is not the same as having methods already in place for testing.

That complaining aside, test-driven development has provided at least a couple of significant benefits that outweigh the negatives.  While developing the tests for the Room class, I had little idea of what return types I wanted to use for many methods.  Some methods are easy of course: getName returns a String containing the name of the room, addItem returns true if successful and false otherwise, and so forth.  However, other methods posed some problems.  Trying to look at all of the items in a room provides an example.  Originally, I had intended for this method to return a String containing the names of all the items in a hierarchical order of sorts.  However, after working on the tests for that section without the finality of knowing what the method had to return, I realized that this is a terribly inefficient way of solving the problem.  Using just the String would reduce flexibility, since the program would be limited to the format that the method used.  If a List is used instead though, then the calling method can handle the output however it wishes rather than having to get the String results. I do not think I would have noticed this without test-drive development; rather, I would have written tests to ensure that the existing code worked as intended. 

The Item and Person classes are fully implemented and tested; however, what I have learned from writing the tests for the Room class will also apply to these other classes as well, so I will probably have to go back to work on them again.  The project site for Programmer's Pursuit is still empty.  Still, with this experiment with test-drive development working so well, I hope that the slow progress on coding will lead to much faster work later on.

Programmer's Pursuit - Project Site Up

The project site is now operational:
http://code.google.com/p/ics-111-programmers-pursuit/

There is nothing much on the site yet, but it is there.

No work was done on this project over the weekend due to studying for exams and various other schoolwork; that should mostly be cleared up by Wednesday, so hopefully I will be able to get back to work on this in the near future.

I will have to think about how to actually store the data for use in generating instances of the Room, Item, and Person classes.  The data would have to be hardcoded or stored in some external files.  I think that putting the data for the various rooms and such into the code itself would save time since the program would not have to access other files.  On the other hand, CSV files (or even plain text if necessary) are much easier to work with for data, and having the data outside of the program allows for the basic program to be used for many different programs later on; to create a new game, all the developer would need to do is write up a new data file.

The game will involve the user writing up some Java code as part of their "assignment."  In the original Lisp code, this involved the program accepting input until receiving a particular string.  This worked back then because the students in that class used Emacs to write their Lisp code.  However, the ICS 111 students use jGRASP, which differs from Emacs in some statistically significant ways.  Essentially, I will have to find some way to launch jGRASP (or whatever IDE they want to use for Java) from within the game and then resume the game once the player has completed the programming assignment.

ICS 111 Game Project: Programmer's Pursuit

After some thought, I have tentatively titled the project for ICS 111 "Programmer's Pursuit."  Aside from making me use the escape character for the apostrophe a lot in the code, the alliterative title actually matches the content of the game quite well.  There are three interpretations of the title that I can think of, all of which are valid.

I have skimmed through the original Lisp code; I had forgotten some of the little jokes and hints hidden in the program, so it was an entertaining as well as educational experience.  The main file itself is 2914 lines long though; it is broken up into several functions admittedly, and those who have actually seen the code that I write may quite correctly predict that about a third of that length is in comments, but still quite a bit of material to sort through. 

I have also started work on the actual programming.  Currently, everything is divided into three packages.  The environment itself consists of Room instances, convenient subdivisions of the area that may not always correspond to actual rooms.  (I suppose the term "room" is more due to tradition than anything else.)  Within these rooms may exist Item instances; items are what the player character can actually interact with in a variety of ways.  Several Person instances will also be present; these are carbon-based living organisms that the player may also interact with.  This is a bit of a change from the original Lisp program in which people were treated as items in their specific rooms; to avoid human rights violations, people are now distinct from items

The actual player character is technically a Person as well.  However, it seems more convenient to have the data on the protagonist available for the rest of the program to access: if the player is just another Person instance, then the player instance might get lost in a Room somewhere and the program would have no idea of how to find the player again.

Of the three basic classes described above, I have completed Item, started on Person, and have not started Room.  I have been partially successful in implementing test-driven development; I did write the test for the Item class immediately after writing the class itself.  My handwritten notes were all for the classes themselves, not for the tests, so starting on the classes seemed more natural than testing.  The Room class is not yet started though, so hopefully I will remember to try working on the tests first this time. 

If all goes well, I should be able to set up the project site on Google Project Hosting over the weekend.  As suggested in the comments on my original post, I will try working with Git, which should be an interesting and hopefully beneficial experience.

Project for ICS 111 (Title Pending)

This semester, I will be serving as the lab assistant for one of the ICS 111 courses at the University of Hawaii at Manoa. While this course is for Java, and while it is still programming that will help keep my limited skills in practice, it is not exactly pushing me to the limits of my abilities. Doing the assignments that the students themselves are doing does take some time, but it is mostly material that I already know well (in some cases, the assignments are identical to those that I did several years ago when I was taking ICS 111). In order to improve, I will have to continue doing new work that will challenge me.

Aside from Java, the various technologies that I have used over the past year have essentially not been touched since December. I have done some programming since then, but never anything that really required build tools or project management or anything of the sort. I have often asserted that these technologies are extremely beneficial for the software engineer (except for PMD and Checkstyle—I remain bitter on that matter), and I need to maintain my ability to use those tools.

At the same time, many of the students taking ICS 111 require help, both on theory and on programming. This is especially true due to the exams interspersed throughout the semester: while a skilled programmer can safely ignore a fair amount of theory on the programming assignments without any noticeable difficulties, such a course of action will undoubtedly prove detrimental on exams. (At least, that is what usually happens to me.) Something that could help on the material that the students need to study could be very useful, especially if presented in an entertaining, engaging manner.

I also have a vast array of old programming projects that I have been meaning to work on. In particular, the oldest (and thus first in the queue) is a Lisp project for school from Fall 2009 in which my group created an adventure game similar to the Colossal Cave Adventure game (http://www.rickadams.org/adventure/). The main character was a Computer Science student who had to take an exam and complete a programming assignment in Lisp. While we did get credit for the project, there were several issues that we failed to address due to time constraints. The protagonist lacked an inventory to hold objects in, and there was at least one area of the game that I wanted to add. Unfortunately, over the years my knowledge of Lisp has deteriorated to the point where working with Lisp is currently impractical.

In order to meet all of these needs, I intend to finish the aforementioned game. As it contains some information specific to the class that I was taking at the time, some adaptation will be necessary in addition to the expected difficulties in translating from Lisp to Java. For example, the programming assignment in the original game was to be written in Lisp; in this new version, the assignment will be in Java. Furthermore, the original Lisp program was a text-based game; the Java version should utilize the Swing components, both for usability and because the ICS 111 students will be learning about said components themselves. While I lack the skill necessary to create a full graphical environment with animated characters and visual environments and such, something as simple as placing text input and output into a JFrame is well within my abilities. The end result of this work will hopefully be a program that will both help the ICS 111 students in their studies as well as provide an example of coding style.

I intend to use many of the tools covered previously on this blog. Eclipse, as usual, will serve as my primary IDE, though I will use Notepad++ for non-Java files and possibly jGRASP since that is what the ICS 111 students are currently using. The project files will be stored on Google Project Hosting as well on my personal computer; while this project will not use anywhere near the full potential that Google offers, the ability to create and monitor Issues has and will work well with Issue Driven Project Management. In conjunction with Google Project Hosting, I will use TortoiseSVN again to commit changes to the project; I do not anticipate needing to update my local copy from the repository, but having that option may prove useful in time. I will also continue using Ant to perform various testing and create distribution files. Regarding testing, JUnit and Jacoco will be of use.

On the other hand, there are some tools that I will not have access to. The most notable of these is Jenkins; since this is a private project not associated with WattDepot, I imagine that the Jenkins server would not be available for use. Though I will use Checkstyle and PMD with some reluctance, I will have to learn to adjust both of them to fit my personal guidelines. The same is true for Eclipse, though as I have already taken care of the formatting in Eclipse this does not really count as much of a task.

While I will try to follow Issue Driven Project Management in working on this project, certain circumstances will make this much more difficult. Of course, since this is an individual project all of the issues will necessarily belong to me (I was born before multiple processors were common, so naturally I would only be able to support a single personality). As a consequence of this lack of partners, there is no need to have meetings every couple of days to discuss progress. Although my schedule is very light in theory—only twelve credits this semester and an average of twelve hours per week at work—the fact that I am serving as a lab assistant easily takes up six hours per week just counting my time in the lab, and unfortunately these hours are spread out across the week so that I am constantly busy. Issue Driven Project Management involves short tasks that should only take a few days at most to complete; however, as of present there is no guarantee that I will be able to work on the project save on the weekends. Nonetheless, I shall endeavor to follow the guidelines of Issue Driven Project Management to the greatest extent possible.

As this project is still in the planning stage, there are no links available yet; in particular, the site on Google Project Hosting has not yet been created. However, this should be rectified in the near future.