Before I go on, I want to welcome Scott and Emily to the project. Scott was a contributor on this release, fixing some critical issues when running on Windows and providing the very cool printing support (a feature that coincided with me running out of paper at home and thus failing to print out the last project of the semester anyway). Emily is just starting out and we’re deciding on where she is going to focus her efforts. I’m psyched to be able to work with them and appreciate the support.

A big improvement with this release is that I finally had the discipline to sit down and begin to write some documentation. I ripped out the hardcoded HTML file from CodeTurtle and began work on a wiki specifically for the project:

http://codeturtle.noopenblockers.com

It’s a work in progress. What a loaded statement, it’s always going to be a work in progress. That’s one of the appeals of using a wiki, you get to use the excuse that “I’ll add that to the wiki soon” since all of the information is stored online.

The wiki has a mixed audience. I’m trying to jump to the quick parts of how to download and run since that’s what most people will be interested in. But I’m also catering to my students who want to contribute (as well as some, um, academics that haven’t actually worked on a real software project and sadly don’t know how to use these things). So I took some extra steps to explain concepts such as source control systems and build systems. This will pay off anyway, since I do a lecture on these things in class but never had a central reference location I could point them to. It’s also got my first feeble attempts at a logo (I’m thinking of blogging on its creation process in the future). My lack of creative skills is astounding.

Along the same lines, since there has been a growing interest lately, I took a number of steps taken to help introduce new users. I flushed out the sample project a bit more to make for a better demo. On the first run, there is a guided setup that will help the user set up the compiler used in the grading process and automatically configuring the sample project. I don’t know why, but I find writing that sort of thing to be a lot of fun.

As usual, the latest release can be found at the SourceForge site: https://sourceforge.net/projects/codeturtle/.

I’m actually including the release notes in this post since there was some pretty cool shit done since 0.3.

New and Cool Stuff

• Added current project printing support (courtesy of Scott).
• Added progress bar to indicate the work done towards creating a gradebook (compiling submissions, grading, etc.).
• Added toolbar to UI to support quick access to common functions.
• Added user preferences support.
• Changed handling of command line options. If any of the gradebook options are specified, the create gradebook dialog will automatically be displayed and prepopulated with the command line values.
  • The “-c” option has been renamed to “-g” to reflect the change in terminology from “project checker” to “project grader”.
  • The “-c” option now clears the Java preferences node for CodeTurtle.
  • The command line options can be displayed by passing the “-?” flag.
  • The “–sample” option will populate the gradebook creation dialog with the included sample project
• Better flushed out sample project, including cleaning up their representation in the source control system and adding build scripts to set up their state.
• Added “first run” feature that will perform installation and sample steps to ease new users into configuration and using CodeTurtle.
• Bug fixes (hopefully more fixed than new ones introduced).

For a while, I’ve wanted to add user preferences to CodeTurtle. My motivation was less letting the user explicitly set certain values and more about adding in polish to the UI. For instance, I wanted to remember the last position and size of the UI if the user moved it (rather than always starting maximized or something like that). Little things like that are somewhat taken for granted until you use a UI that doesn’t have them, at which time phrases like “This sucks” tends to come out. Besides, it seemed like a fun challenge.

I thought I was going to have to choose between using a simple key/value pair serialized to disk or actually adding in an XML framework for more flexibility and dealing with that headache (or some other unholy third option). What I found out was how little I actually knew. The Java preferences framework gives you both for pretty much free.

Java will keep track of storing the preferences in wherever it makes sense based on the native operating system (for instance, they are stored in a directory named .java in the user’s home directory on Linux). The format is XML, but it’s actually not necessary to know that since I don’t have to do squat to actually interact with it.

To load the preferences, it’s a one line call:

Preferences preferences = Preferences.userNodeForPackage(this.getClass());

After that, it’s simple getters to get your values. The Preferences object even has some really nice polish on the API letting you use type specific getters (getString, getBoolean, etc) and specify a default value. Setting values uses a put notation that functions like the Map interface.

int windowWidth = preferences.getInt("window.width", 800);
...
preferences.putInt("window.width", frame.getWidth());

That’s it. That’s all you need to cover reading/writing the file, determining the proper home directory location, and serializing/deserializing the XML store of the data. My daughter could write code to use this if she could stop drooling long enough to not short circuit the keyboard.

You technically don’t even have to worry about saving, it will periodically do that for you. However, if you want to explicitly trigger a save, simply call the flush() method on the preferences object.

I even built in a command line option to CodeTurtle to clear the user preferences, which is in itself a simple call:

preferences.removeNode();

