No Open Blockers

The first project of the semester was due last Thursday, which meant it was time to find out if CodeTurtle is actually, well, useful. I knew from the beginning that there was always a very real chance that it would be simpler to just grade by hand. I figured that chance revolved around two areas: the difficulty or lack of flexibility in the project checker plugins themselves or a clunky, inflexible user interface.

I’m really happy to find that, at least for my purposes, CodeTurtle worked extremely well. In all honesty, it actually worked better than I would have expected. As I was writing it I was surprised how quickly I was able to get stuff done in Swing, and short of the insanely awful detailed report, I used all of the features (benefits of writing a program for yourself I suppose). Squeezing in the HTML summary report right before the semester turned out to be huge since I was able to simply print them out and be done.

The project was, not surprisingly this early in the semester, pretty simple. I gave out a class with a main method making calls to some methods I stubbed out. The students’ job was to implement those methods, the idea being to make sure everyone has some basic knowledge of looping, conditions, reading/writing files, and so on.

My checker ended up using a lot of reflection (all through utilities provided by CodeTurtle, so the code was actually pretty short). In hindsight I could have made calls directly to the class I provided, compiling against my implementation, and letting CodeTurtle’s class loader creation automatically take care of using the student’s version of the class.That will be the approach for most of the interface based projects, so I’ll have my chance in the future.

In a way, I feel a bit of a sense of relief for the rest of the semester. Grading projects was a nightmare by the end of the last semester, so knowing CodeTurtle survived it’s first trial makes me optimistic about how things will go come April.

Some specific notes on things the good, the bad, and the ugly (*cough* detailed report *cough*) after the jump.

• I badly need to implement saving/loading of grade books. I added quite a few custom comments and grade item updates that I’m afraid to close CodeTurtle right now for fear I’ll need to make a change to one. I know how to get around the URLClassLoader not serializable issue, I just have to look up the syntax and take care of it. Hopefully I can squeeze that in before the next project.
• I need to loosen the checking when double-clicking files in the files view to load as source. I require a README file in my project submissions, and being able to view that from within CodeTurtle will be nice, especially since I found myself doing all of the students’ code reviews from within it.
• The detailed report sucks. Admittedly it was a first pass, but I don’t know what I was thinking when I figured I’d print that out. That said, the quick summary report I threw together for 0.2 works really well, so I’d like to spend some more time refining that.
• I’d definitely like to add a progress bar while loading. It’s fine for me since I know to not click anything, but I’m afraid others will start banging around and get UI errors. That said, compiling 11 student projects didn’t take nearly as long as I feared, which is good.
• Dealing with file reading and writing is a pain in the ass. There’s no clean way to change the working directory in Java, so I had to give instructions on extra steps to take. That said, I should probably just suck it up and teach them how to load a file from the classpath (which really is the better way of doing it anyway) and at least for reading, this becomes a non-issue.
• The GradeItem constructors need to be cleaned up. It’s a clear sign that they suck when the author can’t even remember how to use them.
• Along similar lines, I need to change the distribution to include a source JAR. That way I can add in the sources to my checker project and actually have access to the javadoc.
• Ultimately, I should provide a way to kill the classloaders and reload the project checker plugins. During development of the checker I kept having to bounce CodeTurtle to test it, which was mildly annoying.
• It’d be really cool if I accepted the checker and submission directories as command line parameters so when bouncing CodeTurtle it could automatically create the grade book, saving that step in the UI. Always nicer to do things at the command line than the UI.
• The dialog text areas need a quick revisit for line wrapping and scroll panes. I thought I was pretty good about wrapping text areas in scroll panes, but the few times I didn’t it was very apparent.
• The edit a grade item dialog needs a little love. Admittedly, it was part of a last minute decision that the in-table editing sucked, so it could use a quick revisit for auto-population (and a title on the dialog, how did I miss that one?)
• Until I get printing implemented (man is that gonna be sweet), the project reports should be saved to the checker directory rather than (or at least in addition to) running around to every student directory loading and printing them.
• I ran into a headache trying to cleanly convert an Object reference to a string when the reference contained an array of primitives. I have a bit of a hack in there now that only fell apart for an int[][], which really, I don’t imagine using all that much anyway. Still, this automatic string generation for result messages could probably use a little love.
• I need a logo! I have one image I’m thinking of using, but it’s not completely what I want.