Archive for the ‘News’ Category

posted by | Comments Off on Letter from a Customer

Recently, in response to some inquiries from some Financial types, we reached out to a couple of knowledgeable customers [and one partner]  asking them:

If you didn’t use Bright, what would you use?  Who do you think our competition is?

This is relevant to us as Bright sits firmly in the middle of the Build vs. Buy debate.  So, it can be a bit difficult to say who we are actually competing against.

In any event, one of our customers sent us this, which I attach here:


We Did It Again


posted by | Comments Off on We Did It Again

Are we serious about the availability of our service? You bet we are.

Some metrics of how serious we are:

* 87 remote monitors on everything from web server response, disk space, swap space, DNS, job status, you name it.
* As of June 2015, we had 110 automated tests. As of today, the # has topped 260.

How does it manifest itself? Here’s an excerpt of an email I received from a customer who monitors the uptime of all of their cloud vendors.


Why is it title: “you did it again?” It’s not the first time we’ve been measured at 100% available for an entire month. Word in the Aura lab is, “next month, we go for 110% available”.

posted by | Comments Off on Customization Testing Framework

Bright is super powerful, really. During a demo last week, our partner/re-seller said “I can do anything I want”. Or something like that.

Only problem [at least from our perspective] is the proliferation of Bright customizations in the wild. This can be a bit stressful when we go to change “Bright core”. How do we keep from breaking all those cool client-side customizations!??!?!

Part of the problem has been the testing architecture of Bright itself. Bright server, tested to the hilt. A continuous integration chassis is testing Bright server up pretty much day and night. If it breaks, it’s because we didn’t write a test. Easy to fix.

Nice, but in the end, Bright is primarily used to serve web pages in “other” web stacks. How do we keep track of all that UI code sitting on top of the Bright API?

As an experiment, I decided to rig up qUnit onto the Bright.js library core. We added a special settings option in the Bright plugin for WordPress:


Set that, and next thing you know, your web pages are running the new Javascript test chassis. One nice thing is if this isn’t set, all the test javascript isn’t loaded. So there’s no performance impact on production sites.

With jstest=true test, here’s an example of the test output.


The best part? Adding tests for client customizations, super easy!

For a Bright customizations plugin, just add something like this:

Now add some tests:

UGH CODE!!! Yeah don’t worry about that too much. Translated for humans, we’ve made it very simple to write unit tests for Bright templates. Testing rocks!

posted by | Comments Off on License Management in Bright

Developing e-commerce solutions for SCORMCloud is an emerging business for Aura Software, and we are happy to hear that Rustici Software AKA SCORMCloud will feature Bright in a business case on ecommerce to be published on the website. I just have to get around to writing it….

Since we’ve been talking to Rustici about ecommerce a lot, we have had the opportunity to talk to many prospects interested in using the Bright + SCORMCloud + WordPress + WooCommerce system.

One of things that has fallen out of these conversations is the need for license management in Bright, wired straight into the shopping cart.

The idea here is that a customer might want to buy a 1000 seat license in a single transaction, and then distribute the license internally [or externally] to their organization. You also might want to combine licenses for multiple courses into single transaction, and of course, there has to be reporting.

It seems that many learning content producers make these kinds of deals already, in some cases with considerable manual work or one-off coding. This is something that we feel we can make as seamless as regular single-user course buys already are in the Bright WooCommerce Integration Bridge. Coming soon!

How will it work?

The thinking at the moment is that during checkout, a custom checkout field would be provided for the cart:



When this is set, instead of an actual course registration being generated via the completed purchase, a license key will be generated and attached to the user’s order.  The license data will be written into the Bright server, storing the associated courses and the # of seats available.

This key can be used in the following fashion:

  • A user can attach this key to their user profile, and we will provide extensions that will allow user profile fields to be mapped to license keys.
  • Thus, when a license key is added to a user’s profile, an API call will be generated which will associate the user with the license.  This call will have the side effect of generating the appropriate registrations for the user.
  • By using Bright templates that require an existing course registration, the net effect of this will be to grant access to users who have added the appropriate license keys.
  • The Bright API will insure that the seat limits associated with the key is enforced.

This model supports:

  • reporting by license key
  • multiple license keys per user.




posted by | Comments Off on Momentum?

Based on Google analytics:

– the best 4 months in terms of traffic for are #4: Feb 2015, #3 Dec 2014, #2 Jan 2015, #1 Mar 2015
– March 2015 ….. our best month ever by a huge margin [30%]!

posted by | Comments Off on Forcing completed registrations to be passed

For occasions where you have rogue courses that don’t update their “passed” status, but you WANT or NEED the course passed in Bright, you can set a custom course property in your Bright metadata:


The field name is “completion_means_success”.

With that set, every time a registration is updated for this course, if the registration is marked ‘complete’, it will be ‘passed’ as well.

Note, this may not fix existing registrations that were updated BEFORE the change. But no worry, our awesome support will fix that for you in a jiffy.

Under the covers, this is a “after_crawl” registration hook compiled into Bright server. There’s LOTS of things you can do with hooks….

Got “custom” work you need to do to your registrations every time they are changed [aka launched]? Ask us, we do that.

posted by | Comments Off on “Please make a selection” error in SCORMCloud

In some cases, we see issues with existing registrations where when launched, they produce the following errors in the SCORMCloud player: “please make a selection”. At this point, the course is frozen and the only workaround is to reset the registration.

After several months of debugging and troubleshooting, it seems that the source of the problem is somewhere deep in the bowels of the sequencing features of the SCORMCloud player.