I was happy to see that my design of having a central data manager passed throughout the GUI came in handy here as I was able to stuff the preferences object into it and access it from virtually anywhere else in the UI. At that point, it was just a matter of figuring out what I wanted to store. In the beginning it was things like the window placement, window size, and tab placement. Tonight I decided to add a flag indicating if it’s the first time the user is running CodeTurtle. If it is, I enter a bit of a “demo mode” where the sample project included with the CodeTurtle distribution is automatically loaded to more easily show off its complete awesomeness.

I still have other (reasonable) ideas on things I want to stuff into user preferences. Rather than requiring an environment variable to indicate the compiler path (i.e. TURTLE_JDK_HOME, JAVA_HOME), I’d like to move that to the user preferences to make it easier to see where the value came from. The real challenge at this point is trying to not abuse this new found power and stuff every imaginable value into it.

My annoyingly over-engineered (and pretty much completely unnecessary) wrapper on top of the Java preferences framework can be found in CodeTurtle’s SourceForge repository.

Like I said, I’ve now graded four projects this semester using CodeTurtle, so a number of the changes were made directly as a result of something that was actively annoying me. For instance, while writing the project grader, I found myself restarting and reloading the project a number of times. To facilitate that, I added some minimal command line support to automatically create the grade book with the proper grader and submissions values (I’d also like to add a “Reload grader” option in the near future).

The biggest change was gutting and rewriting the project grader APIs. I’ve written about some of the changes before and I want to write up a much better tutorial on writing a project grader in the near future (I know, I know, everything I want to do is in the “near future”), so I won’t talk about too many details right now. I will say that the new APIs feel a lot cleaner and have added quite a bit of flexibility in the way I do the testing of the student submissions.

The sample project is a bit lame and doesn’t really showcase all of what CodeTurtle can do, I realize that. I need to find me an intern or a monkey or a student in dire need of extra credit to flush that out for me.

Oddly, as I look back 0.2 was released right near Spacewalk 0.4, and now this one happens to line up with 0.5. I guess all that talk in work about releasing things inspires me.

CodeTurtle 0.3 can be downloaded at the project’s site on SourceForge.

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.
]]> http://noopenblockers.com/2009/01/25/codeturtle-in-action/feed/ 0 http://noopenblockers.com/2009/01/17/codeturtle-02-released/ http://noopenblockers.com/2009/01/17/codeturtle-02-released/#comments Sat, 17 Jan 2009 19:58:43 +0000 Jay http://notebook.novasurv.com/?p=235 The first project for my class is due next week, so I had to finish flushing out the minimum functionality I’ll need to grade it. This is actually how I suspect the rest of the semester will go, releasing small versions with enhancements to the checker APIs based on what I need to grade the next project in the semester.

So, first the good news. Below are the release notes with the additions in this version:

• Ability to automatically compile student projects at grade book creation time. Compiled classes will be put in the respective student’s project directory.
  • Option to add a grade item for success/failure of compilation
  • Option to delete existing compiled classes
• The user.dir property is now set prior to grading a project, scoping the execution of the student’s code to the project directory in which it is found.*
• Added ability to add custom notes on each grade item.
• Added grade item editor dialog for changing the awarded points, result, or notes, launched by either double-clicking or from the right-click menu (editing the awarded points directly in the table is still supported).
• Added HTML based “Summary Report” to display a high level overview of how points were accumulated, detail on any failed test cases, and all additional comments. The goal behind this initial implementation is a report to print and distribute to the student.**

* The user.dir in particular is to support the reading/writing of files done in my first project of the semester.

** The existing plain-text report is still available, however only the HTML report will be saved to the student’s directory. In the future I hope to add more flexibility around selecting which reports to generate, print, and save.

Additionally, the project checker APIs were enhanced to support the following.

• Added: Utility (checkFileExists) to check that a file was included in the submission.
• Added: Utility (findFile) to locate a file inside of the student’s project directory.
• Added: Utility (checkManual) for adding a manually graded item.
• Added: Utility (classExists) to return whether or not a class exists in the project.
• Changed: signature of “findClass” to return the class object.

It’s quite a bit more than I expected to get done by the start of the semester, which I’m pretty happy with. Alas, there are still many things I want to do. Printing remains my white whale as I just don’t feel like dealing with getting it set up. This version will save an HTML report to each student directory, so for now I’m content opening them individually and printing them. I also took some steps towards saving/loading grade books, but ran into an issue since URLClassLoader isn’t serializable. I know how to get around it — it should be as simple as implementing a custom serialization with Externalizable — I just didn’t feel like putting the time in and then adding the UI hooks for them and, again, I don’t see me needing it for the first project.

