You are browsing as a guest. Sign up (or log in) to start making projects!

rylvion

@rylvion

Joined June 2nd, 2026

  • 6Devlogs
  • 3Projects
  • 1Ships
  • 13Votes
no
.
Open comments for this post

7h 6m 16s logged

Devlog 5 - manifest workflow

time logged: 7hrs 6min 16 sec
date: 21/07/2026



ok so i kinda lied in the last devlog. this ended up being another major architectural change to slackzilla. the slack manifest system was always the most brittle part of the pipeline and manually maintaining manifest.json was a guaranteed way to let things drift. today i finally automated the entire manifest workflow. the new setup makes commands.json and meta.js the single source of truth. i wrote a manifest generator that loads all metadata like descriptions colours oauth scopes bot info and merges it with the command definitions to build a complete slack manifest object. once assembled it writes manifest.json and syncs it during deployment. validation is baked directly into the generator. i wired AJV into both stages. every command is validated against command.schema.json and the final manifest is validated again against slack’s official schema. if anything fails the generator stops immediately with a clear error instead of producing a broken file. this caught several issues especially after i moved all schemas into a dedicated schemas/ directory to clean up the project structure.


the github actions workflow also got a major overhaul. every push now generates the manifest validates commands and manifest rotates the slack configuration token updates github secrets syncs the manifest through the slack api and deploys the bot. changing a slash command in commands.json now updates both the bot and the slack app config automatically. no more manual edits to manifest.json or the slack app settings. the entire pipeline is now self maintaining and fully automated. token rotation was the biggest pain. slack configuration tokens only last twelve hours so storing them in github secrets was not enough. i created a fine grained github PAT with permission to modify repo secrets and wrote rotateManifestToken.js to handle the full refresh cycle. it rotates the manifest token receives a new refresh token and updates both secrets so the next deployment does not break.


i spent way too long debugging an invalid_refresh_token error. note that slack’s copy button does not copy the existing refresh token it generates a new pair. every time i clicked it the previously saved token became invalid instantly. once i realised that i started updating github secrets immediately after copying the new pair so everything stayed in sync. after that the rotated token still was not being passed correctly between github actions steps. i switched to GITHUB_OUTPUT so the rotation step could hand the new token to the manifest sync step. then slack started returning not_authed which led to another rabbit hole. the manifest update endpoint requires the token in the correct auth header not the request body. once i fixed the request format the entire pipeline finally ran clean end to end. See figure 2 for github actions workflow


TL;DR slackzilla now auto generates its slack manifest validates everything with AJV rotates configuration tokens syncs the manifest during deployment and updates the bot server with minimal manual work. after a lot of debugging around token rotation schema mismatches and github actions quirks the deployment pipeline is basically self maintaining except refreshing the github PAT every ninety days.

0
0
5
Open comments for this post

2h 20m 42s logged

Devlog 4: calc and roll commands

time logged: 2 hr 20 minutes
date: 17/07/2026



today i spent some time reading the Java Shunting Yard Algorithm implementation on GeeksforGeeks. The example focuses entirely on converting an infix expression into postfix form. It scans the expression character by character, places operands directly into the output string, and uses a stack to manage operators based on precedence and associativity. Once the scan is complete, any remaining operators are appended to produce a postfix expression like 5238-52^^/+. The Java version supports operators including +, -, *, /, and ^, and it handles parentheses, but it stops after producing the postfix representation. It does not evaluate the numerical result.


after reading that, i wanted something more complete for Slackzilla. I used the same core idea of converting infix to postfix, but I extended it in several ways. My implementation tokenises the input instead of reading one character at a time, which allows it to support multi digit numbers and decimals. I added unary minus detection so expressions like -3 or 5*-2 behave correctly. One challenge was distinguishing unary minus from subtraction. The parser has to determine whether it starts with a number or subtracts two values depending on the previous token. I kept exponentiation with the correct right associativity. Once the postfix array is built, I added a second stage that evaluates the postfix expression using a number stack. This lets the function return the final computed value rather than just the postfix notation. The result is a more flexible and practical version of the algorithm that fits naturally into Slackzilla and can evaluate real expressions interactively.


after finishing the calculator command, I also added another command to Slackzilla called /sz-roll. This command allows users to simulate dice rolls directly inside Slack. It supports normal dice notation like d6, custom dice sizes like d20, multiple dice such as 2d6, and modifiers like 2d20+5. I added parsing logic to split the dice expression into the amount of dice, number of sides, and any modifier before rolling each dice individually and calculating the final total.


I also added a /sz-roll help and /sz-calc help command which explains how to use the command and shows examples of supported formats.


also i spent A LOT of time making the flowchart to describe this more than the implementation itself. I think it will be useful for future reference and for anyone else who wants to understand how the algorithm works.


i also added json schema validation for commands.json as talked in devlog 2 the commands.json is the source of truth, so i addded a validator.yml to validate the json schema of commands.json and make sure it is valid before a pull request is merged. This will help prevent errors and ensure that the commands are correctly defined.


TL;DR: added a calculator using the Shunting Yard algorithm with postfix evaluation, plus a flexible dice rolling command. Also added help commands, a flowchart and automated JSON schema validation.


also ill add way more devlogs from now on since most of my last devlogs were major architecture refactor, unless there is a major change, i will just add a small devlog to add a new command/small feature, fix a bug, improve an existing feature and add more documentation.

0
0
3
Open comments for this post

6h 1m 24s logged

Devlog 3 - github actions webhook request (13/07/2026)

time logged: 6hr 01min

i added a webhook dispatcher that automatically triggers a deployment whenever i commit to the main branch. Instead of manually pulling changes on the server and restarting the service myself, the GitHub Action now sends a signed webhook to my deployment server, which verifies it and runs the deploy script for me.

