Entries Tagged 'Sakai' ↓

It seems that at least a couple of people read my last editorial. I didn’t expect to write a part 2, at least not here or now. But it’s worth a bit of clarification…

[See the very end for the “bit” part…]

The Sakai Product Manager, Clay Fenlason, has posted some notes on this ongoing discussion. He rightly points out that it is evolving and happening in large part on the “management list”, and that you should join up or watch the archives if interested.

The purpose of this post is to clarify what looks to be a basic disconnect on my opinion, since I was cited and don’t mean what it looks like Clay heard. He says:

But again our first practical example risks a misunderstanding - that the full process is only really about Sakai 3. There are even some knowledgeable community leaders that are coming to this conclusion and holding it forth as an insight.

It seems that Clay has drawn an interpretation from my communications where I would attribute the process primarily, or even exclusively, to 3.x, thereby grandfathering 2.x into some who-knows-what process. If he read it this way, it is fair to say that others might, too.

I feel quite the opposite, in fact.

Continue reading →

Something has been gnawing at me. Here is my initial assessment:

There are some gradual but quite significant changes coming to how the Sakai community works and releases software, and these changes are quite unclear.

I don’t think this is controversial or surprising. I do think that there are lots of ideas, fears, and desires for how this might work out. We are definitely having organizational growing pains.

Here is what I see as already present:

• Two new groups: the Product Council and Maintenance Team
• Release Management emerging as possibly distinct from QA
• A relatively new and evolving Product Manager role
• Two streams of software (2.x and 3.x)
• Tension about how each of these roles shapes either stream

Where I’m going with this is that three of us on the PC share a homework item of looking at what would be helpful support of our Incubation and Product Development phases. However, I have been confounded about the very essence of this assignment given the above list. See the email below for specifics — it also frames this post as a written reflection.

So, let me reflect.

Continue reading →

A handy little snippet… This is something I’ve used a few times when I’m hacking in a working copy and need to change POMs for some local reason (usually versioning) but can’t check them back in modified. I’d like to tweak the POMs, work on other stuff, build/test, check everything but the POMs in, rinse and repeat. Here’s a workaround:

svn st | grep '^M' | grep '[ \/]pom.xml' | sed 's/^.......//' | xargs -I{} svn diff {} > pom.patch
svn st | grep '^M' | grep '[ \/]pom.xml' | sed 's/^.......//' | xargs -I{} svn revert {}
svn ci -m 'whatever'
patch -p0 < pom.patch

Happy hacking. -NB

So, I’m going to try to get back in the habit. I owe Ray two posts, so this is a warmup. Anyway…

I’ve just added JSONP callback support to Entity Broker. This allows you to make a data feed that can be used for mashups. The normal JSON feeds don’t allow for this because, when the script tag is added, the object literal just drops into the ether — it needs to be handed off to a function. Plenty of others are using this technique now and it’s well supported in things like jQuery; just search around.

The important bit is that you can either use the default callback function (jsonEntityFeed) or specify your own. You just craft a URL to the entity and optionally give a parameter. For example:

http://sakai/direct/entity-prefix/some-id.jsonp
http://sakai/direct/entity-prefix/some-id.jsonp?jsonCallback=myCustomCallback

If you are using jQuery, you can use the getJSON method to call an inline, unnamed callback like this:

$.getJSON('http://sakai/direct/entity-prefix/some-id.jsonp?jsonCallback=?',
function(data) {
alert(data.whatever.element[0].here);
});


It’s all pretty straightforward and tracked in SAK-16757. I imagine that this will get tagged at some point, but it’s just in trunk for now. Happy Hacking! -NB

So I’m debugging a chain of Sakai helpers and I ask myself…

“Self, is there an easy way to use the Eclipse debugger to fake some runtime/dynamic tracing?”

And the answer is a resounding “yes!”

If you set up conditional breakpoints at the places where you want those debug statements and inject some great println justice, magic is made. Eclipse is also nice enough to allow blocks of code or expressions. This means you can use just the println like an expression if you don’t care about the breaks, or make a println and a return if you do. See the screenshot for a somewhat nonsensical example.

All of this can be yours with a single startup of Tomcat and a tail -f. If you’re lucky enough to be hacking something in *-tool, life is even better. Save, mvn install sakai:deploy, relaunch your debug scenario, and keep an eye on that terminal. Somebody who knows what they’re doing with Eclipse could probably tell you how to even target an IDE view — catalina.out is fine for me, though.

…And for quick reference, you can right click on a breakpoint in the left-hand trough and select Breakpoint properties or use the Breakpoints view. On a Mac, Cmd-Shift-B toggles a breakpoint on a line, but getting to the properties with the keyboard is a pain (Opt-Shift-Q, B). In there, a natural-feeling sequence of arrows and Opt-Enter or a right click opens the dialog. Getting back to the editor is easier: F12.

Happy hacking! -NB

Nathan Pearson, Sakai’s lead for the UX Initiative just forwarded a post from the 37signals blog. It’s referencing a video interview with Ira Glass, where he talks about being a fierce editor and moderator, cutting more tape than you roll. The post extends the interview’s mention of entropy as the disorganizing, enemy force to software.

In principle, I agree: entropy tends to bloat, delay, and complicate software. But the read-only experience of listener/viewer in storytelling is a bit different from daily use software. The post reveals some of the company’s “less is more all” philosophy.

Continue reading →

