Sakai Times

I have often said that the software that the Sakai project ultimately produces is not as important as the opportunity to forge an entirely new way for institutions of higher education to collaborate, to build something together that is greater than the sum of its parts. This new way is an exciting alternative to the old buy vs. build dichotomy.

The basic problem right now is that we have a requirements gathering process, but no organized (or better yet, self-organizing) system for getting the work done. Even though the Sakai Foundation oversees the project, they’re not “the boss.” They can’t force anyone to work on anything, because we’re a coalition of volunteers. That’s good, in the sense that we are the masters of our own destinies, but it’s bad because if no one drives the boat, it just sort of drifts. There is no shortage of resources: institutions have people and money, and they’re ready to use it to get software that helps them fulfill their missions. Among all the institutions in the Sakai community, there amounts to rather a lot of people and money.

There is a gap between what we want and what we get. It’s nobody’s fault; This is a hard problem. We need a (metaphorical) machine that takes people and money as inputs and emits world-class software. At select organizations, this is achieved by world-class software teams. To take it to the next level, we need a means of spawning meta-organizations — purpose-built working groups that swarm to a specific problem and produce great work. This happens now by dint of tremendous effort, currently embodied by the recent Resources work by Jim Eng, Clay Fenlason, and the folks at Unisa. We’ve got to find a way to bottle this up. Wouldn’t it be better if our best people had the mandate and the money to solve community problems full-time, instead of heroically squeezing it in between dinner and Conan O’Brien (I’m looking at you, Aaron Zeckoski)? I personally get frustrated that I can only put in a couple of hours a week to help make Sakai’s data interchange first rate.

I worry that we think this is going to iron itself out. The fact is, crossing institutional boundaries is fairly unnatural, and it’s going to take an intelligent template and a force of will to make it work as well as it should. Our problems are not technical, they’re organizational. Solving them is worth it because we stand a chance of closing the gap and getting what we need and want out of our systems, on our terms. Anybody interested?

I've been asked to give a presentation about Sakai at the North American Council for Online Learning conference in November in Plano Texas. It's a K-12 organization, so I'm going to try to give it the right spin^[1] for that audience. This will be my first chance to use Keynote! Why yes, I am a shameless Apple fanboy. How could you tell? [1] Not, in this case, a euphemism for lying.

We recently had a problem with Samigo that looked like a crisis at first. A professor had just given his second test of the semester, a timed essay — just one question. The trouble was, Samigo showed all scores from the first test and submitted them to the gradebook as such, so students were seeing scores that didn’t make any sense, and since the professor couldn’t see their responses to the new test, he thought they were gone which would be muy malo.

Luckily for us and this modest effort to migrate to Sakai, the test answers were not gone, just weirdly mis-recorded. It’s not easy to debug this, because it involves a lot of digging in Samigo’s tables, which are big and numerous and kind of inscrutable. For instance, there’s two of everything: the template version and then the published version. But the foreign keys that refer to things will just say, like SECTIONID. How do I know if that’s the SAM_SECTION_T or the SAM_PUBLISHEDSECTION_T? A little bit of context and a lot of trial and error.

It turned out that the responses for test 2 had been recorded with the wrong assessment id. I didn’t figure out how this could have happened; I just fixed the data.

The other thing that was wonky is that the rows in SAM_ASSESSMENTGRADING_T all had a submit date, but did not have an attempt date, which caused all the students to have “No Submission” show up next to their names. Once I figured that out, it was easy to fix, but again with the trial and error.

People have been asking me what the process of staying in sync with Sakai code is like, so I made a little screencast. It's about seven minutes long, and you'll find it right here. I also created a diagram that I hope illustrates what happens when you do an svn merge. You'll find that one right here. Let me know what you think!

I still don't know why my JVMs crash, but they seem to always become unstable after I have updated one and restarted it. And it's not only the one I updated that becomes unstable. Jeff and I were talking about it this morning and he suggested that it may be a problem with server affinity and sessions. I'm doing an experiment today where I just update one instance of Tomcat and then watch and wait. It bugs me how this problem has made me gun shy about applying patches to our production servers. In happier news, my technique of using svn_load_dirs.pl is working very well. My production boxes are getting all the changes made to the 2.2.x maintenance branch up to and including r15678.