I just completed my “2007/365″ project, where I took at least one photograph per day for the entire year. I didn’t realize going in just how hard it would be, but it forced me to see things differently and I did learn to be a bit more proficient with the technical aspects of photography.

Download 2007/365

Other versions available here.

One of the tasks that’s been on my desk for awhile has been giving some love to CAREO. It sorta stopped working a few months ago, and nobody really cared enough for it to be a High Priority Urgent Fix. The hard drive started to corrupt, and services went from spotty to unavailable. And stayed that way.

Actually, I think it’s a pretty impressive statement about Institutional Repositories that something that was once trumpeted as The Next Big Thing can be out of action for 9 months without many people even noticing. Relevance of top-down, centrally ordained institutional Repositories?

Personally, I just kept feeding my stuff into del.icio.us, Flickr, and my blog, completely (and blissfully) unaffected by the crumbling of an aging prototype repository.

But, apparently, some people still wanted access, so I spent the day getting my head back into the code (mmm… spaghetti….) and realizing just how much I dislike Java (or, perhaps, all compiled languages). I spent SO much time wasted in compile-recompile-forcecompile-compile-deploy-launch-test-fix-repeat that it was way more frustrating than it needed to be. With an interpreted language, I could be modifying the code on the fly and seeing the changes in realtime. Much better for fixing and debugging stuff.

