SCORM 2.0 White Paper

So, my white paper is at a draft stage.  I essentially have all the data I need to complete it but it still looks ugly.  I need to clean up the graphics and make them attractive and put the paper in the correct layout.  The IEEE uses a two-column format for white papers, so I will need to lay out my paper in the same format.

Essentially, I have put together a concept for SCORM sequencing that removes the burden of the sequencing engine from the LMS vendor and puts the responsibility on the content creator.  Really, the LMS vendor doesn't know how the content should flow, only the content creator will know that.  Instead of using some really complex XML grammar to tell the LMS sequencing engine what to do, I have proposed a JavaScript event model.

So, whenever a SCO terminates, the LMS will call the OnTerminate event for that SCO.  The JavaScript code for that event is in the Manifest, so it is still outside the SCO.  Being outside the SCO means that we do not break the encapsulation of that SCO and it will still be reusable.  All you have to do to reuse it is build a new manifest with a different organization - which is what you would have to do in SCORM 2004 anyway!

I will have this paper out to the LETSI group soon and I will post a copy on this blog.

Vizdos

I recently blogged about my trip to Tampa for a Certified ScrumMaster (CSM) training course.  I just wanted to say that it was pretty cool.  The guy running it, Mike Vizdos, was a pretty good facilitator and we had a great group there.  There where some developers from Chase bank, the Home Shopping Network, the Orange County School Board, and me.

Thanks Mike.  The class was worth the money.

Scrum Roles

I have recently been very excited about Scrum and agile software development in general.  Today, I was thinking about the team roles in Scrum.  Scrum has only three roles - Product Owner, Scrummaster, and Team.

The Team role includes all the people that actually do the work.  This means you have coders, testers, business analysts, DBAs, architects, and whatever else you may call your people.  Scrum lumps them all together to enforce the "we're all in it together" attitude.  An important way to look at a role in a team is to look at what things that role has control over.  The team controls the source code.  Only the team can make changes to the product and they have to decide how to make those changes in the most efficient way that meets the organizational polices.  Trying to decide between MSSQL, Oracle, or MySQL?  The Team decides.  Trying to decide between C#, Java, or Ruby.  The Team decides.

The next role is the Product Owner (PO).  The PO is responsible for defining and prioritizing the product backlog.  The PO owns the backlog.  No changes can be made to the backlog without the PO's involvement.  What that means to the team is that all the outside influences of "can you do this for me" should go through the PO.  This is the guy that everyone has to talk to if they want a feature added to the product and she has the authority to say "no" to any feature.  Of course, the way you say "no" in Scrum is to add the request to the product backlog with such a low priority that it will never get done.  Everything goes on the product backlog, even if it is just plain stupid.

The last role is the Scrummaster.  Scrummasters are there to facilitate team communications and educate everyone (inside the team and out) on how Scrum works and what the basic operational rules are.  The Scrummaster owns the process.  Some will debate me on this point, but I think the Scrummaster should also own the engineering practices.  The Scrummaster sets the benchmark for organizational compliance.  For example, a Scrummaster may set the organizational policy that a daily build is required for all projects.  This policy is "bigger" than one team.  The Scrummaster does not own the team's internal procedures, he only deals with the policies.  For example, at my organization there is a policy to "use C# unless there is a compelling reason to do otherwise."  As such, 90% of our projects are on the .Net framework using C#. 

But, there is a second responsibility that the Scrummaster has that is less obvious.  The Scrummaster is the team facilitator.  He guides discussions in meetings and helps to ensure time boxes for events.  The Scrummaster has to get the team members to talk to each other and collaborate.  This is no easy task.  Let's face it, most of the programmers we work with are introverted and weird.  The are non-communicative and more at home sending IMs to each other than speaking.  They hang a picture of their avatar in a nice frame in the hallway.  They are not the kind of people that want to talk or share or socialize or go outside when the sun is shining.  Scrummasters have to break through the team's tendency to avoid communication and get them to be agile and collaborative.

There one last role that I should point out, even though it is not a Scrum role.  That is the "everyone else" role.  Managers, marketing guys, executives, and users all fall in the "everyone else" group and should address all their concerns with the PO or the Scrummaster.  They should not disturb the Team during a sprint.  To disturb the team during a sprint has a few specific effects.  First, it slows the team down and reduces their velocity.  Second, it undermines the authority given to the PO.  This is a big deal because the team needs to look at the PO as the authority on the product features.

