• Vote on Oct 14!

  

• Search for:
• 
  This work is licensed under a Creative Commons Attribution 2.5 Canada License.

• Similar Posts

  • Pachyderm Foundation Development
  • Pachyderm & APOLLO at Museums and the Web 2005
  • Thoughts on “Learning Objects: Difficulties and Opportunities”
  • dcannell’s thoughts on learning object repositories and metadata
  • LOR Typology: CAREO errata

• Pages

  • About
    • Bookshelf
    • Colophon
    • Contact
    • Music
    • My (not so) Secret Identities
    • Presentations
  • Archives
  • Asides
  • Photos

• My Other Places

  • Mindfulseeing.com (photoblog)
  • Flickr/dnorman
  • Teaching & Learning Centre
  • The University of Calgary

• Recent Comments

  • Jason on mobile (R/C) video with Flip
  • Mike Caulfield on Is there such a thing as “too open”?
  • Alec Couros on Is there such a thing as “too open”?
  • Cole on UCalgaryBlogs update
  • Chris L on Is there such a thing as “too open”?

• Meta

  • Log in
  • Entries RSS
  • Comments RSS
  • WordPress.org

Susan Smith Nash raises some very good points about learning objects - what are they? why would anyone care? how would someone reuse them?

CAREO is mentioned specifically, and the concerns with it are entirely valid. It should be noted that CAREO and its ilk are from the first generation of learning object repositories - a necessary step in the evolution of the concept - and we’ve got some stuff that begins to address many of these concerns (Pachyderm, APOLLO, etc…).

This “second generation” learning object repository stuff is just starting to see the light of day - and even that isn’t anywhere near where we want to end up. It’s all just baby steps along the way…

Disclosure: I built a good chunk of CAREO, and am pretty deeply involved with the development of APOLLO and Pachyderm.

I just deployed a new Wordpress weblog to manage the APOLLO Project Website. It’s a Wordpress 1.3 Alpha site, which gives me a place to play around with the latest builds of WP, and it also gives us a nice and easy way to officially publish information about APOLLO and related activities.

Well, not exactly alive, but it’s working. It’s freaking working! I can now insert new records (creating new xml documents) and save them, run queries, edit records, and save those changes. Whew.

There is some final cleanup I want to do (finish migrating from DOM4J to JDOM, clean out all of the debugging spaghetti outputs, and comment the heck out of it), then I’ll package it up and drop it on Sourceforge.

This has been one of the most frustrating projects I’ve ever done (and I’ve been involved with some doozies). It was frustrating simply because I wasn’t able to grok some of the finer points of EOF’s behind-the-scenes magic. Thanks to King for providing insight (it wouldn’t have ever worked without his guidance!)

I’m completely sure there is some stuff I’ll need to modify, and it’s entirely possible I’m doing stuff the Wrong Way, but it’s working well enough to be used, and that’s what counts…

UPDATE: Just updated the adaptor to use an EO_PK root of the current database, which will increment primary keys in a predictable way. Very cool. Works quite nicely. Now to generate some metrics on the whole operation. Tomorrow…

Well, breakthrough may be a bit much, but we did figure out some stuff today, and it’s going to work quite well…

King just spent an hour with me pouring over the JavaXStreamDBAdaptor code, trying to help me figure wtf was going on (i.e., it wasn’t behaving as expected, leaving it unable to properly insert new documents).

We were looking at the code, and then King had an idea. “Open the EOModel for the xml database,” he said. I cracked it open. “Try it with the _gid attribute set a a non-class-property.” OK. I hit the little diamond widget to tell EOF not to let me access the _gid primary key attribute directly. Recompiled, tweaked some code, and BOOM. It was kinda sorta working. Almost.

The hard part, that I’d been struggling with for the entire week, was basically caused by approximately 30 pixels of diamond widget in EOModeler. 5 days of feeling like an incompetent bumbling moron, caused by a checkbox. Not sure if that clears me or validates the feeling…

It’s not completely working now, but I’ve got a very clear path in front of me, and know exactly where stuff should go. I’m going to try to get to some of it this weekend, but that may prove difficult (with Evan’s second birthday party on Sunday! WOOHOO!).

I just put together an updated installer for APOLLO’s supporting frameworks and resources. PackageMaker on MacOSX makes it so brain-dead simple to create really powerful installers. Gotta love that. And, it’s free (included with the Developer tools).

This version of the installer includes the Pachyderm PXFoundation and PXPublisher frameworks. (Less than subtle hint about project relationships in there somewhere… )

The installer itself isn’t public yet (just for the developers on the project for now - makes it easier to get a new dev. box up to speed without having to manually compile a raftload of frameworks first).

I just finished an initial test deployment of APOLLO, including all frameworks and a sample searching application, on a Solaris server for use by the folks in BC. The install of our stuff was really quite simple - just copy some stuff into the right directories and add a new WebObjects application. Done.

There were only 2 small snags:

• Frameworks need to be installed into $ NEXT_ROOT/Local/Library/Frameworks/ - I had been putting them into the MacOSX-ish $ NEXT_ROOT/Library/Frameworks/. Once I figured out the problem, it took all of 5 seconds to fix.
• The shell in Solaris handles the backspace key differently than on MacOSX - so if I messed up while entering a command (like copying a directory or something), I’d have to control+c and start that one over again. King just suggested setting the “Delete Key Sends Backspace” preference in Terminal.app - that works perfectly. If only I’d have realized that an hour or two earlier…

It’s good to know that the APOLLO stuff really is portable. It wasn’t too difficult to install on a platform that had never seen APOLLO before, and that’s comforting

I’ve just published updated Javadocs for the APOLLO frameworks (and the Pitchboard application that drives Fusion).

It’s a start - we’ll be fleshing out the documentation as we move along (that’s one of the things on my plate, so I’ll be spending some quality time working on documentation over the coming months).

The classes will be updated/cleaned/trimmed over the next little while, but this will give a starting point for grokking the guts of APOLLO.

This version of the javadocs includes:

• ca.ucalgary.apollo.foundation (handles low-level data stuff)
• ca.ucalgary.apollo.appkit (handles high-level application stuff - UI, etc…)
• ca.ucalgary.apollo.workflow (handles creation and execution of step-based workflows)
• ca.ucalgary.apollo.pitchboard (drives Fusion)
• ca.ucalgary.apollo.vocabulary (provides interface for describing vocabularies)
• ca.ucalgary.apollo.vocabulary.vdex (implements the standard VDEX vocab. specification)

Scott Leslie is heading up a rather large initiative in BC to deploy some cool whiz-bang learning object technology across the province for a couple of very large organizations. His group recently made a decision on which technologies they were going to use, and they picked APOLLO.

Scott has written up an excellent description of his rationale, plan, and hopes for the BC/APOLLO collaboration. I really like his pragmatic stance - use what’s best for the job, and for the users. He likes Open Source, but isn’t married to it. He likes commercial software, but will use something else if it’s a better fit.

It’s going to be one heck of a fun ride, through September and beyond!

And Scott is also astute enough to call us on our “pick a cool-sounding-name and shoehorn an acronym into it” strategy. Doh.