TechnoMark

Why Would Anyone Want to Work on Sakai?

2008-08-05T10:15:00.002-05:00

Speaking rhetorically: Why would anyone want to work on Sakai? Think about it. It's a bloated morass of java code written in a dozen or more styles with no overriding standards, poor (and scattered) documentation, an architecture that works well in some areas and is pretty much broken in others, etc. The learning curve is significant towards creating even the simplest tool. Even setting up a development environment is an advanced task. If you get past all that, your work is likely to language in a branch or patch and never see the light of day. Heck, it isn't even clear who to talk to, since committers are largely unknown.

Many of the people who work on Sakai do so because they are directed to by the IT organization in their university. It may be possible to expand that base, but not by a lot, I suspect. The universities that can apply resources to Sakai probably already are. My question is: how can we change how we operate to make existing participants WANT to contribute more? More importantly: how can we improve our processes such that developers who control their own time might want to participate in Sakai development.

Lest I sound too negative here, I freely acknowledge that the project has made SIGNIFICANT improvements over the past few years and this trend continues in a positive direction (I believe). That said, let's explore the lifecycle for a minute (or 10) and see if we can isolate some pain points. I'm going to focus on the independent developer case, in part because it is the more challenging one.

At four years into the project, Sakai is widely known in the educational community. There was a lot of buzz and interest initially and while that has settled down quite a bit, we still make the news from time to time. Suppose I am an experienced Java developer, perhaps in a
university setting, with time that I am allowed to use at my own discretion. I am removing the funding part of the equation to focus on other aspects, though funding is a part of the larger problem, too. So read a reference to Sakai in the Chronicles (etc) and I'm interested. How do I find out about Sakai?

The obvious place to start is http://www.sakaiproject.org. (Feeling lucky on Google will bring you right there). There's lots of good news here. Anthony has done a great job of pulling together a lot of the links needed to find things right on the home page of the web site. I can find most of what I need to get started from here. Sadly (and this is no criticism of Anthony), I also notice that the site is already pretty dated. The last newsletter is for July 26th -- I wonder if there have been any since then? The 9th Sakai conference is listed as an upcoming event. Etc. First impressions are important. Our web site needs to be up to date at least to the current week.

If I have never experienced Sakai before, I might want to poke around a bit. Fortunately, there places I can do that. Both Unicon and rSmart have test drive sites and there is another one called SakaisTheLimit (which, somehow, I have never heard of). All of these do a find job of dipping a toe into the Sakai waters (though sharks lurk below). Interestingly, there is no link to collab.sakaiproject.org on the home page of www.sakaiproject.org. Perhaps it is a bit difficult to explain what that site is for. Hmm - what is it for? (We need to re-think what collab is used for.)

In the interests of brevitiy (ha!), let's assume that I (as a developer) decide to poke around the code a bit and maybe set up a development environment. More good news/bad news. The good is that Aaron Z. has done an outstanding job of describing how to set up the Sakai development environment. Further, it is kept up to date with the latest release of Sakai (big rep points there). Following the instructions, I get my first glimpse into the complexity of Sakai. Depending on how good my developer skills are, I can get the basic environment set up and running in a few hours. Less skilled developers will probably take a day or more and the odds of them getting it right are not good (as documented in any number of sakai-dev messages). This is another pain point that we could improve -- streamlining and simplifying setup of a development environment.

So let's assume that I'm pretty familiar with setting up java web application development environments and databases. Following Aaron's instructions, I get a working Sakai environment. Building and deploying Sakai can take an hour or more, depending on how fast your computer is (K1 will speed this up some). That's frustrating, but unless me (as the new developer) understands that there is a stripped down version of Sakai (Cafe), I'm likely to build the whole shebang and that takes a fair bit of time.

Regardless, I'm into the code now. Train wreck time. How the heck am I supposed to figure out how to write an application, even something as simple as "Hello World" by looking at the code base? There are answers to this question in the Programmer's Cafe and Sakaipedia (admittedly out of date, mea culpa), but how does a newbie (even an experienced one) find that answer. Documentation is getting better, but our organization of it is still horrible. This gets worse once I start digging down into confluence. Which pages are the "official" documents? Worse still once I start looking at code - six ways to do even simple things. There are many examples of Sakai code (including in the Framework) that would (frankly) disgust me. The use of public inner classes, for example. I quickly come up against the lack of standards as well. Which presentation technology should I use? Should I code my application as a server-side one or client-side? There are many, many reasons for why things are the way they are, but I believe the state of Sakai code is one of the biggest turn-offs to developing for it. We need more tutorials, better documentation, better organization for documentation, and enforced coding standards.

