Give the user enough information that they can start creating the assembly language emulator: https://docs.google.com/document/d/19Z9fJVtOPDw1ib0agLEbmLdsNNiKbIuFKBqF0eORfuQ/edit

• Initial Draft

• Proofreading

• Integration with other documentation

• Integration with front-end

Should use the node standard directory structure and explain it in the README

Code doesn't actually have to be doing anything, should just look as if it were being compiled on a desktop. Note that you should verify this with the actual output of compiling said program on desktop

We need something that can compile the assembly language into machine code. This shouldn't be too horrendously difficult but it might take a week or more to implement.

This is still up for debate (whether we even want to do this or just make the students implement it), but we may want to show students how, when the add instruction is implemented, the registers and memory are used. This will give them some footing for how other instructions they'll be implementing will work

This would allow the student to learn the assembly syntax and play around to see how things really work. This would require a way to verify the syntax so it might take a a significant amount of work, but this would be great to have

We need to figure out how we are going to run through the assembly program. For example, we need to understand how to handle jumps.

I propose that we actually compile the program and then feed the user the location to jump to, just having the student set the program counter.

Slide the editor window over to make room for where the user will be editing code in the end product

Since the site is going to be static, we can use a static site generator to get the benefits of templating. This should make updating the site significantly less painless

This is a large task -- probably requires further subdivision. But basically, take the JS code that students write and execute the associated assembly instructions, updating memory/registers as per the JS code

Need to figure out how hot reloading works. Shouldn't be hard, since this is a solved problem, but we'll need to have it implemented.

First step for intro animation sequence

Can be any editor (emacs/nano may be the easiest to replicate)

Grunt is really good for automating garbage no one wants to worry about but that has to be done (i.e. "minification, compilation, unit testing, linting" according to https://gruntjs.com/). Setting this up now will help tremendously save time for local testing later on.

Choose a linter for both JS and HTML (remember, we'll be sticking with this for all of development, so make sure it's something that's well maintained/used). I know there's something called ESLint, which is widely used for JS linting, not sure about HTML.

This may also cover #7, if we're able to automate copyright placement with Grunt (which seems like a totally reasonable thing to expect). I'll paste the exact copyright text below once I've got it written
JS:

/**
* Copyright (c) 2018-present, Yash Patel and Peter DeLong
* All rights reserved.
*/

HTML:

© 2018-present Yash Patel and Peter DeLong. All rights reserved.

If we allow the student to run the assembly against a complete version of the emulator, it might significantly help their understanding

Structure looks sound; add in description on the README so it's clear both for if we forget and when the project structure inevitably becomes more complicated. Also useful if other people join later on

Display the blocks as they move around according to the student code (i.e. bits moving to or between memory/registers)

Give the user enough information that they can start creating the assembly language emulator: https://docs.google.com/document/d/10lF0A50bjONvAXlPfKK-D1ocOESTU7pV8HAbp_HsJ00/edit

• Initial Draft

• Proofreading

• Integration with other documentation

• Integration with front-end

Show the results of compiling. These will be per whatever we have in the powerpoint slides (whatever is needed by the back-end system)

We need to figure out the best way to allow the student to perform bitwise arithmetic. Shifts and things should be straightforward, but I'm not sure how we should handle signed vs unsigned integer arithmetic.

We currently have the following workflow:

Local -> Push to master -> Travis runs tests -> (If passed) Gets pushed to Heroku servers

We may want to consider doing this:

Local -> Master -> PR submitted to prod -> Runs tests and shows results -> Can pull to prod -> Gets pushed to Heroku

Give the user enough information that they can start creating the assembly language emulator: https://docs.google.com/document/d/1YeUQVu8Gj6sUPcjgLwmUHfgbm1E1f_tVwsB_010ha7g/edit

• Initial Draft

• Proofreading

• Integration with other documentation

• Integration with front-end

Deployment will be done via Heroku. While it may be constraining in certain ways, the flexibility services like DigitalOcean or AWS offer also result in more time being taken out for us developers having to manage them. While these sysadmin things can sometimes be interesting, they're not ultimately what we're interested in -- let's leave those for other people to deal with.

Heroku is plenty for what we're aiming to do, which will have minimal server-side work, mostly just serving up some static web pages initially, with potential user settings served later down.

We need something that will be implemented in phase 1 (or all the phases for that matter). This can be whatever assembly files you used for testing from COS 375, unless they said not to distribute materials from that class.

Testing will be critical later down (will probably seem like an unnecessary pain initially), so we should get used to it, especially for when we're deploying live.

Also, to give orientation, Travis CI is used for integration testing, while Grunt is primarily used for local unit tests and such. CI probably has little use now, but it'll be good to get used to for later on.

As instructions are being executed by the student code, highlight them in the view panel

Should have colors that resemble a terminal, though not necessary for completion of the task

This code will not be freely distributed (will be licensed later), so we'll need to maintain copyright on all the source files. Create a template of the copyright agreement to be put in the files and set up linters to automatically note when such copyrights are not present

Write documentation giving a user a basic understanding of the concepts necessary to begin the lessons: https://docs.google.com/document/d/1Uz5y-wJIAVmVoF1R9A7b2ymRAlZ-0h-Am2Qa7K42U6Y/edit

• Initial Draft

• Proofreading

• Integration with other documentation

• Integration with front-end

If the JS code itself has some error (not logical, i.e. the JS code has incorrect syntax), make sure this is handled and doesn't cause the system to bug out or look unresponsive.