Step 1: Review the LX Structure
Step 1: Review the LX Structure#
A learning experience is structured in three parts, each implemented by a different directory.
These directories are created for you when running the command
dts lx create (more on this in the following
sections of this manual). When distributed, they will reside in three different Git repositories.
If you are reading this as a learner, you will only need to use the single LX directory provided to you
by your instructor or class instructions. All the necessary behind the scenes components to drive the LX
activities will be handled automatically by
Three parts make a single LX#
A Learning Experience (LX) is broken down into three parts:
A learner’s workspace;
The learner’s workspace#
The learner’s workspace (also referred to as
the meat) is the only part that a learner will ever need to
interact with. It contains instructions, interactive learning materials (e.g., jupyter notebooks) and
boilerplate code that the learner will have to work on, complete, and in some cases submit.
The back-end (also referred to as
the recipe) is what defines the rules of a learning experience.
It contains all those files that are necessary for the learner’s workspace to function but must be protected
from the learner’s edits. The
recipe constitues the immutable part of a learning experience,
and it is shared by all the learners’ workspaces and solutions of said LX;
For example, in a robot localization exercise, the back-end might have access to a map of the environment and a trajectory taken by a robot within it. The back-end would use this data to generate simulated sensors’ readings and pass those on to the learner’s workspace. The learner is required to implement a system that can consume these readings and reconstruct the original trajectory taken by the robot. In this case, the back-end must protect the ground-truth trajectory of the robot or else the solution would be exposed to the learner, effectively invalidating the usefulness of any grading.
The solution part is simply a copy of the learner’s workspace but with all the solutions to the activities and exercises already implemented. This is usually used for two main reasons: (i) to make sure that the boilerplate provided in the learner’s workspace is enough for a learner to implement a correct solution to the problems presented; (ii) to serve as example solutions to problems that are optional or not graded;
The reason why the back-end the learner’s workspace are also respectively referred to as the recipe and the meat comes from an analogy with a cooking scenario. The back-end defines the rules, so it is a recipe for how the learning experience works, the learner brings the content, the solution, the substance, hence the meat that together with the recipe makes a cooked meal, in this case a solved learning experience. Morevoer, similarly to how better cuts of meat lead to better tasting meals, better solutions lead to better scores for the learner. Solving a learning experience just became a hunt for the best meat.
An LX development workspace is set up on running
dts lx create. This command generates a workspace directory that is named using a filesafe version of the LX name. Fig. 7 shows an example of how
an LX development workspace is structured.
The learner’s workspace (the meat)#
The back-end (the recipe)#
When a new LX is created, the learner’s workspace and the solution located in the
solution directory are identical. The instructor is
then responsible for adding a fully developed and tested solution, with example agents and activity solutions.
While developing a new LX, it is good practice to start working on the solution first. Once the solution is in place, parts of the solution with relative pedagogical value can be stripped out and replaced with placeholders effectively producing a boilerplate code that can populate the learner’s workspace. This procedure guarantees that the resulting boilerplate is (by construction) enough for the learner to achieve a valid solution.