Can’t want what we don’t know about
Categories: SCORM Cloud, SCORM Engine, Software Development
1 Sep 2009
Once upon a time, there was no sliced bread*. And people were happy because they didn’t know they wanted sliced bread.
Then someone gave them sliced bread. Suspicion, amazement and eventually joy erupted. Suddenly, they wanted, no needed, sliced bread. These days, it’s tough to sell bread that isn’t pre-sliced.
It’s a common problem in product development – delivering something amazing you know people will want but can’t ask for because they don’t even know it is possible. (Face it, did you know you needed TIVO before it came along? I’m waiting for a radio version, pretty please!)
I’m seeing a little of this as I explore the LMS world. Lots of talk about reporting and what should be there and whether anyone cares and who should care. I see admins refusing to bother because no one asks for anything other than the bare bones already provided. I see trainers who would love to know more but figure their LMS just can’t deliver so they suffer in silence. I see instructional designers who feel there has to be a better way to judge the success of a course than just a single score at the end.
Lots of talking, not much asking, very little doing.
One of the nice things about SCORM (yes, there are a few) is the amount of data that just naturally gets created. As we wrap up integrating the SCORM Cloud with various open-source LMS packages, the question of reporting has come up. Not whether to report, but just what and how to format the reports. We already know we can slice the bread; we just have to figure out how thick to make the slices and whether to toss in some butter and jam.
Wanna help us shape up LMS reporting? How would you want the SCORM Cloud (and likely the SCORM Engine by default) to deliver reports and what do you think you want to know? We have some devilishly clever ideas but welcome yours.
*After Tim wrote about bread on a software company blog, I had to figure out a way to include it as well. Bread. With butter and jam. Seriously. These posts make me hungry.
1 Comment | Post a comment »
SCORM in “the cloud”, and what we’re doing to TestTrack now
Categories: Products, SCORM Cloud, SCORM Engine, Software Development
13 Apr 2009
A few weeks ago, we released the new version of our website (which has been well received) and upgraded our servers. TestTrack, our freely available testing application, has been growing constantly and was overloading the server on which it lived. The transition went very well, the 404s have been handled (for the most part), and things are functioning as we all wanted.
During the process, TestTrack was down for a period of time, and our phones started ringing. People really depend on TestTrack. We’re glad. We want folks to use it; it helps us get better and it helps further the standard as a whole.
So, for all you who depend on TestTrack, let this be your warning. We’re doing something new with TestTrack again. We’re about to move TestTrack from a traditional SCORM Engine installation to our newest release… something we’re really excited about. We have developed a hosted/cloud based version of the SCORM Engine, the SCORM Cloud.
5 Comments | Post a comment »
Scalable Storage Using Amazon’s Elastic Block Store
Categories: SCORM Cloud, Software Development
24 Mar 2009
We’ve recently completed development of a hosted version of our SCORM Engine. In the coming weeks we will be transitioning TestTrack over to using the hosted Engine to enable much greater scalability than the single server install can currently provide. This project will involved liberal use of several of the Amazon Web Services, due largely to their ease of use, low cost and high scalability. Using the Elastic Compute Cloud (EC2) was an obvious choice for us, as we can easily create and destroy machines as our load fluctuates. Less obvious, however, was how we should go about storing content files. These were our requirements for a storage device:
1) easy ability to upload large files using standard FTP clients, and possibly other commonly available protocols. Files over 1 GB aren’t uncommon, and larger files than that are certainly possible.
2) real-time file updates (i.e. when I upload a new version of a file and then immediately request it, there should be no chance that I get back an older version)
3) small amount of storage for now (so it’s cheap) with the ability to grow to a few TB or more as demand requires it
4) storage should all be accessible at a single root location. We currently have files spread over two drives, which requires a small bit of one-off code to determine which files from which users go on which drive.
5) ability to access the content directly from any one of (potentially) several web servers
6) some form of backup and/or redundancy to prevent data loss
Amazon currently provides two different mechanisms for persistent storage: Simple Storage Service (S3) and Elastic Block Store (EBS). Each of these storage methods has its advantages, but at first look, neither will fulfill all of our requirements straight out of the box.
2 Comments | Post a comment »
Tests like these are why you buy the SCORM Engine.
“What is that?” you might ask. This is a dashboard widget that we maintain on our big screens in the two offices. Anytime you walk through the common space, you get a quick look at this dashboard. Each row here represents a fundamentally important automated test of the SCORM Engine. Green is good news; pink is bad. (Truth be told, I’ve been waiting several days to catch some portion of this screen pink. Things are very stable around here right now, and I thought an “all green” dashboard was a bit contrived. Further truth be told, catching this screen shot half pink might be retaliation for David eating my ice cream yesterday.)
No Comments | Post a comment »
Convert C# to Java Source Code
Categories: Products, Software Development, Uncategorized
17 Aug 2007
The users of our SCORM Engine predominantly run their LMS’s on the Windows platform. To best serve their needs we coded the SCORM Engine using C# on the ASP.NET platform. We’ve long known that we were ignoring the significant population of customers who prefer to develop using Java and deploy to Linux (or any other non-Microsoft platform). We investigated several solutions for supporting these customers and came up with some okay alternatives that allowed us to fulfill the customer need, but they all had one shortcoming or another. Back in November we embarked on an ambitious project to convert the SCORM Engine from C# to Java….automatically. We tapped the expertise of Kevin Glynn to develop a tool which automatically converts C# source code to Java source code and I’m proud to announce that it is complete. We now have a tool capable of translating C# to Java at the source code level. This tool will allow us to support both major platforms concurrently while only maintaining a single code base and still providing full source code to our clients. Initial tests show that the Java version of the SCORM Engine performs comparably to the .Net version and in some cases is even faster. The technology is amazing and we may offer it to others in the future. For now it is just an internal tool, but if you have an interest in it, please let us know as we are batting around the idea of commercializing it or releasing it as an open source product. More info available here.
