HATEOAS for Haunted Houses
sanfordtech.xyz61 points by recursivedoubts 5 days ago
61 points by recursivedoubts 5 days ago
I can’t stand this acronym. Why would you ever create an acronym where the first 4 letters are “HATE”? All I ever hear in my head when I read that is “HateOS”
edit: ALSO, whoever made went particularly out of their way to make it so — typically words like “as” and “the” aren’t included in acronyms. Arrgghh it grinds my gears so much!
It's quite cool honestly, well done to the developer. It works, so it's de facto a good solution.
> The hard parts weren’t the architectural pattern - they were embedded systems constraints. Tuning buffer sizes and designing components shallow enough to fit in 512 bytes required iteration.
I am a bit confused by the choice to use HATEOAS for this. Given the hardware constraints of the controllers I wouldn't have figured that doing handlebars style html templating is a good use of resources, rather than just sending raw data to the client and having it handle the presentation. I probably would have returned a blob of data from the servers and handled everything on the client, but I also am a UI guy first and foremost...
That's the assumption and motivation:
> I wanted to create an architecture that minimized future work on both the admin app and the controller network layer. That way, the business could lean on its in-house development experience to make changes after the project.
From your perspective as a UI developer, you would need to update all clients (in the building) if something on the server changes, e.g. if a new button or game state is added. HATEOAS is a good architectural choice if you want to minimise the likelihood of having to change the client implementation.
I use HATEOAS as much as possible in my daily work. It is a good way to think about state, state transitions and what capabilities a client must have. That's the actual part of the author's motivation. It provides the "in-house development" with paradigms how to make changes.
It sounds like there is one client and multiple servers, so I assumed that it would be easier to change the single client versus multiple servers. I guess it also depends on what the in-house developers are experienced with.
But I'm not so sure that it really minimises future work. Like if they decided they want a button that toggles both the sound and lights in a room, that's trivially implemented on the client. Or if they want to reposition a button from the top of a stack to the bottom. My assumption rests on the idea that changing the client is easier though.
I agree.
If I understand correctly the hard parts are the limited resources of the controllers and a need for high versatility for the rooms. Actually needing to update the controllers to update CSS for the main app is kind of crazy.
With my limited understanding of the system it feels like my go to solution would be: - A thin generic program on the controller that run a arbitrary configuration of room logic. - A main client program that can: 1. manage the state of the current configuration. 2. push / switch configurations on the controllers.
That is pretty much what I do, although my "thin generic program" is still very beta.
I follow the narrow waist principle, and basically have all communication in the form of setting and subscribing to "tag points", plus getting their metadata.
The controllers have some ability to run logic, in the form of web editable "If you are in this state, every frame, set this variable to this expression", and they have a generic UI to set and view all the variables.
But I don't have any legacy controllers to deal with, just ESP32s.
If I do run into legacy stuff, I just leave it alone, my main controller lets you write plugins that make whatever device you want appear as one of these tag point based devices, so I keep as much of the flexibility as possible in nice version controllable python.
I just use Webdis for my haunts/rooms.
can't tell if this is supposed to be a joke
"Haunted house" themed halloween amusement area, I assume from skimming the article
Never thought about a haunted houses tech stack!
I have spent over ten years (Mostly a few hours a week or less, it's pretty much done except when I want a new feature) developing a haunted house and room escape tech stack...
It's mostly the same as general home automation, except with a lot more need for audio, digital signage, DMX lighting, and media features.
And things have to be reliable on a budget. A raspi on an SD card is what you get, anything more takes away from much more important things.
Plus, live programmability, observability and diagnostics, and things like that are critical. Stuff might go wrong and you only have five minutes to fix it. This might involve actually changing game logic. It shouldn't, but it might anyway.
If you can't, you need to at least be able to take manual override control.
And you have to be able to show others how to use it extremely quickly, possibly over the phone.
Nobody dies if it goes wrong, so you can afford more complexity than industrial SCADA, but you still want much higher reliability than people expect from consumer tech.
There's a lot of automated testing, and thinking about edge cases, but not as much low level first principles work, although the firmware on remote embedded controllers has a bit more of that.
You can live with the 99.9999% (or whatever the case may be, I highly doubt anyone has real numbers for a lot of this stuff) reliability of an average complex framework, but something that can't handle a USB getting unplugged and replugged in a different port is unacceptable.
https://github.com/EternityForest/KaithemAutomation/tree/mas...