24stats devlog one!!1!!!!1!!!!

bg info

basically, if you know volanta, it’s like volanta except for ATC24. aka, some nerdy plane stuff

but what is ATC24 you might ask? good question, it’s basically vatsim (though everyone who does ATC24 adamantly stresses that it is much less strict than vatsim) for a roblox game called PTFS (Pilot Training Flight Simulator)

ATC24 provides a set of APIs (known as 24Data) which many community applications like zedruc’s 24scope, among plenty (and i mean plenty) of other apps use to integrate into the game

technically, a 24stats already exists but it doesn’t actually work since their cloudflare is broken. might have to end up renaming it BUT!!! ANYWAYS!!! here we go!

stack/structure

24stats uses RoR (Ruby on Rails) throughout, and database wise runs on postgres. it uses discord OAuth to authenticate users.

authentication

for authentication, a session token is issued along with a remember me token which users will receive should they select the “Remember Me” button

for the session token, it’s created using the user id and the built in session[] method (which, if you don’t know, basically takes it then encrypts it and sends it off to the frontend)

the remember me token is first randomly generated using SecureRandom.hex(16), generating a 16 byte random hex string. this is then hashed, which we store on the server, and then send the original hex string to the frontend as a cookie. currently, this actually only allows one user at a time, but there is a commit staged which isn’t pushed that switches find_or_create_by into find_or_initialize_by in order to allow multiple user sessions to exist

what i worked on for the first 10 hours

okay, firstly: the landing page

it’s nothing too complex, probably took ~2-3 hours (not inclusive of figma time) to build it out

what was more complex was figuring out session handling, especially as i have basically never used RoR before this.

disclaimer: due to the probable insane amount of bugs i’d have, and given RoR is completely new to me, some session handling code was AI-assisted, as well as parts of the underlying model.

second disclaimer: some design choices were ran through by AI, but if not otherwise stated, were implemented by myself.

my first run at session handling failed spectacularly thanks to the fact that apparently omniauth-discord doesn’t return username in nickname as omniauth’s hash format says it should, which is…unfortunate. (also the code i wrote was just a buggy mess in general and i hadn’t figured out :before_action existed yet)

the second go around was better, and included remember_me tokens, though they were still broken at this stage

the third, uncommited go around, fixes most of the bugs that exist in the session stuff. sessions probably took up a majority of my time (that being 10 hours so far)

finally, onboarding! onboarding actually works, some of the code was AI-assisted , but mostly for bug checking, as the core loop actually worked fine at the beginning (and then i added more stuff and it became more complicated so)

anyways, looking ahead, heres what i’m planning to do:

implementing an actual heartbeat model for flights (similar to how hackatime might do it)
figuring out how to store overall statistics and where to do it
figuring out rolling data deletion, which may include timescaledb by the looks of it
actually implementing the dashboard so theres somewhere to redirect to after onboarding and it doesn’t explode
writing more tests
figuring out how to do a 3d map
playing more ATC24 for ~~fun~~ data

that’s it for this one, see y’all in the next devlog