Clearly these guys need my help badly (otherwise, I am out of here). I've got some time, so lets work on something. The first question is: what? What work needs doing in Sakai. Sure, I could figure out Jira and tackle one of the 2871 open issues (today's count), but I know almost nothing about Sakai. Further, I don't know anyone in Sakai or what the processes are (again, buried documentation). By this time, I'm several days into coming up to speed on Sakai and it's getting a bit frustrating. Aha! I've discovered something that needs doing: there is no utility to manage the creating of academic sessions (long story behind this that will be dropped to avoid in-box size limits). A simple tool that CLEARLY is needed. I've done JSP work before, so I code the tool as JavaServer Pages (not the best choice, but how am I to figure out what is best?). Getting it to work was a real chore, but I managed to find a couple of examples in contrib that let me figure out how to configure web.xml and get it recognized as a Sakai tool. Yeah, I did write it using JDBC instead of Hibernate (lack of standards, again), but I did add support for Hypersonic, MySQL, and Oracle - I even tested it (manually). It all works just fine. So, with great pride, I announce the completion of this work on sakai-dev and attach the code as a ZIP archive.

What sort of reaction do you think I'd get? The kindest reaction would be a patient explanation (from four different people) that Sakai has a process by which tools are written. You need to have a Jira entry. You need to propose it to the community first. You should check it into contrib. Sadly, we can't include in the next build of Sakai (in spite of the desperate need), because it is only a contrib tool and needs to be carefully evaluated and used by several universities first. At this point, we lose our new developer. It's not that our processes are bad - they are designed to ensure the best possible quality applications we can manage. It's that they set newbies up for failure. Even if he did follow the recommended procedures, chances are it would be stuck in contrib for a year or more. Our new developer is unlikely to see that this doesn't really matter as much as it appears, since a truly useful tool will get used, even from contrib and it will migrate into the release over time.

The simple fact is that we have not rewarded independent initiative. This happens over and over on large and small scales. To me, this is the main reason why we don't retain good (or even fair) developers. If they make it past the learning curve, there isn't enough reward. It's open source! If I'm not getting paid to do it or I have the choice on how to spend my time, what is the return to me? (Interested readers are urged to read Eric Raymond's book available from Amazon at, *http://tinyurl.com/5scnac)*

We (as a community) need to think hard about how we support and reward contributors. I'm not just talking about Sakai Fellowships, TWSIA awards, or even grants. I thinking about feel good responses, ego-boosting, or even simple thanks. Just a feeling that, somehow, the rest of the world (Sakai in this case) appreciates the fact that someone spend hours working on a contribution to Sakai rather than play a video game. BTW, this extends to ALL contributors, not just programmers. I include teachers who write up new pedagaogy practices, UI designers, accessibility specialists, QA testers, a CIO who shares the slides she wrote to pitch Sakai, etc. Somehow, we need need to find a way to make people WANT to work on Sakai.

Announcing the Sakai Registry

2007-06-05T09:23:00.000-05:00

I'm pretty excited about the possibilities for the Sakai Registry (see announcement below). I've long felt that Sakai needed a better way to search for tools and other content, so rather than waiting for it to happen, Erik and I tackled it ourselves. The content tools are in place, Erik's done a great job of entering the intial products, and I've contracted for a series of interviews with "The People of Sakai".

The Registry is supported by contributions and advertising. The reason for this isn't so Mark and Erik can get rich (though we wouldn't complain, honest!). Rather, the idea is to have money available to compensate people for their time. Besides the interview series, I'd like to be able to pay (a nominal amount) for papers about Sakai. Wouldn't it be nice to read papers about how Sakai is used pedogogically? Erik and I have a lot of great idea for more content, but it's going to time and money to realize. Hopefully the Sakai community will help support these efforts since, in the end, they will be the ones to benefit.

To that end, we'd love to hear ideas from the community about what's really needed, or even what they'd like to see. Think about technical reviews on Sakai tools, or on-line training on how to use Sakai. Should we publish user/technical manuals? Do people like reading news articles and want more? Let me or Erik know.

- Mark

With each passing release of Sakai there are more tools to choose from, new ways to customize, and improvements to integration. How do you find what you need to make intelligent decisions?

