Grooming the backlog, planning, and starting February sprint

Today I groomed the backlog a bit for the sandbox project, closed the last sprint, and started a new one.

Previous Goals

The goals of the January sprint were:

• Scenes in runtime level editor POC are pluggable + code not brittle.
• Some bug + usability fixes for sandbox project actioned.

Instead of this, I ended up actioning:

• Scenes in runtime level editor POC are pluggable + code not brittle.
• Pay down technical debt in signalling server.
• Network editor nodes in runtime level editor POC.
• Architect approach to network placed tokens and avatared tokens, as well as clipboarded items.

My basic conclusion is that I probably should have been a bit more ambitious in setting goals for the January sprint, in-as-much as making progress on the core objectives of my project, instead of finnicking around with fixing a few bugs and making some minor usability improvements.

No matter! Going forward I will make the assumption that I will largely be doing more of the same.

New goals

The key goals of the February sprint for the sandbox project will be:

• Clipboard and token placement in the runtime level editor POC are synchronised via the signalling server between clients.
• Avatared / puppeted tokens are synchronised via the signalling server between clients.
• Some more technical debt paid down for signalling server (uses webpack, github actions block build on test failure, some more tests written, some more TypeScript conversion actioned, potentially using ts-migrate).

In particular, the general focus of this sprint will primarily be on nutting out fully networking the runtime level editor POC for my feature-thin prototype, before jumping into working on user authentication / rearchitecting instance discovery and retention in March.

Not included as an explicit objective but something that I’d also like to look into is implementing some testing / blocking steps in the deployment pipeline for the sandbox project. It would be good to start building the foundation of a test harness.

I’m taking on 26 points. I anticipate potentially needing to drag more cards in and maybe push things out as the sprint progresses; in particular, in terms of my general run rate this should be fairly achievable.

January retrospective

General morale

Battered and borderline neurotic, but better than a few days ago. As I write this on the 9th of January 2021, the sun is shining and I’ve had a chance to go for a number of walks. It was good to get back to work (in a working from home kind of way) last week, but I’m feeling a bit embattled for reasons that I can’t really articulate well or properly. I am hoping that as the days roll by things will continue to improve and get a bit better.

What went well?

Over the last month I:

• Cut into the technical debt for the sandbox client significantly, through eliminating the use of globals, altering the scene structure, and having a sensible folder hierarchy.
• Cut into the technical debt for the signalling server significantly, by breaking the monofile apart into more sensible pieces, supporting TypeScript, linting, testing with mocha and cypress, and implementing a couple of github action workflows
• Made unexpected headway with networking the runtime level editor, in terms of synchronising editor nodes over the wire and laying the groundwork for synchronising placed tokens, as well as avatared tokens.

I did not achieve this goal that I set out for December:

• Some bug + usability fixes for sandbox project actioned.

… as I got sidetracked with focusing on something that was not an objective and was in fact more complicated, being networking the runtime level editor POC. It was very encouraging to make progress on this, as this is essentially the crux of the sandbox project and the defining mission – being “build a networked runtime level editor POC and then make it broadly available for people to use”.

Reviewing my December roadmap, I can update it as follows:

1. networking POC (done, October – November))
2. runtime level editing / drag and drop functionality (done, December)
3. avatar / overview mode switching (done, December)
4. synthesis of runtime level editor with networking POC (in progress, December – February)
5. alleviation of technical debt (in progress, January – February)
6. user login + friend system
7. persistence of session data / saving and loading given sessions

What didn’t go so well?

My sprint planning was an absolute shambles; I committed to doing things that I didn’t actually end up doing, and multiple times I brought things in and then pushed things out of the sprint. Essentially, I was not really sticking to a fine plan; more or less I was reinventing the sprint on a weekly basis as I went along.

This was probably reasonable though as I am currently in part of the project that is a bit complicated and finnicky, and a lot of what I’ve been actioning have been emergent problems and complexities that have cropped up on the fly. I’ve also been a bit opportunistic – seeing an opportunity to solve one of my key technical challenges – the networked runtime level editor POC – I couldn’t resist the chance to start beavering away at it.

Going forward hopefully things should be more conducive to a bit more sprint discipline, as much of the discovery work in the current phase is done now, and I have a reasonable idea as to what I need to do in order to progress.

What’s the outlook?

Good. I should be able to complete clean up of an acceptable amount of the technical debt for the signalling server by the end of February. Furthermore, by the end of February I feel that I have a decent chance of getting synchronised networking working for an extremely feature thin version of my original vision (with respect to roadmap objectives 2, 3, and 4 above).

Github actions + heroku deployment

Today I implemented a github action to run eslint, mocha, and cypress on branch pushes to the signalling server project.

I also implemented a github action to deploy the signalling server to heroku on merge to master.

Once I’ve fixed the linting step I can make sure that the first github action blocks merges to master, and thereby acts in a small way as a gatekeeping mechanism. However, that still is pending implementation of webpack for the project, which will be a goal for the February sprint.

