InSpec html demo

[arlimus]

We want this for the new inspec home (website) and awesomeness during presentations.

Huge props to Adam Jacob and the full Habitat team for their awesome demos!!

Let's collect ideas and implementation direction here.

Decisions

• Pre-record inspec behavior OR use a tty-backend with e.g. Docker.
  => pre-record the behavior
• No server-side component
  => Lives in the inspec repo under www/demo. Users must be able to run this locally in their browser (ideally: via opening an index.html)
• Pre-generate data file via task and update it on every release.

Tasks

MVP

• UX design for the HTML Shell UX & UI design for the interactive HTML demo #953
• The content of the interactive demo: Vision+Goals, outline/steps, commands at each step Create content for interactive inspec online demo #954
• Research: mechanism for recording + playing back behavior Research: determine mechanism for recording + playing back inspec #955
• Viability gate: record behavior + in-browser playback (no special design!) record inspec + in-browser playback for online demo #956
  • record behavior
  • in-browser shell rendering
  • in-browser shell input interaction
  • in-browser playback of shell commands
• --- 0.32
• MVP: one in-browser demo command MVP in-browser inspec demo #957

Release

• Release 1: create all content for inspec homepage demo (recording + playback) Create all content for inspec homepage demo #1021
• Run command whitespace-tolerant
• Error handling for command doesn't match anything (UX + coding)
• Create script for generating demo contents (i.e. record against current release of inspec in the repository)

Extras

• Rake task for bump_version to generate updated online demo contents
• Smart error-handling for certain demo commands (e.g. inspec exec not_here should result in a message about not_here not being here)
• Windows-centric output for inspec interaction

[vjeffrey]

from @stevendanna
"...we mentioned potentially doing a "not-canned" demo on the website where people run actual commands and got actual output. One possibility there is a small app (maybe in go?) that spawns a container and then forwards a websocket connection to the container back to the browser. Not attached to the idea, just thought of it on a walk today. This: https://contained.af/ uses that method"

[vjeffrey]

the website at habitat.sh/try is using josh.js (http://sdether.github.io/josh.js/) --- match commands that are input by the user to the commands you expect, if they don't match, show them a help file, if they do match, display the canned output (https://github.com/habitat-sh/habitat/tree/master/www/source/try, https://github.com/habitat-sh/habitat/tree/master/www/source/javascripts, https://github.com/habitat-sh/habitat/tree/master/www/source/try/responses)

[vjeffrey]

the presentation used for habitat is a tty.js -- https://github.com/habitat-sh/habitat-launch

[chris-rock]

@stevendanna proposed: One possibility there is a small app (maybe in go?) that spawns a container and then forwards a websocket connection to the container back to the browser. Not attached to the idea, just thought of it on a walk today. This: https://contained.af/ uses that method

[chris-rock]

Another alternative would be to use emscripten to compile ruby to javascript. As far as I can see, ruby 1.9.3+ cannot easily compiled to javascript, because it heavily relies on threads. See: https://github.com/replit/emscripted-ruby

Update: Looks like thread support is in Emscripten now: https://groups.google.com/forum/#!topic/emscripten-discuss/gQQRjajQ6iY But I expect a lot of road bumps :-(