So, the Product Owner owns the backlog, the Scrummaster owns the process, and the Team owns the work.

ActionScript and JSON Idea

I just had a new idea.  Or, at least it's new to me.  The idea is a framework for a Rich Internet Application (RIA) that allows a Flex-based RIA to communicate with a server-based database using a RESTful JSON communication channel.

The thing that makes this idea different is that the server would not just use JSON to serialize the data, but would actually embed methods into the object with ActionScript code that implements a full ActiveRecord or ActiveResource pattern for the object being retrieved.

So, in the RIA client we could have some code like this:

1: var prod:Product = Product.Create();
2: prod.name = "my product";
3: prod.Save();

So, on line one we have a factory method that creates a new Product object by calling the http://server/product/create rest method and getting back a block of ActionScript code that it can Eval() into an object.  This product object then has properties that can be read or written and methods for saving the data.  The Save() method on line three actually fires off an http request to the server to save that specific record in the database - http://server/product/save/42 where 42 is the primary key value for this object.

The great thing is that the server side code generator and REST API should then be completely generic across all RIAs.  All the custom application logic is in the RIA, not the server.  The server is only responsible for authentication/membership and data persistence.

RoR is the Mac User's Programming Language

I like to keep an open ear for new technologies coming out, especially in the software development arena.  One new item that a lot of people are raving about is Ruby on Rails (RoR).  So, I decided to check it out.

I found out that it's made by a bunch of Mac users.  As most computer professionals know, Mac users all fall into one of two categories.  The first (and larger) category is grandparents that can't type much less use a computer.  This is the group that believes having more than one button on your mouse is far to confusing.

The second group are the elitist non-conformists.  This is the group that believes it is more trendy and cooler than every one else.  This group buys into the idea that owning a Mac somehow makes you more special and accepted into a cult community of arrogant elite users and ultra-hip cool guys.

Well, the Ruby community is in the second group and keeping that stereotype alive and well.  To be fair, RoR is a pretty neat framework with some awesome features that other frameworks just don't have.  You can roughly accomplish the same stuff with .Net or Java but you would have to combine several third party libraries and code generators to do it.  RoR is a sweet little package that gains all of its efficiencies from one central theme ... convention over configuration.  What this means is that RoR has already made most of the design decisions you will ever need to make for your application for you.  You will build database powered web applications with RESTful interfaces that implement a CRUD interface using the Model-View-Controller pattern.  You will use ActiveRecord, and the other framework-provided base classes.  If you don't do this, then your application is, according to the RoR mantra, wrong and stupid.

The RoR founder, DHH, came right out and said that they are not interested in any new innovations from other languages, but will impose their conventions on everyone else.

All in all, I am a little put off by the whole idea that I have to join the movement or I am not really a RoR developer.   But, what do you expect from a Mac user?

ME the Scrummaster

I will be traveling to Tampa, FL this week (Thursday and Friday) to attend a Certified Scrum Master (CSM) training session hosted by Michael Vizdos.  I have read a couple of his books and his web site seems funny.  Hopefully I will learn something about Agile in general and Scrum in particular.

SCORM 2.0 Call for White Papers

The ADL community has turned over the development of SCORM 2.0 to the LETSI organization. LETSI has just put out a call for white papers that will be used to shape the next version of the SCORM specification. You can find some more info on the status of SCORM 2.0 at the LESTI web site.

I am in process of authoring a white paper for LESTI that I hope will help the community. The basis of my white paper is a revamping of the SCORM sequencing and navigation model. The problem I see is that SCORM attempts to use an XML grammar to describe the logic of sequencing. XML is not a logic language; it is a data language. I propose a way to replace the XML based logic grammar with an event based ECMAScript model. This allows the content developer to program their own sequencing behaviors above and beyond what SCORM has envisioned and do it in a way that clearly separates the concerns of the LMS vendor from the content vendor.

I'll have more on this as I flesh out the paper a little more. If you are interested in submitting a white paper, please see the LESTI site soon as the deadline for submission is August 15, 2008!

I'm Finally Taking the Plunge

Yes, I have created a blog. This is a day I thought would never come. It seems that I have all these crazy ideas and I want to put them down in print somewhere and a blog is the easiest way to do that. So, here it is.

I will be brain-dumping stuff about SCORM, ASP.Net development, C#, Design Patters, Agile Development, and a bunch of other stuff you can find and 47,386 other blogs -- but this is the only one that has my adorable face on it.