i also added 2 more commands

  • /sz-meme - this makes a meme
  • /sz-echo [str] - this echoes the string

you can see the flowchart below and see the full devlog 3 here (hyperlinked)

TL;DR whenever i commit the server automatically receives it and slackzilla updates to the latest version

0
0
3
Open comments for this post

10h 59m 57s logged

Devlog 2 - server setup & modular command system & more [03/07/2026]

time logged: 10hr 59 min
so since the last devlog, i’ve have worked on LOADS of things including behind the scene (this doesnt get tracked on hacaktime :( ), i dont even know if this will hit the char limit, but anyways, here are the logs
EDIT: IT DID HIT THE CHAR LIMIT, turns out the original devlog was ~9.6k characters đź’€ while the limit is only 4k, so this is the shortened version. the full one is still in priv/devlogs/devlog2.md if anyone wants the extended edition.z

Commits logs

e47c48ac0970b49015e920607a59657259122f2f - made the cur proj into more modular featuring dynamic command loading system w commands.json as the source of truth

on this, i figured out that packing every single thing into one file is a bad idea, so i made a modular command system that loads commands dynamically from a commands.json file, this way, i can add new commands without having to touch the main bot.js file, and also, it makes it easier to manage commands since they are all in one place

03b07ffc6f44d0231f9073f637caee1f9437705a) - added more detailed server logging with time & user at the start of most console logs onto terminal [coloured output]

this was way more of a pain than i thought it was gonna be. after countless rounds of testing i finally got it working how i wanted. the ansi colours kept either leaking into the rest of the terminal or resetting back to the default colour when i needed them to go back to the current log level. i was genuinely losing my mind because every “fix” just broke something else. after hours of messing around i ended up making a wrapper so instead of resetting after things like the username or command, it switches back to whatever the current log level colour is (info, success or error), then only resets once right at the end of the log. it took way longer than it should’ve and nearly made me give up, but it finally does exactly what i wanted and nothing leaks anymore.added src/utils/logger.js and switched almost every console.log over to it. it adds timestamps, users, commands and coloured log levels.and changed all the console logs in src/bot.js and src/cmds/ to use the new logger api

b81c739cc06edba2895695e51dbbf88d8868f19f - overhauled readme

well as the name implies its pretty self explanatory lol but i massively expanded the README with better documentation and setup instructions.

Server setup

find more info in the setup guide on Step 7 out of 8 in https://stardance.hackclub.com/missions/slack-bot/guide#step-7

i had to apply for a Nest server and get SSH access.yeah so basically my starting gear is a potato server (2GB RAM, 16GB storage) but that’s more than enough for this bot. i also got to mess around with linux for a bit (yes i am a windows user). honestly… i kinda liked it and i’m like 80% convinced i’ll switch one day (but too much of a hassle to switch rn, but maybe in the future).

after installing everything, setting up the environment variables and creating a systemd service, i finally got the bot running 24/7.TL;DR: i got the bot running 24/7 in the server and it works perfectly fine, and i can now add new commands without having to touch the main bot.js file, and also, and added detailed server logging with time & user

aight y’all i spent an ENTIRE HOUR writing this devlog and THEN i had to rewrite a shortened down version, y’all better rate me 9/9 for story telling, rylvion signing out 🫡 pls see my full devlog version

1
0
1
Ship Changes requested

i created a web app for Unit 15: Website Development as part of my coursework, hosted on GitHub Pages, with multiple pages and a 4-step booking flow. a major challenge was working under time constraints while fixing bugs, improving the website, documenting, writing up the report and way way more than i expected. I am most proud of the booking system, advanced GitHub Actions, and achieving 90+ on PageSpeed Insights. To test the project, users should explore different pages and try the full booking flow (bookings tab) on both mobile and desktop. also there is 1 devlog and im shipping it rn to gather end user feedback for the next stage of u15 (review + refinement + documenting + bug fixing + more )

  • 1 devlog
  • 31h
Try project → See source code →
Open comments for this post

30h 43m 24s logged

devlog 1 (posting out of depression) - 15/06/2026
i knows what you guys are saying HOW COME this random nob got 30 hours of work without a single devlog, here me out its pretty simple, I DIDNT HAVE EOUGH TIME $#$~~$ đź’€

okay back to topic i had to create a website for Unit 15: Website Development, and honestly… I DID LOADS of works wItHoUt TiMe tO dEvLoG.

like, way more than I expected.

most of my time went into building the website, fixing random issues, redesigning things that looked terrible, then redesigning them again because somehow they looked even worse the first time.

okay heres features

  • booking flow (4 steps process)
  • home/pricing/loads of other pages
  • rlly advanced github actions (nerdy)
  • more stuff that i cant remember

BUT through “failure comes success” I GOT 90+ pagespeeed ingishts.

anyways wireframes here https://app.moqups.com/7pztHxaFX9Yz5oI0v58osy9wUSSnmtnt/view/page/aaef4bdbf

0
0
2
Open comments for this post

1h 48m 54s logged

slackzilla

after countless testing of figuring out why my bot isnt working, i found out the reason… well sort of… it seems so that the bot doesnt read my messages nad only respond to app commands idk how to make it respond to my messages if it not a cmd but anyways here are the logs

7be9077de2a487f7be8a779123420295dc9bff7e - add MIT license
9ceb9c2fe638f91ab6b0a14326437c9a5f32f499 - add initial bot setup (just for testing!]
66eb775434c871f063fd57daf0bdfc7bd66501f1 - add launch.json, .env.example (like formats), README.md, add stuff to bot.js

btw this isnt hosted (will host soon) or anything and to use it you have to use the cmd prefix (sc-) e.g., /sz-ping

0
0
3

Followers

Loading…