Open comments for this post
Devlog 3 — Persistence and Control (File-based History + Clear Command)
What I learned:
- Why CLI programs reset completely every time they are executed
- How to use the
fs module to write and read files in Node.js
- How
appendFileSync can be used to store data incrementally
- How to read stored data using
readFileSync
- The difference between in-memory state and persistent state
- How small bugs (like variable naming or extra trims) can break logic in subtle ways
- Why validation, execution and side effects (like saving history) should stay separated
Biggest struggle:
This part was less chaotic than Day 2 but still frustrating in a different way.
The logic itself wasn’t the problem this time. It was understanding how programs behave over time. I had already built a history system before so seeing it disappear every run was confusing at first.
Then came the file system part. Writing to a file felt simple but reading it back properly and formatting it without breaking things took more effort than expected. Small mistakes like misnaming variables or structuring loops incorrectly kept causing issues.
It wasn’t overwhelming chaos but more like constant small friction that slowed everything down.
Current features:
- Persistent history system using
fs
- Calculations are stored in
history.txt across runs
-
history command displays formatted past calculations
-
clear command wipes stored history clean
- Improved validation and error messages
- Clean separation between parsing, validation and execution
Next steps:
- Convert the calculator into an interactive CLI (REPL-style)
- Reduce repeated validation logic into reusable helpers
- Improve overall UX (cleaner outputs and command feedback)
Reflection:
The biggest realization was understanding that programs don’t remember anything unless you explicitly store it. That changed how I think about state completely.
Compared to earlier struggles, this one felt quieter but still tiring. Less confusion, more persistence. Fixing small issues, understanding behavior and slowly making things more stable.
It still isn’t perfect but it finally feels like the calculator has some sense of continuity instead of resetting every time.
Note: The screenshot does not show all features (full validation system).
Open comments for this post
Devlog 1 — Building SlackyssaLiu (Slack Bot)
What I set out to build:
Create a simple Slack bot that can respond to slash commands in real time and make interactions inside a workspace more dynamic and useful.
How I approached it:
I started by following Stardance’s mission guide to understand how Slack apps connect to a backend and handle real-time events.
After setting up the base bot with Socket Mode and environment variables, I focused on implementing slash commands and structuring them in a clean and scalable way.
What I built:
-
A deployed Slack bot running 24/7 with real-time command handling
-
A working Slack bot using Node.js and the Bolt framework
-
Multiple slash commands such as:
-
/skl-ping for latency checking
-
/skl-echo for message reflection
-
/skl-time and /skl-date for utility
-
/skl-help for command discovery
-
API integrations:
- Cat facts using an external API
- Random jokes
- Inspirational quotes
-
Basic error handling for API failures
-
A consistent command-response structure using async functions
Deployment:
The bot is deployed and runs continuously 24/7, allowing it to respond to Slack commands in real time without requiring a local environment.
This helped me understand how to keep services running beyond development and make the bot usable in a live workspace.
What I learned:
- How Slack’s Bolt framework handles commands and events
- The importance of
ack() in Slack interactions
- How to structure asynchronous command handlers
- How to integrate external APIs into a Node.js application
- How to handle failures gracefully using try-catch
Challenges I faced:
- Understanding how Slack’s command lifecycle works
- Managing async responses correctly without breaking Slack’s timing requirements
- Debugging API responses and ensuring consistent formatting
What I improved beyond the mission guide:
While the initial setup followed Stardance’s mission guide, I expanded the bot by adding multiple custom commands and integrating external APIs to make it more interactive and useful.
Future improvements:
- Add command history or logging
- Introduce smarter responses or context awareness
- Improve response formatting for better readability
- Expand the command set with more utility features
Final thoughts:
This project helped me understand how real-time systems work and how to build something that interacts with users in a live environment. It started with guided steps and evolved into a customizable and extendable Slack bot.
Open comments for this post
Devlog 2 — CLI Calculator Upgrade (Validation + History System)
What I set out to build:
Upgrade the CLI calculator into something more structured and “real tool-like” by adding proper input validation improving command handling and introducing a history system.
What I learned:
- How to structure validation into layers (arity type domain)
- How CLI arguments actually behave — missing inputs simply don’t exist in the array
- How to use
slice() + map(Number) to normalize input in one step
- Why separating parsing validation and execution simplifies reasoning
- How function hoisting allows referencing functions before declaration
- How to maintain in-memory state using arrays
- How
for loops and forEach help format structured output
- How small design choices like a
numbers array simplify architecture
Biggest struggle:
This part was genuinely exhausting.
I kept getting stuck on when validation should happen and what exactly needed to be validated. I was duplicating checks mixing raw CLI arguments with parsed numbers and constantly second-guessing my logic.
I also misunderstood CLI arguments. I expected missing inputs to appear as undefined which made my validation more complicated than necessary.
The worst part was the flow. Everything felt tangled. Command lookup parsing validation execution like it was happening all at once. Even when the code worked I didn’t fully trust it which made the whole process frustrating.
Current features:
- Command routing using a function map (
commands[cmd])
- Argument validation based on expected counts
- Clean input parsing using
slice() and map(Number)
- Domain rules (division by zero negative square roots)
- Scientific operations:
sqrt pow log
- In-memory history system
-
history command for session logs
- Improved help command
- More consistent error handling
Next steps:
- Persist history to a file
- Refactor validation into helper functions
- Improve error messages
Reflection:
This stage felt like a shift from “writing code” to “understanding how programs behave.”
Validation was mentally draining. I kept mixing up arity type and domain rules and the code felt like a pile of checks instead of a system. It worked but I didn’t trust it.
The biggest reality check was the history system. I built it saw it work then ran another command and everything was gone. That’s when it clicked. CLI programs don’t persist memory. Every run starts fresh.
That was the most important lesson. Not everything you build “stays” unless you store it. It changed how I think about programs.
By the end the calculator is still simple but my understanding of structure and flow is much stronger. It feels less like guessing and more like knowing what I’m doing.
Note: The screenshot only shows a basic run and does not include all implemented features (validation command handling improvements and history tracking).
Open comments for this post
Devlog 1 — Building a CLI Calculator
What I set out to build :
A command-based CLI calculator using Node.js that can take input directly from the terminal and perform operations like addition, subtraction multiplication and division.
What I learned:
-
How process.argv works for handling command-line input
-
Why "5" + "3" results in "53" (strings vs numbers in JavaScript)
-
How to convert inputs properly using Number()
-
The difference between calling a function and referencing it
-
How to implement a command map using commands[cmd]()
Biggest struggle:
Understanding how to structure the command system cleanly without relying on long and messy if/else chains.
Breakthrough moment:
Realizing that I could store functions inside an object and dynamically execute them based on user input. That made the whole system feel much cleaner and scalable.
Current features:
- Supports
add, sub, mul and div commands
- Handles invalid commands with basic error messaging
- Uses a command map for cleaner execution logic
Next steps:
- Add scientific functions like
sqrt, pow, and log
- Improve input validation
- Potentially add a history system
Reflection:
Started this knowing almost nothing about CLI tools or Node.js input handling and ended up building a working command-based system. It’s simple but it actually feels like the foundation of something bigger.