CodeTurtle 0.2 can be downloaded at the project’s site on SourceForge.

]]> http://noopenblockers.com/2009/01/17/codeturtle-02-released/feed/ 0 http://noopenblockers.com/2009/01/02/right-clicking-tables-in-swing/ http://noopenblockers.com/2009/01/02/right-clicking-tables-in-swing/#comments Fri, 02 Jan 2009 18:07:48 +0000 Jay http://notebook.novasurv.com/?p=198 A lot of the data in CodeTurtle is tabular. Inevitably, I ended up wanting to have a right-click menu for operations on a particular row. The problem is, the default behavior for a JTable doesn’t automatically select the row under the cursor on a right-click. After a bit of poking around, the solution was pretty simple. The following example is a mouse adapter assigned to the table itself. The purpose of this particular implementation is to display a popup menu under the cursor for operations on the selected row. This code allows the user to right-click any row to both select it and then display the menu of operations to execute against it.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

private class PopupMenuListener extends MouseAdapter { public void mousePressed(MouseEvent e) { showPopup(e); }   public void mouseReleased(MouseEvent e) { showPopup(e); }   private void showPopup(MouseEvent e) {   if (e.isPopupTrigger()) {   // Select the row under the cursor so we know // which to edit or delete Point p = e.getPoint(); int rowNumber = rowAtPoint(p); ListSelectionModel model = getSelectionModel(); model.setSelectionInterval(rowNumber, rowNumber);   // Display the popup popupMenu.show(e.getComponent(), e.getX(), e.getY()); }   } }

This can be seen in action (at least as of the time of writing) in the CommentsTable.java file.

]]> http://noopenblockers.com/2009/01/02/right-clicking-tables-in-swing/feed/ 0 http://noopenblockers.com/2008/12/29/codeturtle/ http://noopenblockers.com/2008/12/29/codeturtle/#comments Mon, 29 Dec 2008 18:22:08 +0000 Jay http://notebook.novasurv.com/?p=189 Grading sucks.

Don’t get me wrong, I love teaching. And I love getting to see how students approach problems. I tend to leave my projects open-ended enough where they can express a bit of their own creativity into the solution. I like having small classes since I can spend a good amount of time offering suggestions on their implementation in addition to their results (my students can vouch for this, I usually provided 2-3 pages worth of comments that were unrelated to a particular grade item).

But coming up with an actual consistent, subjective, quantified number grade is a pain in the ass. I end up with a big checklist of things to look for and I am constantly having to go back and recheck projects to make sure I ran a particular test or to see how I scored a certain shortcoming.

I thought about writing my own test cases in one of the existing test frameworks (such as JUnit) to automate some of the process. The concept is sound, but in the end I was trying to shove the square peg into the circle hole; there would still be a lot of manual intervention to interpret the results and turn it into a grade.

I looked around for a solution. From what I saw, there really isn’t a solid application to facilitate what I wanted. So, I decided to write one.

The idea started out small: Point my application at a bunch of student projects and have it run tests and return me a grade. That would give me a very solid and consistent basis on which to derive the grade, allowing me to spend more time providing manual comments on the code or approach itself. I would just need a pretty flexible API to support the types of tests and introspection I wanted so it could be used to grade multiple projects easily.

Not surprisingly, once I started writing it more and more ideas started to take shape. I realized I could have my application, which I named CodeTurtle (more on that later), generate the report to return to the student as to which tests passed or failed. If I was going to have CodeTurtle generate the report, I needed a way to add my comments in, so comment functionality was written. Since most of my comments were based on a code review, I wanted to be able to view the students’ source files as well and then tie that into the comments subsystem to skip the copy/paste need when commenting on particular code snippets. And so on…

Also not surprisingly, I open sourced it at SourceForge. Ideally, I’d love to get other teachers, both at Villanova and eventually other schools, involved with both usage and development. But I also wanted to give some of my former students an opportunity to get some solid, real-world programming experience before they graduate.

I built the 0.1 version and made it available to download from the SourceForge site for people to start playing around with. Being the first release there’s obviously a ton of more work to do, but I included a sample project to demonstrate the types of student submission validation I’m going after (screenshots available as well). I also included some starting documentation, which will continue to get flushed out as I get the time. I’ve also got the interest of at least one friend of mine, so getting it off my laptop into a public area soon was important.

Feel free to contact me through SourceForge (mailing list or forums) or e-mail me directly if anyone is interested in either learning more about it or wanting to contribute.

Oh, and since I’ve been asked this a dozen times already and don’t have a FAQ up yet, I’ll just toss this out now. The name “CodeTurtle” came from the fact that I really didn’t have a good idea for a name. One night while working on it I looked up from my laptop and asked my 18 month daughter what I should call the project. The newest word at the time was “turtle” which sounded as good as any for a project name. And so, CodeTurtle was born. It’s not the most descriptive name out there, but it’s also not the worst named open source project I’ve ever heard of.

]]> http://noopenblockers.com/2008/12/29/codeturtle/feed/ 0