Those of you who attended the Sakai conference in Atlanta might recognize that quote. It’s attributable to Eben Moglen (SFLC), uttered during the “lunch discussion” with Matthew Small (Blackboard). “These are the data,” is a quote I’ve used countless times in the past 16 months. I’ll explain in a moment.

So, fast-forward, and we see posts from Michael Feldstein on the initial invalidation of all 44 claims and Blackboard’s response. The latter post (and Bb’s statement) is specifically about the percentages of patents that are upheld, invalidated, or altered under reexamination. This is the exact context of Dr. Moglen’s original quote. He presented some hard figures and summed up with those ringing words.

I’m not going to beat up on Blackboard — they’re looking at the rules and playing the game. I completely disagree with software patents, but they’re still allowed in the rulebook, so I can’t blame them for filing before someone else did. Indeed, the applications were filed in 1999 and 2000. It was a different frontier with respect to the Internet, Free Software, and software patents then (see LZW, Unisys, SCO).

Personally, I thought it was pretty bad karma to file a press release of a patent and lawsuit on the same day, turning the red lights in people’s minds into white hot light on the detailed claims. But then again, I’m not on their strategy team. It’s just too bad that we’re tying up all the energy, time, and tax dollars, bickering over how we play in the same edusandbox and who gets how big a slice.

Anyway, there are 44 patent claims. Of the 10 issues set forth in the reexamination request, the rejections of 6 were adopted with modification, those of one without modification, and those of 3 were not adopted. The union of all adopted rejections deems that all of the claims set forth in United States Patent 6,988,138 are unpatentable. These are the data. -NB

You can download the audio of the lunch session from the Sakai Confluence page. There is also a transcript from Jim Farmer.

Every so often, something goes your way, ya know? So, last Thursday, I posted to sakai-dev asking whether I should use dojox.storage or borrow some stuff from rWiki:

http://www.nabble.com/Flash-storage—-dojo.storage-or-homebrew–td16033853.html

It also just so happens that the main guy behind dojox.storage, Brad Neuberg, apparently felt like being a kind soul, did a ton of refactoring work, and bundled up the smallest, most practical package possible for my immediate need and posted it, not three hours later:

http://codinginparadise.org/weblog/2008/03/easy-download-of-dojo-storage-for.html

So far, it’s really easy to use (about 15 total lines, and tastes like HashMap) and moves between browsers very well. I’m only having one issue on IE. It’s choking on line 52 of some unnamed file that a little Googling hints is related to the Flash plugin. (For the curious, it’s an Object Required error in __flash__removeCallback()…)

I guess this can happen with different ways of including SWF files — the confusing bit is that one thread says use the HTML embedding, rather than JavaScript, and another says to use JavaScript rather than HTML. The tricky part is that both seemed to fix it.

So, I’m going to test on a machine that doesn’t have script debugging turned on and hope for the best. If it doesn’t grumble too badly, I’ll poke around for a fix in my spare time.

Either way — Cheers, Brad! You really made my day. -NB

How long should personal artifacts submitted in some official capacity be viewable (by learner or official) in their original state? How we can let learners really own their materials?

We’ve approached this problem to date by ignoring it. We make an explicit step: at some point, we force to student to say “I’m done with this thing and it’s yours forever”, and lock it. Or we just let it be malleable forever.

This is directly analogous to how, in logic, math, and computer science, we sometimes restrict input to maintain a lower conceptual threshold. Persistence and security of artifacts is a really hard problem, so we make sure it can’t destabilize the easier ones we’re solving, by distilling a complex grey gradient into blacks and whites.

It’s a perfectly valid way to get a foundation, but it’s time to move into our version of second-order logic — versioned, purpose-stamped, multi-threaded artifacts — to address our complex realities. We can’t lie to ourselves and believe that hard-locking a student’s file forever is practical in a personal learning experience.

The specific thought that triggered this post was that the notion of estimated secure lifetime in cryptography is relevant to visible/storage lifetime in ePortfolios. However, this post also includes thoughts on the concepts of fluid artifacts being copied and made concrete at submission time, and how this relates to our existing web/email usage patterns.

Lots more below the break.

Continue reading →

Sakai/OSP development is expensive, so it’s hard to find funding prioritized for the “soft” benefits of personal ownership and development that might not jive with the “hard” outcomes understood as necessary for accountability.

I believe these “soft” outcomes can communicate accountability just as well, and even better, but it’s a much more intensive project that needs smart, creative, dedicated people over time. The consumable accountability data needs to be assembled as a secondary product, as opposed to the primary, “automatic” data products of rigid accountability measures. (…which feel a bit like TPS reports to student, faculty, and implementors, in my experience.)

This is one area where the “lower bar” open source systems have an apparent upper hand in development. Good portions of the development happens by motivated folks who have some time to give to personalization. It’s easy enough to “get in” that essentially unfunded effort bolsters those aspects.

I believe that, in today’s higher education climate, any system that doesn’t address accountability in a systematic fashion will fall out of favor very quickly at any institution where the words “ePortfolio” and “assessment” have been uttered in the same sentence. It’s really hard to build a realistic accountability system in your spare time, out of the context of a real accountability project.

This is where Sakai/OSP is uniquely positioned. We’re admittedly a bit behind on personalization, but that is changing quickly. At the same time, we have a depth of reach into the “regular” learning system activities and assessment capacities that’s unparalleled. It’s also a primary goal for a number of us to make raw development much easier. I really believe the 2.6 release has the potential to change the game. -NB