Introducing the Sakai Registry (http://www.sakairegistry.com). The registry is a database of Sakai products: tools, services, and commercial offerings. Using simple search commands, you can browse through over 40 descriptions of tools. These descriptions include information on when the tools was released, what status it has (contrib, provisional, full support), and other technical data. Links are provided to the tool source, documentation, and related information. Screenshots are being added.

You are invited to comment on tools and later you'll be able to rate them.

While initially focused on listing Sakai products, the web site will expand over time to include other kinds of content as well. The first new content is "The People of Sakai", a series of articles about the movers and shakers in the Sakai community. You can read interviews with Joseph Hardin, Jeff Merriman, and Charles Severance. A new interview with Rob Lowden will be posted soon.

The Sakai Registry is a joint project of Mark Norton and Erik Froese. The site is supported by contributions and advertisements. If this site is useful to you, please consider making a dontation and supporting our advertisers. Money will go towards maintenance, expanded content and new features.

If you have any feedback or suggestions, please send them to suggestions@sakairegistry.com .

- Mark Norton and Erik Froese

High Tech in India

2007-01-26T08:01:00.000-06:00

I spent a week in Hyderabad, India during the week of Jan. 7. I was hosted by Vinod Palcharla
of Oracle-India, who will be leading a team of developers to integrate certain Oracle products into Sakai. I delivered a three day tool development workshop to the team to help them get a better understanding of Sakai development and it's key services.

High Tech in Hyderabad

India is an amazing country. Everywhere I saw signs of a people doing everything they can to move from an agricultural society to an information-based economy. Not just in HiTech City, but everywhere Indian people are focused on education and connecting to the global economy. Hyderabad, like Bangalore and Pune, have created conditions that allow multi-national corporations to take advantage of low cost development and skilled developers.

HiTech City rises in a once-rural part of Hyderabad. The transition from regluar city to an enclave of modern office buildings is remarkable. In particular, the architecture struck me. The buildings all have a very modern treatment. They stand in visual testimony to the participation of India in modern age. Even the first building on this site has a graceful, circular form that I think will age gracefully, artistically speaking.

Wandering around this complex is like taking a tour of global high technology. There is the IBM and Motorola buildings. Oracle has a whole campus of buildings. Arthur-Andersen over there and many with no names outside, but quite recognizable inside.

This is the other side of out-sourcing. Easy to be critical from so far away -- jobs lost to a foriegn country. How different to see the positive impact its had on Hyderabad and India as a whole. The western world (U.S. in particular) has concentrated so much wealth for so long. Personally, I like the fact that some of that prosparity is flowing to other places. Even if it makes things marginally harder at home.

Cultural Explorations (click links to see pictures)

Work didn't leave me much time to explore the local culture and history. However, Mr. Palcharla was very kind to spend some of his weekend with me showing me Golconda Castle.
This large fortification was built by three warlord families: the Kakatiyas, the Bahmanis and the Qutub Shahis around a hill. The architecture combines Muslim and Hindu inflences with many remarkable rooms, buildings, and walls. I saw the Raj's hareem (now destroyed), his sitting room with niches for dozens of candles focused through diamons, and was treated to an explanation of the wonderful accoustics used to warn guards of enemies.

Later in the week I toured Chowmahalla Palace, a stately palace of royalty, the Charminar Monument rising from a city square in Hyderabad, and the Birla Temple. The temple was a great experience for me. The temple is constructed in white marble and very beautiful. There are several shrines and I had the chance to be blessed by a holy man in one of them.

Perhaps the highlight of sight seeing in Hyderabad is the Salar Jung museum. Salar Jung was the third Salar (royal Nizam minister) who amassed a collection of art objects from India and all over the world. The museum is extensive and ecclectic, with art from Europe, Japan, China, Africa, and India. Perhaps the most remarkable piece in the collection is the Veiled Rebecca. This life-sized marble statue by the Italian sculptor Benzoni is amazing to look at. The treatment of a fragile veil over the body of young bride-to-be ranks it with the world's great scuplture.

Java - Wide Open

2006-11-13T12:35:00.000-06:00

Sun Microsystems has decided to make Java open source. Is this a good thing? Only time will really tell. I generally favor open source project, but somehow, making Java open source leaves me feeling a bit uneasy. Those who enjoy sausages (as I do) are better off not knowing how they are made or what goes into them. I'm way past that point with open source, though. I know only too well what can go wrong and what goes into the process.

Call me old fashioned, but I *liked* the idea that Sun stood behind Java looking after it's interest. In general, I've agreed with the evolution of the language. The 1.5 release has some solid features that I've already started using. Will that continue to be the case or will we start to see langauge feature creep? Sun indicates that it will continue to test releases and I would imagine that they will have a lot of influence on the directions that things go. Will they continue to support it financially?

If I think about the work that I'm doing -- what changes to Java does Sakai need? None that I can think of. Oh, it can be more efficient. Recent rumors of it running out of memory are not pretty, but that's not a feature, per se. Nope, I can't think of anything, at least in terms of langauge definition.

Naturally, the Java object libraries will continue to evolve. Sun has always considered the object libraries to be part of the langauge (java.*). It's hard for me to think of it in those terms after so many years of Fortran, C, C++, etc, etc. This is the area that I think open source will improve the process -- get several thousand programmers working on improving the object libraries, push them in new directions, update things as technologies and standards evolve, etc.

Sun's stated intent for making Java open source is to encourage new people to use the langauge for new applications. They figure that it will sell Sun products and I hope they are right. On the other hand, they've lost the IDE race to Eclipse and I don't see most of use buying Sun workstations for our home or office, though there are exceptions. Sun does make some mighty fine servers, if a bit on the expensive side.

So welcome to the wild world of open source, Java. It's not all law and order out here on the frontier -- people do occasionally get shot on the street. On the other hand, there is lots of wide open territory. Open to innovation, crazy ideas, and the merits of hard work.

- Mark

Live from Educause

2006-10-11T17:50:00.000-05:00

I'm writing this from Dallas, TX, host city of Educause 2006. I've been to many Educause shows over the past 10 years or so. This one is typical of them. Most of the action happens in the exhibitors hall. So many of the people I've come to know over the years come to this show. It's a bit like a class reunion. I think it's one reason why people continue to come every year -- it's a place to meet friends and colleagues.

Needless to say, the BlackBoard patent was a bit topic of debate. BB held a "Town Meeting", which I managed to miss. There were a lot of jokes made, impassionated hallway conversations, and chair-top pundits all willing to share their veiw. I have to believe that BB is getting a better understanding of the reaction this has caused in higher education. I also believe that it's not too late for them to salvage this situation. Time will tell.

As always, I wander around the show floor looking for cool things, new ideas, heck even slick marketing. The swag has come down in quality in recenty years, so I don't bother much. Glowing yo-yo's seem to be prevalent this year. Ho-hum.

Apple had a very nice booth. Josh Holtzman was giving Sakai demo's there. Josh is a great spokesman for Sakai and it was nice to see him at Educause helping to evangelize Sakai (or was it Apple?). I got a closer look at Final Cut Pro. Apple is now claiming a larger marketshare than Avid. Given Avid's very solid market position for many years now, I have to wonder how Apple defines the market. Still, there is no denying that Final Cut Pro is indeed a killer app for the Mac. One very slick application.

Some may know that I consult to Unicon on a part time basis. Unicon was showing a preliminary integration between uPortal and Sakai. Essentially, uPortal and Sakai have single sign-on via CAS. Unicon wrote a small portlet that shows the active user's Sakai sites. A site can be selected launching Sakai. Kinda cool, but needs more work, which I discussed with John Lewis of Unicon. This is just a small example of how uPortal and Sakai are finally coming together.

The keynote speaker was Ray Kurzwiel, founder of many companies and author of "The Age of Spiritual Machines" and "The Singularity is Now". Ray spoke at length about exponential growth in technology and biology, how it relates to where we are now, and where it will likely lead in the future. He demonstated a hand-held reading machine that would enable a blind person to read signs on the wall, a restaraunt menu, or a book. Very slick. Many people have tried to pick holes in Kurzwiel's analysis, but I find it very compelling, having lived through the early days of electronics, and the rise of the information age. His predictions can be outrageous, but his track record is good, looking back over the 20 years I've been following his work. Much of it is hopeful, and all of it interesting.

- Mark

What will Sakai do about Presentation Technology?

2006-10-03T09:15:00.000-05:00

This was written in response to Chuck's annoucement about the JSR-301 Call for Participation. I've been struggling with JSF for over two years now. While it has some very positive aspects to it, it has a large learning curve and some serious internal problems, especially in the Sun Reference Implementation.

My own work on JSF over the past six months has caused me to shift towards the MyFaces implementation of JSF than the Sun reference model. Clearly there is a LOT more development activity going on here (in Apache) than at Sun. Personally, I'd recommend that we drop the Sun RI and just go with MyFaces. There is no downside, except for some code migration.

Presentation technology continues to be a problem for Sakai, IMO. While I'll be exploring the alternatives in a presentation at the upcoming conference, I don't really have a strong recommendation at this time. Frankly, JSF is a barrier to building tools for Sakai. Yeah, there are alternatives that are starting to emerge, including non-Java ones. For serious and major tools, however, we are still encouraging JSF (is that still true?).

If we are NOT encouraging JSF, then we'll continue to see a proliferation of UI technologies. Already we're seeing Sakai tools written using Struts, JSP, and RSF, not to mention pure servlets. While this flexibility does encourage people to "use what they know", in the long term it's gonna hurt us in (lack of) consistency in user experience. Further, the effort we put into developing cool JSF gadgets won't help a bit to someone writing a servlet.

Rather than point at a particular technology (RSF!!!) and declaring it to be the next great thing, I'd like to explore how we will decide this problem. Comparing technologies is a start, but do we REALLY understand what our requirements are in a UI system? Where do we want this to take us? Can we make a choice now that will hold up for the next 2-4 years? How much of the problem is social in nature (lack of training, documentation, best practices, and standards)?

- Mark

Side-lined

2006-09-30T09:13:00.000-05:00

Took the last two days off to recover from surgery to my left shoulder. I injured it sixth months ago (or so), probably being thrown about in my dojo. Martial arts in my fifties is different than practicing in my twenties, I guess. Anyways, it left me with pain that wouldn't go away, so last thursday a sports medical specialist poked in there to file things down, shave a few loose ends, and generally tidy things up. So far, it looks like a complete success.

I've been doped up for the past two days and I can honestly say that drugs and Java just don't mix, so kids .... stay off drugs! I'm clearing out of the fog this morning and have started back in on work. Too much to do to sit in the living room channel-surfing.

One of the things I'll be spending more time on in the coming weeks is requirements for Sakai 2.4. I've started preparing a Sakai 2.4 Requirements Summary page. You can have a look at it, but it doesn't say all that much at the moment. It does start to shape some of the things that we could work on, but it's not a closed subject by any means. If you have suggestions or things you'd like included, give me a shout.

It's not the job of the requirements group to tell developers or designers how to write code for Sakai, but I do think that we can make the job easier by collecting up requirements, use cases, design sketches, comments from the community, etc. into a central place and then promote what needs to be done. Again, you can help me by telling me (representing the rest of the group) what you'd like to see captured or collected.

- Mark

Seasonal Migration

2006-09-27T09:35:00.000-05:00

The air is a bit crisper here in New England. The geese are flying south for the winter. Migration is an instinct for the geese. Too bad data migration isn't instinctive as well.

We had a phone meeting of people interested in moving data into and out of Sakai yesterday under the banner of the Migration Working Group (Mig-WG). The key thing coming out of this meeting was the creation of five sub-projects related to migration:

Vender Content Migration
Sakai Archiving
IMS Course Cartridge Support
Open Courseware (OCW) Support
Migration Architecture

Have a look at the meeting notes for more information.

Naturally, the architecture of migration is of keen interest to me. Zach Thomas has started crafting a migration architecture that should serve as the basis of an archive or migration service in Sakai. This approach calls for parsers and handlers that are registered with an archiving service. It has the nice feature of scanning through parsers to see who can handle a given package to be imported.

One idea that I've kicked around is creating some form of abstract content to serve as an intermediate data structure for import, export, and data handling. It seems to me that if we created a set of objects that describe content and how it is organized, it would enable n-way movement of data. For example, it would allow us to import and SCORM package and export it as OCW. It would allow us to select a collection of Sakai content and export it as an IMS Course Common Cartridge, or QTI Question Pool, etc. This content abstraction would be in-memory only and ephemeral, it's not intended to be persisted -- that's what content hosting does.

This is not a big step from the architecture that Zach has laid out. It does, however, prepare us to handle export, which we've kinda avoided so far. Export, especially for Common Cartridge, will be an important part of Sakai 2.4.

- Mark

Group Providers and Eids

2006-09-22T20:08:00.000-05:00

As part of my upcoming workshop on integrating Sakai into enterprise environments, I'm writing a pair of user and group providers that will access a dummy student information system implemented as a set of MySQL tables. Conceptually, these providers are simple: they enable Sakai to sorta "look over there" for information about a user or a group.

Of the two, the user provider (UserDirectoryProvider) is more powerful. A UserEdit object is passed to the provider (in several of it's methods) which is completed by the provider implementation, presumably drawing on a enterprise-wide information service such as LDAP, CAS, PeopleSoft, etc. Using the user provider, you can pretty much use an external system of record to maintain your user definitions.

However, this is not the case with the group provider. The group has two important methods:

getUserRolesForGroup -- pairs of user ids and roles for a given group.
getGroupRolesForUser -- pairs of group ids and roles for a given user.

For this to work, however, the group must already be established on the Sakai side of things. In part, this is because the group provider is really only getting information about members of groups (and their roles) or determine which groups a user is a member of. It is used to implement authorization on the Sakai side, and thus requires that sites be defined in Sakai, not elsewhere.

Earlier in the year, I developed a way to access Sakai tools from MIT's Stellar course management system. One of the big stumbling blocks was that authorization was defined on the MIT side of things and was required to remain there. Further, there were thousands of sites defined in Stellar that (in theory) would have to be provisioned in Sakai for the tool integration to work.

I got around this problem by adding a few new methods to the group provider:

isAllowed() - an authorization check.
isGroup() - check to see if this group is known to the enterprise
getAllowedFunctions() - get the list of allowed functions.

with some modifications to the BaseAuthzGroupService code, these functions allowed authorization to be moved external to Sakai.

I have the code around, if people are interested. The modifications to the authz group implementation was such that if external authorization wasn't implemented, it would fall through to the current database solution. Is this a useful thing to include in a future release?

Enterprise Ids

Josh Holtzman recently lamented that he was bit repeatedly by Ids vs Eids while developing providers for the new course management service. Even in the existing providers, the use of these two identifiers is confusing. It's quite clear what the difference is: the user id is the Sakai identifier, the Eid is the enterprise identifier. They could be the same, since user ids can be supplied when the user is created, but I believe we are trying to establish a practice of letting the system assign a GUID.

Regardless, I also had quite a bit of trouble with my test harness and use cases trying to get Sakai to understand the equivalence of a given user id and her eid. Likely this is due to my lack of understanding, but how DO people figure this out? There is some documentation, but frankly, it doesn't help much when it's time to code.

Ids and Eids will figure prominently in my up coming workshop. It's something that developers need to have a good understanding of if they are going to implement providers or do other kinds of system integration with Sakai.

- Mark

Course Cartridges, Requirements, and Integration

2006-09-15T15:09:00.000-05:00

Well, it's been a busy week in spite of not being out in Ann Arbor for Sakai Integration Week. I miss the geek-intensive meetings we used to have in previous years, but Chuck tells me that he'll be setting something up soon, perhaps connected to the Atlanta Conference.

Course Cartridge
Some may know that I've been working with Zach Thomas and others on moving data around for Sakai. This has several aspects to it including archiving, data migration from other CMS environments, portable portfolios, Open Courseware support, and IMS Common Cartidge. You can learn more about this at the Migration Confluence Site but what I want talk a bit about is Common Cartridge (CC).

For years, the major textbook publishers (Pearson, Thomson, McGraw-Hill, etc.) have made their content available electronically and often augment a textbook with on-line material. Professors who select one of these books can get a "course cartridge" which is a piece of data enabling content access from a course environment. Many of the leading course environments support such things (BlackBoard, WebCT, Angel, etc.)

Early last year, Sakai hosted a meeting out at Foothill College with publishers to discuss support for this kind of content in Sakai. Chuck Severance suggested that what was needed was an industry standard rather than writing custom access for each CMS and volunteered IMS to manage it. Well, this led to a course cartridge guideline last year, and the development of a specification this year. The spec isn't done and won't be until next year, but the key aspects of it are firming up nicely. IMS gave an industry briefing on it last week in Lynnfield, MA.

The course cartridge specification is a profile of IMS Content Package. That means that it perscribes EXACTLY how content package is used to create a common cartridge. It's very specific in what it allows and what it doesn't Data types are limited, but include most of the things that people would like to distribute as content: web materials, learning objects including SCORM, assessments based on QTI, etc. Content can be either in the package, or accessed remotely. Provisions are made to define authorization and the Tool Interoperability Guildlines (also jump started by Sakai) is used.

While the spec has a ways to go, Zach has already got prototype code up and running as part of the new archive module additions in 2.3. This was based on demoware shown at alt-i-lab last June in Indianapolis. With today's code freeze, archiving functionality is final, but we'll be testing it against sample cartridges and tweak it up for robustness. Meanwhile, I'll be attending the CC spec meetings and helping the Sakai development team to stay on track for conformance. I think this will be a very important feature in the future and it's very cool that Sakai is out in front of it.

Requirements WG
Mara Hancock stepped down as the chair of the Sakai Requirements group after doing an outstanding job of establishing this group. I led my first meeting of the group today. There was a lot of discussion on how the process has worked to date and how it can be improved.

Simply put, the requirements group has the job of getting people to make suggestions and working with those people to refine them into a form that will encourage designers and developers to step up and work on it. Refining them means collecting use cases, extracting requirements, and perhaps guiding early design efforts. Naturally, I'm open to any ideas any of you may have in making this process better. Sakai is a community of volunteers and generating work enthusiasm is a big part of getting things done.

Part of promoting this process will include several events at the up coming Sakai Conference in Atlanta. The REQ-WG will report out on the process to date, examine some success stories, and explain how the Sakai development process is very different than developing a commercial product. We are also exploring the idea of have a requirements writing workshop, perhaps in conjunction with the UI Book Camp. All TBD at this point, but interesting.

Integration Workshop
I'll be presenting a Sakai Developer Workshop focused on integrating Sakai into enterprise environment on Oct. 16 - 18, 2006 in Phoenix. There are still places left if you are interested in attending.

Meanwhile, I'm working on finishing up the material for it. I'm writing a small tool that displays a list of Sakai sites. If you click on one of these links, you see a page with all members of that AuthzGroup. You can then click on one of the group members to see their full name and email address. Besides illustrating how to use various Sakai services, this application will serve as a test harness for workshop participants to write Group and User providers. These providers will interface to a dummy student information system that I've put together in a MySQL database that will run locally on a LAN. I'm writing the sample providers now.

Part of the course will also include writing an application to populate course sites using SakaiSpeak (our web services system). While the app could be written in PHP, Perl, or Ruby, we'll probably do it in Java since it's already a requirement for the workshop. The test application (MemberTool) will show new course sites as they are added by the webservice application.

- Mark

The Blogosphere Comes to Sakai

2006-09-13T12:26:00.000-05:00

Steve Githens has created Sakai Planet to aggregate blogs about Sakai. Personally, I think it's a great idea to bring together people's thoughs in one place. Since I've used TechnoMark as my off and on technical blog for a while, I may as well feed it into Sakai Planet as well.

This is integration week at UMich. Sadly, I have too much going on to be there. I'm still juggling work on the IMS Common Cartridge specification with supporting Zach Thomas and his archiving work, ramping up to speed as chairman of the Sakai Requirements WG, preparing for Educause, and finishing off the development of a new Sakai workshop focused on system integration (see http://www.unicon.net/training_887.html to register).

Lurking in the background is a JSF bug that's had me stumped for months. Even a very simple JSF program (literally Hello World) doesn't render, dumping XML into the browser instead of rendered HTML. I've spoken with many people about it, but few clues. It's hard to debug this stuff, too. Well, I'll get back to it as time allows.

I have to admit it's been great to have the OSP confluence site and lists folded into Sakai. It's a lot easier to track what's going on there now and get a better idea of how OSP integrates into Sakai. There are some really outstanding tools that are not getting the visibility that they deserve. Hopefully, we'll see more at the upcoming Atlanta Conference.

Speaking of the conference, the conference commitee is coming together nicely under the leadership of Brigid Cassidy. Brigid accepted the role of Program Chair a few weeks ago and already has things organized and moving forward. I think Atlanta is shaping up to be a really great conference.

- Mark

Over Worked

2006-05-15T15:39:00.000-05:00

The past five months have taken their toll on me. The fault is purely my own. I took on too much work! Forty hours a week sounds like a normal workload for most, but to a contractor, that's 40 hours excluding breaks, meals, errands, distractions, travel, etc. It was too much. Add to that the stress of working with undocumented software and the pressure to produce a miracle and it leads to ulcers (or depression).

Well, one of those contracts is due to end at the end of June. I didn't accomplish as much as I'd like, but the contractor got what they asked for within risk parameters specified up front. I am happy to have proved the concept that I recommended to them. The Sakai framework can be used independently of it's custom portal and UI aggregation system. Sakai tools can be made to work in other UI environments. I'll be reporting on the (nominal) success of this approach at the upcoming conference in Vancouver.

So I'll be cutting back on my hours for the remainder of the year. Something in the 20 hours a week range would be good. That will allow me to explore some things of my own. Develop a new workshop that I plan on giving in the Fall. Contribute to Sakai purely as an independent developer. Etc.

I need some down time.

- Mark

Change in Focus

2006-01-26T15:11:00.000-06:00

With arrival of 2006, I have nailed down by contracts for the year. While I will still be on staff with Sakai, it will be at a substantially reduced amount of time. I'll continue my architecture work, but the bulk with be focused on training and documentation.

Meanwhile, most of my time will be spent working for MIT integrating Sakai into their Stellar Course Management System. I need to strip down the Sakai offering and integrate key Sakai services to Stellar data sources. This will be done using providers, adaptors, or out right re-implementation (if necessary). Stellar wants to use three Sakai tools: Message Forum, Samigo (Quiz and Test), and Gradebook. In addition, an image archive tools is being built.

Finally, I'll be working with Unicon to improve their Sakai offerings and perhaps do some training for them.

It's gonna be a busy year (I'm already over committed).

- Mark

Headed for 2006

2005-12-27T08:31:00.000-06:00

Looking back on 2005, it was a good year for me and my work. Sakai is coming along slowly. I don't agree with all of it's directions, but it is a collaborative effort, so I expect some things to be different.

With the transition from project to foundation, Sakai will have less money to spend on staff next year. I'm looking at several business opportunities, primarily working at MIT to help them migrate their Stellar course management system to being based on Sakai. That should allow them to leverage Sakai tools.

Meanwhile, I'm expanding my training program by developing new modules for it, collecting material for a book, thinking about various programming projects, etc. Life is both rich and full. With Brigid (my wife) joining me in my consultancy, we'll spend more time traveling together and less time apart. I like that.

- Mark

Travel

2005-06-29T07:42:00.000-05:00

Life is full of opportuities and distractions. I'm finally getting back into the regular routine after two very full weeks of travel.

First to Baltimore for the Summer 2005 SEPP Conference. As usual, I was in the thick of it. Several presentations and discussion groups to manage. I attended others and contributed where meaningful. The theme of this conference was governance -- how will Sakai run itself in the future? People are starting to wake up to the fact that it's a community and that we all need to contribute to the best of our abilitities. The board will continue on as it current does, though some of the members will likely change. Beyond that is anyone's guess at this point.

I was home for 24 hours and then boarded a plane for Armenia. USAID invited me to organize and deliver a 3 day workshop on developing Sakai tools. The workshop was set up as lectures in the morning and hands on coding exercises in the afternoon. Forteen people worked through a series of exercises that culminated in a simple JSF-based tool to manage notes. In general, it was a success, though some things could be improved.

Armenia is a country at an interesting point in its history. Emerging from the Soviet influence and a terrible earthquake several years ago, the economy is starting to blossom. Tourism is up. Capital is starting to flow in. There are many construction projects in Yerevan (the capital city). People are busy, well-dressed, and seem happy. Wander outside of the city and you see a very different story, however. The country is very poor. There is no industry, only agriculture. While the land is fertile and there is water, I have to wonder how the properity of the city will be shared by the outlying villages.

We have meeting next week in Cambridge, an all-hands Sakai meeting. These meetings tend to be group status communication, high level coordination, etc. It's hard to get any real work done, but the breakout sessions allow for some of that. The Sakai Architecture Team (of which I am/was a member) is scheduled to meet, which is strange in a way. Charles Severance has largely disbanded this group in favor of a Sakai Developer's Meeting to be held at Yale next month. No doubt we will find things to talk about, but there is no real process, IHMO.

The Discussion Groups are getting active. The Enterprise Group had another call yesterday and seems to be moving ahead in figuring out how to integrate Sakai in enterprise environments. They have a lot of work ahead of them and it's good see some action. The Content DG needs to be revived. The previous leader stepped down. We have a new volunteer, but nothing has happened yet.

No travel planned for July so far. That's fine with me. I can use some home-time.

- Mark

Welcome

2005-06-04T08:42:00.000-05:00

Welcome to TechnoMark, my technical blog. My name is Mark Norton and I am an independent consultant working in the field of eLearning for universities. Currently, I am primarily engaged as a Senior Technical Consultant to the Sakai Project (http://www.sakaiproject.org). This project has been running for the past two years or so and grows out of the CHEF project at the University of Michigan and the Open Knowledge Initiative managed by MIT. Other key contributors to Sakai include Indiana University, Stanford University, UC Berkeley, Foothill College, and many others.

For more information on what I do, please see http://www.nolaria.org.