Anyway, CAREO is back on the air, with its library of 4145 contributed “learning objects” (of which, the vast majority don’t really provide much context for learning, but are rather simple assets or resources to be used in other contexts…

It’s now running on my old dual-800MHz-G4 desktop box, which would sound slow except that CAREO is now running on a box that has more than 4x the horsepower it did before The Fall From Grace. Pretty sure it won’t handle a Slashdotting, or even moderate use. But it should work well enough for people to refer to again.

My first reaction on seeing it again after over a year was “Blech! THIS was the best we could come up with?” - The interface is pretty hideous, especially by “modern” standards. And it’s so un-Web2.0 that it hurts. I did bolt on wiki and discussion features, but that’s what they are - bolted on grift.

Of course, it was pre-Web2.0, so it’s funny how perceptions change with experience.

ps. the CAREO Project Website, which was hosted by Athabasca, is unavailable for completely different reasons (they let the domain lapse and didn’t renew it. doh.)

I've been involved with a shared Drupal hosting project with BCIT and BCCampus. Part of it is based on an easy way to create new Drupal sites via a web interface, complete with database creation and population, Drupal site directory creation and settings modification, symlink creation to make the site visible to Apache, and management of a Drupal Sites Manifest table to keep track of sites.

At first blush, it seems rather similar to both sympal_scripts and the Drupal 5 installer, except for the management of a sites manifest table, and creation of the symlink to expose the site to Apache in a shared setting.

I'm investigating ways to better integrate with either/both of those, but in the meantime, I've got a working Drupal module that will do the whole shooting match. Not everything is fully implemented yet, but I've got the various bits working as a Drupal module, and most of it working as a standalone PHP application.

Currently, it reads available database profile templates from a directory of .sql files created via mysqldump. It creates a new database on demand, and populates it with the contents of the specified profile.

Future versions will let you customize the admin user/pass, and create an additional user/pass at install time. I also need to add site decommissioning (freeze-dry to static html, delete database and site config directory, etc…)

Writing this module has been an interesting exercise in learning the Drupal forms API and module programming in general. I've had a few false starts on both fronts, but think I finally grokked it this time. This is the only real code I’ve written in something like 6 months. Yikes.

Provisionator (alpha)

Update: We’ve committed to sharing this openly, so I’ll be cleaning it up a bit and setting up a project on Drupal.org so others can play with it if they like. I’ll likely wait until after the Drupal.org project reorganization though.

I’ve been given the opportunity to reflect some more on the nature of portfolios, and on the differences between “portfolios” and “dossiers”. I last wrote about ePortfolios vs. dossiers last month. This morning I got to see a presentation on a Very Important Project that is building a “Teaching Dossier” system as part of its offerings. I’m not going to name the project, because the exact implementation is irrelevant - it’s the concept of the dossier that is off the mark.

There has been a lot of effort into producing systems to facilitate the authoring and publishing of Teaching Dossiers - what appear to be a variation on the traditional CV, but with different headings and fields that get filled in. Essentially an online Word document template with some supporting documentation. It’s billed as a great way to document teaching philosophy, practices, successes, and history. Well, yeah. In the same way that Word can do that, too.

The system I saw this morning was literally a set of online forms that eventually spit out a single html file (no images, some links to external stuff though). No personal creativity - just fill in page after page of forms, and it will distill that info into a web page.

It just hit me that the process is just so, well, uninteresting - you get a web page, sure, and you’ve followed some guidelines about what to document and what to write about. But that’s no more than “Save as .html” It’s not even useful as an interchange format - if it was magically talking with various institutional systems, it might be cool, but it’s a proprietary silo of data, generating a simple web page. They could have just as easily created a Word template to do the same thing, and might have wound up with a better result. Or, a Dreamweaver template, or iWeb, or…

It’s also pedagogically uninteresting. It tells nothing of yourself as an individual. You can fill in a form on a web page. Goody. Now, can you communicate? Can you tell the story of your teaching (and learning)? Can you show video clips? Photos? It’s impossible for an individual’s personality to be captured through this process.

The dossier may have a place in an old-school paper-pushing regime, but we’re in a different century now, and the documentation of what we do (and how we do it) needs to reflect that. A simple text-only web page can’t possibly capture the various activities and media types.

The presentation I saw completely validated the approach we’re taking with our “ePortfolio” pilot project, where we’re essentially handing the students and professors a set of flexible tools (Drupal and Pachyderm) that will let them do what they want. There are no constraints or rigid boxes to fill in. Heck, Pachyderm doesn’t even have the concept of “ePortfolio” in the software - it’s being used because it’s a freeform generic authoring environment. And Drupal is being used because of the fluid nature of users and communities. Put the two together, and you have the antithesis of a “Teaching Dossier”.

In the background thinking/planning for our own “ePortfolios” project (man, I hate that “e”) we realized that many/most of the off-the-shelf portfolio packages were really just simple fill-in-the-blanks templates. Not really a portfolio, at all. Essentially a simple dossier. A collection of standardized data about a person, with no real creative input required or allowed.

A portfolio (e- or otherwise) is about as far from a simple templated dossier as I can imagine. Ok. Flying monkeys with laser guns on their heads would be farther, but you get the point. Portfolios are a process of creative expression. Of reflecting on what you’ve done, how you did it, and hopefully, where you’d like to go. Every person’s portfolio should be different. Different content, different presentation, different context. Things that a dossier just can’t capture. Dossiers are good for comparing batches of nearly-identical things, and helping to highlight differences between them. I imagine a hiring committee sitting at a big table with a stack of 500 of these templated dossiers, sorting them by some criterion to get to the Right Person To Hire.

That’s not really what a portfolio should be - it’s best used as a showcase for an individual. I picture the portfolio as being closer to the job interview than the resume. It’s a creative proxy for an individual, not a standardized data transmission vector.

So, when we were deep in development of Pachyderm, and tossing ideas around about how it could be used academically, the idea of a dynamic, interactive, person-centric portfolio management tool seemed pretty cool. It’s totally not what Pachyderm was initially designed or intended to do, but because it’s basically content-agnostic, it doesn’t care how you use it. And that’s pretty much what we need from an “ePortfolio” authoring tool.

I’m very interested to see how the first batch of students use it, and what they come up with. Should be interesting…

The Mavericks online exhibit went live on Wednesday. The event featured several of the Mavericks (or family members) attending to answer questions. I missed the event, but it sounded like a great one.

The project is really quite cool, presenting a history of the prominent figures in Alberta’s history from the 1700s to modern day. Themes such as settlement, ranching, Mounties, oil, politics, war, and immigration are covered in pretty impressive depth. There are over 1400 screens of content (images, text, audio, and video), as well as a full teacher’s resource for use as part of the curriculum.

The online exhibit was authored using the in-development versions of Pachyderm 2.0, and provided a pretty serious beta test suite for the software. The really impressive thing is that now that Pachyderm 2.0 is essentially “stable” enough to let people hammer at it, anyone can create online exhibits like this…

Update: I made a Flickr Album for photos from this trip.

Had a really good first day of meetings. We had a quick lunch on the 36th floor of the Grand Hyatt, overlooking the awesome skyline of San Francisco. Then we got into the recap of the last 2 years, and touched base.

Then, we packed into a bunch of cars, and headed over to the De Young Museum in Golden Gate Park. What a cool museum! We headed straight for the Education Tower, with a spectacular view of The City - from an angle I’d never seen before.

We then proceeded with a tour through the Education Tower offices, and got a brief introduction to their education resources collection. Wow. They’ve put together a series of excellent binders for K-12 (well, 4-9 now, K-12 in January) art education. And they’re providing it free to any teacher. This is some high end stuff, so if you are looking to integrate art into your classroom, give them a shout!

After the tour, we were unleashed into the galleries. We spent most of our time in The Jolika Collection of New Guinea Art - very interesting pieces. And the collection wasn’t just dropped into the gallery - it feels like the rooms were designed completely around and for the collection, providing an immersive and compelling experience.

As we moved through to the next gallery, the fire alarm sounded. Emergency doors slid down over every doorway and window. Metal rollers. I was expecting Halon gas to fill the gallery to protect the art, but apparently it was a false alarm. Thankfully so, since the security staff simply herded us into a group on the second floor and left us there with no apparent way to get out. We eventually were led downstairs and out of the building…

We ended the evening at Maya (2nd and Harrison) with a private dining room for the rowdy pachyderms. Some really good food (of course), and fun conversation with the folks on the project. We were also introduced to the new Pachyderm mascots - the iPachyderm. It plugs into an audio source (iPod, computer, whatever) and bops along dancing and barking and blinking and sitting and beeping and wagging and…

The Tips for Large Projects post I made earlier makes more sense as a wiki page.

And now it is one. Enjoy.

Update: I’ve wikified this list to make it more useful.

Some notes I’ve gathered while working on some Very Large Projects™ over the last couple of years. Some of the projects have done some of these things, and some have done few/none of these. Live and learn… I’m just documenting them here so I can refer to something quasi-concrete on the next big-ish project that comes along.

None of these tips are written in stone. They are also not necessary for a project to get done, but these should make things much easier on everyone. YMMV. IANAL. YHBH. Wait. Not the last one…

I’ll update the list as I think more about it.

• Maintain a central repository of files for the project
  • avoids 16,326 revisions of Word .doc files being emailed around. Which is the most recent? Are all changes in the latest-modified version? Do I need to keep the previous 16.325 revisions on my drive Just In Case?
  • Everyone will be on the same page - no confusion with some people talking about stuff in revision 16,3200, some in the latest revision.
  • Word files are definitely not suited to sharing information with a group - use a wiki or CMS or something, but Word .doc files are not the best way to share information, even though everyone might have Word installed (and they may even use it with the project - but .doc is NOT an interchange format).
  • If something like Subversion is too geeky, try a shared FTP directory. Just do something to prevent confusion and missing files/data.
  • For a simple text/data repository, Wiki Is Your Friend™
• Have concrete targets/objectives/goals/milestones
  • Make sure everyone (organizations and individuals) knows exactly what the plan is.
  • Make sure everyone knows about the timeline - what are the “real” deadlines? What are dependencies within the project(s) to meet the deadlines? Avoid “fake” or “internal” deadlines - make sure everyone knows the real dates.
  • What are the risks in the project? Where should resources be focussed to prevent failure?
  • What is the plan to communicate about the project? Will you be showing it at conferences? If so, pick them well ahead of time and make sure everyone knows about them. Make sure everyone is on the same page so there aren’t any last minute “oh, by the way, we’re presenting it at X conference tomorrow…” types of surprises.
• Communicate
  • Have regular meetings - they don’t have to be face-to-face, they can even be phone calls or IM sessions - but talk regularly to avoid confusion.
  • Don’t have meetings just to have meetings. That’s a bigger waste of time than not having any meetings at all. Meetings should be short, productive, and useful. As soon as they stop being any of these things, they cut into efficiency on the project. Meet when you need to, and only when you need to.
  • Share notes from (online and offline) meetings so that there isn’t any confusion about what was discussed. Wiki pages are handy for this.
  • Make sure everyone on the project has an instant messaging account. It’s so much easier on everyone if they can just quickly ping each other for quick questions without drafting emails, or interrupting each other with phone calls, etc… As an added bonus, iChat and Skype accounts function for both text messaging as well as audio conferences (and in the case of iChat, video as well) - very handy for free ad-hoc meetings.
• Document
  • The documentation for the project should include links to the central file repository(ies), timelines/milestones/objectives, meeting notes, etc…
  • Documentation should be written both for people new to the project (people come and go - prepare for it), and for existing people who may not have all of the information active in their heads - projects take time, so there should be a backup outboard brain shared by project members
• Iterate
  • Avoid monolithic “here it is - it’s done” releases. Build early, build often, seek feedback/review/critique throughout the entire project lifespan.
  • Make sure the plan/timeline/milestones are still valid as you move along. Stuff happens. Things change. Make sure you’re not painting yourself into a corner with outdated plans. If plans change, make sure everyone is on the same page, and document the change (why did it change? what is the new plan? how does the change affect the rest of the project? the timeline? deliverables? etc…)
  • Embrace change/risk. If you’re not changing the plan at all, you’re likely not being responsive. (don’t change just for something to do, but don’t freak out about it) Also, risk isn’t a bad thing. If there was no risk, the project wouldn’t be necessary. Risk is where the magic happens, so work with it.

One of my tasks for the next few weeks is to investigate Drupal, and specifically its ability to support the online interactions of a community of practice. We have a few projects that will involve some form of online interaction by students and professionals who are spread throughout southern Alberta, and it looks like Drupal may provide most, if not all, of the functionality to support these communities. I’ll be specifically looking at Drupal in the context of:

• personal and professional reflection (blogging - either privately or to selected audiences)
• information gathering
• asynchronous communication - forums, threaded discussions, etc…
• communication with peers and/or instructors
• combinations of the above to form an “ePortfolio” type of view on the whole shebang, suitable for sharing with potential employers, or others
• likely other stuff

I’m actually pretty excited to be working on this stuff - it feels like I’ve been working so long on media-production-supporting-utilities that I’ve been out of the loop on the whole community side of things. We’ll be looking at integrating Drupal with Pachyderm (likely via a download/upload process, rather than a direct tie-in), and the institutional WebDAV storage/sharing system. Should be fun.

I’ve got a project that will require the use of Drupal (or something like it, but it’s looking like Drupal at the moment - I’ve got a mockup running for the project, and it’s solving about 90+% of their defined needs just using a stock Drupal installation with a handful of plugins), and one of the things that the users will have to do will be to upload files (images, .doc, .zip, whatever) into the system for reflection/commenting/review. They would also like to use these uploaded files outside of the system (for instance, on their own web pages, in an “ePortfolio”, whatever), and we’d like to provide a solution that wouldn’t force them to upload the files separately into two locations (their WebDAV volume for “regular” use, and into the Drupal system for review).

A quick Google search turned up a WebDAV project as part of the Google Summer of Code, but it’s intended to expose the Drupal database via WebDAV (for backup, or alternate interfaces…)

Any ideas on how a file uploaded into Drupal could be placed into a user’s institutional WebDAV space, rather than in Drupal’s /files/ directory?

ps. this was posted using Flock, and I think it took me longer to enter it via the WYSIWYG interface than it would have taken to just enter the HTML. Perhaps once I get used to the editor… Oh, and no place to enter categories? wtf?

Update: Apparently, editing an existing post using Flock’s editor makes the post disappear from my blog. Have to go in and manually re-publish the post after editing in Flock…

Technorati Tags: drupal, lazyweb, eportfolio, webdav

Julian and I were just IMing about how to set up a new Subversion repository - and we both commented about how this process should be documented. King set one up last week, and we said the same thing then.

So, I bit the bullet, and wrote up a first draft of the documentation for the process of creating a new Subversion repository for a Learning Commons project.

I left a page to list all documentation for the Learning Commons, in case the idea takes off and others start doing it…

I’ve used wikis to store “spontaneous documentation” before - but I’m hoping to keep the wiki as part of the formal documentation process. We’re about to head into another Learning Commons website rethink, so it might make sense.

Last night, it totally hit me just how fried I am. I’ve been fighting off burnout for awhile now, but I think I may have finally succumbed to it. I realized this when, at almost midnight, my family was upstairs fast asleep, and and I continued to work on my PowerBook to try to catch up on the backlog of bugs to fix - not feeling like I was making any progress anyway. I’m having to keep working this late so I don’t have to essentially abandon my family, which I refuse to do.

My work is backlogging because of some insanely tight deadlines, on 2 projects that are chronically understaffed. The One Project has been in actual development for over a year now, and while we’re close to being done, the Final Stretch is looming, with all that is entailed with that. The Other Project relies so completely on The One Project that I have had to walk a carefully balanced line between the two. Can’t finish The Other, without The One working well. Can’t work on The One without billing time to The Other, since we’ve used up our budget for The One long long ago… On top of that, I inherited The Other Project after budget cuts led to layoffs here in the spring, and there is no way I would have set the project up the way it is - but it’s waaaaay too late to change anything. The only thing left to do is grit teeth and push through it.

So now, The Other Project is coming due. Like, tomorrow due. And I’m still putting in revisions to content, and tweaking code in The One Project to support what is needed. And working with external contractors on some key supporting files that are basically out of my hands, but I can’t deliver without them working perfectly. And still receiving revisions to content and structure for The Other Project. And bugs/todos piling up for The One Project. Repeat ad nauseam.

Basically, to finish The One Project properly, the three of us programmers need to be able to direct 100% our our energy toward it for about a month. And, to finish The Other Project properly, I need to have the time and energy of about 5 people in order to finish massaging what can only be described as a freaking huge mass of content and resources.

My caffeine intake is waaaay up. My sleep is waaaay down. My cranky rating is off the chart. I feel (rightly or wrongly - doesn’t matter at this point) like I’m placed as a single point of failure for The Other Project, and have had to neglect The One Project more than I’d hoped and promised. It had gotten to the point where I seriously considered leaving, for the first time since I started here in 2001.

Anyway, there endeth the rant. Hopefully there is light at the end of the tunnel (there is an end of the tunnel, isn’t there?). In case anyone from either Projects stumbles across this - this is why I’ve been so pissy/grumpy/silent lately. Trying to keep my head down and pulling out all stops to get this stuff done, but there’s not a sane way to do that.

On the plus side, it’s Evan’s third birthday this weekend. I’ll be forced to take most of the weekend off for that, and we’re heading to West Edmonton Mall on Sunday and Monday (staying at the hotel in the mall). Should be at least a welcome break from the unceasing pressures…

Update: No, I’m not planning on quitting the Learning Commons - it’s just one of the things that go through a person’s head when faced with seamingly endless pressures. I’m staying here - we’ve got lots of ideas that will be fun to be a part of implementing, so I have no reason to go elsewhere.

We had a great hacking session today, with Josh piped in over iChat and VNC from California, and King and I hunkered around his collection of Cinema Displays. We managed to replace our krufty jGenerator-powered flash file wrapper class with one based on JSwiff, in under a day.

JSwiff takes care of the nastiness of dealing with the .swf file format, and provides an extremely helpful XML intermediary - you can convert any .swf file to this xml format, modify the xml, then render back as .swf. Very handy for what we need to do.

Basically, all we do is a fancy search-and-replace for some custom tags (for things like the image - encoded in Base64 - and the tombstone fields for display on screen) in this intermediate xml file, then pass it into JSwiff and ask it to transform that xml into a swf that we can use in our finished presentation. It’s fast, and so far very reliable. As an added bonus, it appears to handle accented characters and such, which totally borked in jGenerator. Mavericks will look better now, once I regenerate all transformed assets.

And JSwiff doesn’t look like it will be affected by the scary deadlocks that made jGenerator basically useless for us. Yay, JSwiff!

Even better, if this works out (it’s still being tested), then Pachyderm 2 is fully usable again, and on track for the October release!

I originally posted this entry on May 18, on the Apple Digital Campus Exchange (ADCE) “Tools to Enhance Teaching and Learning” weblog. I’d post a link, but everyone (including myself) would have to login to the ADCE system to read it. So I’m reposting it here in the hopes that it might make some difference. I’m not holding my breath. I was almost convinced that a walled garden might have value, but on further consideration I have to agree wholeheartedly with Alan - and won’t be posting to the ADCE weblogs unless/until the walled garden is opened up to everyone.

One thing that the read-write model of the internet is pretty much diametrically opposed to is the concept of content silos, or walled gardens of content.

There has to be a pretty compelling reason to lock content behind logins and registration. Restricting publishing is another matter, but restricting access to content that is not confidential is just plain wrong.

People won’t create accounts just to read content. Walled Gardens will wither and die - quickly atrophying into irrelevance.

I can see having a requirement for a login to post in the discussion boards, or to comment on a weblog (although even that is questionable). But the concept of having to log in just to find the URL to a weblog is pretty shortsighted.

Hopefully that’s just an oversight that will be quickly righted (especially considering the fact that Google has already found the ADCE blogs).

Update: I’ve put a quick-and-dirty PlanetADCE site up, which aggregates all posts from all ADCE blogs into one easy-to-read page. Enjoy!

PlanetADCE remains the only way to read the ADCE weblog posts. At least until the walled garden stormtroopers decide to seal our backdoor entrance…

The only way this kind of walled garden would fly is if it were the first, the only, or the largest (by an order of magnitude or so). ADCE isn’t any of those, but it does offer some cool things. For me the biggest draw of ADCE is the fact that it’s getting Carl Berger blogging. If that was the only product of the project, it would be well worth it.