We Keep Coding

Use SCORM runtime API without LMS?

I am new to SCORM and have been given an assignment to integrate SAP Workforce Performance Builder exported SCORM (can either be 1.2 or 2004) content into an existing PHP website.
To put it simple, I need to be able to display the exported SCORM material in the browser (I can already do this), and be able to get the statistics through the SCORM runtime API.
I understand that I will need to make use of an LMS to allow communication with the SCO through the SCORM runtime API. I have looked into several open source LMS's, but haven't found a good solution for my purpose. The problem is that a lot of these LMS's are designed to run on the domain of the provider, and have built in tools to follow up on users' progress and scoring.
What I'm looking for is a simple, lightweight solution to be able to interact with the SCORM runtime API, so I can fetch the time a user has spent on a course, his score, etc. I will insert the gathered data into my own database, and code the backend where results can be evaluated myself, all I need is a way to get to the SCORM data.
I feel like I'm missing something, as surely you don't need an entire LMS implementation to simply listen for the basic 8 SCORM API calls, and log the results? Any help or a nudge in the right direction is greatly appreciated!

If you just need to mimic an LMS, providing a pseudo SCORM API so the course can 'speak' to your PHP site, try Claude Ostyn's SCORM Test Wrapper. It's pure client-side JavaScript, as lightweight as you can get with SCORM.
In a nutshell, Claude's test wrapper provides a simple SCORM API for the course to connect to. It receives communication from the course, which you can handle however you like. No backend code is provided; if you want to incorporate with a database, you will need to modify the wrapper to push/pull data from your site's database (this is typically handled via AJAX).
Once you build out the data store, you can make your site behave as an LMS, enabling the site to launch SCORM courses, and enabling the courses to send/receive data to your site via the SCORM API. No LMS or 3rd-party server required.
Notes:
There is no support for unzipping packages or reading manifests. (I suspect you're not interested in going that far.)
SCORM also supports sequencing and navigation, which go way beyond simple JavaScript wrappers. If you need to support the sequencing and navigation features, you'll need to grab them from an existing open-source project (not easy) or pay a 3rd party like Rustici Software (SCORM Cloud). I suspect the content you create via SAP will not use any of SCORM's sequencing or navigation features, so you'll probably be OK.
Claude passed away a while ago, so he can't support you. Shout out to the guys at Rustici Software, who have preserved the site for the SCORM community.

From the courseware's point of view, it is just using javascript to call functions on an API or API_1484_11 object. If you can write the javascript code to sufficiently ape the interface, and store/return the necessary data model elements, then you don't need "an entire LMS implementation".
You need to carefully read the Run-Time Environment documentation though.
If you only ever plan to use it for running SAP Workforce Performance Builder produced courseware, then you can implement enough or the data-model to make that work correctly (although I've seen this done, then people surprised/confused/angry when other SCORM compliant courseware does not work, so beware.)
(Aside) You also need a reliable way to install/update your courseware packages from a PIF zip file. Again, for dealing with courseware from a specific content creator and not needing to write a full blown generic interface, you can just pick out the bits of the imsmanifest.xml file you need.
(Digression) Having written the courseware side of the interface a few times, I've seen interesting gotchas in various LMS implementations of the API, including things like returning the boolean true or false instead of a string "true" or "false" which can catch you off guard. May favourite so far is an LMS that truncates the cmi.suspend_data at the first newline character. (Actually, the implementation was that inept that there was a bug in their bug, and it also chopped off the character before the newline as well.)

You'll mainly want to capture, maintain and enforce the Student Attempt Object. I've used this in a JSON format now for a while, and you can take different approaches to how you store information collected by a Shareable Content Object. Normally people pluck the parts they need vs. trying to go 100% into full SCORM support so these types of questions are popular.
By creating the SCORM Runtime for either SCORM 1.2 or 2004 you'll mainly be providing those methods to build the data from the student session.
This can look like https://gist.github.com/cybercussion/4675334 (based on Unit test data for SCORM 2004)
You attempt to route your calls to your server side. Normally this results in a lot of lag. And I normally don't advocate it as an option.
You cache the student attempt, but you post the whole JSON object on a commit call. This normally results in a larger data post which can blimp on you if there are a lot of journaled interactions.
You take a hybrid approach and only post the data thats changed and merge that on your server limiting the data blimp issues that could occur.
I have a bunch of info up on the wiki here too https://github.com/cybercussion/SCOBot/wiki as well as a lot of sample code, tips etc...

Implementing a RESTful API based Web App. Do I need a server-side framework?

I'm starting a project that basically is a single-page app that downloads and shows a bunch of stats (using d3.js). The data layer is Mongo-powered, served through a RESTful API, and the client app will be coded in Ember.js. We want all data to be exchanged through the API, since we also have some mobile apps in the back burner that will hook to the same API.
I'm debating on whether write the API (using Express.js or other server-side MVC framework), or just serve the API use Deployd and not using a server-side framework at all, besides Deployd. I'll provide some hints about the project characteristics:
The main feature is basically a dashboard that shows aggregated stats that are already computed and stored in the Mongo database.
User interaction is minimal, enough only to allow users to customize their dashboards, but users never upload data (other that customization preferences).
Most of the app is a lot of d3.js to create and render a bunch of graphs, which can customized in many ways.
It requires a very rich and responsive user interface.
I proposed skipping completely the server-side framework, and simply go with a bunch of static HTML+CSS and do all the heavy lifting with a client-side MVC such as Ember.js. Since all data download and upload can be handled by Deployd, a pure static site would load much faster and is also easier to scale. Also, (I think) all user-related data and validation can be done with Deployd itself.
The thing is, some of my colleagues had a heart-stroke when I mentioned this idea. So I'd like a reality check: do I really need a server-side framework besides Deployd to cope with problems I cannot foresee yet? Are the benefits of having a pure static site a good enough tradeoff versus having, say, Express.js just in case?

I haven't worked with Deployd before, but from a quick skim of its docs, it is a server-side framework. It accepts requests and respond with json. It's just oriented to APIs and json and neglects html, unlike, say, default Ruby on Rails.
The main issues I can think of that might arise due to a lack of a traditional server-side framework are things like auth, CORS, and XSS/CSRF/other common security issues. You could cater for this through Deployd if it's built in or easily added, but that may be difficult.
Looking further into Deployd's docs, I see there's a guide for users and CORS. I can't find anything about XSS or CSRF.

Why Angular/Ember/Backbone and not a regular web framework?

So I'm afraid I might be missing something pretty fundamental here, but I really can't get my head around this - Why? Why would we want to use those JS MVC frameworks, instead of sticking with Rails, Django, PHP and so on?
What do these JS frameworks give us that can't be achieved by the old web frameworks? I read about SPA, and there's nothing I couldn't do there with ASP.NET MVC, right?
I'm really baffled by hearing all the people at work wanting to leave our current framework for these new ones, and it's much more than just for the sake of learning something new.
I am totally up for that, and I've always tried playing around with other frameworks to see what I'm missing, but perhaps these new technologies have something really big to offer that I simply cannot see?

Single page applications provide a better experience by having all page transitions be seamless. This means you never see the "page flash" between user actions, in addition to a few other user experience improvements.
Front-end frameworks also generally provide a common way to interface with APIs. So instead of writing an AJAX wrapper for every page in your site, you just say 'This page has this route (path), hooks data with this schema from that API endpoint and presents it with these templates and helpers.' There are many proponents of APIs, because there are many good reason to write you applications from a service standpoint. This talk sums up a lot of the points in favor of APIs. To summarize:
Orchestrating your web offerings as services makes them inherently decoupled. This means they are easily changed out. All the reasons behind strong Object Oriented design principles apply equally to the larger parts of an application. Treat each piece as an independent part, like a car, and the whole platform is more robust and healthy. That way, a defect in the headlights doesn't cause the motor to blow up.
This is very similar to how a SOAP WSDL works, except you have the auto creation tools right out of the box.
Having well defined touch points for each part of your application makes it easier for others to interface with. This may not ever factor into your specific business, but a number of very successful web companies (Google/Yahoo, Amazon AWS) have created very lucrative markets on this principle. In this way, you can have multiple products supported by the same touch points, which cuts a lot of the work out of product development.
As other point out, the front end framework is not a replacement for the backend, server technologies. How could it be? While this may seem like a hindrance ("Great, now we have two products to support!"), it is actually a great boon. Now your front and back ends can be changed and version with much less concern over inadvertently breaking one or the other. As long as you stick to the contract, things will "Just WorkTM".
To answer your additional question in the comment, that is exactly correct. You use a front end framework for handling all the customer interaction and a completely separate back-end technology stack to support it.
I'm forgetting a few good ones...

Angular, Ember, and Backbone are client-side JavaScript frameworks. They could be used interchangeably with a Rails, Django, or PHP backend. These JavaScript MVCs are only responsible for organizing JavaScript code in the browser and don't really care how their data is handled or persisted server-side.

Django/Rails etc are server-side MVC frameworks. Angular/Backbone etc are client-side Javascript MVC frameworks. Django/Rails and Angular/Backbone work together - in a single-page app, usually the server-side MVC will serve the initial HTML/JS/static assets once, and then once that is done, the client-side router will take over and handle all subsequent navigations/interactions with your app.
The difference here lies in the concept of what a "single-page application" is. Think about how a "regular" web Django/Rails website works. A user enters your app, the backend fetches data and serves a page. A user clicks on a link, which triggers the server to serve a new page, which causes the entire page to reload. These traditional types of websites are basically stateless, except for things like cookies/sessions etc.
In contrast, a single-page application is a stateful Javascript application that runs in the browser and appears to act like a traditional webapp in that you can click on things and navigate around as usual, but the page never reloads, instead, specific DOM nodes have their contents refreshed according to the logic of your application. To achieve a pure Javascript client-side experience like this in a maintainable fashion really requires that you start organizing your Javascript code for the same reasons you do on the server - you have a router which takes a URL path and interacts with a controller that often contains the logic for showing/hiding views for a particular URL, you have a model which encapsulates your data (think of a model as roughly one "row" of a database result) which your views consume. And because it's Javascript there are events going on, so you can have your view listen for changes in it's associated model and automatically re-render itself when the data is updated.
Also keep in mind that you don't just have one view on the client side, there are usually many separate views that make up a page and these views are often nested, not only for organizational purposes but because we want the ability to only refresh the parts of the UI that need to be refreshed.
The intro to Backbone is probably a good starter on the topic: http://backbonejs.org/#introduction

Check this article, there is well explained how a modern web application should looks like in the client side, server side and the communication between them.
By the way:
Client side -> Ember, Angular, Backbone, Knockout.
Server side -> Django, Node, Rails

Mobile Web Apps - Multiple pages or AJAX?

I'm about to embark on a large project based around mobile web apps. I am going to create a mobile web app that will have multiple screens, a search system and a few other features.
I need to establish a primary framework for this application. It seems I have two options; multiple separate HTML pages, or alternatively, use AJAX to download the contents and move divs in and out of the viewport.
I don't have to worry about SEO. I'm primarily looking for good performance. I understand Stack Overflow is a site about questions and answers and this does somewhat involve opinion, but I feel that based on my criteria there should be a solid answer to this question.
I'd highly appreciate it if somebody could share what they think the best option would be for me on this project.

What I believe you're referring to by using AJAX to download the contents is commonly known as a single-page web app. These generally involve rendering data using templates on the client side and sending and receiving the data via AJAX.
For these, there are plenty of excellent JavaScript framework options, including:
Backbone.js
Knockout.js
Angular.js
Ember.js
Of these, Knockout is probably the easiest to learn (seriously, the tutorial is brilliant), but the lack of routing lets it down somewhat. I tend to use Backbone for this type of thing myself, although if I were starting over I would probably go for Angular as it's made by Google and seems to have more momentum. But try a few tutorials and see which one works best for you!
All of these offer a lot of very handy functionality for your use case, as they enable you to load data via AJAX and render it on the client side quite easily. There is a learning curve for all of them, but they result in a much more maintainable and testable client-side application. Believe me, I have tried to build such an application with just jQuery, and I would recommend you avoid it as it gets very painful, very quickly!
Your mileage may vary, but by and large a single-page web app like this should perform better than a more traditional web page because once the application has loaded, all the communication with the server is just sending and receiving JSON. It will also likely be simpler as you can use a lightweight REST framework like Slim, Sinatra, Express or Flask on the server side, and just serve up the static content on the home page, then do everything else via AJAX.

rails and backbone working together

I am just starting to look at MVC structure, first i looked at how backbone.js worked, and now I have just completed rails for zombies, by Code School. I know that I haven't delved too far into any of this, but I had a question to begin with.
Can you use these libraries together?
I have learned how to create models, views, etc in both, but when creating a real application do you use both backbone and rails?
If so...
When do you use a backbone.js model vs. a rails model?
Maybe I am just getting ahead of myself and need to keep practicing and doing tutorials but I couldn't seem to find anything directly on this.
Thanks!

Before anything else I'd suggest taking a look at thoughtbot's Backbone.js on Rails book, which is a great starting point, although aimed at an intermediate to advanced audience. I bought this book having already worked with rails but as a total backbone.js beginner and it has served me very well.
Beyond that, there are some fundamental issues with combining these frameworks which go beyond the details covered in this book and other books. Below are some things I'd suggest you think about, from my own experiences pairing RoR and backbone.js. This is a long answer and strays a bit from the specifics of your question, but I hope it might help you out in the "big picture" sense of understanding the problem you're facing.
Rails: Web Framework vs API
The first thing you confront when using backbone.js on top of a rails application is what to do about views, but this is really just the surface of a much deeper issue. The problem goes to the very heart of what it means to create a RESTful web service.
Rails is set up out of the box to encourage its users to create RESTful services, by structuring routing in terms of a set of resources accessed at uniform URIs (defined in your routes.rb file) through standard HTTP actions. So if you have a Post model, you can:
Get all posts by sending GET request to /posts
Create a new post by sending a GET request to /posts/new, filling out the form and sending it (a POST request) to /posts
Update a post with id 123 by sending a GET request to /posts/123/edit, filling out the form and sending it (a PUT request) to posts/123
Destroy a post with id 123 by sending a DELETE request to /posts/123
The key thing to remember about this aspect of Rails is that it is fundamentally stateless: regardless of what I was doing previously, I can create a new Post simply by sending a POST request with a valid form data to the correct URI, say /posts. Of course there are caveats: I may need to be logged in (have a session cookie identifying me), but in essence Rails doesn't really care what I was doing before I sent that request. I could follow it up by updating another post, or by sending a valid action to whatever other resources are made available to me.
This aspect of how Rails is designed makes it relatively easy to turn a (Javascript-light) Rails web application into an API: the resources will be similar or the same, the web framework returning HTML pages while the API (typically) returns data in JSON or XML format.
Backbone.js: A new stateful layer
Backbone is also based on RESTful resources. Whenever you create, update or destroy a backbone.js model, you do so via the standard HTTP actions sent to URIs which assume a RESTful architecture of the kind described above. This makes it ideal for integrating with RESTful services like RoR.
But there is a subtle point to be stressed here: backbone.js integrates seamlessly with Rails as an API. That is to say, if you strip away the HTML views and just use Rails for serving RESTful resources, integrating with the database, performing session management, etc., then it integrates very nicely with the structure that backbone.js provides for client-side code. Many people argue that there's nothing wrong with using rails this way, and I think in many ways they are right.
The complications arise though from the issue of what to do with that other part of Rails that we've just thrown away: the views and what they represent.
Stateful humans, stateless machines
This is actually more important than it may initially seem. HTML views represent the stateless interface that humans use for accessing the RESTful resources your service provides. Doing away with them leaves you with two access points:
For humans: a rich, client-side interface provided by the backbone.js layer (stateful)
For machines: a resource-oriented RESTful API provided by the rails layer (stateless)
Notice that there is no longer a stateless (RESTful) interface for humans. In contrast, in a traditional rails app with an API, we had something closer to this:
HTML resources for humans (stateless)
JSON/XML resources (API) for machines (stateless)
The latter two interfaces for accessing resources are much closer in nature to each other than the previous two. Just think for example of rails' respond_with, which takes advantage of the similarities to wrap various RESTful responders in a unified method.
Working together
This might all seem very abstract and beside the point, I know. To try to make it more concrete, consider the following problem, which gets back to your question about getting rails and backbone.js to work together. In this problem, you want to:
Create a web service with a rich client-side experience using backbone.js, with rails as the back end serving resources in JSON format.
Use pushState to give each page in the app a URL (e.g. /posts/123) which can be accessed directly (by entering it into the browser bar).
For each of these URLs, also serve an HTML page for clients without javascript.
These are not unusual demands for a modern web service, but they create a complex challenge. To make a long story short, you now have to create two "human-oriented" layers:
Stateful client-side interface (backbone.js templates and views)
Stateless HTML resources (Rails HTML views)
The complexity of actually doing this leads many nowadays to abandon the latter of these two and just offer a rich client-side interface. What you decide to do depends on your goals and what you want to achieve, but it's worth thinking about this problem carefully.
As another possible reference for doing that, I'd suggest having a look at O'Reilly's RESTful Web Services. It might seem odd to be recommending a book on REST in a question about Rails and Backbone.js, but actually I think this is the key piece that fits these very different frameworks together, and understanding it more fully will help you take advantage of the strengths of both.

Yes, you can use both side by side. Backbone is for storing and manipulating data within the client browser. It generally needs a server to talk to and fetch the data from. This is where Rails comes in. You can have a web application without heavy client-side code. Backbone is for building out sites that feel more like apps--think of Gmail or Pandora.
I advise just learning Rails first. Once you can get static pages loading and styled as you wish, then understanding Backbone's place will make more sense

I've used rails as a backend server to serve a fairly large website, which included a few one-page apps (built in backbone).
I'd suggest the backbone-on-rails gem. The idea is that your rails server will serve up the backbone app as a script tag in one of your views. You keep your backbone app itself in the rails app/assets folder.
Backbone understands rails routing conventions, and you just need to give it a path to a json api that rails can almost generate for you with rails generate resource.
Other than the syncing between the models, your backbone apps and rails apps are fairly separate. Backbone and Rails don't have quite the same MVC model, but getting them to cooperate is pretty easy.