In working with Rustici, it looks like a two phase fix is in the works.

Phase 1 will be a bugfix for the “alwaysFlowToFirstSco” course property [which currently doesn’t work correctly and thus can’t be used to workaround the problem]. As described here []:

“If true the SCORM Engine will always load the first SCO in a course upon initial launch regardless of whether sequencing rules dictate this behavior. “

For courses with a single SCO, this will be sufficient to fix the problem. This bugfix is in progress for SCORMCloud [April 2015] so we expect it shortly.


Note this option is default setting.

In phase 2, the sequencing engine will need to be fixed. Release date for that is TBD.

Got questions about SCORMCloud? Ask us.

posted by | Comments Off on Performance of Bright versus the SCORMCloud plugin for WordPress

One of the most common questions we get is, “what does Bright for WordPress do that I can’t do with the SCORMCloud plugin for WordPress?

Invariably the topic of performance comes up.  What we say is the performance of the SCORMCloud plugin for WordPress scales according to the # of courses on the page.  So it is “linear”.  In contrast, Bright performance is flat …. which means more courses doesn’t result in more time.

So today I got a support request from a customer to look at the performance of a page.   It seems that they’d embedded 5 courses on the page, but used the SCORMCloud plugin, not bright.

It was taking about 21 seconds for the page to respond:



So I just replaced those embeds with Bright embeds.  There’s even a “SCORMCloud classic” embedder template that replicates the look and feel of the SCORMCloud plugin; so you can’t even tell that it was changed.
Then I refreshed the page:




OK even we grant that this call took a bit longer to setup [for DNS lookup]; we killed it.  Wait time went from 21.08 seconds to 1.75 seconds.

So with Bright, the page load time is 8% of what it is using the SCORMCloud plugin; or 12x faster.  As the SCORMCloud plugin gives linear performance, you can expect it to be 24 times faster for a page w/ 10 courses on it, and so on.




Curious on how to speed up SCORMCloud applications?  Ask us …. we do that.

posted by | on , , | Comments Off on A brief history of LaunchHistory [ies]

SCORMCloud maintains launch history, but so does Bright.

But they are totally different animals.

In SCORMCloud, launch history is recorded, in Bright launch history is ‘captured’.

HUH WHAT!? Yer talking …… MADNESS!!!!

But all kidding aside, what’s the difference [there are lots of Bright blog posts with this theme]?

  • in SCORMCloud, a course has to write its own ‘launch history’ data.  So if its a TinCan course, for instance, there’s no launch history.  Also for misbehaving courses, you may also get no launch history.  In the world of debugging, this can be a big bummer.
  • for Bright, we capture the fact a course has been launched before it happens.  This means that you get launch history for TinCan and you get it even if the course didn’t load correctly.

That’s what I mean the difference between recorded and captured.
So we does the Bright launch history include?   Lots of goodness!  Check it out:


Now this is just formatted JSON like is returned from the Bright API:

  • id – that’s just an internal reference.  Unlikely to be of much use.
  • registration_guid – for SCORMCloud, that’s the registration ID.  For other types of course providers, the unique ID for that resource.
  • course_guid – for SCORMCloud, that’s the course ID.  For other types of course providers, the unique ID for that resource.
  • learner_id – that’s the user.  Hi!
  • launch_source – what requested the launch; or the client type.
  • http_referer – this is the page we launched off.  It’s the where.  Click it, it should be live!
  • http_user_agent – the holy grail.  User agent.  YES!
  • remote_addr:  IP address of where the launch was requested.  Also highly useful and also not available from SCORMCloud.
  • request_uri: the actual request generated to the Bright server.  Just guts.
  • created_at: when?
  • provider_launch_url: see below

So there’s some REAL magic here in the provider_launch_url.  Since we capture this, we now can provide introspection to running courses.   If they can grab their own location [via window.location from javascript], they can do their own logging by holding onto the window URL and logging it.

You can then backtrack via Bright to the original learner id and registration ID.   Already we’ve built some really amazing tracking with this…. and the possibilities are quite breathtaking.

What’s next?  Recording the registration state before and after the launch.   That will be too cool and will provide great insight.


posted by | Comments Off on What happens when things go wrong?

For a split second, I was getting the error
“Oops! There was a general error executing method [createInvitationAsync]: Too many bytes in this Domain.”

out of SCORMCloud while creating a registration.

It seems like registration creation was currently not working [although w/ SCORMCloud’s excellent support we fully expect this to be fixed immediately].

But here’s a great and fairly unique chance to test Bright …. with the SCORMCloud backend responding not exactly perfectly at the moment. Reality is, 100% uptime doesn’t exist, anywhere. But when its 99.9999% you don’t get much chance to test you infrastructure when a cooperating service isn’t working……

In virtue of the Bright web service, all pages are functioning normally, which is what I expected.

But since we know we can’t create a reservation, what do I get if I go to launch a course [which will require a new registration]? LET’S BREAK SOME STUFF!

And here’s what I get:


The launch button changes text, with the error:

“There was a general error executing method [createRegistration]: Timed out waiting for operation – failing node: ip-10-2-20-98.ec2.internal/”

Everything else functions perfectly well. Does this qualify as graceful failure? Beauty is the eye of the beholder…. but it’s not too bad since launch/registration are a fraction of the requests we server.

And look now, SCORMCloud is already fixed!

I can imagine a fancier message along the lines of ; we’re sorry, your request can be fulfilled just this moment. Why not refresh the page and try again?