This was discovered in RB369, the Computer Science lab, and shared on the department's Facebook page.
I wonder if I can include this as a student evaluation in my promotion and tenure materials?
Wednesday, November 30, 2011
With great power comes great responsibility
I wonder if I can include this as a student evaluation in my promotion and tenure materials?
Monday, November 14, 2011
All the UML you need to know
Each semester, when I teach CS222, I give a one-class lecture on UML class and sequence diagrams. It always goes the same: I introduce some ideas, then give the students some time to draw some diagrams, and I critique them. It works well, except for the lecturing part. That part is boring, for me and for the students.
This year I am trying something different. I have created a Web site off my BSU space called "All the UML You Need to Know." Actually, I've only half-created it. We already discussed sequence diagrams in class earlier this semester, so I didn't take the time to write that section yet.
I sent out the link to my students earlier today. Tomorrow, we'll talk about class diagrams, and I will direct them to this site as a resource as they play with the ideas. It took about eight times as long to write as it does for me to talk through it, which is actually not as bad as I had feared. Hopefully this will save me time in the long run, but more importantly, it will give the students accurate notes about the parts of UML I expect them to know.
This year I am trying something different. I have created a Web site off my BSU space called "All the UML You Need to Know." Actually, I've only half-created it. We already discussed sequence diagrams in class earlier this semester, so I didn't take the time to write that section yet.
I sent out the link to my students earlier today. Tomorrow, we'll talk about class diagrams, and I will direct them to this site as a resource as they play with the ideas. It took about eight times as long to write as it does for me to talk through it, which is actually not as bad as I had feared. Hopefully this will save me time in the long run, but more importantly, it will give the students accurate notes about the parts of UML I expect them to know.
Friday, November 11, 2011
Social networks, fairies, and Club 369
One of the CS222 project teams is working on Club 369: The Game. "Club 369" is a reference to the Computer Science undergraduate lab, RB369, and the camaraderie that the space affords. The game is a Computer Science quiz constructed of multiple-choice questions.
On Thursday, the team gave their milestone presentation. Here's a screenshot of their executable release.
That guy on the bottom-right is "The Dr. G. Fairy". Let's take a closer look...
Clicking on him removes two of the incorrect choices, leaving the player with a 50/50 chance if they guess. Needless to say, this presentation got quite a reaction from the other students. When a student asked, incredulously, "Why?" a team member responded, "He's Dr. G. He helps you learn Computer Science." This is the nicest complement I've received in some time!
After class, one of the students posted the picture to the Ball State Computer Science Facebook Group, where it became a hit. It may seem a bit silly, but as I see it, it's a great success for the department. We created the Facebook group to help foster a sense of community among our students and alumni, and we've had some luck with members sharing informational links, job opportunities, and the like. The fact that students feel they can share this kind of fun content as well shows that we have succeeded in our goal. (I had to do a bit of legwork to understand the Butterfree and Hey! Listen! references in the comments, but this made it even more fun for me.)
Of course, I immediately changed my Facebook profile picture to the Dr. G. Fairy. This led some old friends to reminisce about the classic "Get Paul some shirts with color" Flash animation—a reference to my proclivity to wear black when playing at Higher Grounds Coffeehouse. I think we all assumed the animation was lost to the ages. My clever and creative friend Matt was able to find the old image and recreated the animation with a brand new feature.
On Thursday, the team gave their milestone presentation. Here's a screenshot of their executable release.
 |
| Club 369: The Game, Milestone #1 |
 |
