Software Developer | Building https://xitter.gq/t.co/duRrXcgOIX | Wetech AI Vibecoding Hackathon 2026 - 2nd Runner-Up
Unknown
Joined July 2017
- Tweets2.1K
- Following1.6K
- Followers248
- Likes896
brainarena.study
BrainArena turns any topic, selected category or your own notes into a quiz battle in seconds, so studying for exams, prepping for interviews or just testing what you know becomes a game you'll actually want to play with your friends.
BrainArena now have a feature, you can now generate quizzes based on the selected category . 😎🚀🚀🚀🥳🥳
Compete with family and friends on BrainArena.
Think you can outsmart everyone 😏? There's only one way to find out 😂
Hi guys, I built BrainArena.
BrainArena is a platform for building critical thinking, reasoning, problem-solving, and cognitive skills through engaging challenges and multiplayer competitions.
You can play with family or friends 😊.
there’s a game building “pandemic” on the TL and I refuse to be left behind😂
I’ve always loved Family Feud, so I built my own something based on that: Crowd Said.
and you can even play solo.
crowd-said.vercel.app/
btw, @druids01 what a guy👑
Hi guys, I've been building in silent and I'm so glad to show you what I've been building because it's now LIVE 🤩🤩.
I've always noticed that people learn faster when it feels like play, and studies of game-bases learning back this up.
Turn studying into fun with brainarena.study. Share invite code with friends or Whatsapp group and have fun.
I wanted the game to be the practice and added competition because nothing makes people try harder than wanting to beat their friends 😂😂😂.
All work and no play makes Jack a dull boy.
Project cleanup has a funny way of exposing things you thought you had already finished. 😂
While reviewing and cleaning up Sentinel, I discovered something important:
I had only implemented two detection rules so far:
- No-hardcoded URL
- Missing error handler when working with APIs
And I had completely skipped the API contract mismatch detection.
So I had another conversation with myself. 😂
One question kept coming up:
What happens when the frontend and backend are in completely separate repositories?
Not every project is a monorepo.
Some teams have a frontend repository and a backend repository hosted separately. So how would Sentinel know that the frontend's request body doesn't match what the backend expects?
I started thinking about all the possible ways to solve it and honestly, I could have spent a lot of time trying to solve every possible scenario before even launching.
Then I told myself:
Why don't I start with what I know? 😂
For the first version, I've decided to work with the assumption that either:
The project is a monorepo, or the OpenAPI specification is available within the frontend repository.
I know there is still a lot to consider.
What if the OpenAPI specification is hosted somewhere else?
What if it's a .yaml file instead of .json?
What if the frontend and backend contracts are maintained in completely different systems?
Those are problems I'll have to think about as Sentinel evolves.
But for now, I'm taking the baby step.
Sentinel will improve as the project grows. 😂
I'm really excited about the first three rules I'm launching with:
- No-hardcoded URL: Detects URLs written directly as literal strings in the code instead of coming from a configuration value.
- Missing error handler: Checks whether an API call has appropriate error handling such as try/catch or .catch().
- API contract mismatch: Checks whether the frontend request contract matches the backend API contract.
And today, I made a lot of progress on that third rule.
I worked on:
- Request body shape diffing
- Path pattern matching
- OpenAPI specification parsing
- Wiring everything into the CLI
I also got my README.md and CONTRIBUTING.md up to date, and I've published the npm packages - the CLI and core package.
Tomorrow, I'll be testing the packages before making Sentinel publicly available for developers to use and test.
At this point, I'm honestly excited to see what happens when other developers start using it.
Find issues before they reach production.
I want developers to use Sentinel, break it, tell me what's wrong, suggest improvements, contribute to it, and hopefully even drop a ⭐.
This project stressed me. 😂😂😂, I won't lie.
But I've enjoyed almost every bit of the process.
Sentinel isn't perfect.
This first version won't solve every API contract problem but it's a start.
And I'm really looking forward to seeing where it goes.
I've worked on AST traversal in Sentinel, and honestly, this was one of the parts I had to slow down and really understand.
At first, I was getting confused about the difference between an AST and AST traversal.
My initial understanding was that AST traversal was basically the order in which nodes are searched when the source code is converted into an AST during parsing.
I wasn't completely satisfied with that explanation, so I decided to challenge my understanding and asked AI if I was right.
The response was basically: "You're close 😂, but there's an important distinction."
And that distinction made everything click.
Parsing decides the structure of the code.
Traversal happens after the AST already exists. It is the systematic process of visiting the nodes in that tree according to a particular order or strategy.
So I created a simple mental model for myself:
The AST is the museum.
Traversal is the tour guide taking you through the rooms. 😂
Once I sketched it out on paper, everything became much clearer.
And that understanding helped me implement AST traversal in Sentinel.
Other progress on Sentinel:
- Implemented AST traversal
- Implemented the API extractor
- Implemented the reporting system
- Reviewed and improved error handling
- Tested file parsing and inspected the generated AST output
- Verified that the parser is behaving as expected
I'm genuinely excited about how this project is coming together.
The next step is project cleanup. It probably won't be 100% perfect, but I think it's important to take a step back, review what I've built so far, and clean things up before moving forward.
After that, I'll be updating the documentation to make Sentinel easier for developers to understand and contribute to.
This part is particularly important to me because I'm also an open-source contributor, and honestly, one thing I really dislike when I find a project I'm interested in contributing to is bad documentation.
If I have to spend more time figuring out how a project works than actually contributing to it, that's a problem. 😂
So I want Sentinel's documentation to make it as easy as possible for someone to:
- Understand what the project does
- Set it up locally
- Understand the architecture
- Make their first contribution
- Know where they can help
I'm getting closer to releasing Sentinel, and I'm really looking forward to getting feedback from other developers and, hopefully, seeing people contribute to the project.
One step at a time. 🚀
I've worked on AST traversal in Sentinel, and honestly, this was one of the parts I had to slow down and really understand.
At first, I was getting confused about the difference between an AST and AST traversal.
My initial understanding was that AST traversal was basically the order in which nodes are searched when the source code is converted into an AST during parsing.
I wasn't completely satisfied with that explanation, so I decided to challenge my understanding and asked AI if I was right.
The response was basically: "You're close 😂, but there's an important distinction."
And that distinction made everything click.
Parsing decides the structure of the code.
Traversal happens after the AST already exists. It is the systematic process of visiting the nodes in that tree according to a particular order or strategy.
So I created a simple mental model for myself:
The AST is the museum.
Traversal is the tour guide taking you through the rooms. 😂
Once I sketched it out on paper, everything became much clearer.
And that understanding helped me implement AST traversal in Sentinel.
Other progress on Sentinel:
- Implemented AST traversal
- Implemented the API extractor
- Implemented the reporting system
- Reviewed and improved error handling
- Tested file parsing and inspected the generated AST output
- Verified that the parser is behaving as expected
I'm genuinely excited about how this project is coming together.
The next step is project cleanup. It probably won't be 100% perfect, but I think it's important to take a step back, review what I've built so far, and clean things up before moving forward.
After that, I'll be updating the documentation to make Sentinel easier for developers to understand and contribute to.
This part is particularly important to me because I'm also an open-source contributor, and honestly, one thing I really dislike when I find a project I'm interested in contributing to is bad documentation.
If I have to spend more time figuring out how a project works than actually contributing to it, that's a problem. 😂
So I want Sentinel's documentation to make it as easy as possible for someone to:
- Understand what the project does
- Set it up locally
- Understand the architecture
- Make their first contribution
- Know where they can help
I'm getting closer to releasing Sentinel, and I'm really looking forward to getting feedback from other developers and, hopefully, seeing people contribute to the project.
One step at a time. 🚀
I haven't been able to work on or post updates about Sentinel recently because a few things disrupted my workflow. I'm back on it now, and one thing this project has done is take me back to my Compiler Construction course in university.
I majored in Computer Science, and while we focused mostly on the theory back then, I'm finally getting to put those concepts into practice.
Surprisingly, I still remember terms like lexing (tokenization) and parsing, and they're making a lot more sense now than they did in class.
A lexer scans source code from left to right and converts characters into tokens. A parser then takes those tokens, applies grammar rules, and builds an Abstract Syntax Tree (AST).
One rule that really helped me understand ASTs is:
Expressions become subtrees, while statements become siblings within a block.
I already had a basic understanding of ASTs, but I decided to slow down and learn them properly because I believe they're the foundation of Sentinel. I spent time reading more about them and experimenting with astexplorer.net, which lets you visualize how your code is transformed into an AST.
To test myself, I wrote a few simple snippets of code, predicted what the tree would look like, and then checked my answers in AST Explorer. It's been one of the most enjoyable parts of building this project, and I'm genuinely proud of how much clearer these concepts have become.
Progress so far on Sentinel:
- Built the CLI framework
- Implemented the file scanner
- Created the necessary configuration files
- Added a CONTRIBUTING[dot]md (Sentinel will be open source, and I'll keep improving it as the project grows)
- Successfully parsing source files
Next up:
- AST traversal
- API extraction
- Reporting system
- Project review and cleanup
- More testing
- Improved error handling
#buildinpublic #opensource #typescript #compiler #ast #developertools #softwareengineering