Added Cypress to the signalling server

Today I added Cypress to the signalling server for testing things such as reaching out to the bookkeeper, as well as emitting signals to the sandbox client. I have not added any tests yet, though.

One thing that I noticed was that I wasn’t able to resolve all linting errors, as one of my typescript files can’t be directly referenced yet – as, if I do, the tsc compilation makes it inaccessible when running the project!

To be a bit clearer here, I have a file A.js importing B.ts. Then these are compiled to A.js and B.js. But then A.js is referencing B.ts in the compiled code, which is no longer present.

The solution here is evidently to use a pre-processor such as webpack. I already have a card for this, maybe I will action this in the next sprint.

Added mocha and chai

Today I added mocha and chai to the signalling server, as well as moved all the code (including test files) to src, and also fixed a few linting errors.

Tomorrow I’d like to write one or two tests using request and express following the guide here https://semaphoreci.com/community/tutorials/getting-started-with-node-js-and-mocha, in order to test connections to the book-keeper.

Added TypeScript support to the signalling server

Today I succeeded in adding TypeScript to the signalling server. I ended up not needing Webpack. Using this as my tsconfig was enough:

{
  "compilerOptions": {
    /* Visit https://aka.ms/tsconfig.json to read more about this file */

    /* Basic Options */
    "target": "es5",                          /* Specify ECMAScript target version: 'ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017', 'ES2018', 'ES2019', 'ES2020', or 'ESNEXT'. */
    "module": "ES2015",                     /* Specify module code generation: 'none', 'commonjs', 'amd', 'system', 'umd', 'es2015', 'es2020', or 'ESNext'. */
    "lib": ["ES6"],                             /* Specify library files to be included in the compilation. */
    "allowJs": true,                       /* Allow javascript files to be compiled. */
    "outDir": "dist",                        /* Redirect output structure to the directory. */
    "rootDir": "./",                       /* Specify the root directory of input files. Use to control the output directory structure with --outDir. */

    /* Strict Type-Checking Options */
    "strict": true,                           /* Enable all strict type-checking options. */
    "noImplicitAny": true,

    /* Module Resolution Options */
    "esModuleInterop": true                  /* Enables emit interoperability between CommonJS and ES Modules via creation of namespace objects for all imports. Implies 'allowSyntheticDefaultImports'. */

    /* Source Map Options */
    // "sourceRoot": "",                      /* Specify the location where debugger should locate TypeScript files instead of source locations. */
    // "mapRoot": "",                         /* Specify the location where debugger should locate map files instead of generated locations. */
    // "inlineSourceMap": true,               /* Emit a single file with source maps instead of having a separate file. */
    // "inlineSources": true,                 /* Emit the source alongside the sourcemaps within a single file; requires '--inlineSourceMap' or '--sourceMap' to be set. */
  }
}

In particular, swapping “module” from commonjs to ES2015 was the key.

I’ve created follow up cards for adding Webpack support and Sourcemaps, but I think this is a decent progression in terms of supporting TypeScript and JavaScript side by side.

Started adding TypeScript to the signalling server

Today I started adding TypeScript to the signalling server. Essentially, I am after doing something like this in terms of having javascript and typescript run side by side in my project, so that I can slowly migrate to TypeScript over time if I so choose to do so.

I made a fair bit of progress, but was stumped by this issue. Since I need module imports and exports, I need to therefore use Webpack. This post here is helpful, as are the webpack docs. In particular, from the former post there is this interesting diagram regarding compilation:

Essentially I need to leverage ts-loader, typescript (the tsc tool) and Webpack, in order to generate … either a bundle.js and/or a main.js file to run. Something something sourcemaps too … anyway looks like this will need to be a tomorrow problem.

Added lint tooling to signaller + linted project

Today I added eslint to the signalling server and linted the project. Some of the bits and pieces I worked around a bit, in terms of allowing maximum function length to be 200 and line length to be a similar figure, but apart from that I got it done.

I also needed to disable a linting rule within a few lines of a file (alphabetical imports) so that there wouldn’t be a race condition that caused the server not to work.

Tomorrow I will aim to look into the typescriptification of the project – in terms of allowing javascript and typescript to run side by side.

Broke up signaller monofile into semi-sensible folder structure

Today I broke up the signalling server from being a monofile into a semi-sensible folder structure.

Next steps will be to:

• Add some form of linter to the project, such as eslint
• Start converting the project to typescript (I’d like to support javascript and typescript simultaneously if possible, so that I don’t have to do everything in one hit)
• Start adding unit tests (stretch task: also functional tests)

NextMind’s work on VR control

Today I learned about NextMind’s work on noninvasive brain interfaces for interacting with VR environments. The technology looks interesting, but I guess it remains to be seen as to which companies competing in this area win the race in this respect. Nonetheless things have certainly come a long way in this field; it will be interesting to see what developments the next few years bring.