| The Dr. G. Fairy |
After class, one of the students posted the picture to the Ball State Computer Science Facebook Group, where it became a hit. It may seem a bit silly, but as I see it, it's a great success for the department. We created the Facebook group to help foster a sense of community among our students and alumni, and we've had some luck with members sharing informational links, job opportunities, and the like. The fact that students feel they can share this kind of fun content as well shows that we have succeeded in our goal. (I had to do a bit of legwork to understand the Butterfree and Hey! Listen! references in the comments, but this made it even more fun for me.)
Of course, I immediately changed my Facebook profile picture to the Dr. G. Fairy. This led some old friends to reminisce about the classic "Get Paul some shirts with color" Flash animation—a reference to my proclivity to wear black when playing at Higher Grounds Coffeehouse. I think we all assumed the animation was lost to the ages. My clever and creative friend Matt was able to find the old image and recreated the animation with a brand new feature.
Rubric-based self- and peer-evaluation on team programming projects
I have written before about grading rubrics, and I am taking this opportunity to share some of my recent developments here. In my game programming class (CS315), I have eleven students working together on one project. We're using Scrum, and it's still going well. The early part of the semester was ungraded, formative, small-project work, and I found myself needing a way to assign grades to the students. It may be worth mentioning that I don't actually want to assign grades to them, but it is a requirement of the course, and so I must do it responsibly.
I happened to stumble across a rubric I created in 2008, before my blogging days, while I was cleaning up my Web space. As I recall, this was an amalgam of several other rubrics I had found on the Web with an ounce of invention. This was my inspiration to create the following rubric:
I created this after the team's first sprint, and parts of it are reactions to problems the team was having. For example, in the team's first sprint retrospective, they identified that many had spent inordinate time on aesthetic issues that were unrelated to the user stories. Hence, there is a distinction between those technical contributions that facilitate success and those that do not. Note that the numbers across the top relate to my triage grading approach; some day I will write a blog post about my experiences with it, but for the time being, suffice it to say A=3, C=2, D=1, F=0.
I shared this rubric with the team during Sprint 2, and at the end of the Sprint, I asked each person to do a personal evaluation. This was designed as a formative evaluation for the student as well as a trial run of the rubric. From reading the students' self-evaluations, I think the instrument worked as intended, and we're going to do self- and peer-evaluations at the end of this sprint.
In my other course (CS222), students are working in teams of four on six-week projects of their own design. They just finished their mid-project milestone presentations, and I've modified and distributed the rubric to this other group as well. I've highlighted those cells that have changed.
These students are not using and are not familiar with Scrum, and so the Scrum-specific references needed to change. I am not that happy with the articulation of participation above, in part because we invested a lot of time on test-driven development, and I fear the students will be confused about separation of testing and implementation. The "communication" entry is clearly influenced by the idea of the Daily Scrum, but I have not previously suggested this particular reporting strategy to the students. My hope is that by asking them to conduct rubric-based self- and peer-assessments, they will gain some insight into better ways to organize themselves. As with the game programming students, I am using this first pass as a formative assessment, and also as an instrument to help me identify teams that are having problems with team members—an unfortunate but oft-inevitable situation.
The students in CS222 had their first group experience with rubric-based evaluations this week when they evaluated each others' milestone presentations using this instrument:
I printed these on small slips of paper. On Tuesday, we had four presentations, so I instructed the students to pick up four slips as I talked through the structure and purpose of the rubric. On Thursday, we had five presentations, so I left the slips in the same place in the back of the room and I put on some mood music.
I was a little disappointed that none of them stopped to tell me how incredibly clever this was.
I happened to stumble across a rubric I created in 2008, before my blogging days, while I was cleaning up my Web space. As I recall, this was an amalgam of several other rubrics I had found on the Web with an ounce of invention. This was my inspiration to create the following rubric:
| 3 | 2 | 1 | 0 | |
|---|---|---|---|---|
| Commitment | Attended all scheduled team meetings or notified the team of absence. | Missed team meetings, with notifications, with enough regularity to be problematic. | Missed one or more team meetings without notifying the team. | Regularly missed team meetings without notifying the team. |
| Participation | Contributed to sprint planning, sprint review, and sprint retrospective meetings. | Did not contribute to one of the following: sprint planning, sprint review, or sprint retrospective meetings. | Did not contribute to two of sprint planning, sprint review, and sprint retrospective meetings. | Did not contribute to any of sprint planning, sprint review, and sprint retrospective meetings. |
| Communication | Clear standup reports on what was accomplished, what is planned, and identification of impediments, to allow the team to continue to make progress. | Some unclear standup reports that inhibit team progress. | Regularly unclear standup reports that inhibit team progress. | Did not give standup reports. |
| Technical contributions | High quality technical contributions that facilitate success of the team. | High quality technical contributions that do not directly facilitate the team's success. | Low quality technical contributions that frequently require redress by other team members. | Low quality technical contributions that inhibit success. |
| Attitude and Leadership | Listens to, shares with, and supports efforts of others, and actively tries to keep the team together. | Listens to, shares with, and supports the efforts of others. | Frequently fails to listen, share, or support teammates. | Displays an antagonism that inhibits team success. |
I created this after the team's first sprint, and parts of it are reactions to problems the team was having. For example, in the team's first sprint retrospective, they identified that many had spent inordinate time on aesthetic issues that were unrelated to the user stories. Hence, there is a distinction between those technical contributions that facilitate success and those that do not. Note that the numbers across the top relate to my triage grading approach; some day I will write a blog post about my experiences with it, but for the time being, suffice it to say A=3, C=2, D=1, F=0.
I shared this rubric with the team during Sprint 2, and at the end of the Sprint, I asked each person to do a personal evaluation. This was designed as a formative evaluation for the student as well as a trial run of the rubric. From reading the students' self-evaluations, I think the instrument worked as intended, and we're going to do self- and peer-evaluations at the end of this sprint.
In my other course (CS222), students are working in teams of four on six-week projects of their own design. They just finished their mid-project milestone presentations, and I've modified and distributed the rubric to this other group as well. I've highlighted those cells that have changed.
| 3 | 2 | 1 | 0 | |
|---|---|---|---|---|
| Commitment | Attended all scheduled team meetings or notified the team of absence. | Missed team meetings, with notifications, with enough regularity to be problematic. | Missed one or more team meetings without notifying the team. | Regularly missed team meetings without notifying the team. |
| Participation | Contributed to project planning, implementation, testing, and milestone presentations. | Did not contribute to one of the following: project planning, implementation, testing, and milestone presentations. | Did not contribute to two of the following: planning, implementation, testing, presentation. | Did not contribute to three or more of the following: planning, implementation, testing, presentation. |
| Communication | Clear reports on what has been accomplished, what is in progress, and what stands in the way, thereby facilitating progress. | Sometimes is unclear about what has been done, what is in progress, and what stands in the way, creating minor impediments to progress. | Is regularly unclear about what has been done, what is in progress, and what stands in the way, creating significant impediments to progress. | Communication patterns directly disrupt team progress. |
| Technical contributions | High quality technical contributions that facilitate success of the team. | High quality technical contributions that do not directly facilitate the team's success. | Low quality technical contributions that frequently require redress by other team members. | Low quality technical contributions that inhibit success. |
| Attitude and Leadership | Listens to, shares with, and supports efforts of others, and actively tries to keep the team together. | Listens to, shares with, and supports the efforts of others. | Frequently fails to listen, share, or support teammates. | Displays an antagonism that inhibits team success. |
These students are not using and are not familiar with Scrum, and so the Scrum-specific references needed to change. I am not that happy with the articulation of participation above, in part because we invested a lot of time on test-driven development, and I fear the students will be confused about separation of testing and implementation. The "communication" entry is clearly influenced by the idea of the Daily Scrum, but I have not previously suggested this particular reporting strategy to the students. My hope is that by asking them to conduct rubric-based self- and peer-assessments, they will gain some insight into better ways to organize themselves. As with the game programming students, I am using this first pass as a formative assessment, and also as an instrument to help me identify teams that are having problems with team members—an unfortunate but oft-inevitable situation.
The students in CS222 had their first group experience with rubric-based evaluations this week when they evaluated each others' milestone presentations using this instrument:
| Presentation requirement | Satisfactory (3) | Probationary (2) | Unsatisfactory (1) | Unacceptable (0) |
|---|---|---|---|---|
| Executable release | Stable and appropriate demo of executable release | Unclear demonstration of stable executable release | Unstable executable release | No demo |
| Milestone #1 Estimate | Clearly met milestone estimates | Clearly met a reasonable subset of milestone estimates | Did not meet an adequate subset of milestone estimates | Progress on initial estimates was not addressed |
| Milestone #2 Estimate | Clear presentation of well-articulated estimates for next milestone | Clear presentation of poorly-articulated estimates for next milestone | Unclear presentation of poorly-articulated estimates for next milestone | Milestone #2 estimates not addressed |
| Software architecture | Good presentation of reasonable software architecture | Decent presentation of reasonable software architecture | Unclear or awkward software architecture | No presentation of software architecture |
I printed these on small slips of paper. On Tuesday, we had four presentations, so I instructed the students to pick up four slips as I talked through the structure and purpose of the rubric. On Thursday, we had five presentations, so I left the slips in the same place in the back of the room and I put on some mood music.
I was a little disappointed that none of them stopped to tell me how incredibly clever this was.
Sunday, November 6, 2011
Morgan's Raid on CD
We recently received a request to make Morgan's Raid available to a school that has blocked Internet connections from its lab machines. Morgan's Raid was built for distribution via Java Web Start (JWS), which simplifies the process of dealing with native libraries. However, as the name implies, the technology was designed for computers with Web connections. Distributing as an executable jar is not possible because they do not adequately handle native libraries.
The JNLP file contains all of the configuration information for JWS. This includes codebase, through which JWS determines where to find referenced resources. The Morgan's Raid codebase points to the server that hosts the jar files, for example. Turns out that if you leave out the codebase, it will default to the same path as the JNLP file itself.
My next step, then, was to revise the Morgan's Raid JNLP file for local files. I created a CD containing all the requisite jar files and the revised JNLP file. Running the JNLP file off of the CD almost solves the problem. The game runs, and it creates a desktop and start menu shortcut in the process. However, it also records the fact that the jar files came from the optical drive. As a result, the game will then only run with the CD in the drive, even though all the jars have been copied to Java's cache: JWS still tries to check the codebase to see if there's any changes to the files or configuration.
The problem is easily solved by having the user copy the CD contents to any folder on their hard drives and running the JNLP from there. Now it's this path that is recorded by JWS, so using the desktop shortcut or start menu shortcut will happily run the application locally. This gets the desired result that I can hand someone a CD, and they can put it on as many machines as desired, without my having to fiddle with installation software beyond JWS. (I guess that changing the location of those files would break the installation, in the same way that removing the CD did before, but I did not verify this.)
With my CD experiments successfully concluded, and after a little help from my department's friendly system administrators, the result looks like this:
I found it deeply satisfying to hold this disc. Physical media doesn't change the existential state of the software system, but there's something about holding this disc in my hands that made the software more real.
As I was printing the CD, a sysadmin asked, "Does it have to be on CD?" Her reason for asking was that she had blank white DVDs, on which the printed label would be more crisp, but I thought she meant, "Can't it be on something other than a disc, like a thumb drive?" I laughed aloud when I realized that I had never considered anything but an optical disc for this project, because, you know, software comes on discs!
The JNLP file contains all of the configuration information for JWS. This includes codebase, through which JWS determines where to find referenced resources. The Morgan's Raid codebase points to the server that hosts the jar files, for example. Turns out that if you leave out the codebase, it will default to the same path as the JNLP file itself.
My next step, then, was to revise the Morgan's Raid JNLP file for local files. I created a CD containing all the requisite jar files and the revised JNLP file. Running the JNLP file off of the CD almost solves the problem. The game runs, and it creates a desktop and start menu shortcut in the process. However, it also records the fact that the jar files came from the optical drive. As a result, the game will then only run with the CD in the drive, even though all the jars have been copied to Java's cache: JWS still tries to check the codebase to see if there's any changes to the files or configuration.
The problem is easily solved by having the user copy the CD contents to any folder on their hard drives and running the JNLP from there. Now it's this path that is recorded by JWS, so using the desktop shortcut or start menu shortcut will happily run the application locally. This gets the desired result that I can hand someone a CD, and they can put it on as many machines as desired, without my having to fiddle with installation software beyond JWS. (I guess that changing the location of those files would break the installation, in the same way that removing the CD did before, but I did not verify this.)
With my CD experiments successfully concluded, and after a little help from my department's friendly system administrators, the result looks like this:
I found it deeply satisfying to hold this disc. Physical media doesn't change the existential state of the software system, but there's something about holding this disc in my hands that made the software more real.
As I was printing the CD, a sysadmin asked, "Does it have to be on CD?" Her reason for asking was that she had blank white DVDs, on which the printed label would be more crisp, but I thought she meant, "Can't it be on something other than a disc, like a thumb drive?" I laughed aloud when I realized that I had never considered anything but an optical disc for this project, because, you know, software comes on discs!
Subscribe to:
Posts (Atom)