Technologies:
Python (sync and async, Django and non-django), C, Java, Typescript, some C++, past in Rails.
AWS, Docker, Pulumi, Linux, a little GCP.
Résumé/CV:
10 years doing tech, past six in SRE roles (one FAANG, one startup). Lots of scalability and automation work in these roles, working with SWEs. GitHub is sheenobu.
A continuation is a function that, when called, jumps back to a specific part of the program that was frozen (meaning current memory, the call stack, the line number). So it can't really be stored. If your game state was stored in a db, you'd still have to load it memory to perform operations on it. Those operations, if using continuations, would then stick around in memory while waiting the continuation to be resumed. If it's a multi-player game, then you'd be in real trouble as your continuation could end up with stale data.
Game state has to be propagated from the server to the client so the player knows what is happening where-as continuations as used in this article are more about avoiding this propagation (the hidden field in the example is replaced by dispatch-table tag which acts as a session id / location in the dispatch-table for finding the continuation function)
If someone builds a container that is designed like this:
FROM debian
RUN do-x
RUN install python2
and then someone changes do-x, if I understand, the layers below it get invalidated and all of a sudden install python2 fails. This is very bad design but very easy to replicate.
Remote: Preferred!
Willing to relocate: No
Technologies: Python (sync and async, Django and non-django), C, Java, Typescript, some C++, past in Rails. AWS, Docker, Pulumi, Linux, a little GCP.
Résumé/CV: 10 years doing tech, past six in SRE roles (one FAANG, one startup). Lots of scalability and automation work in these roles, working with SWEs. GitHub is sheenobu.
Email: [email protected]