16 exercises 10 block challenges Nothing is reported
The lab
Reading code and writing code are different skills, and the second one only arrives by writing some. Everything here runs in this page, against tests that are the brief rather than a mark: if they pass, the thing is done, which is also how a handover works.
Two notations, one subject. The exercises run JavaScript, because that is what a browser runs without asking you to install anything, and every one carries the same answer in Python beside it. The block challenges have no syntax at all. Nothing here is a simplified version of programming; it is programming with the spelling removed, which is what a patcher, a ladder diagram and a cue stack also are.
Write it and run it
Pick one. The brief is in production terms, the tests are the acceptance criteria, and every failing row says what it is defending against rather than only what went wrong. Your code is kept in this browser, so you can leave one half finished.
A blank page
No exercise, no tests. This is the one to open when you want to build something of your own: the tool for the job nobody sells a product for, which is most of what a technical director ends up writing. Both languages run, and the console underneath takes an expression and evaluates it against whatever is in the editor.
Build it out of blocks
The same subject with the syntax taken away. Assemble the program, press run, and watch the block that is executing light up while the line of Python it generated lights up beside it. Pause it, scrub it, or step one block at a time; the list underneath is every block that ran, in order, and clicking one takes you to that moment.
The runtime is single threaded, like the loop on a microcontroller, so a wait
really does stop it hearing anything. There are two wait blocks, the same shape, one word apart,
and only one of them hears the stop button. On a board that difference is delay()
against a loop that checks millis(), and it is the most common bug in theatre
firmware.